diff options
| author | Jeremy Rubin <jeremy.l.rubin@gmail.com> | 2022-02-20 08:29:00 -0800 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-02-20 16:29:15 +0000 |
| commit | 33c79a9ec54bfb3bcc62bd63bae42f181f0c2907 (patch) | |
| tree | 353b55db06f3fa4dc5e945727e8309cb4556e094 /77 | |
| parent | f6adb0d40fd6c308f1ed5eed8d90a5c65aa54034 (diff) | |
| download | pi-bitcoindev-33c79a9ec54bfb3bcc62bd63bae42f181f0c2907.tar.gz pi-bitcoindev-33c79a9ec54bfb3bcc62bd63bae42f181f0c2907.zip | |
Re: [bitcoin-dev] [Pre-BIP] Fee Accounts
Diffstat (limited to '77')
| -rw-r--r-- | 77/cbe736df0448b1c5fdd1902fa9b7b8b65891f2 | 362 |
1 files changed, 362 insertions, 0 deletions
diff --git a/77/cbe736df0448b1c5fdd1902fa9b7b8b65891f2 b/77/cbe736df0448b1c5fdd1902fa9b7b8b65891f2 new file mode 100644 index 000000000..168e50bed --- /dev/null +++ b/77/cbe736df0448b1c5fdd1902fa9b7b8b65891f2 @@ -0,0 +1,362 @@ +Return-Path: <jeremy.l.rubin@gmail.com> +Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 7462CC0033; + Sun, 20 Feb 2022 16:29:15 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp1.osuosl.org (Postfix) with ESMTP id 5C2DF813AD; + Sun, 20 Feb 2022 16:29:15 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -2.098 +X-Spam-Level: +X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 + tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, + DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, + HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, + SPF_PASS=-0.001] autolearn=ham autolearn_force=no +Authentication-Results: smtp1.osuosl.org (amavisd-new); + dkim=pass (2048-bit key) header.d=gmail.com +Received: from smtp1.osuosl.org ([127.0.0.1]) + by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id pNpfHVFpYXTY; Sun, 20 Feb 2022 16:29:14 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.8.0 +X-Greylist: whitelisted by SQLgrey-1.8.0 +Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com + [IPv6:2a00:1450:4864:20::12d]) + by smtp1.osuosl.org (Postfix) with ESMTPS id D666A81394; + Sun, 20 Feb 2022 16:29:13 +0000 (UTC) +Received: by mail-lf1-x12d.google.com with SMTP id b9so14359461lfv.7; + Sun, 20 Feb 2022 08:29:13 -0800 (PST) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; + h=mime-version:references:in-reply-to:from:date:message-id:subject:to + :cc; bh=c8TxWfd+wCUpl+uV2MO90xsSO+q9c9QXSPv06gz56dw=; + b=hLSMMSU/u88EXst1WpXTRS+ICikiITKb823cbd1AxLJItLvyStR91s7zVRo95wLwj2 + ilFSQyKnQ3K20nafYCcXNX+yneZGC7S/EnNpScJSh3hGKppeVBLbk3kqFXRc++LiuJws + kZXM1ahWJohq9HOabmJbsTyXooh+aRPhAOIVKUcq93sHfolbhBY150wm3S1EnFih6pQB + 8+jRPvGl/XZmiM9UVz0LEXpYx/ALaDVx5nIdNTWymdCO1VgPwy8AXXeCvs0KljolMLUh + 1CMH2NE7YLRlNNHyIOBhlZjTAA06c56QlU6SNAr49Y2s2M6T1uyG0o2XpDTf88SzYsvx + V6XA== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20210112; + h=x-gm-message-state:mime-version:references:in-reply-to:from:date + :message-id:subject:to:cc; + bh=c8TxWfd+wCUpl+uV2MO90xsSO+q9c9QXSPv06gz56dw=; + b=tbXmYP8YXLr4VUUwHOaCs/1+xuiVztTNytaxkn1qRLVax3RtFJNj6u2+9gCRFRra0s + CY64uMvWsc7sqIJV9JQcklU+tDM6OFgBv2om0qQRng0HpfiMd40vkGrq/eeb1srqpRgY + bzAxYdKtFwckR7aSxNX3IS1/xrZBXVmDWlWwB2AziymyIuS5KjqUkzphTb6XTtE2Uhk3 + 9C4hdny66Wwr0ebpndwOYPfQ92HFW6/EPzWwaYSARtFGeixkEeU/TOgwjBrKoGkqzXkz + Ux+Fzp0G8pZ1T0wrvvM6YTyxZGHW1I/jqfJeYYb2VEZbKKXCeeNqpezRXrhYyLPpbMZh + qjeQ== +X-Gm-Message-State: AOAM53246G6r9Sx/E+BROui6soZlvF0Lj3MJkCpgJu4w8njbkNI93Wb/ + MRApUnDFh6HuJ9XtO3QyUPekRNzW14MiHNbnTWc= +X-Google-Smtp-Source: ABdhPJxwD/wPUJByTgafgWGqZshOaqp5sbry+BRMDkXgO93PhrP8Iu6iumR7dHwiixawcauokllWTa0OfBR0b3REzuo= +X-Received: by 2002:a05:6512:1322:b0:443:161a:c693 with SMTP id + x34-20020a056512132200b00443161ac693mr11364531lfu.363.1645374551515; Sun, 20 + Feb 2022 08:29:11 -0800 (PST) +MIME-Version: 1.0 +References: <CAD5xwhik6jVQpP2_ss7d5o+pPLsqDCHuaXG41AMKHVYhZMXF1w@mail.gmail.com> + <YgS3sJvg6kG3WnVJ@petertodd.org> + <CAD5xwhi3Ja8gdU2h_6-1ck4kdU0TiC2Kx5O-61=f9=6JQSMs=A@mail.gmail.com> + <YhAwr7+9mGJAe2/p@petertodd.org> + <CAD5xwhi=sKckFZew75tZTogoeFABraWtJ6qMC+RgZjcirxYyZw@mail.gmail.com> + <YhC6yjoe3bAfBS+W@petertodd.org> +In-Reply-To: <YhC6yjoe3bAfBS+W@petertodd.org> +From: Jeremy Rubin <jeremy.l.rubin@gmail.com> +Date: Sun, 20 Feb 2022 08:29:00 -0800 +Message-ID: <CAD5xwhjR06Lp3ka-MqZQE64tfE5uDQB6TrMh06khjYrDzuT95g@mail.gmail.com> +To: Peter Todd <pete@petertodd.org> +Content-Type: multipart/alternative; boundary="000000000000aa684205d8759d3c" +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>, + lightning-dev <lightning-dev@lists.linuxfoundation.org>, + Jeremy <jlrubin@mit.edu> +Subject: Re: [bitcoin-dev] [Pre-BIP] Fee Accounts +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.15 +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: Sun, 20 Feb 2022 16:29:15 -0000 + +--000000000000aa684205d8759d3c +Content-Type: text/plain; charset="UTF-8" + +-- +@JeremyRubin <https://twitter.com/JeremyRubin> + + +On Sat, Feb 19, 2022 at 1:39 AM Peter Todd <pete@petertodd.org> wrote: + +> On Fri, Feb 18, 2022 at 04:38:27PM -0800, Jeremy Rubin wrote: +> > > As I said, it's a new kind of pinning attack, distinct from other types +> > of pinning attack. +> > +> > I think pinning is "formally defined" as sequences of transactions which +> > prevent or make it less likely for you to make any progress (in terms of +> > units of computation proceeding). +> +> Mentioning "computation" when talking about transactions is misleading: +> blockchain transactions have nothing to do with computation. +> + +It is in fact computation. Branding it as "misleading" is misleading... The +relevant literature is https://en.wikipedia.org/wiki/Non-blocking_algorithm, +sponsors helps get rid of deadlocking so that any thread can be guaranteed +to make progress. E.g., this is critical in Eltoo, which is effectively a +coordinated multi-party computation on-chain to compute the highest +sequence number known by any worker. + +That transactions are blobs of "verification" (which is also itself a +computation) less so than dynamic computations is irrelevant to the fact +that series of transactions do represent computations. + + + +> > Something that only increases possibility to make progress cannot be +> > pinning. +> +> It is incorrect to say that all use-cases have the property that any +> version of +> a transaction being mined is progress. +> + +It is progress, tautologically. Progress is formally definable as a +transaction of any kind getting mined. Pinning prevents progress by an +adversarial worker. Sponsoring enables progress, but it may not be your +preferred interleaving. That's OK, but it's inaccurate to say it is not +progress. + +Your understanding of how OpenTimestamps calendars work appears to be +> incorrect. There is no chain of unconfirmed transactions. Rather, OTS +> calendars +> use RBF to _update_ the timestamp tx with a new merkle tip hash for to all +> outstanding per-second commitments once per new block. In high fee +> situations +> it's normal for there to be dozens of versions of that same tx, each with a +> slightly higher feerate. +> + +I didn't claim there to be a chain of unconfirmed, I claimed that there +could be single output chain that you're RBF'ing one step per block. + +E.g., it could be something like + +A_0 -> {A_1 w/ CSV 1 block, OP_RETURN {blah, foo}} +A_1 -> {A_2 w/ CSV 1 block, OP_RETURN {bar}} + +such that A_i provably can't have an unconfirmed descendant. The notion +would be that you're replacing one with another. E.g., if you're updating +the calendar like: + + +Version 0: A_0 -> {A_1 w/ CSV 1 block, OP_RETURN {blah, foo}} +Version 1: A_0 -> {A_1 w/ CSV 1 block, OP_RETURN {blah, foo, bar}} +Version 2: A_0 -> {A_1 w/ CSV 1 block, OP_RETURN {blah, foo, bar, delta}} + +and version 1 gets mined, then in A_1's spend you simply shift delta to +that (next) calendar. + +A_1 -> {A_2 w/ CSV 1 block, OP_RETURN {delta}} + +Thus my claim that someone sponsoring a old version only can delay by 1 +block the calendar commit. + + + + + +> OTS calendars can handle any of those versions getting mined. But older +> versions getting mined wastes money, as the remaining commitments still +> need to +> get mined in a subsequent transaction. Those remaining commitments are also +> delayed by the time it takes for the next tx to get mined. +> +> There are many use-cases beyond OTS with this issue. For example, some +> entities +> use "in-place" replacement for update low-time-preference settlement +> transactions by adding new txouts and updating existing ones. Older +> versions of +> those settlement transactions getting mined rather than the newer version +> wastes money and delays settlement for the exact same reason it does in +> OTS. +> +> +> > Lastly, if you do get "necromanced" on an earlier RBF'd transaction by a +> > third party for OTS, you should be relatively happy because it cost you +> > less fees overall, since the undoing of your later RBF surely returned +> some +> > satoshis to your wallet. +> +> As I said above, no it doesn't. +> +> +It does save money since you had to pay to RBF, the N+1st txn will be +paying higher fee than the Nth. So if someone else sponsors an earlier +version, then you save whatever feerate/fee bumps you would have paid and +the funds are again in your change output (or something). You can apply +those change output savings to your next batch, which can include any +entries that have been dropped . + +--000000000000aa684205d8759d3c +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div dir=3D"ltr"><div><div dir=3D"ltr" class=3D"gmail_sign= +ature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr">--<br><a href=3D= +"https://twitter.com/JeremyRubin" target=3D"_blank">@JeremyRubin</a><br></d= +iv></div></div><br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" cl= +ass=3D"gmail_attr">On Sat, Feb 19, 2022 at 1:39 AM Peter Todd <<a href= +=3D"mailto:pete@petertodd.org">pete@petertodd.org</a>> wrote:<br></div><= +blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= +eft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pa= +dding-left:1ex">On Fri, Feb 18, 2022 at 04:38:27PM -0800, Jeremy Rubin wrot= +e:<br> +> > As I said, it's a new kind of pinning attack, distinct from o= +ther types<br> +> of pinning attack.<br> +> <br> +> I think pinning is "formally defined" as sequences of transa= +ctions which<br> +> prevent or make it less likely for you to make any progress (in terms = +of<br> +> units of computation proceeding).<br> +<br> +Mentioning "computation" when talking about transactions is misle= +ading:<br> +blockchain transactions have nothing to do with computation.<br></blockquot= +e><div><br></div><div><div class=3D"gmail_default" style=3D"font-family:ari= +al,helvetica,sans-serif;color:rgb(0,0,0)">It is in fact computation. Brandi= +ng it as "misleading" is misleading... The relevant literature is= +=C2=A0<a href=3D"https://en.wikipedia.org/wiki/Non-blocking_algorithm">http= +s://en.wikipedia.org/wiki/Non-blocking_algorithm</a>, sponsors helps get ri= +d of deadlocking so that any thread can be guaranteed to make progress. E.g= +., this is critical in Eltoo, which is effectively a coordinated multi-part= +y computation on-chain to compute the highest sequence number known by any = +worker.</div><div><div dir=3D"ltr" class=3D"gmail_signature"><div dir=3D"lt= +r"></div></div></div></div><div><br></div><div><div class=3D"gmail_default"= + style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(= +0,0,0)">That transactions are blobs of "verification" (which is a= +lso itself a computation) less so than dynamic computations is irrelevant t= +o the fact that series of transactions do represent computations.</div><br>= +</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0p= +x 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-c= +olor:rgb(204,204,204);padding-left:1ex"> +> Something that only increases possibility to make progress cannot be<b= +r> +> pinning.<br> +<br> +It is incorrect to say that all use-cases have the property that any versio= +n of<br> +a transaction being mined is progress.<br></blockquote><div><br></div><div>= +<div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-seri= +f;font-size:small;color:rgb(0,0,0)">It is progress, tautologically. Progres= +s is formally definable as a transaction of any kind getting mined. Pinning= + prevents progress by an adversarial worker. Sponsoring enables progress, b= +ut it may not be your preferred interleaving. That's OK, but it's i= +naccurate to say it is not progress.</div></div><div class=3D"gmail_default= +" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb= +(0,0,0)"><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p= +x 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color= +:rgb(204,204,204);padding-left:1ex"> +Your understanding of how OpenTimestamps calendars work appears to be<br> +incorrect. There is no chain of unconfirmed transactions. Rather, OTS calen= +dars<br> +use RBF to _update_ the timestamp tx with a new merkle tip hash for to all<= +br> +outstanding per-second commitments once per new block. In high fee situatio= +ns<br> +it's normal for there to be dozens of versions of that same tx, each wi= +th a<br> +slightly higher feerate.<br></blockquote><div><br></div><div class=3D"gmail= +_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c= +olor:rgb(0,0,0)">I didn't claim there to be a chain of unconfirmed, I c= +laimed that there could be single output chain that you're RBF'ing = +one step per block.</div><div class=3D"gmail_default" style=3D"font-family:= +arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div= + class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fo= +nt-size:small;color:rgb(0,0,0)">E.g., it could be something like</div><div = +class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fon= +t-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style= +=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)= +">A_0 -> {A_1 w/ CSV 1 block, OP_RETURN {blah, foo}}</div><div class=3D"= +gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sm= +all;color:rgb(0,0,0)">A_1 -> {A_2 w/ CSV 1 block, OP_RETURN {bar}}</div>= +<div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-seri= +f;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" = +style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0= +,0,0)">such that A_i provably can't have an unconfirmed descendant. The= + notion would be that you're replacing one with another. E.g., if you&#= +39;re updating the calendar like:</div><div class=3D"gmail_default" style= +=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)= +"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helveti= +ca,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gma= +il_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small= +;color:rgb(0,0,0)"><div class=3D"gmail_default">Version 0: A_0 -> {A_1 w= +/ CSV 1 block, OP_RETURN {blah, foo}}</div><div class=3D"gmail_default">Ver= +sion 1: A_0 -> {A_1 w/ CSV 1 block, OP_RETURN {blah, foo, bar}}</div><di= +v class=3D"gmail_default">Version 2: A_0 -> {A_1 w/ CSV 1 block, OP_RETU= +RN {blah, foo, bar, delta}}</div><br class=3D"gmail-Apple-interchange-newli= +ne"></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica= +,sans-serif;font-size:small;color:rgb(0,0,0)">and version 1 gets mined, the= +n in A_1's spend you simply shift delta to that (next) calendar.</div><= +div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= +;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" s= +tyle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,= +0,0)"><div class=3D"gmail_default">A_1 -> {A_2 w/ CSV 1 block, OP_RETURN= + {delta}}</div><br class=3D"gmail-Apple-interchange-newline"></div><div cla= +ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-s= +ize:small;color:rgb(0,0,0)">Thus my claim that someone sponsoring a old ver= +sion only can delay by 1 block the calendar commit.</div><div class=3D"gmai= +l_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;= +color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-fami= +ly:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><= +div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= +;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" s= +tyle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,= +0,0)"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,hel= +vetica,sans-serif;font-size:small;color:rgb(0,0,0)"></div><blockquote class= +=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo= +rder-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"> +<br> +OTS calendars can handle any of those versions getting mined. But older<br> +versions getting mined wastes money, as the remaining commitments still nee= +d to<br> +get mined in a subsequent transaction. Those remaining commitments are also= +<br> +delayed by the time it takes for the next tx to get mined.<br> +<br> +There are many use-cases beyond OTS with this issue. For example, some enti= +ties<br> +use "in-place" replacement for update low-time-preference settlem= +ent<br> +transactions by adding new txouts and updating existing ones. Older version= +s of<br> +those settlement transactions getting mined rather than the newer version<b= +r> +wastes money and delays settlement for the exact same reason it does in OTS= +.<br><br> +<br> +> Lastly, if you do get "necromanced" on an earlier RBF'd = +transaction by a<br> +> third party for OTS, you should be relatively happy because it cost yo= +u<br> +> less fees overall, since the undoing of your later RBF surely returned= + some<br> +> satoshis to your wallet.<br> +<br> +As I said above, no it doesn't.<br><br></blockquote><div><br></div><div= + class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fo= +nt-size:small;color:rgb(0,0,0)">It does save money since you had to pay to = +RBF, the N+1st txn will be paying higher fee than the Nth. So if someone el= +se sponsors an earlier version, then you save whatever feerate/fee bumps yo= +u would have paid and the funds are again in your change output (or somethi= +ng). You can apply those change output savings to your next batch, which ca= +n include any entries that have been dropped .</div></div></div> + +--000000000000aa684205d8759d3c-- + |