ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2019-03-20 📝 Original message: Hi aj, Re-reading again, ...
📅 Original date posted:2019-03-20
📝 Original message:
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:
>
> <A> CHECKSIGVERIFY <B> CHECKSIG
> or <P> CHECKSIGVERIFY <Q> 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:
<muSig(A,B)> CHECKVERIFY <Q> 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:
<muSig(A_u,B_u)> CHECKVERIFY <Q> CHECKSIG
Then each update transaction pays out to:
OP_IF
<csv_delta> OP_CSV OP_DROP
<muSig(A_si,B_si)> OP_CHECKSIGVERIFY <Q> OP_CHECKSIG
OP_ELSE
<i> OP_CHECKLOCKTIMEVERIFY OP_DROP
<muSig(A_u,B_u)> OP_CHECKSIGVERIFY <Q> 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 <lightning-dev at lists.linuxfoundation.org> 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 rusty at rustcorp.com.au writes:
> >
> > > Anthony Towns aj at 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 at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
📝 Original message:
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:
>
> <A> CHECKSIGVERIFY <B> CHECKSIG
> or <P> CHECKSIGVERIFY <Q> 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:
<muSig(A,B)> CHECKVERIFY <Q> 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:
<muSig(A_u,B_u)> CHECKVERIFY <Q> CHECKSIG
Then each update transaction pays out to:
OP_IF
<csv_delta> OP_CSV OP_DROP
<muSig(A_si,B_si)> OP_CHECKSIGVERIFY <Q> OP_CHECKSIG
OP_ELSE
<i> OP_CHECKLOCKTIMEVERIFY OP_DROP
<muSig(A_u,B_u)> OP_CHECKSIGVERIFY <Q> 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 <lightning-dev at lists.linuxfoundation.org> 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 rusty at rustcorp.com.au writes:
> >
> > > Anthony Towns aj at 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 at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev