Good morning darosior,
> Hi Lisa and all, > > Given the discussion about utxos snooping, I wondered if there was any > obvious drawbacks of using a transaction chain construction ? > > Since the obvious target of the probing is the accepter, it seems that the > opener needs to at least have something at stake in order to be revealed some > of the accepter's utxos. > Thus, the opener giving the accepter a signed transaction commited to the > channel opening is one way of avoiding the opener to probe gratuitously. I > was thinking of something like: > > A is opener, B is accepter. > A could sign the first input (and accordingly the 2of2 output) with > SIGHASH_SINGLE|SIGHASH_ANYONECANPAY. Unfortunately this doesn't handle A's > change, but it can be solved using a chain of transaction. > A creates a first transaction txA1: > > txA1 (SIGHASH_ALL) > _________________ __________________________ > | A's input 1 | A's channel participation | > |----------------|--------------------------- > | A's input 2 | A's change | > |----------------|--------------------------- > | A's input n | > |________________| > > > And then creates /signs the funding transaction out of the first output of > txA1: > > txA2 (SIGHASH_SINGLE|SIGHASH_ANYONECANPAY) > _________________ _______________ > | txA1 vout 0 | 2of2 with B | > |________________|________________ > > Since txA2 is signed with SINGLE|ANYONECANPAY, B can add inputs to fulfill > the value requirement of the 2of2, and add outputs for its own change. > > This comes at the cost of more setup fees opener-side, but avoids the > accepter to be gratuitously probed, so this is arguably a far lesser evil. > Is there any other downside I'm missing here ? This is an excellent idea. A drawback is that anything that is not `SIGHASH_ALL` sticks out in chain analysis. This is not an issue currently with Lightning since every 2-of-2 is (almost) definitely a Lightning Channel, but future improvements (Schnorr, Taproot) let us get better hiding, so the `SIGHASH_SINGLE | SIGHASH_ANYONECANPAY` is a massive flag. As the point of protecting against this kind of probing is privacy, this is not a perfect privacy solution. We could also consider PoDLE as used in JoinMarket, which solves a similar problem. https://gist.github.com/AdamISZ/9cbba5e9408d23813ca8#defence-2-committing-to-a-utxo-in-publicplaintext-at-the-start-of-the-handshake Basically, a PoDLE commits to a UTXO, without being trivially grindable from the UTXO set and also including a proof that the creator of the PoDLE knows the secret key behind it. It can later be opened to reveal which UTXO the opener allocated. If the opener aborts (i.e. does not provide its signatures to the funding transaction) then the acceptor can gossip the UTXO and the revealed PoDLE as well to the rest of Lightning, so that the opener at least cannot reuse the same UTXO to probe other potential acceptors. (though, my understanding, there is no clear way to determine *when* we can safely delete old PoDLEs: maybe each node can keep it around for a month, which might be good enough to limit the practical ability of a snoop to probe other nodes) I believe JoinMarket also has solved the issue of allowing a UTXO to be used at most N times (for example due to "honest" failures, such as connectivity interruptions which might cause an abort of the protocol); I think it involves appending a single byte to something that is hashed, and ensuring its value is less than N, so that it can only be used from 0 to N - 1 (and thus allow a UTXO to be used at most N times). Getting into contact with waxwing / Adam Gibson for this might be useful to fill out how PoDLE works and so on; basically, I believe this issue is a practically solved problem already for JoinMarket, though waxwing may be able to provide a more nuanced opinion. Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
