Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 06D0BC0001 for ; Sat, 1 May 2021 16:59:19 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id E21B56081D for ; Sat, 1 May 2021 16:59:18 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: YES X-Spam-Score: 6.93 X-Spam-Level: ****** X-Spam-Status: Yes, score=6.93 tagged_above=-999 required=5 tests=[BAYES_50=0.8, BITCOIN_IMGUR=3.33, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HOSTED_IMG_MULTI_PUB_01=2.999, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=tutanota.de Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BRA5MXjiS0C for ; Sat, 1 May 2021 16:59:17 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from w1.tutanota.de (w1.tutanota.de [81.3.6.162]) by smtp3.osuosl.org (Postfix) with ESMTPS id 45835605E2 for ; Sat, 1 May 2021 16:59:17 +0000 (UTC) Received: from w3.tutanota.de (unknown [192.168.1.164]) by w1.tutanota.de (Postfix) with ESMTP id 6F1E6FA0254; Sat, 1 May 2021 16:59:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1619888354; s=s1; d=tutanota.de; h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:In-Reply-To:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:References:Sender; bh=FFXJys2wPLFKOnEXRwRxJ+hS9uI4WwRuQnBKyDfomnw=; b=3P7pawp1x9Lp8nGBVkrLePOMsMIeG1FsVKuhyeIUg6aEBu3KMHgpSo3VbTDFxAK7 qDAp86vSKkxqBpsTZDiv9JxC1n+5pTnWOY97egzlV63Sw68VdgH0GGqdTHVjAH8EaSr zO+v7E5UdQs+xSfdg/+OaQWhh3HVh5wBDmK0Q4lh7c3J4GuzsShgQPWpb87MOYMMK+T KMBqEHN0dafzJtyyZigStcSifoS2VF+9Bf/UaESaO1alQaESSAm43FwfbW3WjWSgwJY b44YUEZ16L9rB/xvLWPSiEdN3OL3tN3b/jm7kVVGCrNuIgaIk2VaWWOrb57U8YY6olb s7zRnjJVSg== Date: Sat, 1 May 2021 18:59:14 +0200 (CEST) From: Prayank To: Jeremy Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_67712_99364510.1619888354429" X-Mailman-Approved-At: Sat, 01 May 2021 18:04:34 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Fee estimates and RBF X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2021 16:59:19 -0000 ------=_Part_67712_99364510.1619888354429 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Jeremy for sharing this link:=C2=A0https://lists.linuxfoundation.org= /pipermail/bitcoin-dev/2020-September/018168.html Trying to understand everything mentioned and "fee-only" wallet sounds inte= resting. --=20 Prayank May 1, 2021, 05:41 by jlrubin@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/p= ipermail/bitcoin-dev/2020-September/018168.html> especially with regards t= o background services. > > In the long term, this can be particularly useful since you can use a sep= arate fee-only wallet to arrange the bumps if your main wallet keys are off= line, 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 p= ay 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 tra= ffic, and a sponsor vector can be offered across a number of txns by a serv= ice provider. > > Cheers, > > Jeremy > -- > @JeremyRubin > > > On Fri, Apr 30, 2021 at 2:40 PM Prayank via bitcoin-dev <> bitcoin-dev@li= sts.linuxfoundation.org> > wrote: > >> Hello World,=20 >> >> I hope everyone is doing okay. Things are not good in India and even I w= as tested covid positive few days back. Recovered and feeling better now. H= oping everything gets back to normal soon. >> >> There are different estimations used in wallets, explorers and other Bit= coin 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).=C2=A0 Are different estimations misleading an= d affect the way fees are used in Bitcoin transactions? Will it be better i= f 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 t= o estimate at what price buy order will get filled in certain time? Does th= at 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 f= ee rate 1-5 sat/vByte will be included in 1 week or maybe a transaction wit= h X sat/VByte will be included in Y time which is not true. Users can decid= e the fee rate and can do bidding, transaction will be included based on de= mand, 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 bi= dding >> >> 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 a= utomatically. >> >> I wanted to know what others think about this approach of creating and u= sing 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 i= f 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 co= nfirmed. Alice decides to shut down her system or switch off mobile or mobi= le 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 replac= e 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 >> ------=_Part_67712_99364510.1619888354429 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


--
<= /div>
Prayank


May 1, 2021, 05:4= 1 by jlrubin@mit.edu:
=
Hi Prayank,

Very glad to hear you are weathering the s= torm OK, wishing you and yours safety in the weeks ahead.

I think you'll be interested to s= ee https:= //lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.htm= l especially with regards to background services.

In the long term, this can be parti= cularly 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 t= he 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 (u= sing oracle network OK) by a particular date. Then you can abstract the who= le system a lot better, so that you can fee bump without having to create a= ny direct on chain traffic, and a sponsor vector can be offered across a nu= mber of txns by a service provider.

=
Cheers,

Jeremy


On Fri,= Apr 30, 2021 at 2:40 PM Prayank via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
Hello World,

<= /div>
I hope everyone is doing okay. Things are not good in India and e= ven I was tested covid positive few days back. Recovered and feeling better= now. Hoping everything gets back to normal soon.

<= div>There are different estimations used in wallets, explorers and other Bi= tcoin 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 a= nd 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 a= ny exchange, are we trying to estimate at what price buy order will get fil= led in certain time? Does that make sense?

BTCUSD Orderbook: https://i.imgur.com/ylGVHJB.png
<= /div>

I consider it misleading because lot of users thin= k a transaction with fee rate 1-5 sat/vByte will be included in 1 week or m= aybe 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 b= e 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 automate= d bidding

A basic algorithm for automated bidd= ing can be: https://i.stack.imgur.com/1SlPv.png
<= /div>

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

I wanted t= o know what others think about this approach of creating and using differen= t RBF algos instead of predicting something that is difficult or doesn't ma= ke sense. Also if there was a way we could achieve this even if the user go= es offline. For example: Alice broadcasts Tx1 with 1 sat/vByte, its replace= d with Tx2 (2 sat/vByte) after 2 blocks because Tx1 was not confirmed. Alic= e 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 a= s one OP_RETURN output which is used by Bitcoin nodes that see this transac= tion in the mempool. Bob's node use this information to replace the transac= tion with Tx3 and use fee rate 3 sat/vByte.

--=
Prayank

_________________= ______________________________

------=_Part_67712_99364510.1619888354429--