From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id E19BDAB9 for ; Wed, 22 May 2019 20:49:26 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6A37F5D0 for ; Wed, 22 May 2019 20:49:26 +0000 (UTC) Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au) by azure.erisian.com.au with esmtpsa (Exim 4.89 #1 (Debian)) id 1hTYAm-0000oR-8X; Thu, 23 May 2019 06:49:17 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Thu, 23 May 2019 06:49:11 +1000 Date: Thu, 23 May 2019 06:49:11 +1000 From: Anthony Towns To: ZmnSCPxj , Bitcoin Protocol Discussion Message-ID: <20190522204911.q4omleepjt5mpxeo@erisian.com.au> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) X-Spam-Score: -1.9 X-Spam-Score-int: -18 X-Spam-Bar: - X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Thu, 23 May 2019 13:31:42 +0000 Subject: Re: [bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY proposal X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2019 20:49:27 -0000 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