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-...@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 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-...@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > Lightning-dev mailing list > lightning-...@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev