Good morning Jeremy,
Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, May 22, 2019 4:10 PM, Jeremy <jlru...@mit.edu> wrote: > > * I do not think CoinJoin is much improved by this opcode. > > Typically, you would sign off only if one of the outputs of the CoinJoin > > transaction is yours, and this does not really improve this situation. > > Coinjoin benefits a lot I think. > > Coinjoin is improved because you can fit more users into the protocol and > create many more outputs at lower cost or include more participants. Ideally > a coinjoin creates a lot of outputs so that the ownership is smeared more, > but this has a cost at the time of the coinjoin. But the separate outputs still need to be published at some point in the future. Further, ideally CoinJoin should be as indistinguishable from normal transactions as possible. (admittedly, the equal-sized outputs often recommended for CoinJoin tend to blatantly signal "this is a CoinJoin!!", but in any case that "should" be fixed with some kind of future Confidential Transactions) > > Coinjoin is also improved because you don't reveal the outputs created by the > coinjoin until some time, perhaps very far in the future, when you need the > coin. In fact, you only need to reveal where you're moving the coins to > participants in your subtree because participants need only verify their > branch. The same technique of congestion control can still be used with only an "ordinary" MuSig of all participant keys on the output of the "funding" transaction, forming a sort of very tiny CoinJoinXT. This has the advantage that the MuSig is indistinguishable from 1-of-1 spends, which is important for a privacy technique like CoinJoin. Even in the future and we have published the output-side transaction of the CoinJoin, the transaction chain *could* be interpreted as "one person consolidated all his coins in an ordinary 1-of-1 UTXO, then spent on several things at once" whereas use of the `OP_CHECKOUTPUTSHASHVERIFY` is a blatant "several people agreed to put in their coins provided these outputs were on the second transaction, i.e. some kind of attempt at hiding their coins". > > It also makes the protocol more stable with respect to input choice. This is > because, similar to how NOINPUT may work, OP_COSHV outputs are spendable > without knowing what the TXID will be. Therefore if someone changes their > input or non segwit spend script, it won't break the presigned txns. This > also means that all the inputs can be ANYONECANPAY, so there is no need to > reveal your inputs before anyone else. > > This culminates in being able to open channels from a coinjoin safely, I > believe this is difficult/impossible to do currently. This is already *technically* possible, though no software exists to do so (sorry, we have bugs between interop of c-lightning and lnd that take up our debugging time already, we cannot spare it for this *yet*). SegWit by itself already allows child transactions to be signed before parent transactions are signed. This safety underlies *all* offchain protocols. See: https://zmnscpxj.github.io/offchain/generalized.html This is sufficient to ensure that channels can be opened from whatever transactions you want, though having to interop with other software that *also* has to coordinate with other participants in a different protocol is much more difficult than having to interop with other software using the same protocol. Finally, `SIGHASH_ANYPREVOUT` can *also* do this, since the txid becomes mooted. And `SIGHASH_ANYPREVOUT` *also* enables a better offchain update mechanism (Decker-Russell-Osuntokun, more commonly known as "eltoo") whereas I am unable to derive a similar offchain update mechanism using `OP_CHECKOUTPUTSHASHVERIFY` (though possibly for lack of trying). > > > * Using this for congestion control increases blockchain usage by one TXO > > and one input, ending up with *more* bytes onchain, and a UTXO that will be > > removed later in (we hope) short time. > > I do not know if this is a good idea, to increase congestion by making > > unnecessary intermediate transaction outputs, at times when congestion is a > > problem. > > This is a good idea because it improves QoS for most users. > > For receiving money pending spendable but confirmed payment (i.e. certified > checks) is superior to having unconfirmed funds. > > For sending money, being able to clear all liabilities in a single txn > decreases business exposure to fee variance and confirmation time variance. > E.g., if I'm doing payroll in Bitcoin I will pay big fines if I am a day > late. If I have 10,000 employees this might be painful if fees are currently > up. > > It also helps to have a backlog of low priority txns to support the fee > market. > > Overall block bandwidth utilization is fairly spikey, so having long term > well known outputs that are not time sensitive can be used to better utilize > bandwidth. > > The total extra bandwidth btw is really small given the expansion factor > optimizations available. Okay, you have convinced me regarding this point, at least. > > * Channel factories created by this opcode do not, by themselves, support > > updates to the channel structure. > > But such simple "close only" channel factories can be done using n-of-n > > and a pre-signed offchain transaction (especially since the entities > > interested in the factory are known and enumerable, and thus can be induced > > to sign in order to enter the factory). > > I'm not really an expert at Bitcoin Lightning, but this basic mechanism > should work. > Imagine the script at a leaf node: > > Taproot([Alice, Bob], [OP_COSHV <H(H(2 coins to uncooperative script))>] > > where uncooperative script is: > > Taproot([Alice, Bob], ["1 week" CHECKSEQUENCEVERIFY DROP OP_COSHV <H(H(Pay > alice 2 coins))>) > > Cooperative closing skips the extra transactions. Updates are signed against > the uncooperative script with repudation. E.g.: > > HASH160 <revokehash> EQUAL > IF > <Bob's pubkey> > ELSE > "1 week" CHECKSEQUENCEVERIFY DROP > <Alice's pubkey> > ENDIF > CHECKSIG > > It can even be optimized by letting the uncooperative script branches in the > leaf be blaming Alice or Bob. > > Does that not work? Possibly, but the point is that an n-of-n MuSig will work just as well and we would not need to reveal the Taproot key (33 bytes) and the specific script containing the output hash (1+32 bytes) we want, we just have to reveal a single 64-byte signature. My objection here is simply that n-of-n already exists, it will work already using that (and it is much more likely to be assured of getting into base layer). Again, we only need to use SegWit and sign transactions in reverse order to ensure proper operation. This is already what is done for normal channel opens (the initial commitment transactions are signed first, then the funding transaction is signed and confirmed onchain). Regards, ZmnSCPxj _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
