From: Jeremy Rubin <jeremy.l.rubin@gmail•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] [Pre-BIP] Fee Accounts
Date: Fri, 18 Feb 2022 16:38:27 -0800 [thread overview]
Message-ID: <CAD5xwhi=sKckFZew75tZTogoeFABraWtJ6qMC+RgZjcirxYyZw@mail.gmail.com> (raw)
In-Reply-To: <YhAwr7+9mGJAe2/p@petertodd.org>
[-- Attachment #1: Type: text/plain, Size: 2411 bytes --]
> 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).
Something that only increases possibility to make progress cannot be
pinning.
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).
I would posit that we should be wholly unconcerned with necromancing -- if
your protocol is particularly vulnerable to a third party necromancing then
your protocol is insecure and we shouldn't hamper Bitcoin's forward
progress on secure applications to service already insecure ones. Lightning
is particularly necromancy resistant by design, but pinning vulnerable.
This is also true with things like coinjoins which are necromancy resistant
but pinning vulnerable.
Necromancy in particular is something that isn't uniquely un-present in
Bitcoin today, and things like package relay and elimination of pinning are
inherently at odds with making necromancy either for CPFP use cases.
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.
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.
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.
Best,
Jeremy
[-- Attachment #2: Type: text/html, Size: 4195 bytes --]
next prev parent reply other threads:[~2022-02-19 0:38 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-01 20:04 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 [this message]
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
[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='CAD5xwhi=sKckFZew75tZTogoeFABraWtJ6qMC+RgZjcirxYyZw@mail.gmail.com' \
--to=jeremy.l.rubin@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jlrubin@mit$(echo .)edu \
--cc=lightning-dev@lists$(echo .)linuxfoundation.org \
--cc=pete@petertodd$(echo .)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