Date: Sun, 20 Feb 2022 02:24:37 +0000
To: Peter Todd <pete@petertodd.org>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <Id0jz_ihSCY4KpH4iCljOInrvHVpKIbxsrmROOdqY3mwCFDqSvGVkmFnYgFKzIhOTaqj3SI2Hc4WIZEusT_aJNURHR6nAMPtgwwA9ia2Ahw=@protonmail.com>
In-Reply-To: <YhFUiA9/YlY99Bok@petertodd.org>
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>
 <YhFUiA9/YlY99Bok@petertodd.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Jeremy <jlrubin@mit.edu>,
 lightning-dev <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev]  [Pre-BIP] Fee Accounts
Precedence: list

Good morning Peter and Jeremy,

> On Sat, Feb 19, 2022 at 05:20:19PM +0000, darosior wrote:
>
> > > Necromancing might be a reasonable name for attacks that work by gett=
ing an
> > > out-of-date version of a tx mined.
> >
> > It's not an "attack"? There is no such thing as an out-of-date transact=
ion, if
> > you signed and broadcasted it in the first place. You can't rely on the=
 fact that
> > a replacement transaction would somehow invalidate a previous version o=
f it.
>
> Anyone on the internet can send you a packet; a secure system must be abl=
e to
> receive any packet without being compromised. Yet we still call packet fl=
oods
> as DoS attacks. And internet standards are careful to avoid making packet
> flooding cheaper than it currently is.
>
> The same principal applies here: in many situations transactions do becom=
e
> out of date, in the sense that you would rather a different transaction b=
e
> mined instead, and the out-of-date tx being mined is expensive and annoyi=
ng.
> While you have to account for the possibility of any transaction you have
> signed being mined, Bitcoin standards should avoid making unwanted necrom=
ancy a
> cheap and easy attack.
>

This seems to me to restrict the only multiparty feebumping method to be so=
me form of per-participant anchor outputs a la Lightning anchor commitments=
.

Note that multiparty RBF is unreliable.
While the initial multiparty signing of a transaction may succeed, at a lat=
er time with the transaction unconfirmed, one or more of the participants m=
ay regret cooperating in the initial signing and decide not to cooperate wi=
th the RBF.
Or for that matter, a participant may, through complete accident, go offlin=
e.

Anchor outputs can be keyed to only a specific participant, so feebumping o=
f particular transaction can only be done by participants who have been aut=
horized to feebump.

Perhaps fee accounts can include some kind of proof-this-transaction-author=
izes-this-fee-account?

Regards,
ZmnSCPxj