Date: Thu, 23 May 2019 06:49:11 +1000
From: Anthony Towns <aj@erisian.com.au>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20190522204911.q4omleepjt5mpxeo@erisian.com.au>
References: <CAD5xwhgHyR5qdd09ikvA_vgepj4o+Aqb0JA_T6FuqX56ZNe1RQ@mail.gmail.com>
	<VU6YVz_dc9U4BhGd6WWNvYLS-DI1lBE14tpYdXEyIufTZ2OvqQfcWh6RVelCLWTQMWqiNsSf_AM3Pq2hzn3G62RIQwceLx54rRmD-zHCdNU=@protonmail.com>
	<CAD5xwhixyvAA0zak86BwG3ZjinUJ37266K_wn_NCa-ECrVmouw@mail.gmail.com>
	<CljXxJhTEILR7KZxgZ3o_yJm66XeySWzUY3abCm01blY9yX3AmMczvu41CAm9dr4ZQTDCTQqEM1D4MhEaGASuM54l51DaJmZSKv0eqtPjEo=@protonmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CljXxJhTEILR7KZxgZ3o_yJm66XeySWzUY3abCm01blY9yX3AmMczvu41CAm9dr4ZQTDCTQqEM1D4MhEaGASuM54l51DaJmZSKv0eqtPjEo=@protonmail.com>
User-Agent: NeoMutt/20170113 (1.7.2)
Subject: Re: [bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY
 proposal
Precedence: list

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