From: Peter Todd <pete@petertodd•org>
To: Jeremy Rubin <jeremy.l.rubin@gmail•com>
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 18:50:07 -0500 [thread overview]
Message-ID: <YhAwr7+9mGJAe2/p@petertodd.org> (raw)
In-Reply-To: <CAD5xwhi3Ja8gdU2h_6-1ck4kdU0TiC2Kx5O-61=f9=6JQSMs=A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1603 bytes --]
On Thu, Feb 10, 2022 at 12:08:59AM -0800, Jeremy Rubin wrote:
> That's not really pinning; painning usually refers to pinning something to
> the bottom of the mempool whereas these mechanisms make it easier to
> guarantee that progress can be made on confirming the transactions you're
> interested in.
As I said, it's a new kind of pinning attack, distinct from other types of
pinning attack.
> Often times in these protocols "the call is coming inside the house". It's
> not a third party adding fees we are scared of, it's a direct party to the
> protocol!
Often times that is true. But other times that is not true! I gave examples of
use-cases where being able to arbitrary add fees to transactions is harmful;
the onus is on you to argue why that is acceptable to burden those users with a
new class of attack.
> Sponsors or fee accounts would enable you to ensure the protocol you're
> working on makes forward progress. For things like Eltoo the internal
> ratchet makes this work well.
>
> Protocols which depend on in mempool replacements before confirmation
> already must be happy (should they be secure) with any prior state being
> mined. If a third party pays the fee you might even be happier since the
> execution wasn't on your dime.
"Must be able to deal with" is not the same thing as "Must be happy". While
those use-cases do have to deal with those exceptional cases happening
occasionally, it's harmful if an attacker can harass you by making those
exceptional cases happen frequently.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2022-02-18 23:50 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 [this message]
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
[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=YhAwr7+9mGJAe2/p@petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jeremy.l.rubin@gmail$(echo .)com \
--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