path: root/95/a51748d8a315a534b1f9d682c62908b1d65116

Return-Path: <jim.posen@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id E1445CAF
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  4 Apr 2018 23:11:54 +0000 (UTC)
Received: by mail-io0-f181.google.com with SMTP id 141so28309417iou.12
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <jim.posen@gmail.com>
Date: Wed, 4 Apr 2018 16:11:52 -0700
Message-ID: <CADZtCSh43AQ5zkRN=RJnUYPY9f=MBMmXwmAnL+Ou0kguOptBhg@mail.gmail.com>
To: Rusty Russell <rusty@rustcorp.com.au>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <bitcoin-dev@lists.linuxfoundation.org>
> 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.
>
>         <txid1>... <txidN>
>
> That's pretty large though, and it's non-witness data (though
> discardable).  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
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I&#39;ll just mention that non-interactive one-way aggrega=
tion with BLS signatures solves this problem rather nicely.</div><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Apr 2, 2018 at 10:3=
1 PM, Rusty Russell via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto=
:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists=
.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><span class=3D"">Anthony Towns via bitcoin-dev &lt;<a href=3D"mailto:bitc=
oin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.o=
rg</a>&gt; writes:<br>
&gt; If you&#39;ve got one bundle that overpays fees and another that under=
pays,<br>
&gt; you can safely combine the two only if you can put a SIGHASH_ALL sig i=
n<br>
&gt; the one that overpays (otherwise miners could just make their own tx o=
f<br>
&gt; just the overpaying bundle).<br>
<br>
</span>This is a potential problem, yes :( And I&#39;m not sure how to solv=
e it,<br>
unless you do some crazy thing like commit to a set of keys which are<br>
allowed to bundle, which kind of defeats the generality of outsourcing.<br>
<span class=3D""><br>
&gt; This could replace SINGLE|ANYONECANPAY at a cost of an extra couple of=
<br>
&gt; witness bytes.<br>
&gt;<br>
&gt; I think BUNDLESTART is arguably redundant -- you could just infer<br>
&gt; BUNDLESTART if you see an INBUNDLE flag when you&#39;re not already in=
<br>
&gt; a bundle. Probably better to have the flag to make parsing easier,<br>
&gt; so just have the rule be BUNDLESTART is set for precisely the first<br=
>
&gt; INBUNDLE signature since the last bundle finished.<br>
<br>
</span>Indeed.<br>
<span class=3D""><br>
&gt;&gt; One of the issues we&#39;ve struck with lightning is trying to gue=
ss future<br>
&gt;&gt; fees for commitment transactions: we can&#39;t rely on getting ano=
ther<br>
&gt;&gt; signature from our counterparty to increase fees.=C2=A0 Nor can we=
 use<br>
&gt;&gt; parent-pays-for-child since the outputs we can spend are timelocke=
d.<br>
&gt;<br>
&gt; That doesn&#39;t quite work with the HTLC-Success/HTLC-Timeout transac=
tions<br>
&gt; though, does it? They spend outputs from the commitment transaction<br=
>
&gt; and need to be pre-signed by your channel partner in order to ensure<b=
r>
&gt; the output address is correct -- but if the commitment transaction get=
s<br>
&gt; bundled, its txid will change, so it can&#39;t be pre-signed.<br>
<br>
</span>Not without SIGHASH_NOINPUT, no.<br>
<span class=3D""><br>
&gt; FWIW, a dumb idea I had for this problem was to add a zero-value<br>
&gt; anyone-can-spend output to commitment transactions, that can then be<b=
r>
&gt; used with CPFP to bump the fees. Not very nice for UTXO bloat if fee<b=
r>
&gt; bumping isn&#39;t needed though, and I presume it would fail to pass t=
he<br>
&gt; dust threshold...<br>
<br>
</span>Yeah, let&#39;s not do that.<br>
<span class=3D""><br>
&gt; I wonder if it would be plausible to have after-the-fact fee-bumping<b=
r>
&gt; via special sighash flags at the block level anyway though. Concretely=
:<br>
&gt; say you have two transactions, X and Y, that don&#39;t pay enough in f=
ees,<br>
&gt; you then provide a third transaction whose witness is [txid-for-X,<br>
&gt; txid-for-Y, signature committing to (txid-for-X, txid-for-Y)], and can=
<br>
&gt; only be included in a block if X and Y are also in the same block. You=
<br>
&gt; could make that fairly concise if you allowed miners to replace txid-f=
or-X<br>
&gt; with X&#39;s offset within the block (or the delta between X&#39;s txn=
um and the<br>
&gt; third transaction&#39;s txnum), though coding that probably isn&#39;t =
terribly<br>
&gt; straightforward.<br>
<br>
</span>What would it spend though?=C2=A0 Can&#39;t use an existing output, =
so this<br>
really needs to be stashed in an *output script*, say a zero-amount<br>
output which is literally a push of txids, and is itself unspendable.<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 &lt;txid1&gt;... &lt;txidN&gt;<br>
<br>
That&#39;s pretty large though, and it&#39;s non-witness data (though<br>
discardable).=C2=A0 How about &#39;OP_NOP4 &lt;N&gt; &lt;ripemd160-of-last-=
N-txids&gt;&#39;?<br>
Then the miner just bundles those tx all together?<br>
<br>
Cheers,<br>
Rusty.<br>
<div class=3D"HOEnZb"><div class=3D"h5">______________________________<wbr>=
_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</div></div></blockquote></div><br></div>

--94eb2c07077ad9574d05690df25c--