Re: [Lightning-dev] More thoughts on NOINPUT safety
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
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
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
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
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
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
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
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
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
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
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
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
[Lightning-dev] More thoughts on NOINPUT safety
Hi all, The following has some more thoughts on trying to make a NOINPUT implementation as safe as possible for the Bitcoin ecosystem. One interesting property of NOINPUT usage like in eltoo is that it actually reintroduces the possibility of third-party malleability to transactions -- ie, you publish transactions to the blockchain (tx A, which is spent by tx B, which is spent by tx C), and someone can come along and change A or B so that C is no longer valid). The way this works is due to eltoo's use of NOINPUT to "skip intermediate states". If you publish to the blockchain: funding tx -> state 3 -> state 4[NOINPUT] -> state 5[NOINPUT] -> finish then in the event of a reorg, state 4 could be dropped, state 5's inputs adjusted to refer to state 3 instead (the sig remains valid due to NOINPUT, so this can be done by anyone not just holders of some private key), and finish would no longer be a valid tx (because the new "state 5" tx has different inputs so a different txid, and finish uses SIGHASH_ALL for the signature so committed to state 5's original txid). There is a safety measure here though: if the "finish" transaction is itself a NOINPUT tx, and has a a CSV delay (this is the case in eltoo; the CSV delay is there to give time for a hypothetical state 6 to be published), then the only way to have a problem is for some SIGHASH_ALL tx that spends finish, and a reorg deeper than the CSV delay (so that state 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. 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. 2) your signature is applied to some transaction and works perfectly; but then someone else sends money to the same address and reuses your prior signature to forward it on to the same destination, without your consent I still like OP_MASK as a solution to (1), but I can't convince myself that the problem it solves is particularly realistic; it doesn't apply to address blacklists, because for OP_MASK to make the signature invalid the address has to be different, and you could just short circuit the whole thing by sending money from a blacklisted address to the target's personal address directly. Further, if the sig's been seen on chain before, that's probably good evidence that someone's messing with you; and if it hasn't been seen on chain before, how is anyone going to tell it's your sig to blame you for it? I still wonder if there isn't a real problem hiding somewhere here, but if so, I'm not seeing it. 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 * 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 That's not super likely to happen by chance: NOINPUT sigs will commit to the value being spent, so to lose money, you (Alice) have to have done a NOINPUT sig spending a coin sent to your address X, to someone (Bob) and then have to have a coin with the exact same value sent from someone else again (Carol) to your address X (or if you did a script path NOINPUT spend, to some related address Y with a script that uses the same key). But because it involves losing money to others, bad actors might trick people into having it happen more often than chance (or well written software) would normally allow. That "nightmare" could be stopped at either the first step or the last step: * if we "tag" addresses that can be spent via NOINPUT then having an exchange ban those addresses doesn't also impact regular taproot/schnorr addresses, though it does mean you can tell when someone is using a protocol like eltoo that might need to make use of NOINPUT signatures. This way exchanges and wallets could simply not provide NOINPUT capable addresses in the first place normally, and issue very large warnings when asked to send money to one. That's not a problem for eltoo, because all the NOINPUT-capable address eltoo needs are internal parts of the protocol, and are spent automatically. * or we could make it so NOINPUT signatures aren't replayable on different transactions, at least by third parties. one way of doing this might be to require
