From: Eric Voskuil <eric@voskuil•org>
To: Bram Cohen <bram@chia•net>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Improving RBF policy
Date: Tue, 1 Feb 2022 11:44:37 -0800 [thread overview]
Message-ID: <F47C4368-76F1-4365-977B-7939981C3182@voskuil.org> (raw)
In-Reply-To: <CAHUJnBD034D4-Ru0d4b4_2eYeNUKvmMcvQCW7OJTO9YzWFYHnQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3651 bytes --]
> On Feb 1, 2022, at 00:32, Bram Cohen <bram@chia•net> wrote:
>
>> On Mon, Jan 31, 2022 at 4:08 PM Eric Voskuil <eric@voskuil•org> wrote:
>>
>>
>>>> On Jan 31, 2022, at 15:15, Bram Cohen via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>> Is it still verboten to acknowledge that RBF is normal behavior and disallowing it is the feature, and that feature is mostly there to appease some people's delusions that zeroconf is a thing? It seems a bit overdue to disrespect the RBF flag in the direction of always assuming it's on.
>> What flag?
>
> The opt-in RBF flag in transactions.
Was being facetious. The “disrespect” referred to above assumes respect that some implementations have never given.
>>> There are two different common regimes which result in different incentivized behavior. One of them is that there's more than a block's backlog in the mempool in which case between two conflicting transactions the one with the higher fee rate should win. In the other case where there isn't a whole block's worth of transactions the one with higher total value should win.
>> These are not distinct scenarios. The rational choice is the highest fee block-valid subgraph of the set of unconfirmed transactions, in both cases (within the limits of what is computationally feasible of course).
>
> It's weird because which of two or more conflicting transactions should win can oscillate back and forth depending on other stuff going on in the mempool.
The assumption of RAM storage is an error and unrelated to network protocol. There is nothing “going on” in a set of unconfirmed valid transactions. They are logically unchanging.
> There's already a bit of that with child pays but this is stranger and has more oddball edge cases about which transactions to route.
There’s really no such thing. The p2p network is necessarily permissionless. A person can route whatever he wants. Presumably people will not generally waste their own bandwidth by routing what they believe to be unconfirmable. And whatever they would retain themselves is their presumption of confirmable.
This decision of what to retain one’s self is just a graph traversal to determine the most valuable subset - an optimizing CSP (though generally suboptimal due to the time constraint).
Short of DoS, the most profitable model is to retain *all* valid transactions. [Note that a spend conflict is not an invalidity. Two valid transactions can be confirmed in sibling branch blocks - both valid in some context.]
So the only consideration is low cost storage fill. The fee is a proof of spend, which like proof of work (for headers/blocks), is the basis of DoS protection (for unconfirmed transactions). The issue with two conflicting subgraphs is that one or the other is ultimately unspendable. As such the fee on each is non-cumulative and therefore only one (the highest) is providing DoS protection. Any subsequent conflicting subgraph must pay not only for itself, but for all preceding conflicting subgraphs.
This pays for the storage, which is a trade accepted by the owner of the node in order to have a preview of confirmable transactions. This supports both mining generation of candidate blocks and rapid validation/confirmation of blocks.
It’s a rather straightforward system when considered in terms of how it actually works (ie from a consensus standpoint). The only p2p issue is the need to package transactions for consideration as a set, as otherwise parents may be discarded before children can pay for them. Any set up to a full block is entirely reasonable for consideration.
e
[-- Attachment #2: Type: text/html, Size: 5317 bytes --]
next prev parent reply other threads:[~2022-02-01 19:44 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.19693.1643292568.8511.bitcoin-dev@lists.linuxfoundation.org>
2022-01-31 22:54 ` Bram Cohen
2022-02-01 0:08 ` Eric Voskuil
2022-02-01 8:32 ` Bram Cohen
2022-02-01 19:44 ` Eric Voskuil [this message]
2022-02-01 0:42 ` Antoine Riard
2022-02-09 17:57 [bitcoin-dev] Improving RBF Policy lisa neigut
-- strict thread matches above, loose matches on Subject: below --
2022-02-01 2:47 Prayank
2022-02-01 9:30 ` Bastien TEINTURIER
2022-02-02 10:21 ` Anthony Towns
2022-01-27 13:42 Gloria Zhao
2022-01-28 1:35 ` Jeremy
2022-01-30 22:53 ` Antoine Riard
2022-01-31 15:57 ` Bastien TEINTURIER
2022-02-01 1:56 ` Anthony Towns
2022-02-05 13:21 ` Michael Folkson
2022-02-07 10:22 ` Bastien TEINTURIER
2022-02-07 11:16 ` Gloria Zhao
2022-02-08 4:58 ` Anthony Towns
2022-03-09 15:09 ` Gloria Zhao
2022-03-11 16:22 ` Billy Tetrud
2022-03-12 8:18 ` Billy Tetrud
2022-03-14 10:29 ` Gloria Zhao
2022-03-15 1:43 ` Billy Tetrud
2022-03-17 2:02 ` Antoine Riard
2022-03-17 15:59 ` Billy Tetrud
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=F47C4368-76F1-4365-977B-7939981C3182@voskuil.org \
--to=eric@voskuil$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=bram@chia$(echo .)net \
/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