path: root/ef/4d54eec2bd88686610d6acafd434565773e560

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 9ACBBC0033;
 Sun, 20 Feb 2022 16:29:49 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 89974813BC;
 Sun, 20 Feb 2022 16:29:49 +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 q02EpUmvAneR; Sun, 20 Feb 2022 16:29:48 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com
 [IPv6:2a00:1450:4864:20::22f])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 78B5E81376;
 Sun, 20 Feb 2022 16:29:48 +0000 (UTC)
Received: by mail-lj1-x22f.google.com with SMTP id e2so7926633ljq.12;
 Sun, 20 Feb 2022 08:29:48 -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=FQ5Ht9zNc6ROFAM7V9ZrvPPAnGk9ISOQzdRbPn4uDFI=;
 b=VhipUlnytfT3x8zOhuntSTdV8F4mkCfq8hXs9DZmgecIpV/04Gnn/w7xBtPbtVDP5H
 zIf9MZFZ46xSYjS07vvM0H8+Av3fbdcu28jZJ0S7+zcp9swjwXMDVCUTDrbr1x0Mge3Y
 7+3ZoOVrW/dK2+VDSwWBqlxzyGyNvoBJwMw8idZnP6NyFoCGJwsSSfzy/7hzLwnpbyrx
 5lXHRqqMITToRU33ZcEYlMNK/HEzZavQgS1Coo27/r8CZMrI/woLUjIUEsa+USDAnTNa
 O/Eo4fabwDVY3LZ+JgaYwy4pDkXu1mvSEvYqGq4/2gLUnNoH1YQNtW2sTYa9dWgcQGji
 fouQ==
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=FQ5Ht9zNc6ROFAM7V9ZrvPPAnGk9ISOQzdRbPn4uDFI=;
 b=j7gIDpzGUl8Yt6lPdzz6SwWscNXHblG1WiB9dLVrTdfFnkBplutC2imJoK78dEtiVc
 i3muhMdkoYFHrUH9PccHb/ulQvQo8N9zY7sO42zkRZ6MVsnfhwvETKfpzrf/MpctsUFQ
 PUE3neWVEBi5CPX9VyqJaR4PkkiRJxcoGQD+xx93CzICZEWHkaS90pUOf25gNGBjRAwu
 RijHsQ305yzFUYYL3xi2ArqUpeO4mHlUgVozbZ5baFsntAbBC/YeH809hWFMRSaMo4eu
 JKe3t7ATIlArlLwYKcjURkSXq/J/WYI+jZK8atrpqbXCkke3AbfTKE8CX+ndaLpX8pfn
 AjOA==
X-Gm-Message-State: AOAM533wUd8eSr2agrHtadpBnA69AuoMid4MxaWZxhrtVzDQVa3nOiDx
 wSWhNtMsrHJFa6ipXBzQxTeg/EGFDAMXm0f9CCBfhVqqQ2TQGA==
X-Google-Smtp-Source: ABdhPJz7U3o35G9PcWNSXbMYJWCzcjXhYZ3mCp+kFHj+sm51zq/hYdgK3jDlvQWN0PcNsZE4exNOXBZ+WCrI7THfaHA=
X-Received: by 2002:a2e:b16e:0:b0:23b:92f0:9191 with SMTP id
 a14-20020a2eb16e000000b0023b92f09191mr11418514ljm.57.1645374586386; Sun, 20
 Feb 2022 08:29:46 -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>
 <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
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:49 -0000

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