path: root/5e/11b5ee3fc01d9ebd4f1befe3fff17c85d4ca9e

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 &#39;lots of people&#=
39; stuff (get confused, can&#39;t figure out what i&#39;m quoting, actuall=
y are reading this conversation) is an appeal to an authority that doesn&#3=
9;t exist. If something is unclear to you, let me know. If it&#39;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&#39;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&#39;s not just &#39;read the code&#39;, 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&#39;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&#39;s=C2=A0servers can be linea=
rized and because old clients aren&#39;t looking for linearization, then th=
e new linearization won&#39;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 &lt;<a href=3D"mailto:pete@petertodd.org">pete@peter=
todd.org</a>&gt; 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>
&gt; &gt; nonsense marketing<br>
&gt; <br>
&gt; I&#39;m sure the people who are confused about &quot;blockchain scheme=
s as \&quot;world<br>
&gt; computers\&quot; and other nonsense<br>
&gt; marketing&quot; are avid and regular readers of the bitcoin devs maili=
ng list so<br>
&gt; I offer my sincerest apologies to all members of the intersection of t=
hose<br>
&gt; 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>
&gt; &gt; useless work<br>
&gt; <br>
&gt; progress is not useless work, it *is* useful work in this context. you=
 have<br>
&gt; committed to some subset of data that you requested -- if it was &#39;=
useless&#39;,<br>
&gt; why did you *ever* bother to commit it in the first place? However, it=
 is<br>
&gt; not &#39;maximally useful&#39; in some sense. However, progress is pro=
gress --<br>
&gt; suppose you only confirmed 50% of the commitments, is that not progres=
s? If<br>
&gt; you just happened to observe 50% of the commitments commit because of<=
br>
&gt; proximity to the time a block was mined and tx propagation naturally w=
ould<br>
&gt; you call it useless?<br>
<br>
Please don&#39;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&#39;t helpful to them.<br>
<br>
&gt; &gt; Remember that OTS simply proves data in the past. Nothing more.<b=
r>
&gt; &gt; OTS doesn&#39;t have a chain of transactions<br>
&gt; Gotcha -- I&#39;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 &quot;How It W=
orks&quot; section.<br>
It&#39;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>
&gt; anywhere, so I suppose I just assumed based on how I think it *should*=
<br>
&gt; work. Having a chain of transactions would serve to linearize history =
of<br>
&gt; OTS commitments which would let you prove, given reorgs, that knowledg=
e of<br>
&gt; commit A was before B a bit more robustly.<br>
<br>
I&#39;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>
&gt; &gt;=C2=A0 I&#39;d rather do one transaction with all pending commitme=
nts at a<br>
&gt; particular time<br>
&gt; rather than waste money on mining two transactions for a given set of<=
br>
&gt; commitments<br>
&gt; <br>
&gt; This sounds like a personal preference v.s. a technical requirement.<b=
r>
&gt; <br>
&gt; You aren&#39;t doing any extra transactions in the model i showed, wha=
t you&#39;re<br>
&gt; 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&#39;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>
&gt; See the diagram below, you would have to (if OTS is correct) support t=
his<br>
&gt; sort of &#39;attempt/confirm&#39; head that tracks attempted commitmen=
ts and<br>
&gt; confirmed ones and &#39;rewinds&#39; after a confirm to make the next =
commit<br>
&gt; contain the prior attempts that didn&#39;t make it.<br>
&gt; <br>
&gt; [.....................................................................=
....]<br>
&gt;=C2=A0 ------^ confirm head tx 0 at height 34<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0------------------------^ attempt hea=
d after tx 0<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -----------^ confirm head tx 1 at he=
ight 35<br>
&gt;=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>
&gt;=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>
&gt;=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>
&gt; attempt head after tx 2<br>
&gt;=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>
&gt; confirm head tx 3 at height 37<br>
&gt; <br>
&gt; you can compare this to a &quot;spherical cow&quot; model where RBF is=
 always perfect<br>
&gt; and guaranteed inclusion:<br>
&gt; <br>
&gt; <br>
&gt; [.....................................................................=
....]<br>
&gt;=C2=A0 ------^ confirm head tx 0 at height 34<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 -------------------------^ confirm head tx =
1 at height 35<br>
&gt;=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>
&gt; height 36<br>
&gt;=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>
&gt; confirm head tx 3 at height 37<br>
&gt; <br>
&gt; 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> &#39;peter&#39;[:-1]@<a href=3D"http://petertodd.org"=
 rel=3D"noreferrer" target=3D"_blank">petertodd.org</a><br>
</blockquote></div>

--000000000000e7fc1e05dcdfe472--