Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2019-05-22 📝 Original message:On Wed, May 22, 2019 at ...
📅 Original date posted:2019-05-22
📝 Original message: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)
out:
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.
Cheers,
aj
📝 Original message: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)
out:
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.
Cheers,
aj