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

Good morning Peter and Jeremy,

> 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 ge=
tting an
> > > > out-of-date version of a tx mined.
> > >
> > > It's not an "attack"? There is no such thing as an out-of-date transa=
ction, if
> > > you signed and broadcasted it in the first place. You can't rely on t=
he fact that
> > > a replacement transaction would somehow invalidate a previous version=
 of it.
> >
> > Anyone on the internet can send you a packet; a secure system must be a=
ble to
> > receive any packet without being compromised. Yet we still call packet =
floods
> > as DoS attacks. And internet standards are careful to avoid making pack=
et
> > flooding cheaper than it currently is.
> > The same principal applies here: in many situations transactions do bec=
ome
> > out of date, in the sense that you would rather a different transaction=
 be
> > mined instead, and the out-of-date tx being mined is expensive and anno=
ying.
> > While you have to account for the possibility of any transaction you ha=
ve
> > signed being mined, Bitcoin standards should avoid making unwanted necr=
omancy a
> > cheap and easy attack.
>
> This seems to me to restrict the only multiparty feebumping method to be =
some form of per-participant anchor outputs a la Lightning anchor commitmen=
ts.
>
> Note that multiparty RBF is unreliable.
> While the initial multiparty signing of a transaction may succeed, at a l=
ater time with the transaction unconfirmed, one or more of the participants=
 may regret cooperating in the initial signing and decide not to cooperate =
with the RBF.
> Or for that matter, a participant may, through complete accident, go offl=
ine.
>
> Anchor outputs can be keyed to only a specific participant, so feebumping=
 of particular transaction can only be done by participants who have been a=
uthorized to feebump.
>
> Perhaps fee accounts can include some kind of proof-this-transaction-auth=
orizes-this-fee-account?

For example:

* We reserve one Tapscript version for fee-account-authorization.
  * Validation of this tapscript version always fails.
* If a transaction wants to authorize a fee account, it should have at leas=
t one Taproot output.
  * This Taproot output must have tapleaf with the fee-account-authorizatio=
n Tapscript version.
* In order for a fee account to feebump a transaction, it must also present=
 the Taproot MAST path to the fee-account-authorization tapleaf of one outp=
ut of that transaction.

This gives similar functionality to anchor outputs, without requiring an ex=
plicit output on the initial transaction, saving blockspace.
In particular, once the number of participants grows, the number of anchor =
outputs must grow linearly with the number of participants being authorized=
 to feebump.
Only when the feerate turns out to be too low do we need to expose the auth=
orization.
Revelation of the fee-account-authorization is O(log N), and if only one pa=
rticipant decides to feebump, then only a single O(log N) MAST treepath is =
published.

Regards,
ZmnSCPxj