MIME-Version: 1.0
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"
Subject: Re: [bitcoin-dev] Signature bundles
Precedence: list

--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--