Date: Sun, 20 Feb 2022 16:34:35 +0000
To: Jeremy <jlrubin@mit.edu>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <erAXod9aNdpQ3eMQQsfHwcaCe0S0rGU1Z9VnDy2yxlywBaSdaMJOEZ0XnGbIMSjRm9e3M4rJCwQuIgoNzrvw57e3jYxvi1cZPTeFYCjZ9vU=@protonmail.com>
In-Reply-To: <CAD5xwhgEeTETburW=OBgHNe_V1kk8o06TDQLiLgdfmP2AEVuPg@mail.gmail.com>
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>
 <CAD5xwhgEeTETburW=OBgHNe_V1kk8o06TDQLiLgdfmP2AEVuPg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
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

Good morning Jeremy,

> 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 k=
ey 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=C2=A0key you have to maintain? What happens to your ability to=
 bump should it be compromised (which may be more likely if it's intended t=
o be a hot-wallet function for bumping).
>
> Furthermore, it's quite often the case that someone might do a transactio=
n that pays you that is low fee that you want to bump but they choose to op=
t-out... then what? It's better that you should always be able to fee bump.

Good point.

For the latter case, CPFP would work and already exists.
**Unless** you are doing something complicated and offchain-y and involves =
relative locktimes, of course.


Once could point out as well that Peter Todd gave just a single example, Op=
enTimeStamps, for this, and OpenTimeStamps is not the only user of the Bitc=
oin blockchain.

So we can consider: who benefits and who suffers, and does the benefit to t=
he former outweigh the detriment of the latter?


It seems to me that the necromancing attack mostly can *only* target users =
of RBF that might want to *additionally* add outputs (or in the case of OTS=
, commitments) when RBF-ing.
For example, a large onchain-paying entity might lowball an onchain transac=
tion for a few withdrawals, then as more withdrawals come in, bump up their=
 feerate and add more withdrawals to the RBF-ed transaction.
Such an entity might prefer to confirm the latest RBF-ed transaction, as if=
 an earlier transaction (which does not include some other withdrawals requ=
ested later) is necromanced, they would need to make an *entire* *other* tr=
ansaction (which may be costlier!) to fulfill pending withdrawal requests.

However, to my knowledge, there is no actual entity that *currently* acts t=
his way (I do have some sketches for a wallet that can support this behavio=
r, but it gets *complicated* due to having to keep track of reorgs as well.=
.. sigh).

In particular, I expect that many users do not really make outgoing payment=
s often enough that they would actually benefit from such a wallet feature.
Instead, they will generally make one payment at a time, or plan ahead and =
pay several in a batch at once, and even if they RBF, they would just keep =
the same set of outputs and just reduce their change output.
For such low-scale users, a rando third-party necromancing their old transa=
ctions could only make them happy, thus this nuisance attack cannot be exec=
uted.

We could also point out that this is really a nuisance attack and not an ec=
onomic-theft attack.
The attacker cannot gain, and can only pay in order to impose costs on some=
body else.
Rationally, the only winning move is not to play.


So --- has anyone actually implemented a Bitcoin wallet that has such a fea=
ture (i.e. make a lowball send transaction now, then you can add another se=
nd later and if the previous send transaction is unconfirmed, RBF it with a=
 new transaction that has the previous send and the current send) and if so=
, can you open-source the code and show me?


Regards,
ZmnSCPxj