public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [bitcoin-dev] Fee estimates and RBF
@ 2021-04-30 20:28 Prayank
  2021-05-01  0:11 ` Jeremy
  2021-05-03  4:02 ` ZmnSCPxj
  0 siblings, 2 replies; 7+ messages in thread
From: Prayank @ 2021-04-30 20:28 UTC (permalink / raw)
  To: Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 2519 bytes --]

Hello World, 

I hope everyone is doing okay. Things are not good in India and even I was tested covid positive few days back. Recovered and feeling better now. Hoping everything gets back to normal soon.

There are different estimations used in wallets, explorers and other Bitcoin projects. For example: `estimatesmartfee` in Bitcoin Core (One of the implementation for Bitcoin which is used more but not official as there is nothing official in Bitcoin).  Are different estimations misleading and affect the way fees are used in Bitcoin transactions? Will it be better if we just share mempool stats and user can decide the fee rate accordingly?

If I compare this with BTCUSD orderbook on any exchange, are we trying to estimate at what price buy order will get filled in certain time? Does that make sense?

Mempool Stats: https://i.imgur.com/r4XKk2p.png
BTCUSD Orderbook: https://i.imgur.com/ylGVHJB.png

I consider it misleading because lot of users think a transaction with fee rate 1-5 sat/vByte will be included in 1 week or maybe a transaction with X sat/VByte will be included in Y time which is not true. Users can decide the fee rate and can do bidding, transaction will be included based on demand, supply and miners.

Will it be better if the wallets used this approach?
1.Show mempool stats
2.Leave the fee rate for user to decide
3.RBF every transaction and follow different algorithms for automated bidding

A basic algorithm for automated bidding can be: https://i.stack.imgur.com/1SlPv.png

Such RBF algos can be helpful for users when Bitcoin wallets are open in background. Maybe it will work better for mobile wallets in which you can see a notification every time transaction is replaced with a new fee rate automatically.

I wanted to know what others think about this approach of creating and using different RBF algos instead of predicting something that is difficult or doesn't make sense. Also if there was a way we could achieve this even if the user goes offline. For example: Alice broadcasts Tx1 with 1 sat/vByte, its replaced with Tx2 (2 sat/vByte) after 2 blocks because Tx1 was not confirmed. Alice decides to shut down her system or switch off mobile or mobile data. Tx2 is still not confirmed after another 2 blocks but it has some information as one OP_RETURN output which is used by Bitcoin nodes that see this transaction in the mempool. Bob's node use this information to replace the transaction with Tx3 and use fee rate 3 sat/vByte.

--
Prayank


[-- Attachment #2: Type: text/html, Size: 3148 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] Fee estimates and RBF
@ 2021-05-14 10:05 Prayank
  2021-05-18 13:10 ` ZmnSCPxj
  0 siblings, 1 reply; 7+ messages in thread
From: Prayank @ 2021-05-14 10:05 UTC (permalink / raw)
  To: Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 894 bytes --]

I have shared response by Jeremy and ZmnSCPxj in an answer to https://bitcoin.stackexchange.com/questions/105860/what-are-we-trying-to-predict-in-fee-estimation-and-why

Also find the recent CVE related to RBF by Antoine Riard and implementation of RBF in Bitcoin Core compared to btcd interesting. Even though I am not sure why inherited signalling is not implemented in Bitcoin Core.
RBF, CPFP and their combinations are something that is less explored IMO. For example: I had discussed one usecase of CPFP with Harding in IRC once in which a project uses maker-taker model. Maker broadcasts transaction with 1 sat/vByte and taker has to confirm this transaction by creating a child transaction with an effective fee rate according to mempool stats. Basically, the idea of receiver paying for the transaction instead of sender. But it will involve lot of exception handling.
-- 
Prayank

[-- Attachment #2: Type: text/html, Size: 1249 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2021-05-18 13:10 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-30 20:28 [bitcoin-dev] Fee estimates and RBF Prayank
2021-05-01  0:11 ` Jeremy
2021-05-01 16:59   ` Prayank
2021-05-03  4:02 ` ZmnSCPxj
2021-05-06  1:57   ` Prayank
2021-05-14 10:05 Prayank
2021-05-18 13:10 ` ZmnSCPxj

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox