search

0xB10C / miningpool-observer

Transparency for Mining Pool Transaction Selection
https://miningpool.observer
MIT License
55 stars 13 forks source link

Observe full RBF #53

Closed Sjors closed 1 year ago

Sjors commented 1 year ago

It would be useful to observe which pools (don't) include fee bumped transactions that are compatible with the new -mempoolfullrbf setting. I suppose this detection would be more useful on top of a node with this setting enabled, because otherwise you can't see how long such a fee bump has been in the mempool.

If we can sort the list by amount-bumped we can also see if @petertodd's bounty program is working.

petertodd commented 1 year ago

You can easily see that ~no miners are mining full-rbf right now by the transaction fees paid: https://alice.btc.calendar.opentimestamps.org/

I currently believe the double spends I found before were all due to slow propagation. I've since taken a number of steps to avoid that like only spending outputs with >2 confirmations, and waiting a few minutes at minimum between double spends.

On November 9, 2022 1:35:14 PM AST, Sjors Provoost @.***> wrote:

It would be useful to observe which pools (don't) include fee bumped transactions that are compatible with the new -mempoolfullrbf setting. I suppose this detection would be more useful on top of a node with this setting enabled, because otherwise you can't see how long such a fee bump has been in the mempool.

If we can sort the list by amount-bumped we can also see if @petertodd's bounty program is working.

-- Reply to this email directly or view it on GitHub: https://github.com/0xB10C/miningpool-observer/issues/53 You are receiving this because you were mentioned.

Message ID: @.***>

petertodd commented 1 year ago

Note that due to how the calendars double spend txs multiple times with full-rbf, you'll be able (in some cases) to distinguish between miners that are actually running full-rbf vs ones that have just set a higher than usual minimum fee, or small mempool size limit.

Both the Alice and Bob calendars are doing full-rbf double spends; only the former is doing them with high fees.

On November 9, 2022 1:35:14 PM AST, Sjors Provoost @.***> wrote:

It would be useful to observe which pools (don't) include fee bumped transactions that are compatible with the new -mempoolfullrbf setting. I suppose this detection would be more useful on top of a node with this setting enabled, because otherwise you can't see how long such a fee bump has been in the mempool.

If we can sort the list by amount-bumped we can also see if @petertodd's bounty program is working.

-- Reply to this email directly or view it on GitHub: https://github.com/0xB10C/miningpool-observer/issues/53 You are receiving this because you were mentioned.

Message ID: @.***>

Sjors commented 1 year ago

@petertodd I assume Finney and Catallaxy are the control group? I.e. opt-in RBF, one with low fees and the other with high fees?

petertodd commented 1 year ago

I don't run those calendars so I can't make any guarantees.

Anyway, I don't see what you even need a control group for. If a non-min-fee transaction is mined when the mempool isn't full, obviously that's strong evidence of either full-rbf or an unusually low mempool size limit/unusually high min fee.

And you can rule out the latter with high certainty by seeing if the tx that got mined was the highest fee replacement available.

On November 10, 2022 7:02:07 AM AST, Sjors Provoost @.> wrote: @. I assume Finney and Catallaxy are the control group? I.e. opt-in RBF, one with low fees and the other with high fees?

-- Reply to this email directly or view it on GitHub: https://github.com/0xB10C/miningpool-observer/issues/53#issuecomment-1310112785 You are receiving this because you were mentioned.

Message ID: @.***>

0xB10C commented 1 year ago

I agree that it would be useful to track pools having full-rbf enabled. There is https://miningpool.observer/conflicting already which lists conflicts between template and block transactions. Adding more details about conflicts between replaced and replacement transaction is also the goal of https://github.com/0xB10C/miningpool-observer/issues/2.

The methodology to observe full-rbf transactions based on my templates and mined blocks blocks isn't clear to me yet. On one hand, a mempoolfullrbf=0 node will conflict with mining pools on many full-rbf replaced transactions. In the case of full-rbf, the template transaction has a lower feerate than the block transaction. But it could also be just a double-spend and not intended as RBF replacement. On the other hand, if the getblocktemplate node is running with mempoolfullrbf=1, it won't conflict with pools that also have mempoolfullrbf enabled.

I think a better way to observe full-rbf is to look at which transactions a mempoolfullrbf=1 node considers as replaced, but doesn't signal opt-in RBF. That should be doable with e.g. a rebased https://github.com/0xB10C/bitcoin-zmq-mempool-chain-events or any other patch that logs non-signaling replacements.

0xB10C commented 1 year ago

I'm observing full-RBF replacements here: https://fullrbf.mempool.observer. While this isn't really based on the miningpool-observer project, I think this closes this issue.

petertodd commented 1 year ago

Thanks, the mempool observer is useful.

Where should I open issues with it?

One nit with it: the order of outputs is different between replaced and replacement. Should be the same on both sides IMO.

On December 9, 2022 9:58:01 AM CST, 0xB10C @.***> wrote:

I'm observing full-RBF replacements here: https://fullrbf.mempool.observer. While this isn't really based on the miningpool-observer project, I think this closes this issue.

-- Reply to this email directly or view it on GitHub: https://github.com/0xB10C/miningpool-observer/issues/53#issuecomment-1344475975 You are receiving this because you were mentioned.

Message ID: @.***>

0xB10C commented 1 year ago

Feel free to use this repo for issues: https://github.com/0xB10C/mempool-observer-fullrbf-ui

I'm treating this as something temporary (i.e. for a few months), with a quick and dirty setup. But will generally fix-up stuff and add smaller features.

One nit with it: the order of outputs is different between replaced and replacement. Should be the same on both sides IMO.

Ah, I see why that's happening. I'd guess you favor keeping the original ordering as it's in the transaction or does having them sorted e.g. alphabetically work for you too?

petertodd commented 1 year ago

On Fri, Dec 09, 2022 at 10:17:15AM -0800, 0xB10C wrote:

Feel free to use this repo for issues: https://github.com/0xB10C/mempool-observer-fullrbf-ui

I'm treating this as something temporary (i.e. for a few months), with a quick and dirty setup. But will generally fix-up stuff and add smaller features.

One nit with it: the order of outputs is different between replaced and replacement. Should be the same on both sides IMO.

Ah, I see why that's happening. I'd guess you favor keeping the original ordering as it's in the transaction or does having them sorted e.g. alphabetically work for you too?

Whatever order you feel is best is fine. Just make it consistent on both sides of the display. :)

Having details about what txouts are different would be cool too. Though obviously, that's more work to implement.