> On Feb 1, 2022, at 00:32, Bram Cohen <b...@chia.net> wrote:
>
>> On Mon, Jan 31, 2022 at 4:08 PM Eric Voskuil <e...@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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
