Thanks Jeremy for sharing this link: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html
Trying to understand everything mentioned and "fee-only" wallet sounds interesting. -- Prayank May 1, 2021, 05:41 by jlru...@mit.edu: > Hi Prayank, > > Very glad to hear you are weathering the storm OK, wishing you and yours > safety in the weeks ahead. > > I think you'll be interested to see > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html> > especially with regards to background services. > > In the long term, this can be particularly useful since you can use a > separate fee-only wallet to arrange the bumps if your main wallet keys are > offline, and you do not disturb any of the on-chain dependants. > > It can also be much cheaper to use this mechanism than actual RBF because you > are not subject to the feerate improvement rule, which forces you to pay for > the bump on all tx data. > > I would be very interested to see a system whereby you can make a market > (maybe via LN) for someone to get your TX included (using oracle network OK) > by a particular date. Then you can abstract the whole system a lot better, so > that you can fee bump without having to create any direct on chain traffic, > and a sponsor vector can be offered across a number of txns by a service > provider. > > Cheers, > > Jeremy > -- > @JeremyRubin <https://twitter.com/JeremyRubin> > <https://twitter.com/JeremyRubin> > > > On Fri, Apr 30, 2021 at 2:40 PM Prayank via bitcoin-dev <> > bitcoin-dev@lists.linuxfoundation.org> > wrote: > >> 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 >> >> _______________________________________________ >> bitcoin-dev mailing list >> >> bitcoin-dev@lists.linuxfoundation.org >> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
