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 98A9F11FF for ; Tue, 3 Apr 2018 05:31:37 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from ozlabs.org (ozlabs.org [103.22.144.67]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D6BC3418 for ; Tue, 3 Apr 2018 05:31:36 +0000 (UTC) Received: by ozlabs.org (Postfix, from userid 1011) id 40Fd4Q2n3xz9s1t; Tue, 3 Apr 2018 15:31:34 +1000 (AEST) From: Rusty Russell To: Anthony Towns , Bitcoin Protocol Discussion , bitcoin-dev@lists.linuxfoundation.org In-Reply-To: <20180403035723.GA21120@erisian.com.au> References: <874lktdvdm.fsf@rustcorp.com.au> <20180403035723.GA21120@erisian.com.au> Date: Tue, 03 Apr 2018 15:01:24 +0930 Message-ID: <87sh8cc0ur.fsf@rustcorp.com.au> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, T_RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Signature bundles 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: Tue, 03 Apr 2018 05:31:37 -0000 Anthony Towns via bitcoin-dev writes: > If you've got one bundle that overpays fees and another that underpays, > you can safely combine the two only if you can put a SIGHASH_ALL sig in > the one that overpays (otherwise miners could just make their own tx of > just the overpaying bundle). This is a potential problem, yes :( And I'm not sure how to solve it, unless you do some crazy thing like commit to a set of keys which are allowed to bundle, which kind of defeats the generality of outsourcing. > This could replace SINGLE|ANYONECANPAY at a cost of an extra couple of > witness bytes. > > I think BUNDLESTART is arguably redundant -- you could just infer > BUNDLESTART if you see an INBUNDLE flag when you're not already in > a bundle. Probably better to have the flag to make parsing easier, > so just have the rule be BUNDLESTART is set for precisely the first > INBUNDLE signature since the last bundle finished. Indeed. >> One of the issues we've struck with lightning is trying to guess future >> fees for commitment transactions: we can't rely on getting another >> signature from our counterparty to increase fees. Nor can we use >> parent-pays-for-child since the outputs we can spend are timelocked. > > That doesn't quite work with the HTLC-Success/HTLC-Timeout transactions > though, does it? They spend outputs from the commitment transaction > and need to be pre-signed by your channel partner in order to ensure > the output address is correct -- but if the commitment transaction gets > bundled, its txid will change, so it can't be pre-signed. Not without SIGHASH_NOINPUT, no. > FWIW, a dumb idea I had for this problem was to add a zero-value > anyone-can-spend output to commitment transactions, that can then be > used with CPFP to bump the fees. Not very nice for UTXO bloat if fee > bumping isn't needed though, and I presume it would fail to pass the > dust threshold... Yeah, let's not do that. > I wonder if it would be plausible to have after-the-fact fee-bumping > via special sighash flags at the block level anyway though. Concretely: > say you have two transactions, X and Y, that don't pay enough in fees, > you then provide a third transaction whose witness is [txid-for-X, > txid-for-Y, signature committing to (txid-for-X, txid-for-Y)], and can > only be included in a block if X and Y are also in the same block. You > could make that fairly concise if you allowed miners to replace txid-for-X > with X's offset within the block (or the delta between X's txnum and the > third transaction's txnum), though coding that probably isn't terribly > straightforward. What would it spend though? Can't use an existing output, so this really needs to be stashed in an *output script*, say a zero-amount output which is literally a push of txids, and is itself unspendable. ... That's pretty large though, and it's non-witness data (though discardable). How about 'OP_NOP4 '? Then the miner just bundles those tx all together? Cheers, Rusty.