diff options
| author | Jeremy Rubin <jeremy.l.rubin@gmail.com> | 2022-04-17 13:57:28 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-04-17 20:57:44 +0000 |
| commit | add015cb0f750e846345eacfbc4703b19f062c87 (patch) | |
| tree | 35869a55ab63a93d2d217292cc622390470faa1e | |
| parent | e7dd8da71a71ecac7d099e99e5c0801fb64e3e94 (diff) | |
| download | pi-bitcoindev-add015cb0f750e846345eacfbc4703b19f062c87.tar.gz pi-bitcoindev-add015cb0f750e846345eacfbc4703b19f062c87.zip | |
Re: [bitcoin-dev] [Pre-BIP] Fee Accounts
| -rw-r--r-- | 5e/11b5ee3fc01d9ebd4f1befe3fff17c85d4ca9e | 448 |
1 files changed, 448 insertions, 0 deletions
diff --git a/5e/11b5ee3fc01d9ebd4f1befe3fff17c85d4ca9e b/5e/11b5ee3fc01d9ebd4f1befe3fff17c85d4ca9e new file mode 100644 index 000000000..64c6291f9 --- /dev/null +++ b/5e/11b5ee3fc01d9ebd4f1befe3fff17c85d4ca9e @@ -0,0 +1,448 @@ +Return-Path: <jeremy.l.rubin@gmail.com> +Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 6808AC002C; + Sun, 17 Apr 2022 20:57:44 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp4.osuosl.org (Postfix) with ESMTP id 4E83641C35; + Sun, 17 Apr 2022 20:57:44 +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: smtp4.osuosl.org (amavisd-new); + dkim=pass (2048-bit key) header.d=gmail.com +Received: from smtp4.osuosl.org ([127.0.0.1]) + by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id 1V9Cx0BCDYkJ; Sun, 17 Apr 2022 20:57:42 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.8.0 +X-Greylist: whitelisted by SQLgrey-1.8.0 +Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com + [IPv6:2a00:1450:4864:20::229]) + by smtp4.osuosl.org (Postfix) with ESMTPS id 4046741C31; + Sun, 17 Apr 2022 20:57:42 +0000 (UTC) +Received: by mail-lj1-x229.google.com with SMTP id c15so14961809ljr.9; + Sun, 17 Apr 2022 13:57:41 -0700 (PDT) +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=6FwbimsW/+Bl/evBU9oiUQVMkySX8UMOByeFjSPV28o=; + b=i9sFh2OR05pQBcs6RBekwYuEviPYUE+Jx8j5/Uh1UeHz+0nJIDpR56L0rJOZHqg740 + 2Pu3CaWMswVLsg4J2OIoMOKiwj9bBm3QtXs+bqOw53XCNTyjMAKiTwCUYRHtgDcuAK2V + ESneliFUu5Z7Vx2Cu7EnVbs/N+vJIusQ7rGrhRp3mkqKh10GYpoxT+CPvKx4KvzNHoJc + 65Aw4Al+aSLL1BafegBQx8kjOI/FOKKojkqselLMJ3t8Vj76GdH0d9eDKQd1H/7UMvM7 + NBGtvUa8gJdFuPYqH4Dav602WPPNCuHqRce843KIGxoEmyStQzCUUXeDGusEPqwqDN0d + t/mg== +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=6FwbimsW/+Bl/evBU9oiUQVMkySX8UMOByeFjSPV28o=; + b=ZKpGCr2egS/90UBi0prjJ2/43iW8nENFh9tUjiwXtOGaTgvZX7KmzcW55fldxHPsUw + zIE8du+Xno888jc8RVnknzVAnogVU5L/VYumV8uYJARnqwcVm8KBXR6B2DvWw7ekjm/j + y5z5W7MI/JZyJ0xOvhPWWMGrpAhWox3wjcn5VtME7z0Ait1mySCjAcneHXiIONb38BR/ + Z8IYBrT5EtSNgzNSbi4ypyBm7AbvSW5RLNHi2fty7bMzJwSgjWjVU6fNO9nzymA6f8OP + Kj6mJfK4t506Ef/JaBU1oPqTa1DEa33ogqFuWzydWw7NlB80KwErsO/wbqzO57D5HX8y + RNTg== +X-Gm-Message-State: AOAM532wxbeugQ6isQYPjWMxks+7SgZaIcHFoWwm5z0UxJc6Kt3Cpr+o + N+lIyhqKhIbpBVi7I0HkisCZfpY/xFB+yS2efRU+DBQV +X-Google-Smtp-Source: ABdhPJwAQBnYT5SyIrGU1EOsQBsDhQKq2QxjcXOmF/pZaeK5PZxJNrwcS5u39A9eYkH3pRSGl9qGGrqg4X5IXh/WN3A= +X-Received: by 2002:a05:651c:2cb:b0:24d:aa5e:fe11 with SMTP id + f11-20020a05651c02cb00b0024daa5efe11mr5230076ljo.425.1650229059778; Sun, 17 + Apr 2022 13:57:39 -0700 (PDT) +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> + <CAD5xwhjR06Lp3ka-MqZQE64tfE5uDQB6TrMh06khjYrDzuT95g@mail.gmail.com> + <YlMw5NxXnGV9WrVg@petertodd.org> + <CAD5xwhj1kaJf+QCcf1MOtaAec-xTTr2M9LkJPCu2Ej0L9_3iPg@mail.gmail.com> + <YlmGv6WbDeDqGJKX@petertodd.org> +In-Reply-To: <YlmGv6WbDeDqGJKX@petertodd.org> +From: Jeremy Rubin <jeremy.l.rubin@gmail.com> +Date: Sun, 17 Apr 2022 13:57:28 -0700 +Message-ID: <CAD5xwhgGgq30C7GniNh1_DobPe+P4NTJySUkDiBZBj=OjzO5KA@mail.gmail.com> +To: Peter Todd <pete@petertodd.org> +Content-Type: multipart/alternative; boundary="000000000000e7fc1e05dcdfe472" +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, 17 Apr 2022 20:57:44 -0000 + +--000000000000e7fc1e05dcdfe472 +Content-Type: text/plain; charset="UTF-8" + +the 'lots of people' stuff (get confused, can't figure out what i'm +quoting, actually are reading this conversation) is an appeal to an +authority that doesn't exist. If something is unclear to you, let me know. +If it's unclear to a supposed existential person or set of persons, they +can let me know. + + +concretely, I am confused by how OTS can both support RBF for updating to +larger commitments (the reason you're arguing with me) and not have an +epoch based re-comittings scheme and still be correct. My assumption now, +short of a coherent spec that's not just 'read the code', is that OTS +probably is not formally correct and has some holes in what is +committed to, or relies on clients re-requesting proofs if they fail to be +committed. in any case, you would be greatly aided by having an actual spec +for OTS since i'm not interested in the specifics of OTS software, but I'm +willing to look at the protocol. So if you do that, maybe we can talk more +about the issue you see with how sponsors works. + +further, I think that if there is something that sponsors does that could +make a hypothetical OTS-like service work better, in a way that would be +opaque (read: soft-fork like wrt compatibility) to clients, then we should +just change what OTS is rather than committing ourselves to a worse design +in service of some unstated design goals. In particular, it seems that +OTS's servers can be linearized and because old clients aren't looking for +linearization, then the new linearization won't be a breaking change for +old clients, just calendar servers. And new clients can benefit from +linearization. +-- +@JeremyRubin <https://twitter.com/JeremyRubin> + + +On Fri, Apr 15, 2022 at 7:52 AM Peter Todd <pete@petertodd.org> wrote: + +> On Mon, Apr 11, 2022 at 09:18:10AM -0400, Jeremy Rubin wrote: +> > > nonsense marketing +> > +> > I'm sure the people who are confused about "blockchain schemes as \"world +> > computers\" and other nonsense +> > marketing" are avid and regular readers of the bitcoin devs mailing list +> so +> > I offer my sincerest apologies to all members of the intersection of +> those +> > sets who were confused by the description given. +> +> Of course, uninformed people _do_ read all kinds of technical materials. +> And +> more importantly, those technical materials get quoted by journalists, +> scammers, etc. +> +> > > useless work +> > +> > progress is not useless work, it *is* useful work in this context. you +> have +> > committed to some subset of data that you requested -- if it was +> 'useless', +> > why did you *ever* bother to commit it in the first place? However, it is +> > not 'maximally useful' in some sense. However, progress is progress -- +> > suppose you only confirmed 50% of the commitments, is that not progress? +> If +> > you just happened to observe 50% of the commitments commit because of +> > proximity to the time a block was mined and tx propagation naturally +> would +> > you call it useless? +> +> Please don't trim quoted text to the point where all context is lost. Lots +> of +> people read this mailing list and doing that isn't helpful to them. +> +> > > Remember that OTS simply proves data in the past. Nothing more. +> > > OTS doesn't have a chain of transactions +> > Gotcha -- I've not been able to find an actual spec of Open Time Stamps +> +> The technical spec of OpenTimestamps is of course the normative validation +> source code, currently python-opentimestamps, similar to how the technical +> spec +> of Bitcoin is the consensus parts of the Bitcoin Core codebase. The +> explanatory +> docs are linked on https://opentimestamps.org under the "How It Works" +> section. +> It'd be good to take the linked post in that section and turn it into +> better +> explanatory materials with graphics (esp interactive/animated graphics). +> +> > anywhere, so I suppose I just assumed based on how I think it *should* +> > work. Having a chain of transactions would serve to linearize history of +> > OTS commitments which would let you prove, given reorgs, that knowledge +> of +> > commit A was before B a bit more robustly. +> +> I'll reply to this as a separate email as this discussion - while useful - +> is +> getting quite off topic for this thread. +> +> > > I'd rather do one transaction with all pending commitments at a +> > particular time +> > rather than waste money on mining two transactions for a given set of +> > commitments +> > +> > This sounds like a personal preference v.s. a technical requirement. +> > +> > You aren't doing any extra transactions in the model i showed, what +> you're +> > doing is selecting the window for the next based on the prior conf. +> +> ...the model you showed is wrong, as there is no reason to have a +> linearized +> transaction history. OpenTimestamps proofs don't even have the concept of +> transactions: the proof format proves that data existed prior to a merkle +> root +> of a particular Bitcoin block. Not a Bitcoin transaction. +> +> > See the diagram below, you would have to (if OTS is correct) support this +> > sort of 'attempt/confirm' head that tracks attempted commitments and +> > confirmed ones and 'rewinds' after a confirm to make the next commit +> > contain the prior attempts that didn't make it. +> > +> > +> [.........................................................................] +> > ------^ confirm head tx 0 at height 34 +> > ------------------------^ attempt head after tx 0 +> > -----------^ confirm head tx 1 at height 35 +> > --------------------------^ attempt head after tx 1 +> > ------------^ confirm head tx 2 at height 36 +> > -------------------------------^ +> > attempt head after tx 2 +> > -------------------------------^ +> > confirm head tx 3 at height 37 +> > +> > you can compare this to a "spherical cow" model where RBF is always +> perfect +> > and guaranteed inclusion: +> > +> > +> > +> [.........................................................................] +> > ------^ confirm head tx 0 at height 34 +> > -------------------------^ confirm head tx 1 at height 35 +> > -----------^ confirm head at tx 1 +> > height 36 +> > -----------------^ +> > confirm head tx 3 at height 37 +> > +> > The same number of transactions gets used over the time period. +> +> None of the above has anything to do with how OpenTimestamps works. +> +> Anyway, getting back to the topic at hand, I remain of the opinion that in +> the +> unlikely event that fee accounts is ever implemented, it should be opt-in. +> +> -- +> https://petertodd.org 'peter'[:-1]@petertodd.org +> + +--000000000000e7fc1e05dcdfe472 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he= +lvetica,sans-serif;font-size:small;color:#000000">the 'lots of people&#= +39; stuff (get confused, can't figure out what i'm quoting, actuall= +y are reading this conversation) is an appeal to an authority that doesn= +9;t exist. If something is unclear to you, let me know. If it's unclear= + to a supposed existential person or set of persons, they can let me know.<= +/div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans= +-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail_default= +" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#00= +0000"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,hel= +vetica,sans-serif;font-size:small;color:#000000">concretely, I am confused = +by how OTS=C2=A0can both support RBF for updating to larger commitments=C2= +=A0(the reason you're arguing with me) and not have an epoch based re-c= +omittings scheme and still be correct. My assumption now, short of a cohere= +nt spec that's not just 'read the code', is that OTS probably i= +s not formally correct and has some holes in what is committed=C2=A0to, or = +relies on clients re-requesting proofs if they fail to be committed. in any= + case, you would be greatly aided by having an actual spec for OTS since i&= +#39;m not interested in the specifics of OTS software, but I'm willing = +to look at the protocol. So if you do that, maybe we can talk more about th= +e issue you see with how sponsors works.</div><div class=3D"gmail_default" = +style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#0000= +00"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helve= +tica,sans-serif;font-size:small;color:#000000">further, I think that if the= +re is something that sponsors does that could make a hypothetical OTS-like = +service work better, in a way that would be opaque (read: soft-fork like wr= +t compatibility) to clients, then we should just change what OTS is rather = +than committing ourselves to a worse design in service of some unstated des= +ign goals. In particular, it seems that OTS's=C2=A0servers can be linea= +rized and because old clients aren't looking for linearization, then th= +e new linearization won't be a breaking change for old clients, just ca= +lendar servers. And new clients can benefit from linearization.</div><div><= +div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_signature= +"><div dir=3D"ltr">--<br><a href=3D"https://twitter.com/JeremyRubin" target= +=3D"_blank">@JeremyRubin</a><br></div></div></div><br></div><br><div class= +=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Apr 15, 2022= + at 7:52 AM Peter Todd <<a href=3D"mailto:pete@petertodd.org">pete@peter= +todd.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D= +"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;bor= +der-left-color:rgb(204,204,204);padding-left:1ex">On Mon, Apr 11, 2022 at 0= +9:18:10AM -0400, Jeremy Rubin wrote:<br> +> > nonsense marketing<br> +> <br> +> I'm sure the people who are confused about "blockchain scheme= +s as \"world<br> +> computers\" and other nonsense<br> +> marketing" are avid and regular readers of the bitcoin devs maili= +ng list so<br> +> I offer my sincerest apologies to all members of the intersection of t= +hose<br> +> sets who were confused by the description given.<br> +<br> +Of course, uninformed people _do_ read all kinds of technical materials. An= +d<br> +more importantly, those technical materials get quoted by journalists,<br> +scammers, etc.<br> +<br> +> > useless work<br> +> <br> +> progress is not useless work, it *is* useful work in this context. you= + have<br> +> committed to some subset of data that you requested -- if it was '= +useless',<br> +> why did you *ever* bother to commit it in the first place? However, it= + is<br> +> not 'maximally useful' in some sense. However, progress is pro= +gress --<br> +> suppose you only confirmed 50% of the commitments, is that not progres= +s? If<br> +> you just happened to observe 50% of the commitments commit because of<= +br> +> proximity to the time a block was mined and tx propagation naturally w= +ould<br> +> you call it useless?<br> +<br> +Please don't trim quoted text to the point where all context is lost. L= +ots of<br> +people read this mailing list and doing that isn't helpful to them.<br> +<br> +> > Remember that OTS simply proves data in the past. Nothing more.<b= +r> +> > OTS doesn't have a chain of transactions<br> +> Gotcha -- I've not been able to find an actual spec of Open Time S= +tamps<br> +<br> +The technical spec of OpenTimestamps is of course the normative validation<= +br> +source code, currently python-opentimestamps, similar to how the technical = +spec<br> +of Bitcoin is the consensus parts of the Bitcoin Core codebase. The explana= +tory<br> +docs are linked on <a href=3D"https://opentimestamps.org" rel=3D"noreferrer= +" target=3D"_blank">https://opentimestamps.org</a> under the "How It W= +orks" section.<br> +It'd be good to take the linked post in that section and turn it into b= +etter<br> +explanatory materials with graphics (esp interactive/animated graphics).<br= +> +<br> +> anywhere, so I suppose I just assumed based on how I think it *should*= +<br> +> work. Having a chain of transactions would serve to linearize history = +of<br> +> OTS commitments which would let you prove, given reorgs, that knowledg= +e of<br> +> commit A was before B a bit more robustly.<br> +<br> +I'll reply to this as a separate email as this discussion - while usefu= +l - is<br> +getting quite off topic for this thread.<br> +<br> +> >=C2=A0 I'd rather do one transaction with all pending commitme= +nts at a<br> +> particular time<br> +> rather than waste money on mining two transactions for a given set of<= +br> +> commitments<br> +> <br> +> This sounds like a personal preference v.s. a technical requirement.<b= +r> +> <br> +> You aren't doing any extra transactions in the model i showed, wha= +t you're<br> +> doing is selecting the window for the next based on the prior conf.<br= +> +<br> +...the model you showed is wrong, as there is no reason to have a linearize= +d<br> +transaction history. OpenTimestamps proofs don't even have the concept = +of<br> +transactions: the proof format proves that data existed prior to a merkle r= +oot<br> +of a particular Bitcoin block. Not a Bitcoin transaction.<br> +<br> +> See the diagram below, you would have to (if OTS is correct) support t= +his<br> +> sort of 'attempt/confirm' head that tracks attempted commitmen= +ts and<br> +> confirmed ones and 'rewinds' after a confirm to make the next = +commit<br> +> contain the prior attempts that didn't make it.<br> +> <br> +> [.....................................................................= +....]<br> +>=C2=A0 ------^ confirm head tx 0 at height 34<br> +>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0------------------------^ attempt hea= +d after tx 0<br> +>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -----------^ confirm head tx 1 at he= +ight 35<br> +>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = +=C2=A0 =C2=A0--------------------------^ attempt head after tx 1<br> +>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = +=C2=A0 =C2=A0------------^ confirm head tx 2 at height 36<br> +>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ------------= +-------------------^<br> +> attempt head after tx 2<br> +>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0------= +-------------------------^<br> +> confirm head tx 3 at height 37<br> +> <br> +> you can compare this to a "spherical cow" model where RBF is= + always perfect<br> +> and guaranteed inclusion:<br> +> <br> +> <br> +> [.....................................................................= +....]<br> +>=C2=A0 ------^ confirm head tx 0 at height 34<br> +>=C2=A0 =C2=A0 =C2=A0 =C2=A0 -------------------------^ confirm head tx = +1 at height 35<br> +>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -----= +------^ confirm head at tx 1<br> +> height 36<br> +>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= +=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -----------------^<br> +> confirm head tx 3 at height 37<br> +> <br> +> The same number of transactions gets used over the time period.<br> +<br> +None of the above has anything to do with how OpenTimestamps works.<br> +<br> +Anyway, getting back to the topic at hand, I remain of the opinion that in = +the<br> +unlikely event that fee accounts is ever implemented, it should be opt-in.<= +br> +<br> +-- <br> +<a href=3D"https://petertodd.org" rel=3D"noreferrer" target=3D"_blank">http= +s://petertodd.org</a> 'peter'[:-1]@<a href=3D"http://petertodd.org"= + rel=3D"noreferrer" target=3D"_blank">petertodd.org</a><br> +</blockquote></div> + +--000000000000e7fc1e05dcdfe472-- + |