On Wed, May 22, 2019 at 06:04:27AM +0000, ZmnSCPxj via bitcoin-dev wrote:
> * I do not think CoinJoin is much improved by this opcode.

I think (especially with cross-input sig aggregation) it makes it easier
to do a coinjoin during a high fee period -- if you're willing to wait
'til fees are lower to claim your funds you can still do that, despite
participating now.

Otherwise, I don't think it makes coordination that much easier. 

If the coinjoin groups stays around in a Layer 2-ish protocol, and
coordinates to cut-through transactions, that could be a scaling and
privacy benefit, but comes with much harder coordination problems. ie:

   A,B,C,D do a coinjoin with outputs of 1 BTC each
   tx on chain looks like:
     in: 1 A
         1 B
         1 C
         1 D
     out: 4 to muSig(A,B,C,D) or COHV(1 A, 1 B, 1 C, 1 D)

but then A wants to spend 0.2 BTC to E, and B wants to spend 0.1 BTC to
F, so they agree to update the state and publish:

     in: (above, signed by A+B+C+D)
         0.1 F
         0.2 E
         3.7 to muSig(A,B,C,D) or COHV(0.8 A, 0.9 B, 1 C, 1 D)

and they continue the protocol.

> * I cannot support replacing `SIGHASH_NOINPUT` with this opcode.

(I don't think this in any way replaces ANYPREVOUT or similar)

I think lightning is improved by this in that it makes it cheaper to
create lightning channels during a high fee period. If you're creating
1000 channels you can do that via a single output with this opcode, and
then wait until either there's a low fee period to publish the funding
tx cheaply; or until the channel fails and you need to extract the funds
which always has the risk of happening during a high fee period.

You might be able to slightly simplify eltoo (or conceivably some parts of
current lightning); if your eltoo update tx has as it's output [musig(A,B)
or (n+1 cltv checksig) or (d CSV COHV(balances))] then your settlement
transaction only needs to reveal the 40B script, rather than needing a
65B ANYPREVOUT signature.


bitcoin-dev mailing list

Reply via email to