📅 Original date posted:2022-02-19
📝 Original message:
> 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 at 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 at lists.linuxfoundation.org
>
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
darosior [ARCHIVE] /
npub1pj…x22xp
2023-06-09 13:05:09
in reply to nevent1q…gyw0
Author Public Key
npub1pj9022f74rzq7d5x7gnxje6wpsgk4r5jgeck8y5awd423ydhan3q7x22xpPublished at
2023-06-09 13:05:09Event JSON
{
"id": "638337b83cce55d68c559d91740fed4cf463e1d4b3b01e849807ab059d100b51",
"pubkey": "0c8af5293ea8c40f3686f22669674e0c116a8e92467163929d736aa891b7ece2",
"created_at": 1686315909,
"kind": 1,
"tags": [
[
"e",
"89c09cd12ad867d6d2e1314b947516b47b5e1de41f7e8e55839a0abf57779c80",
"",
"root"
],
[
"e",
"5f603dd6216680901d42c44280304affee8cc43d527107b42fd9a468c71acbe2",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2022-02-19\n📝 Original message:\n\u003e Necromancing might be a reasonable name for attacks that work by getting an\n\u003e out-of-date version of a tx mined.\n\nIt's not an \"attack\"? There is no such thing as an out-of-date transaction, if\nyou signed and broadcasted it in the first place. You can't rely on the fact that\na replacement transaction would somehow invalidate a previous version of it.\n\n------- Original Message -------\n\nLe samedi 19 février 2022 à 10:39 AM, Peter Todd \u003cpete at petertodd.org\u003e a écrit :\n\n\u003e On Fri, Feb 18, 2022 at 04:38:27PM -0800, Jeremy Rubin wrote:\n\u003e\n\u003e \u003e \u003e As I said, it's a new kind of pinning attack, distinct from other types\n\u003e \u003e \u003e\n\u003e \u003e \u003e of pinning attack.\n\u003e \u003e\n\u003e \u003e I think pinning is \"formally defined\" as sequences of transactions which\n\u003e \u003e\n\u003e \u003e prevent or make it less likely for you to make any progress (in terms of\n\u003e \u003e\n\u003e \u003e units of computation proceeding).\n\u003e\n\u003e Mentioning \"computation\" when talking about transactions is misleading:\n\u003e\n\u003e blockchain transactions have nothing to do with computation.\n\u003e\n\u003e \u003e Something that only increases possibility to make progress cannot be\n\u003e \u003e\n\u003e \u003e pinning.\n\u003e\n\u003e It is incorrect to say that all use-cases have the property that any version of\n\u003e\n\u003e a transaction being mined is progress.\n\u003e\n\u003e \u003e If you want to call it something else, with a negative connotation, maybe\n\u003e \u003e\n\u003e \u003e call it \"necromancing\" (bringing back txns that would otherwise be\n\u003e \u003e\n\u003e \u003e feerate/fee irrational).\n\u003e\n\u003e Necromancing might be a reasonable name for attacks that work by getting an\n\u003e\n\u003e out-of-date version of a tx mined.\n\u003e\n\u003e \u003e In particular, for the use case you mentioned \"Eg a third party could mess\n\u003e \u003e\n\u003e \u003e up OpenTimestamps calendars at relatively low cost by delaying the mining\n\u003e \u003e\n\u003e \u003e of timestamp txs.\", this is incorrect. A third party can only accelerate\n\u003e \u003e\n\u003e \u003e the mining on the timestamp transactions, but they can accelerate the\n\u003e \u003e\n\u003e \u003e mining of any such timestamp transaction. If you have a single output chain\n\u003e \u003e\n\u003e \u003e that you're RBF'ing per block, then at most they can cause you to shift the\n\u003e \u003e\n\u003e \u003e calendar commits forward one block. But again, they cannot pin you. If you\n\u003e \u003e\n\u003e \u003e want to shift it back one block earlier, just offer a higher fee for the\n\u003e \u003e\n\u003e \u003e later RBF'd calendar. Thus the interference is limited by how much you wish\n\u003e \u003e\n\u003e \u003e to pay to guarantee your commitment is in this block as opposed to the next.\n\u003e\n\u003e Your understanding of how OpenTimestamps calendars work appears to be\n\u003e\n\u003e incorrect. There is no chain of unconfirmed transactions. Rather, OTS calendars\n\u003e\n\u003e use RBF to update the timestamp tx with a new merkle tip hash for to all\n\u003e\n\u003e outstanding per-second commitments once per new block. In high fee situations\n\u003e\n\u003e it's normal for there to be dozens of versions of that same tx, each with a\n\u003e\n\u003e slightly higher feerate.\n\u003e\n\u003e OTS calendars can handle any of those versions getting mined. But older\n\u003e\n\u003e versions getting mined wastes money, as the remaining commitments still need to\n\u003e\n\u003e get mined in a subsequent transaction. Those remaining commitments are also\n\u003e\n\u003e delayed by the time it takes for the next tx to get mined.\n\u003e\n\u003e There are many use-cases beyond OTS with this issue. For example, some entities\n\u003e\n\u003e use \"in-place\" replacement for update low-time-preference settlement\n\u003e\n\u003e transactions by adding new txouts and updating existing ones. Older versions of\n\u003e\n\u003e those settlement transactions getting mined rather than the newer version\n\u003e\n\u003e wastes money and delays settlement for the exact same reason it does in OTS.\n\u003e\n\u003e If fee accounts or any similar mechanism get implemented, they absolutely\n\u003e\n\u003e should be opt-in. Obviously, using a currently non-standard nVersion bit is a\n\u003e\n\u003e possible approach. Conversely, with CPFP it may be desirable in the settlement\n\u003e\n\u003e case to be able to prevent outputs from being spent in the same block. Again,\n\u003e\n\u003e an nVersion bit is a possible approach.\n\u003e\n\u003e \u003e By the way, you can already do out-of-band transaction fees to a very\n\u003e \u003e\n\u003e \u003e similar effect, google \"BTC transaction accelerator\". If the attack were at\n\u003e \u003e\n\u003e \u003e all valuable to perform, it could happen today.\n\u003e\n\u003e I just checked: all the BTC transaction accellerator services I could find look\n\u003e\n\u003e to be either scams, or very expensive. We need compelling reasons to make this\n\u003e\n\u003e nuisance attack significantly cheaper.\n\u003e\n\u003e \u003e Lastly, if you do get \"necromanced\" on an earlier RBF'd transaction by a\n\u003e \u003e\n\u003e \u003e third party for OTS, you should be relatively happy because it cost you\n\u003e \u003e\n\u003e \u003e less fees overall, since the undoing of your later RBF surely returned some\n\u003e \u003e\n\u003e \u003e satoshis to your wallet.\n\u003e\n\u003e As I said above, no it doesn't.\n\u003e\n\u003e ----------------------------------\n\u003e\n\u003e https://petertodd.org 'peter'[:-1]@petertodd.org\n\u003e\n\u003e Lightning-dev mailing list\n\u003e\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev",
"sig": "ff6b74e2382a3d695b9cd2a506d24016ce1d844a62cc5490ddefb9849e0ab2cf849f4185eb7b54fce429d6c4052de64deb952202a6e7b41e8c8e8b5a221815b1"
}