Re: [bitcoin-dev] [Lightning-dev] [Pre-BIP] Fee Accounts

[ZmnSCPxj <ZmnSCPxj@protonmail.com>]

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 getting an
> > > > out-of-date version of a tx mined.
> > >
> > > It's not an "attack"? There is no such thing as an out-of-date transaction, 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 of it.
> >
> > Anyone on the internet can send you a packet; a secure system must be able to
> > receive any packet without being compromised. Yet we still call packet floods
> > 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 become
> > 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 annoying.
> > While you have to account for the possibility of any transaction you have
> > signed being mined, Bitcoin standards should avoid making unwanted necromancy 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 commitments.
>
> Note that multiparty RBF is unreliable.
> While the initial multiparty signing of a transaction may succeed, at a later 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 offline.
>
> Anchor outputs can be keyed to only a specific participant, so feebumping of particular transaction can only be done by participants who have been authorized to feebump.
>
> Perhaps fee accounts can include some kind of proof-this-transaction-authorizes-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 least one Taproot output.
  * This Taproot output must have tapleaf with the fee-account-authorization 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 output of that transaction.

This gives similar functionality to anchor outputs, without requiring an explicit 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 authorization.
Revelation of the fee-account-authorization is O(log N), and if only one participant decides to feebump, then only a single O(log N) MAST treepath is published.

Regards,
ZmnSCPxj