> This seems at odds with the goal of "if the remote party force closes,
then
> I get my funds back immediately without requiring knowledge of any secret
> data"
Scratch that: the static back ups just need to include this CSV value!
-- Laolu
On Tue, Nov 6, 2018 at 3:29 PM Olaoluwa Osuntokun wr
Olaoluwa Osuntokun writes:
> Hi Rusty,
>
> I'm a big fan in general of most of this! Amongst many other things, it'll:
> simplify the whole static channel backup + recovery workflow, and avoid all
> the fee related headaches we've run into over the past few months.
I certainly hope so!
>> - HTLC
Hi Rusty,
I'm a big fan in general of most of this! Amongst many other things, it'll:
simplify the whole static channel backup + recovery workflow, and avoid all
the fee related headaches we've run into over the past few months.
> - HTLC-timeout and HTLC-success txs sigs are
> SIGHASH_ANYONECANPA
Jim Posen writes:
> Instead of leaving an extra output for CPFP, is it not sufficient to just
> sign all inputs with ANYONECANPAY and expect the sender to make an exact
> output for the fees input? It would require an extra tx assuming they don't
> already have a properly sized UTXO handy (which t
Instead of leaving an extra output for CPFP, is it not sufficient to just
sign all inputs with ANYONECANPAY and expect the sender to make an exact
output for the fees input? It would require an extra tx assuming they don't
already have a properly sized UTXO handy (which they may!), but I believe
CP
Good morning everyone,
> We could also use SIGHASH_ANYONECANPAY|SIGHASH_SINGLE
> for HTLC txs, without adding the "OP_TRUE"
> output to the commitment transaction
Doesn’t this require a non-zero number of HTLCs on the commitment txn? We
would still require the OP_TRUE if there are no HTLCs, right
Fabrice Drouin writes:
> Hello,
>
>> 1. Rather than trying to agree on what fees will be in the future, we
> > should use an OP_TRUE-style output to allow CPFP (Roasbeef)
>
> We could also use SIGHASH_ANYONECANPAY|SIGHASH_SINGLE for HTLC txs, without
> adding the "OP_TRUE" output to the comm
Hello,
> 1. Rather than trying to agree on what fees will be in the future, we
> should use an OP_TRUE-style output to allow CPFP (Roasbeef)
We could also use SIGHASH_ANYONECANPAY|SIGHASH_SINGLE for HTLC txs, without
adding the "OP_TRUE" output to the commitment transaction. We would still
ZmnSCPxj writes:
> Sent with ProtonMail Secure Email.
>
> ‐‐‐ Original Message ‐‐‐
> On Friday, October 12, 2018 2:36 PM, Rusty Russell
> wrote:
>
>> ZmnSCPxj zmnsc...@protonmail.com writes:
>>
>> > Good morning Rusty and list,
>> >
>> > > 1. Rather than trying to agree on what fees wil
Sent with ProtonMail Secure Email.
‐‐‐ Original Message ‐‐‐
On Friday, October 12, 2018 2:36 PM, Rusty Russell
wrote:
> ZmnSCPxj zmnsc...@protonmail.com writes:
>
> > Good morning Rusty and list,
> >
> > > 1. Rather than trying to agree on what fees will be in the future, we
> > >
ZmnSCPxj writes:
> Good morning Rusty and list,
>
>>
>> 1. Rather than trying to agree on what fees will be in the future, we
>> should use an OP_TRUE-style output to allow CPFP (Roasbeef)
>>
>
> My understanding is that this would require some base-layer changes at
> Bitcoin level first? A
Good morning Rusty and list,
>
> 1. Rather than trying to agree on what fees will be in the future, we
> should use an OP_TRUE-style output to allow CPFP (Roasbeef)
>
My understanding is that this would require some base-layer changes at Bitcoin
level first? At minimum IsStandard() modific
12 matches
Mail list logo
