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 E1445CAF for ; Wed, 4 Apr 2018 23:11:54 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f181.google.com (mail-io0-f181.google.com [209.85.223.181]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3329762B for ; Wed, 4 Apr 2018 23:11:54 +0000 (UTC) Received: by mail-io0-f181.google.com with SMTP id 141so28309417iou.12 for ; Wed, 04 Apr 2018 16:11:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ptydcroPFsAhUQ4eO9iqoi7QDC7k/ZjKZ8uPiZT6bBs=; b=Er3XRq8i4MyUy8falBWse4iLC7qYPkdSQcWHRxaqX31CEGMtjhIruG7m+GXBEx1caH +eZDIde6fScPiuordBVDJRvB8FCcLiwm7AfOApKKPeAAv8WU74PmBatbFL74yD8/Rb18 AfLvjjkbL0k7jNOWpPK1Xq7SDLhtLm3YuHK/IqAA3RbHH06yVSX8znS0UfKPMfDIb0Nx bNIC6K5RCuWX2qHaLr+kC8Xavy34SeGX/QdXdmOy49jsSrw9RYs8tmGi54Viseg9jfy2 FkpkIt6mgG2fY8hCfLRtytTrL1GgqxWbsubsyBco1Z3mg3q3ghYFSNsqWbXqTMOOT8Vp X+1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ptydcroPFsAhUQ4eO9iqoi7QDC7k/ZjKZ8uPiZT6bBs=; b=gAE3OYIlygtUOw1hK0S5+MSbU1oYcw37Q4ofwGU1vQ7YTC4oiU5UWcJulro3ap9I9C VM2kD3ENmDXK9OWHkVF6TaAjGKuMlY6syyDgkekW8XXeYq10OEfO02bOLYO8lzDVy+ka OHUw2aT49+eVbz2n/EVrWbiVLghBjLR4oNsaWfKYkFLDlWKTcfzXUn/OK7T2b1Hv5xZ9 TEYsf/N7CLpT/mWPb7k8IzFXz8N+Ma+21XSRksWL1UqMy7Y2zfti8Km3WYf202Wb8b0R fSwjYLQZY+IuMriUnehyxNrWzHRS0Ygz2+sMlwGrj87R7R8df1jnHsoki1+aoFtjnolv QoOw== X-Gm-Message-State: AElRT7EPkj8bIR99pnmq/slVBr0+NuiWkmeDE0125AxZQYF2RNHvH9lP MbX/FVPNYoipSHO+O66wJgl2F3ljzZtoWM+V86Expg== X-Google-Smtp-Source: AIpwx4/inwbeghGcoVl3pUBvbWdqbXSVfrbjl/5HtSK2kGqc0rroKHgGG1sj9AKumH4CEwS+IDrBQfBbJW6TlxmjI3Q= X-Received: by 10.107.186.139 with SMTP id k133mr17336907iof.95.1522883513373; Wed, 04 Apr 2018 16:11:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.52.80 with HTTP; Wed, 4 Apr 2018 16:11:52 -0700 (PDT) In-Reply-To: <87sh8cc0ur.fsf@rustcorp.com.au> References: <874lktdvdm.fsf@rustcorp.com.au> <20180403035723.GA21120@erisian.com.au> <87sh8cc0ur.fsf@rustcorp.com.au> From: Jim Posen Date: Wed, 4 Apr 2018 16:11:52 -0700 Message-ID: To: Rusty Russell , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="94eb2c07077ad9574d05690df25c" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE 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: Fri, 06 Apr 2018 13:36:33 +0000 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: Wed, 04 Apr 2018 23:11:55 -0000 --94eb2c07077ad9574d05690df25c Content-Type: text/plain; charset="UTF-8" I'll just mention that non-interactive one-way aggregation with BLS signatures solves this problem rather nicely. On Mon, Apr 2, 2018 at 10:31 PM, Rusty Russell via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 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. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --94eb2c07077ad9574d05690df25c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'll just mention that non-interactive one-way aggrega= tion with BLS signatures solves this problem rather nicely.

On Mon, Apr 2, 2018 at 10:3= 1 PM, Rusty Russell via bitcoin-dev <bitcoin-dev@lists= .linuxfoundation.org> wrote:
Anthony Towns via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.o= rg> writes:
> If you've got one bundle that overpays fees and another that under= pays,
> you can safely combine the two only if you can put a SIGHASH_ALL sig i= n
> the one that overpays (otherwise miners could just make their own tx o= f
> just the overpaying bundle).

This is a potential problem, yes :( And I'm not sure how to solv= e 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 gue= ss future
>> fees for commitment transactions: we can't rely on getting ano= ther
>> signature from our counterparty to increase fees.=C2=A0 Nor can we= use
>> parent-pays-for-child since the outputs we can spend are timelocke= d.
>
> That doesn't quite work with the HTLC-Success/HTLC-Timeout transac= tions
> 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 get= s
> 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 t= he
> 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 f= ees,
> 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-f= or-X
> with X's offset within the block (or the delta between X's txn= um and the
> third transaction's txnum), though coding that probably isn't = terribly
> straightforward.

What would it spend though?=C2=A0 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.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 <txid1>... <txidN>

That's pretty large though, and it's non-witness data (though
discardable).=C2=A0 How about 'OP_NOP4 <N> <ripemd160-of-last-= N-txids>'?
Then the miner just bundles those tx all together?

Cheers,
Rusty.
______________________________= _________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev

--94eb2c07077ad9574d05690df25c--