From: darosior <darosior@protonmail.com>
To: Peter Todd <pete@petertodd.org>
Cc: Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>,
lightning-dev <lightning-dev@lists.linuxfoundation.org>,
Jeremy <jlrubin@mit.edu>
Subject: Re: [bitcoin-dev] [Lightning-dev] [Pre-BIP] Fee Accounts
Date: Sat, 19 Feb 2022 17:20:19 +0000 [thread overview]
Message-ID: <kJWi5A4sc0UEU4JrtSg3gbR_M1UTp15XW3Oj5B5cQZQvygFn9pIqrxVxCU0sFjG5L05fqDFH6nz2PnU0sE_zVNMGsCXzmtJeDAc1kEYmYKA=@protonmail.com> (raw)
In-Reply-To: <YhC6yjoe3bAfBS+W@petertodd.org>
> 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.
------- Original Message -------
Le samedi 19 février 2022 à 10:39 AM, Peter Todd <pete@petertodd.org> a écrit :
> On Fri, Feb 18, 2022 at 04:38:27PM -0800, Jeremy Rubin wrote:
>
> > > As I said, it's a new kind of pinning attack, distinct from other types
> > >
> > > of pinning attack.
> >
> > I think pinning is "formally defined" as sequences of transactions which
> >
> > prevent or make it less likely for you to make any progress (in terms of
> >
> > units of computation proceeding).
>
> Mentioning "computation" when talking about transactions is misleading:
>
> blockchain transactions have nothing to do with computation.
>
> > Something that only increases possibility to make progress cannot be
> >
> > pinning.
>
> It is incorrect to say that all use-cases have the property that any version of
>
> a transaction being mined is progress.
>
> > If you want to call it something else, with a negative connotation, maybe
> >
> > call it "necromancing" (bringing back txns that would otherwise be
> >
> > feerate/fee irrational).
>
> Necromancing might be a reasonable name for attacks that work by getting an
>
> out-of-date version of a tx mined.
>
> > In particular, for the use case you mentioned "Eg a third party could mess
> >
> > up OpenTimestamps calendars at relatively low cost by delaying the mining
> >
> > of timestamp txs.", this is incorrect. A third party can only accelerate
> >
> > the mining on the timestamp transactions, but they can accelerate the
> >
> > mining of any such timestamp transaction. If you have a single output chain
> >
> > that you're RBF'ing per block, then at most they can cause you to shift the
> >
> > calendar commits forward one block. But again, they cannot pin you. If you
> >
> > want to shift it back one block earlier, just offer a higher fee for the
> >
> > later RBF'd calendar. Thus the interference is limited by how much you wish
> >
> > to pay to guarantee your commitment is in this block as opposed to the next.
>
> Your understanding of how OpenTimestamps calendars work appears to be
>
> incorrect. There is no chain of unconfirmed transactions. Rather, OTS calendars
>
> use RBF to update the timestamp tx with a new merkle tip hash for to all
>
> outstanding per-second commitments once per new block. In high fee situations
>
> it's normal for there to be dozens of versions of that same tx, each with a
>
> slightly higher feerate.
>
> OTS calendars can handle any of those versions getting mined. But older
>
> versions getting mined wastes money, as the remaining commitments still need to
>
> get mined in a subsequent transaction. Those remaining commitments are also
>
> delayed by the time it takes for the next tx to get mined.
>
> There are many use-cases beyond OTS with this issue. For example, some entities
>
> use "in-place" replacement for update low-time-preference settlement
>
> transactions by adding new txouts and updating existing ones. Older versions of
>
> those settlement transactions getting mined rather than the newer version
>
> wastes money and delays settlement for the exact same reason it does in OTS.
>
> If fee accounts or any similar mechanism get implemented, they absolutely
>
> should be opt-in. Obviously, using a currently non-standard nVersion bit is a
>
> possible approach. Conversely, with CPFP it may be desirable in the settlement
>
> case to be able to prevent outputs from being spent in the same block. Again,
>
> an nVersion bit is a possible approach.
>
> > By the way, you can already do out-of-band transaction fees to a very
> >
> > similar effect, google "BTC transaction accelerator". If the attack were at
> >
> > all valuable to perform, it could happen today.
>
> I just checked: all the BTC transaction accellerator services I could find look
>
> to be either scams, or very expensive. We need compelling reasons to make this
>
> nuisance attack significantly cheaper.
>
> > Lastly, if you do get "necromanced" on an earlier RBF'd transaction by a
> >
> > third party for OTS, you should be relatively happy because it cost you
> >
> > less fees overall, since the undoing of your later RBF surely returned some
> >
> > satoshis to your wallet.
>
> As I said above, no it doesn't.
>
> ----------------------------------
>
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
> Lightning-dev mailing list
>
> Lightning-dev@lists.linuxfoundation.org
>
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
next prev parent reply other threads:[~2022-02-19 17:20 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-01 20:04 [bitcoin-dev] [Pre-BIP] Fee Accounts 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 ` darosior [this message]
2022-02-19 20:35 ` [bitcoin-dev] [Lightning-dev] " Peter Todd
2022-02-20 2:24 ` ZmnSCPxj
2022-02-20 2:39 ` ZmnSCPxj
[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='kJWi5A4sc0UEU4JrtSg3gbR_M1UTp15XW3Oj5B5cQZQvygFn9pIqrxVxCU0sFjG5L05fqDFH6nz2PnU0sE_zVNMGsCXzmtJeDAc1kEYmYKA=@protonmail.com' \
--to=darosior@protonmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=jlrubin@mit.edu \
--cc=lightning-dev@lists.linuxfoundation.org \
--cc=pete@petertodd.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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