ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2022-02-20 📝 Original message: Good morning Peter and ...
📅 Original date posted:2022-02-20
📝 Original message:
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?
Regards,
ZmnSCPxj
📝 Original message:
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?
Regards,
ZmnSCPxj