Re: [Lightning-dev] More thoughts on NOINPUT safety

2019-03-22 Thread ZmnSCPxj via Lightning-dev
Good morning aj, I understand. Looks like that makes sense. It seems possible to use this, then, together with watchtowers. Regards, ZmnSCPxj Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Friday, March 22, 2019 10:58 AM, Anthony Towns wrote: > On Fri, Mar 22, 2019

Re: [Lightning-dev] More thoughts on NOINPUT safety

2019-03-21 Thread Anthony Towns
On Fri, Mar 22, 2019 at 01:59:14AM +, ZmnSCPxj wrote: > > If codeseparator is too scary, you could probably also just always > > require the locktime (ie for settlmenet txs as well as update txs), ie: > > OP_CHECKLOCKTIMEVERIFY OP_DROP > > OP_CHECKDLSVERIFY OP_CHECKDLS > > and have update

Re: [Lightning-dev] More thoughts on NOINPUT safety

2019-03-21 Thread ZmnSCPxj via Lightning-dev
Good morning aj, > > If you are committing to the script code, though, then each settlement > sig is already only usable with the corresponding update tx, so you > don't need to roll the keys. But you do need to make it so that the > update sig requires the CLTV; one way to do that is using

Re: [Lightning-dev] More thoughts on NOINPUT safety

2019-03-21 Thread Anthony Towns
On Thu, Mar 21, 2019 at 10:05:09AM +, ZmnSCPxj wrote: > > IF OP_CODESEPARATOR OP_CHECKLOCKTIMEVERIFY OP_DROP ENDIF > > OP_CHECKDLSVERIFY OP_CHECKDLS > > Signing with NOINPUT,NOSCRIPT and codeseparatorpos=1 enforces CLTV > > and allows binding to any prior update tx -- so works for an update

Re: [Lightning-dev] More thoughts on NOINPUT safety

2019-03-21 Thread ZmnSCPxj via Lightning-dev
Good morning aj, > > Then each update transaction pays out to: > > OP_IF > > OP_CSV OP_DROP > > OP_CHECKSIGVERIFY OP_CHECKSIG > > OP_ELSE > > OP_CHECKLOCKTIMEVERIFY OP_DROP > > OP_CHECKSIGVERIFY OP_CHECKSIG > > OP_ENDIF > > Yeah. > > I think we could potentially make that shorter still: > >

Re: [Lightning-dev] More thoughts on NOINPUT safety

2019-03-21 Thread Anthony Towns
On Wed, Mar 20, 2019 at 08:07:00AM +, ZmnSCPxj via Lightning-dev wrote: > Re-reading again, I think perhaps I was massively confused by this: > > that commits to the input. In that case, you could do eltoo with a > > script like either: > > CHECKSIGVERIFY CHECKSIG > > or CHECKSIGVERIFY

Re: [Lightning-dev] More thoughts on NOINPUT safety

2019-03-20 Thread ZmnSCPxj via Lightning-dev
Hi aj, Re-reading again, I think perhaps I was massively confused by this: > - alternatively, we could require every script to have a valid signature > that commits to the input. In that case, you could do eltoo with a > script like either: > > CHECKSIGVERIFY CHECKSIG > or CHECKSIGVERIFY

Re: [Lightning-dev] More thoughts on NOINPUT safety

2019-03-20 Thread ZmnSCPxj via Lightning-dev
Hi all, > Since "must have a non-SIGHASH_NOINPUT" rule addresses the first reuse > scenario (as well as the second), I'd be content with that proposal. How would this work with watchtowers? As I understand it, the current plan for eltoo watchtowers would be to store both `SIGHASH_NOINPUT`

Re: [Lightning-dev] More thoughts on NOINPUT safety

2019-03-19 Thread Rusty Russell
Sorry AJ, my prior email was not constructive :( I consider the "my software reused my keys" the most reasonable attack scenario, though still small compared to other lightning attack surfaces. But I understand the general wariness of third-parties reusing SIGHASH_NOINPUT signatures. Since

Re: [Lightning-dev] More thoughts on NOINPUT safety

2019-03-19 Thread Rusty Russell
Anthony Towns writes: > If you publish to the blockchain: ... > 4 can be dropped, state 5 and finish can be altered). Since the CSV delay > is chosen by the participants, the above is still a possible scenario > in eltoo, though, and it means there's some risk for someone accepting > bitcoins

Re: [Lightning-dev] More thoughts on NOINPUT safety

2019-03-18 Thread Anthony Towns
On Thu, Mar 14, 2019 at 01:00:56PM +0100, Christian Decker wrote: > Anthony Towns writes: > > I'm thinking of tagged outputs as "taproot plus" (ie, plus noinput), > > so if you used a tagged output, you could do everything normal taproot > > address could, but also do noinput sigs for them. > >

Re: [Lightning-dev] More thoughts on NOINPUT safety

2019-03-14 Thread Christian Decker
Anthony Towns writes: > I'm thinking of tagged outputs as "taproot plus" (ie, plus noinput), > so if you used a tagged output, you could do everything normal taproot > address could, but also do noinput sigs for them. > > So you might have: > >funding tx -> cooperative claim > >funding tx

Re: [Lightning-dev] More thoughts on NOINPUT safety

2019-03-14 Thread ZmnSCPxj via Lightning-dev
Good morning aj, > > Trying to maximise privacy there has the disadvantage that you have to > do a new signature for every in-flight HTLC every time you update the > state, which could be a lot of signatures for very active channels. If I remember accurately this is already true for current

Re: [Lightning-dev] More thoughts on NOINPUT safety

2019-03-14 Thread Anthony Towns
On Thu, Mar 14, 2019 at 05:22:59AM +, ZmnSCPxj via Lightning-dev wrote: > When reading through your original post I saw you mentioned something about > output tagging somehow conflicting with Taproot, so I assumed Taproot is not > useable in this case. I'm thinking of tagged outputs as

Re: [Lightning-dev] More thoughts on NOINPUT safety

2019-03-13 Thread ZmnSCPxj via Lightning-dev
Good morning aj, When reading through your original post I saw you mentioned something about output tagging somehow conflicting with Taproot, so I assumed Taproot is not useable in this case. However, it is probably more likely that I simply misunderstood what you said, so if you can

Re: [Lightning-dev] More thoughts on NOINPUT safety

2019-03-13 Thread Anthony Towns
On Wed, Mar 13, 2019 at 06:41:47AM +, ZmnSCPxj via Lightning-dev wrote: > > - alternatively, we could require every script to have a valid signature > > that commits to the input. In that case, you could do eltoo with a > > script like either: > > CHECKSIGVERIFY CHECKSIG > >

Re: [Lightning-dev] More thoughts on NOINPUT safety

2019-03-13 Thread ZmnSCPxj via Lightning-dev
Good morning aj, First off, I have little to no idea of the issues at the lower-level Bitcoin. In any case --- > - alternatively, we could require every script to have a valid signature > that commits to the input. In that case, you could do eltoo with a > script like either: > >