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 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 txs set their timelock; and settlement txs set a absolute
> > > timelock, relative timelock via sequence, and commit to the script code.
> >
> > I think the issue I have here is the lack of `OP_CSV` in the settlement 
> > branch.
>
> You can enforce the relative timelock in the settlement branch simply
> by refusing to sign a settlement tx that doesn't have the timelock set;
> the OP_CSV is redundant.
>
> > Consider a channel with offchain transactions update-1, settlement-1, 
> > update-2, and settlement-2.
> > If update-1 is placed onchain, update-1 is also immediately spendable by 
> > settlement-1.
>
> settlement-1 was signed by you, and when you signed it you ensured that
> nsequence was set as per BIP-68, and NOINPUT sigs commit to nsequence,
> so if anyone changed that after the fact the sig isn't valid. Because
> BIP-68 is enforced by consensus, update-1 isn't immediately spendable
> by settlement-1.
>
> Cheers,
> aj


___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


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 txs set their timelock; and settlement txs set a absolute
> > timelock, relative timelock via sequence, and commit to the script code.
> 
> I think the issue I have here is the lack of `OP_CSV` in the settlement 
> branch.

You can enforce the relative timelock in the settlement branch simply
by refusing to sign a settlement tx that doesn't have the timelock set;
the OP_CSV is redundant.

> Consider a channel with offchain transactions update-1, settlement-1, 
> update-2, and settlement-2.
> If update-1 is placed onchain, update-1 is also immediately spendable by 
> settlement-1.

settlement-1 was signed by you, and when you signed it you ensured that
nsequence was set as per BIP-68, and NOINPUT sigs commit to nsequence,
so if anyone changed that after the fact the sig isn't valid. Because
BIP-68 is enforced by consensus, update-1 isn't immediately spendable
by settlement-1.

Cheers,
aj

___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


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 codeseparator
> to distinguish between the two cases.
>
> > Also, I cannot understand `OP_CODESEPARATOR`, please no.
>
> 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 txs set their timelock; and settlement txs set a absolute
> timelock, relative timelock via sequence, and commit to the script code.
>
> (Note that both those approaches (with and without codesep) assume there's
> some flag that allows you to commit to the scriptcode even though you're
> not committing to your input tx (and possibly not committing to the
> scriptpubkey). BIP118 doesn't have that flexibility, so the A_s_i and
> B_s_i key rolling is necessary)

I think the issue I have here is the lack of `OP_CSV` in the settlement branch.

Consider a channel with offchain transactions update-1, settlement-1, update-2, 
and settlement-2.
If update-1 is placed onchain, update-1 is also immediately spendable by 
settlement-1.
But settlement-1 cannot be spent by update-2 and thus the invalidation of older 
state fails.

The `OP_CSV` in the settlement branch of the update transaction outputs exists 
to allow later update transactions have higher priority over settlement 
transactions.

To ensure that a settlement signature can only take the settlement branch, we 
need a distinct public key for the branch, so at least `A_s` and `B_s` without 
rolling them for each `i`, if we use `nLockTime` on the settlement transactions 
and enforce it with `OP_CHECKLOCKTIMEVERIFY`.
It might be possible to do this with `OP_CODESEPARATOR`, but we do need the 
`OP_CSV` in the settlement branch.

Regards,
ZmnSCPxj
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


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 tx
> > spending previous update txs; while signing with codeseparatorpos=-1
> > and NOINPUT but committing to the script code and nSequence (for the
> > CSV delay) allows binding to only that update tx -- so works for the
> > settlement tx. That's two pubkeys, two sigs, and the taproot point
> > reveal.
> 
> Actually, the shared keys are different in the two branches above.

Yes, if you're not committing to the script code you need the separate
keys as otherwise any settlement transaction could be used with any
update transaction. 

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 codeseparator
to distinguish between the two cases.

> Also, I cannot understand `OP_CODESEPARATOR`, please no.

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 txs set their timelock; and settlement txs set a absolute
timelock, relative timelock via sequence, and commit to the script code.

(Note that both those approaches (with and without codesep) assume there's
some flag that allows you to commit to the scriptcode even though you're
not committing to your input tx (and possibly not committing to the
scriptpubkey). BIP118 doesn't have that flexibility, so the A_s_i and
B_s_i key rolling is necessary)

Cheers,
aj

___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


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:
>
> 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 tx
> spending previous update txs; while signing with codeseparatorpos=-1
> and NOINPUT but committing to the script code and nSequence (for the
> CSV delay) allows binding to only that update tx -- so works for the
> settlement tx. That's two pubkeys, two sigs, and the taproot point
> reveal.


Actually, the shared keys are different in the two branches above.
The "update" branch (which has no `OP_CSV`) uses the same constant `A_u` and 
`B_u` points.
The "state commit" branch (which has `OP_CSV`) uses different `A_si` and `B_si` 
points depending on `i` (state/sequence number).

Also, I cannot understand `OP_CODESEPARATOR`, please no.

Regards,
ZmnSCPxj
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


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  CHECKSIG
> Do you mean that *either* of the above two scripts is OK, *or* do you mean 
> they are alternatives within a single MAST or `OP_IF`?

I meant "either of the two scripts is okay".

> In the blob sent to Watchtower, A (or B) includes the `SIGHASH_NOINPUT` as 
> well as the `q` private key.
> Would it be safe for Watchtower to know that?

I think so. From Alice/Bob's point-of-view, the NOINPUT sig ensures they
control their money; and from the network's point-of-view (or at least
that part of the network that thinks NOINPUT is unsafe) the Q private
key being shared makes the tx no worse than a 1-of-n multisig setup,
which has to be dealt with anyway.

> 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:

   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 tx
spending previous update txs; while signing with codeseparatorpos=-1
and NOINPUT but committing to the script code and nSequence (for the
CSV delay) allows binding to only that update tx -- so works for the
settlement tx. That's two pubkeys, two sigs, and the taproot point
reveal.

Cheers,
aj

___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


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  CHECKSIG
>
>
> where A is Alice's key and B is Bob's key, P is muSig(A,B) and Q is
> a key they both know the private key for. In the first case, Alice
> would give Bob a NOINPUT sig for the tx, and when Bob wanted to publish
> Bob would just do a SIGHASH_ALL sig with his own key. In the second,
> Alice and Bob would share partial NOINPUT sigs of the tx with P, and
> finish that when they wanted to publish.

Do you mean that *either* of the above two scripts is OK, *or* do you mean they 
are alternatives within a single MAST or `OP_IF`?

If you mean that *either* of the above two scripts is OK, then this script:

 CHECKVERIFY  CHECKSIG

should probably be used for Watchtower-compatibility.

When creating a new state, both A and B would cooperatively sign with 
`muSig(A,B)` with a `SIGHASH_NOINPUT` that ensures the state transaction is 
correct.
Then they somehow derive or share the private key to `Q`.

In the blob sent to Watchtower, A (or B) includes the `SIGHASH_NOINPUT` as well 
as the `q` private key.
Would it be safe for Watchtower to know that?

Note that the above `Q` would need to be the same in the "state" trunk of the 
Decker-Russell-Osuntokun construction.

So, building this, our initial setup transaction pays out to script:

 CHECKVERIFY  CHECKSIG

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

The `SIGHASH_NOINPUT` signature for `muSig(A_u,B_u)` would then be sufficient 
to unlock the setup transaction, or any update transaction with lower 
`nLockTime`.
The watchtower would then have to generate the signature for `Q`, committing to 
a particular UTXO.

Regards,
ZmnSCPxj


Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Wednesday, March 20, 2019 3:38 PM, ZmnSCPxj via Lightning-dev 
 wrote:

> 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` signatures from both sides in the blob sent to the 
> watchtower.
>
> Then the watchtower can always attach this to whatever is the tipmost 
> available on the chain of transactions.
>
> However, if one of the signatures MUST be non-`SIGHASH_NOINPUT` --- how does 
> the watchtower create such a non-`SIGHASH_NOINPUT` signature?
>
> Regards,
> ZmnSCPxj
>
> > Future segwit versions may choose to relax it.[1]
> > Cheers,
> > Rusty.
> > [1] Must be consensus, not standardness; my prev suggestion was bogus.
> > Rusty Russell ru...@rustcorp.com.au writes:
> >
> > > Anthony Towns a...@erisian.com.au 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 that result from a non-cooperative close of an eltoo channel.
> > >
> > > AJ, this was a meandering random walk which shed very little light.
> > > I don't find the differentiation between malicious and non-malicious
> > > double-spends convincing. Even if you trust A, you already have to
> > > worry about person-who-sent-the-coins-to-A. This expands that set to be
> > > "miner who mined coins sent-to-A", but it's very hard to see what
> > > difference that makes to how you'd handle coins from A.
> > >
> > > > Beyond that, I think NOINPUT has two fundamental ways to cause problems
> > > > for the people doing NOINPUT sigs:
> > > >
> > > > 1.  your signature gets applied to a unexpectedly different
> > > > script, perhaps making it look like you've being dealing
> > > > with some blacklisted entity. OP_MASK and similar solves
> > > > this.
> > > >
> > >
> > > ... followed by two paragraphs describing how it's not a "fundamental
> > > way to cause problems" that you (or I) can see.
> > >
> > > > For the second case, that seems a little more concerning. The nightmare
> > > > scenario is maybe something like:
> > > >
> > > > -   naive users do silly things with NOINPUT signatures, and end up
> > > > losing funds due to replays like the above
> > > >
> > >
> > > As we've never seen with SIGHASH_NONE?
> > >
> > > > -   initial source of funds was some major exchange, who decide it's
> > > > cheaper to refund the lost funds than deal with the customer 
> > > > complaints
> > > >
> > > 

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` signatures from both sides in the blob sent to the 
watchtower.

Then the watchtower can always attach this to whatever is the tipmost available 
on the chain of transactions.

However, if one of the signatures MUST be non-`SIGHASH_NOINPUT` --- how does 
the watchtower create such a non-`SIGHASH_NOINPUT` signature?

Regards,
ZmnSCPxj


> Future segwit versions may choose to relax it.[1]
>
> Cheers,
> Rusty.
> [1] Must be consensus, not standardness; my prev suggestion was bogus.
>
> Rusty Russell ru...@rustcorp.com.au writes:
>
> > Anthony Towns a...@erisian.com.au 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 that result from a non-cooperative close of an eltoo channel.
> >
> > AJ, this was a meandering random walk which shed very little light.
> > I don't find the differentiation between malicious and non-malicious
> > double-spends convincing. Even if you trust A, you already have to
> > worry about person-who-sent-the-coins-to-A. This expands that set to be
> > "miner who mined coins sent-to-A", but it's very hard to see what
> > difference that makes to how you'd handle coins from A.
> >
> > > Beyond that, I think NOINPUT has two fundamental ways to cause problems
> > > for the people doing NOINPUT sigs:
> > >
> > > 1.  your signature gets applied to a unexpectedly different
> > > script, perhaps making it look like you've being dealing
> > > with some blacklisted entity. OP_MASK and similar solves
> > > this.
> > >
> >
> > ... followed by two paragraphs describing how it's not a "fundamental
> > way to cause problems" that you (or I) can see.
> >
> > > For the second case, that seems a little more concerning. The nightmare
> > > scenario is maybe something like:
> > >
> > > -   naive users do silly things with NOINPUT signatures, and end up
> > > losing funds due to replays like the above
> > >
> >
> > As we've never seen with SIGHASH_NONE?
> >
> > > -   initial source of funds was some major exchange, who decide it's
> > > cheaper to refund the lost funds than deal with the customer 
> > > complaints
> > >
> > > -   the lost funds end up costing enough that major exchanges just 
> > > outright
> > > ban sending funds to any address capable of NOINPUT, which also bans
> > > all taproot/schnorr addresses
> > >
> >
> > I don't find this remotely credible.
> >
> > > FWIW, I don't have a strong opinion here yet, but:
> > >
> > > -   I'm still inclined to err on the side of putting more safety
> > > measures in for NOINPUT, rather than fewer
> > >
> >
> > In theory, sure. But not feel-good and complex "safety measures" which
> > don't actually help in practical failure scenarios.
> >
> > > -   the "must have a sig that commits to the input tx" seems like it
> > > should be pretty safe, not too expensive, and keeps taproot's privacy
> > > benefits in the cases where you end up needing to use NOINPUT
> > >
> >
> > If this is considered necessary, can it be a standardness rule rather
> > than consensus?
> > Thanks,
> > Rusty.
>
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


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 "must have a non-SIGHASH_NOINPUT" rule addresses the first reuse
scenario (as well as the second), I'd be content with that proposal.
Future segwit versions may choose to relax it.[1]

Cheers,
Rusty.
[1] Must be consensus, not standardness; my prev suggestion was bogus.

Rusty Russell  writes:
> 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 that result from a non-cooperative close of an eltoo channel.
>
> AJ, this was a meandering random walk which shed very little light.
>
> I don't find the differentiation between malicious and non-malicious
> double-spends convincing.  Even if you trust A, you already have to
> worry about person-who-sent-the-coins-to-A.  This expands that set to be
> "miner who mined coins sent-to-A", but it's very hard to see what
> difference that makes to how you'd handle coins from A.
>
>> Beyond that, I think NOINPUT has two fundamental ways to cause problems
>> for the people doing NOINPUT sigs:
>>
>>  1) your signature gets applied to a unexpectedly different
>> script, perhaps making it look like you've being dealing
>> with some blacklisted entity. OP_MASK and similar solves
>> this.
>
> ... followed by two paragraphs describing how it's not a "fundamental
> way to cause problems" that you (or I) can see.
>
>> For the second case, that seems a little more concerning. The nightmare
>> scenario is maybe something like:
>>
>>  * naive users do silly things with NOINPUT signatures, and end up
>>losing funds due to replays like the above
>
> As we've never seen with SIGHASH_NONE?
>
>>  * initial source of funds was some major exchange, who decide it's
>>cheaper to refund the lost funds than deal with the customer complaints
>>
>>  * the lost funds end up costing enough that major exchanges just outright
>>ban sending funds to any address capable of NOINPUT, which also bans
>>all taproot/schnorr addresses
>
> I don't find this remotely credible.
>
>> FWIW, I don't have a strong opinion here yet, but:
>>
>>  - I'm still inclined to err on the side of putting more safety
>>measures in for NOINPUT, rather than fewer
>
> In theory, sure.  But not feel-good and complex "safety measures" which
> don't actually help in practical failure scenarios.
>
>>  - the "must have a sig that commits to the input tx" seems like it
>>should be pretty safe, not too expensive, and keeps taproot's privacy
>>benefits in the cases where you end up needing to use NOINPUT
>
> If this is considered necessary, can it be a standardness rule rather
> than consensus?
>
> Thanks,
> Rusty.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


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 that result from a non-cooperative close of an eltoo channel.

AJ, this was a meandering random walk which shed very little light.

I don't find the differentiation between malicious and non-malicious
double-spends convincing.  Even if you trust A, you already have to
worry about person-who-sent-the-coins-to-A.  This expands that set to be
"miner who mined coins sent-to-A", but it's very hard to see what
difference that makes to how you'd handle coins from A.

> Beyond that, I think NOINPUT has two fundamental ways to cause problems
> for the people doing NOINPUT sigs:
>
>  1) your signature gets applied to a unexpectedly different
> script, perhaps making it look like you've being dealing
> with some blacklisted entity. OP_MASK and similar solves
> this.

... followed by two paragraphs describing how it's not a "fundamental
way to cause problems" that you (or I) can see.

> For the second case, that seems a little more concerning. The nightmare
> scenario is maybe something like:
>
>  * naive users do silly things with NOINPUT signatures, and end up
>losing funds due to replays like the above

As we've never seen with SIGHASH_NONE?

>  * initial source of funds was some major exchange, who decide it's
>cheaper to refund the lost funds than deal with the customer complaints
>
>  * the lost funds end up costing enough that major exchanges just outright
>ban sending funds to any address capable of NOINPUT, which also bans
>all taproot/schnorr addresses

I don't find this remotely credible.

> FWIW, I don't have a strong opinion here yet, but:
>
>  - I'm still inclined to err on the side of putting more safety
>measures in for NOINPUT, rather than fewer

In theory, sure.  But not feel-good and complex "safety measures" which
don't actually help in practical failure scenarios.

>  - the "must have a sig that commits to the input tx" seems like it
>should be pretty safe, not too expensive, and keeps taproot's privacy
>benefits in the cases where you end up needing to use NOINPUT

If this is considered necessary, can it be a standardness rule rather
than consensus?

Thanks,
Rusty.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


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.
> > So you might have:
> >funding tx -> cooperative claim
> >funding tx -> update 3 [TAGGED] -> settlement 3 -> claim
> >funding tx -> update 3 [TAGGED] -> 
> >  update 4 [TAGGED,NOINPUT] -> 
> >  settlement 4 [TAGGED,NOINPUT] -> 
> >  claim [NOINPUT]
> > In the cooperative case, no output tagging needed.
> I might be missing something here, but how do you bind update 3 to the
> funding tx output, when that output is not tagged? Do we keep each
> update in multiple separate states, one bound to the funding tx output
> and another signed with noinput?

I don't know that "separate states" is a great description -- until it
hits the blockchain "update N" is a template that can be filled out in a
variety of ways -- in the above the ways are:
 - with a NOINPUT sig and a previous "update" tx as its input
 - or with a SINGLE|ANYONECANPAY sig and the funding tx as input

The important thing is that approach means two sigs for each update tx.
The above also has two sigs for each settlement tx (and likewise two sigs
for each HTLC claim if using scriptless scripts) -- one using NOINPUT
in case multiple update tx's make it to the blockchain, and one assuming
everything works as expected that can just use direct key path spending.

I think you can do SINGLE,ANYCANPAY and combine multiple channel closures
if you're directly spending the funding tx, but can't do that if you're
using a NOINPUT sig, because the NOINPUT sig would commit to the tx's
locktime and different channel's states will generally have different
locktimes. You still probably want SINGLE,ANYCANPAY in that case so you
can bump fees though.

> If that's the case we just doubled our
> storage and communication requirements for very little gain.

There's three potential gains:
 * it lets us make a safer version of NOINPUT
 * it makes the common paths give fewer hints that you're using eltoo
 * it puts less data/computation load on the blockchain

With tagged outputs your update tx already indicates you're maybe going
to use NOINPUT, so that probably already gives away that you're using
eltoo, so, at least with output tagging, the second benefit probably
doesn't exist. Using a key path spend (without a script) is probably
going to be cheaper on the blockchain though.

But while I think output tagging is probably better than nothing,
requiring a non-NOINPUT signature seems a better approach to me. With
that one, having a dedicated sig for the normal "publish the latest
state spending the funding tx" case, reduces a unilateral close to only
being special due to the settlement tx having a relative timelock, and
the various tx's using SINGLE|ANYCANPAY, which seems like a win. In that
scenario, just using a single sig is much cheaper than revealing a taproot
point, a pubkey or two, and using two sigs and a CLTV check of course.

It does goes from 1+n signatures per update today to 4+n signatures,
if you're using scriptless scripts. If you don't mind revealing the
HTLCs are HTLCs, and could do them with actual scripts, that reduces to
4 signatures. You could reduce it to 2 signatures by also always posting
"funding tx -> update 0 -> update N -> settlement N", or you could reduce
it to 2+2/k signatures by only doing the non-NOINPUT sigs for every k'th
state (or no more often than every t seconds or similar).

> An
> alternative is to add a trigger transaction that needs to be published
> in a unilateral case, but that'd increase our on-chain footprint.

(The above essentially uses update tx's as optional trigger tx's)

Also, I'd expect the extra latency introduced by the interactive signing
protocol for muSig would be more of a hit (share the nonce hash, share
the nonce, calculate the sig). Particularly if you're doing multiparty
channels with many participants, rather than just two.

Cheers,
aj

___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


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 -> update 3 [TAGGED] -> settlement 3 -> claim
>
>funding tx -> update 3 [TAGGED] -> 
>  update 4 [TAGGED,NOINPUT] -> 
>settlement 4 [TAGGED,NOINPUT] -> 
>claim [NOINPUT]
>
> In the cooperative case, no output tagging needed.

I might be missing something here, but how do you bind update 3 to the
funding tx output, when that output is not tagged? Do we keep each
update in multiple separate states, one bound to the funding tx output
and another signed with noinput? If that's the case we just doubled our
storage and communication requirements for very little gain. An
alternative is to add a trigger transaction that needs to be published
in a unilateral case, but that'd increase our on-chain footprint.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


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 Poon-Dryja channels 
in BOLT 1.0, so at least it is not a degradation of performance.
It does make this modified form of Decker-Russell-Osuntokun much less 
attractive for use with DLC as the Fulgurite effort would like, but the 
Fulgurite effort already mitigates this by splitting a channel into two 
sub-channels (one for high-activity LN payments, one for rare-activity DLC 
bets) anyway.

Regards,
ZmnSCPxj

___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


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 "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 -> update 3 [TAGGED] -> settlement 3 -> claim

   funding tx -> update 3 [TAGGED] -> 
 update 4 [TAGGED,NOINPUT] -> 
 settlement 4 [TAGGED,NOINPUT] -> 
 claim [NOINPUT]

In the cooperative case, no output tagging needed.

For the unilateral case, you need to tag all the update tx's, because
they *could* be spend by a later update with a NOINPUT sig, and if
that actually happens, then the settlement tx also needs to use a
NOINPUT sig, and if you're using scriptless scripts to resolve HTLCs,
claiming/refunding the HTLCs needs a partially-pre-signed tx which also
needs to be a NOINPUT sig, meaning the settlement tx also needs to be
tagged in that case.

You'd only need the script path for the last case where there actually
are multiple updates, but because you have to have a tagged output in the
second case anyway, maybe you've already lost privacy and always using
NOINPUT and the script path for update and settlement tx's would be fine.

> However, it is probably more likely that I simply misunderstood what you 
> said, so if you can definitively say that it would be possible to hide the 
> clause "or a NOINPUT sig from A with a non-NOINPUT sig from B" behind a 
> Taproot then I am fine.

Yeah, that's my thinking.

> Minor pointless reactions:
> > 5.  if you're using scriptless scripts to do HTLCs, you'll need to
> > allow for NOINPUT sigs when claiming funds as well (and update
> > the partial signatures for the non-NOINPUT cases if you want to
> > maximise privacy), which is a bit fiddly
> If I remember accurately, we do not allow bilateral/cooperative close when 
> HTLC is in-flight.
> However, I notice that later you point out that a non-cheating unilateral 
> close does not need NOINPUT, so I suppose. the above thought applies to that 
> case.

Yeah, exactly.

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.

Cheers,
aj

___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


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 definitively say that it would be possible to hide the clause "or 
a NOINPUT sig from A with a non-NOINPUT sig from B" behind a Taproot then I am 
fine.

Minor pointless reactions:

> 5.  if you're using scriptless scripts to do HTLCs, you'll need to
> allow for NOINPUT sigs when claiming funds as well (and update
> the partial signatures for the non-NOINPUT cases if you want to
> maximise privacy), which is a bit fiddly

If I remember accurately, we do not allow bilateral/cooperative close when HTLC 
is in-flight.
However, I notice that later you point out that a non-cheating unilateral close 
does not need NOINPUT, so I suppose. the above thought applies to that case.


Regards,
ZmnSCPxj
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


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
> > or  CHECKSIGVERIFY  CHECKSIG
> > where A is Alice's key and B is Bob's key, P is muSig(A,B) and Q is
> > a key they both know the private key for. In the first case, Alice
> > would give Bob a NOINPUT sig for the tx, and when Bob wanted to publish
> > Bob would just do a SIGHASH_ALL sig with his own key. In the second,
> > Alice and Bob would share partial NOINPUT sigs of the tx with P, and
> > finish that when they wanted to publish.
> At my point of view, if a NONINPUT sig is restricted and cannot be
> used to spend an "ordinary" 2-of-2, this is output tagging regardless
> of exact mechanism.

With taproot, you could always do the 2-of-2 spend without revealing a
script at all, let alone that it was meant to be NOINPUT capable. The
setup I'm thinking of in this scenario is something like:

  0) my key is A, your key is B, we want to setup an eltoo channel

  1) post a funding tx to the blockchain, spending money to an address
 P = muSig(A,B)

  2) we cycle through a bunch of states from 0..N, with "0" being the
 refund state we establish before publishing the funding tx to
 the blockchain. each state essentially has two corresponding tx's,
 and update tx and a settlement tx.

  3) the update tx for state k spends to an output Qk which is a
 taproot address Qk = P + H(P,Sk)*G where Sk is the eltoo ratchet
 condition:
Sk = (5e8+k+1) CLTV A CHECKDLS_NOINPUT B CHECKDLS_NOINPUT_VERIFY

 we establish two partial signatures for update state k, one which
 is a partial signature spending the funding tx with key P and
 SIGHASH_ALL, the other is a NOINPUT signature via A (for you) and
 via B (for me) with locktime set to (k+5e8), so that we can spend
 any earlier state's update tx's, but not itself or any later
 state's update tx's.

  4) for each state we have also have a settlement transaction,
 Sk, which spends update tx k, to outputs corresponding to the state
 of the channel, after a relative timelock delay.

 we have two partial signatures for this transaction too, one with
 SIGHASH_ALL assuming that we directly spent the funding tx with
 update state k (so the input txid is known), via the key path with
 key Qk; the other SIGHASH_NOINPUT via the Sk path. both partially
 signed tx's have nSequence set to the required relative timelock
 delay.

  5) if you're using scriptless scripts to do HTLCs, you'll need to
 allow for NOINPUT sigs when claiming funds as well (and update
 the partial signatures for the non-NOINPUT cases if you want to
 maximise privacy), which is a bit fiddly

  6) when closing the channel the process is then:

   - if you're in contact with the other party, negotiate a new
 key path spend of the funding tx, publish it, and you're done.

   - otherwise, if the funding tx hasn't been spent, post the latest
 update tx you know about, using the "spend the funding tx via
 key path" partial signature

   - otherwise, trace the children of the funding tx, so you can see
 the most recent published state:
   - if that's newer than the latest state you know about, your
 info is out of date (restored from an old backup?), and you
 have to wait for your counterparty to post the settlement tx
   - if it's equal to the latest state you know about, wait
   - if it's older than the latest state, post the latest update
 tx (via the NOINPUT script path sig), and wait

   - once the CSV delay for the latest update tx has expired, post
 the corresponding settlement tx (key path if the update tx
 spent the funding tx, NOINPUT if the update tx spent an earlier
 update tx)

   - once the settlement tx is posted, claim your funds

So the cases look like:

   mutual close:
 funding tx -> claimed funds

 -- only see one key via muSig, single signature, SIGHASH_ALL
 -- if there are active HTLCs when closing the channel, and they
timeout, then the claiming tx will likely be one-in, one-out,
SIGHASH_ALL, with a locktime, which may be unusual enough to
indicate a lightning channel.

   unilateral close, no cheating: 
 funding tx -> update N -> settlement N -> claimed funds

 -- update N is probably SINGLE|ANYONECANPAY, so chain analysis
of accompanying inputs might reveal who closed the channel
 -- settlement N has relative timelock
 -- claimed funds may have timelocks if they claim active HTLCs via
the refund path
 -- no NOINPUT signatures needed, and all signatures use the key path
so don't reveal any scripts

  

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:
>
>  CHECKSIGVERIFY  CHECKSIG
> or  CHECKSIGVERIFY  CHECKSIG
>
>
> where A is Alice's key and B is Bob's key, P is muSig(A,B) and Q is
> a key they both know the private key for. In the first case, Alice
> would give Bob a NOINPUT sig for the tx, and when Bob wanted to publish
> Bob would just do a SIGHASH_ALL sig with his own key. In the second,
> Alice and Bob would share partial NOINPUT sigs of the tx with P, and
> finish that when they wanted to publish.
>
> This is a bit more costly than a key path spend: you have to reveal
> the taproot point to do a script (+33B) and you have two signatures
> instead of one (+65B) and you have to reveal two keys as well
> (+66B), plus some script overhead. If we did the  variant,
> we could provide a "PUSH_TAPROOT_KEY" opcode that would just push
> the taproot key to stack, saving 33B from pushing P as a literal,
> but you can't do much better than that. All in all, it'd be about 25%
> overhead in order to prevent cheating. [0]
>
> I think that output tagging doesn't provide a workable defense against the
> third party malleability via a deeper-than-the-CSV-delay reorg mentioned
> earlier; but requiring a non-NOINPUT sig does: you'd have to replace
> the non-NOINPUT sig to make state 5 spend state 3 instead of state 4,
> and only the holders of the appropriate private key can do that.

At my point of view, if a NONINPUT sig is restricted and cannot be used to 
spend an "ordinary" 2-of-2, this is output tagging regardless of exact 
mechanism.
So the restriction to add a non-NOINPUT sig in addition to a NOINPUT sig is 
still output tagging, as a cooperative close would still reveal that the output 
is not a 2-of-2.

Ideally, historical data of whether onchain coin was used in Lightning or not 
should be revealed as little as possible.
So in a cooperative close (which we hope, to be a common case), ideally the 
spend should look no different from an ordinary 2-of-2 spend.
Of course if the channel is published on Lightning, those who participated in 
Lightning at the time will learn of it, but at least the effort to remember 
this information is on those who want to remember this fact.

Now, this can be worked around by adding a "kickoff" transaction that spends 
the eltoo setup transaction.
The eltoo setup transaction outputs to an ordinary 2-of-2.
The kickoff outputs to an output that allows NOINPUT.
Then the rest of the protocol anchors on top of the kickoff.

The kickoff is kept offchain, until a non-cooperative close is needed.
Of course, as it is not a NOINPUT itself, it must need onchain fees attached to 
it.
This of course complicates fees, as we know.
Alternately maybe the kickoff can be signed with `SIGHASH_SINGLE | 
SIGHASH_ANYONECANPAY` so that it is possible to add a fee-paying UTXO to it.

Regards,
ZmnSCPxj
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev