+Return-Path: <prayank@tutanota.de>

+Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])

+ by lists.linuxfoundation.org (Postfix) with ESMTP id 06D0BC0001

+ for <bitcoin-dev@lists.linuxfoundation.org>;

+ 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 <bitcoin-dev@lists.linuxfoundation.org>;

+ 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 <bitcoin-dev@lists.linuxfoundation.org>;

+ 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 <bitcoin-dev@lists.linuxfoundation.org>;

+ 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 <prayank@tutanota.de>

+To: Jeremy <jlrubin@mit.edu>

+Message-ID: <MZcrehR----2@tutanota.de>

+In-Reply-To: <CAD5xwhhCipMiOSHd3Ff_SJPkkjGFh44G_A3nARQ3M_OfhjqoUA@mail.gmail.com>

+References: <MZZT0_o--3-2@tutanota.de>

+ <CAD5xwhhCipMiOSHd3Ff_SJPkkjGFh44G_A3nARQ3M_OfhjqoUA@mail.gmail.com>

+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 <bitcoin-dev@lists.linuxfoundation.org>

+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 <bitcoin-dev.lists.linuxfoundation.org>

+List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,

+ <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>

+List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>

+List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>

+List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>

+List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,

+ <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <https://twitter.com/JeremyRubin> <https://twitter.com/Jerem=

+yRubin>

+>

+>

+> 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

+

+<html>

+ <head>

+ <meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUTF-8=

+">

+ </head>

+ <body>

+<div>Thanks Jeremy for sharing this link:&nbsp;<a href=3D"https://lists.lin=

+uxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html">https://=

+lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html<=

+/a><br></div><div><br></div><div>Trying to understand everything mentioned =

+and "fee-only" wallet sounds interesting.</div><div><br></div><div>-- <br><=

+/div><div>Prayank</div><div><br></div><div><br></div><div>May 1, 2021, 05:4=

+1 by jlrubin@mit.edu:<br></div><blockquote class=3D"tutanota_quote" style=

+=3D"border-left: 1px solid #93A3B8; padding-left: 10px; margin-left: 5px;">=

+<div dir=3D"ltr"><div style=3D"font-family:arial,helvetica,sans-serif;font-=

+size:small;color:#000000" class=3D"">Hi Prayank,<br></div><div style=3D"fon=

+t-family:arial,helvetica,sans-serif;font-size:small;color:#000000" class=3D=

+""><br></div><div style=3D"font-family:arial,helvetica,sans-serif;font-size=

+:small;color:#000000" class=3D"">Very glad to hear you are weathering the s=

+torm OK, wishing you and yours safety in the weeks ahead.<br></div><div sty=

+le=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"=

+ class=3D""><br></div><div style=3D"font-family:arial,helvetica,sans-serif;=

+font-size:small;color:#000000" class=3D"">I think you'll be interested to s=

+ee <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-=

+September/018168.html" rel=3D"noopener noreferrer" target=3D"_blank">https:=

+//lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.htm=

+l</a> especially with regards to background services.<br></div><div style=

+=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000" c=

+lass=3D""><br></div><div style=3D"font-family:arial,helvetica,sans-serif;fo=

+nt-size:small;color:#000000" class=3D"">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.<br></div><div style=3D"font-family:arial,helvetica,=

+sans-serif;font-size:small;color:#000000" class=3D""><br></div><div style=

+=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000" c=

+lass=3D"">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.<br></div><div style=3D"font-family:=

+arial,helvetica,sans-serif;font-size:small;color:#000000" class=3D""><br></=

+div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;co=

+lor:#000000" class=3D"">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.<br></div><div style=3D"font-family:aria=

+l,helvetica,sans-serif;font-size:small;color:#000000" class=3D""><br></div>=

+<div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:=

+#000000" class=3D"">Cheers,<br></div><div style=3D"font-family:arial,helvet=

+ica,sans-serif;font-size:small;color:#000000" class=3D""><br></div><div sty=

+le=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"=

+ class=3D"">Jeremy<br></div><div><div data-smartmail=3D"gmail_signature" cl=

+ass=3D"" dir=3D"ltr"><div dir=3D"ltr"><div>--<br></div><div><a target=3D"_b=

+lank" href=3D"https://twitter.com/JeremyRubin" rel=3D"noopener noreferrer">=

+@JeremyRubin</a><a target=3D"_blank" href=3D"https://twitter.com/JeremyRubi=

+n" rel=3D"noopener noreferrer"></a><br></div></div></div></div><div><br></d=

+iv></div><div><br></div><div class=3D""><div class=3D"" dir=3D"ltr">On Fri,=

+ Apr 30, 2021 at 2:40 PM Prayank via bitcoin-dev &lt;<a href=3D"mailto:bitc=

+oin-dev@lists.linuxfoundation.org" rel=3D"noopener noreferrer" target=3D"_b=

+lank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockq=

+uote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=

+4);padding-left:1ex" class=3D""><div><div>Hello World, <br></div><div><br><=

+/div><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.<br></div><div><br></div><=

+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).&nbsp; 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=

+?<br></div><div><br></div><div>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?<br></div><div><br></div><div>Mem=

+pool Stats: <a target=3D"_blank" href=3D"https://i.imgur.com/r4XKk2p.png" r=

+el=3D"noopener noreferrer">https://i.imgur.com/r4XKk2p.png</a><br></div><di=

+v>BTCUSD Orderbook: <a target=3D"_blank" href=3D"https://i.imgur.com/ylGVHJ=

+B.png" rel=3D"noopener noreferrer">https://i.imgur.com/ylGVHJB.png</a><br><=

+/div><div><br></div><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.<br></div><div><br></div><div=

+>Will it be better if the wallets used this approach?<br></div><div>1.Show =

+mempool stats<br></div><div>2.Leave the fee rate for user to decide<br></di=

+v><div>3.RBF every transaction and follow different algorithms for automate=

+d bidding<br></div><div><br></div><div>A basic algorithm for automated bidd=

+ing can be: <a target=3D"_blank" href=3D"https://i.stack.imgur.com/1SlPv.pn=

+g" rel=3D"noopener noreferrer">https://i.stack.imgur.com/1SlPv.png</a><br><=

+/div><div><br></div><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.<br></div><div><br></div><div>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.<br></div><div><br></div><div>--=

+<br></div><div>Prayank<br></div><div><br></div></div><div>_________________=

+______________________________<br></div><div> bitcoin-dev mailing list<br><=

+/div><div> <a target=3D"_blank" href=3D"mailto:bitcoin-dev@lists.linuxfound=

+ation.org" rel=3D"noopener noreferrer">bitcoin-dev@lists.linuxfoundation.or=

+g</a><br></div><div> <a target=3D"_blank" rel=3D"noopener noreferrer" href=

+=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https:/=

+/lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br></div></bloc=

+kquote></div></blockquote><div><br></div> </body>

+</html>

+

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

+