> 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
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!
>> -
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
>
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
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
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
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?
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()
