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>
 <kJWi5A4sc0UEU4JrtSg3gbR_M1UTp15XW3Oj5B5cQZQvygFn9pIqrxVxCU0sFjG5L05fqDFH6nz2PnU0sE_zVNMGsCXzmtJeDAc1kEYmYKA=@protonmail.com>
 <590cf52920040c9cf7517b219624bbb5@willtech.com.au>
 <W70OBHZ0-DtXNdUQfA6YOmC3BVrl0zSo-xl8IQRIRSkKh7xnEV3QQwOYrgSQ8L1HvWML_bPEXB23tad6ta4lnb3caVR4rPu0mjCmVMRD264=@protonmail.com>
In-Reply-To: <W70OBHZ0-DtXNdUQfA6YOmC3BVrl0zSo-xl8IQRIRSkKh7xnEV3QQwOYrgSQ8L1HvWML_bPEXB23tad6ta4lnb3caVR4rPu0mjCmVMRD264=@protonmail.com>
From: Jeremy Rubin <jeremy.l.rubin@gmail.com>
Date: Sun, 20 Feb 2022 08:29:35 -0800
Message-ID: <CAD5xwhjk+PtkbjvD9yEjP=tc44HEJp2hXeGMuV79K8ZS6nMssQ@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="000000000000be7bc905d8759f3c"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 lightning-dev <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev]  [Pre-BIP] Fee Accounts
Precedence: list

--000000000000be7bc905d8759f3c
Content-Type: text/plain; charset="UTF-8"

opt-in or explicit tagging of fee account is a bad design IMO.

As pointed out by James O'Beirne in the other email, having an explicit key
required means you have to pre-plan.... suppose you're building a vault
meant to distribute funds over many years, do you really want a *specific*
precommitted key you have to maintain? What happens to your ability to bump
should it be compromised (which may be more likely if it's intended to be a
hot-wallet function for bumping).

Furthermore, it's quite often the case that someone might do a transaction
that pays you that is low fee that you want to bump but they choose to
opt-out... then what? It's better that you should always be able to fee
bump.


--
@JeremyRubin <https://twitter.com/JeremyRubin>


On Sun, Feb 20, 2022 at 6:24 AM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

> Good morning DA,
>
>
> > Agreed, you cannot rely on a replacement transaction would somehow
> > invalidate a previous version of it, it has been spoken into the gossip
> > and exists there in mempools somewhere if it does, there is no guarantee
> > that anyone has ever heard of the replacement transaction as there is no
> > consensus about either the previous version of the transaction or its
> > replacement until one of them is mined and the block accepted. -DA.
>
> As I understand from the followup from Peter, the point is not "this
> should never happen", rather the point is "this should not happen *more
> often*."
>
> Regards,
> ZmnSCPxj
>

--000000000000be7bc905d8759f3c
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"><div class=3D"gmail_defau=
lt">opt-in or explicit tagging of fee account is a bad design IMO.</div><di=
v class=3D"gmail_default"><br></div><div class=3D"gmail_default">As pointed=
 out by James O&#39;Beirne in the other email, having an explicit key requi=
red means you have to pre-plan.... suppose you&#39;re building a vault mean=
t to distribute funds over many years, do you really want a *specific* prec=
ommitted=C2=A0key you have to maintain? What happens to your ability to bum=
p should it be compromised (which may be more likely if it&#39;s intended t=
o be a hot-wallet function for bumping).</div><div class=3D"gmail_default">=
<br></div><div class=3D"gmail_default">Furthermore, it&#39;s quite often th=
e case that someone might do a transaction that pays you that is low fee th=
at you want to bump but they choose to opt-out... then what? It&#39;s bette=
r that you should always be able to fee bump.</div><div><div dir=3D"ltr" st=
yle=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif"></div></=
div><br class=3D"gmail-Apple-interchange-newline"></div><br clear=3D"all"><=
div><div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_sign=
ature"><div dir=3D"ltr">--<br><a href=3D"https://twitter.com/JeremyRubin" t=
arget=3D"_blank">@JeremyRubin</a><br></div></div></div><br></div><br><div c=
lass=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Feb 20, =
2022 at 6:24 AM ZmnSCPxj &lt;<a href=3D"mailto:ZmnSCPxj@protonmail.com">Zmn=
SCPxj@protonmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-sty=
le:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Good morning =
DA,<br>
<br>
<br>
&gt; Agreed, you cannot rely on a replacement transaction would somehow<br>
&gt; invalidate a previous version of it, it has been spoken into the gossi=
p<br>
&gt; and exists there in mempools somewhere if it does, there is no guarant=
ee<br>
&gt; that anyone has ever heard of the replacement transaction as there is =
no<br>
&gt; consensus about either the previous version of the transaction or its<=
br>
&gt; replacement until one of them is mined and the block accepted. -DA.<br=
>
<br>
As I understand from the followup from Peter, the point is not &quot;this s=
hould never happen&quot;, rather the point is &quot;this should not happen =
*more often*.&quot;<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div>

--000000000000be7bc905d8759f3c--