From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: ZmnSCPxj <ZmnSCPxj@protonmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Cc: lightning-dev <lightning-dev@lists•linuxfoundation.org>,
Jeremy <jlrubin@mit•edu>
Subject: Re: [bitcoin-dev] [Lightning-dev] [Pre-BIP] Fee Accounts
Date: Sun, 20 Feb 2022 02:39:50 +0000 [thread overview]
Message-ID: <sU815XyMYVgcVVo1yHJSUgfiraHeug7GNMMPxu_PQhv_Zhld3XPa82DawQp3vOsWppvvBZkPEt4h95fwALOcMPIy-wOvMp3fYb_xzV92V-E=@protonmail.com> (raw)
In-Reply-To: <Id0jz_ihSCY4KpH4iCljOInrvHVpKIbxsrmROOdqY3mwCFDqSvGVkmFnYgFKzIhOTaqj3SI2Hc4WIZEusT_aJNURHR6nAMPtgwwA9ia2Ahw=@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
next prev parent reply other threads:[~2022-02-20 2:39 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-01 20:04 [bitcoin-dev] " Jeremy
2022-01-18 16:12 ` Billy Tetrud
2022-01-18 17:43 ` Jeremy
2022-01-19 2:37 ` Billy Tetrud
2022-01-19 2:51 ` Jeremy
2022-01-19 4:53 ` Billy Tetrud
2022-01-19 7:32 ` Jeremy
2022-01-19 16:51 ` Billy Tetrud
2022-01-19 20:08 ` Jeremy
2022-01-20 5:23 ` Billy Tetrud
2022-02-10 6:58 ` Peter Todd
2022-02-10 8:08 ` Jeremy Rubin
2022-02-18 23:50 ` Peter Todd
2022-02-19 0:38 ` Jeremy Rubin
2022-02-19 9:39 ` Peter Todd
2022-02-19 17:20 ` [bitcoin-dev] [Lightning-dev] " darosior
2022-02-19 20:35 ` Peter Todd
2022-02-20 2:24 ` ZmnSCPxj
2022-02-20 2:39 ` ZmnSCPxj [this message]
[not found] ` <590cf52920040c9cf7517b219624bbb5@willtech.com.au>
2022-02-20 14:24 ` ZmnSCPxj
2022-02-20 16:29 ` Jeremy Rubin
[not found] ` <CAD5xwhgEeTETburW=OBgHNe_V1kk8o06TDQLiLgdfmP2AEVuPg@mail.gmail.com>
2022-02-20 16:34 ` ZmnSCPxj
2022-02-20 16:45 ` Jeremy Rubin
2022-02-20 16:29 ` [bitcoin-dev] " Jeremy Rubin
2022-04-10 19:32 ` Peter Todd
2022-04-11 13:18 ` Jeremy Rubin
2022-04-15 14:52 ` Peter Todd
2022-04-17 20:57 ` Jeremy Rubin
2022-04-28 12:15 ` Peter Todd
2022-05-02 15:59 ` Jeremy Rubin
2022-06-14 11:12 ` [bitcoin-dev] Why OpenTimestamps does not "linearize" its transactions Peter Todd
2022-06-14 11:39 ` Undiscussed Horrific Abuse, One Victim of Many
2022-06-14 11:53 ` Undiscussed Horrific Abuse, One Victim of Many
2022-06-14 12:28 ` rot13maxi
2022-06-14 12:45 ` Undiscussed Horrific Abuse, One Victim of Many
2022-06-14 13:55 ` Bryan Bishop
2022-06-14 15:06 ` digital vagabond
2022-06-14 15:34 ` Peter Todd
2022-06-14 17:15 ` Undiscussed Horrific Abuse, One Victim of Many
2022-06-14 20:33 ` Andrew Poelstra
2022-06-15 1:16 ` Undiscussed Horrific Abuse, One Victim of Many
2022-06-15 1:21 ` Undiscussed Horrific Abuse, One Victim of Many
2022-06-19 11:04 ` Peter Todd
2022-06-14 15:22 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='sU815XyMYVgcVVo1yHJSUgfiraHeug7GNMMPxu_PQhv_Zhld3XPa82DawQp3vOsWppvvBZkPEt4h95fwALOcMPIy-wOvMp3fYb_xzV92V-E=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jlrubin@mit$(echo .)edu \
--cc=lightning-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox