f3e08092fa87cda7bb77b06340016bf2cecd95
1 Return-Path: <prayank@tutanota.de> 2 Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) 3 by lists.linuxfoundation.org (Postfix) with ESMTP id 06D0BC0001 4 for <bitcoin-dev@lists.linuxfoundation.org>; 5 Sat, 1 May 2021 16:59:19 +0000 (UTC) 6 Received: from localhost (localhost [127.0.0.1]) 7 by smtp3.osuosl.org (Postfix) with ESMTP id E21B56081D 8 for <bitcoin-dev@lists.linuxfoundation.org>; 9 Sat, 1 May 2021 16:59:18 +0000 (UTC) 10 X-Virus-Scanned: amavisd-new at osuosl.org 11 X-Spam-Flag: YES 12 X-Spam-Score: 6.93 13 X-Spam-Level: ****** 14 X-Spam-Status: Yes, score=6.93 tagged_above=-999 required=5 15 tests=[BAYES_50=0.8, BITCOIN_IMGUR=3.33, DKIM_SIGNED=0.1, 16 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 17 HOSTED_IMG_MULTI_PUB_01=2.999, HTML_MESSAGE=0.001, 18 RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 19 SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 20 Authentication-Results: smtp3.osuosl.org (amavisd-new); 21 dkim=pass (2048-bit key) header.d=tutanota.de 22 Received: from smtp3.osuosl.org ([127.0.0.1]) 23 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) 24 with ESMTP id 1BRA5MXjiS0C 25 for <bitcoin-dev@lists.linuxfoundation.org>; 26 Sat, 1 May 2021 16:59:17 +0000 (UTC) 27 X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 28 Received: from w1.tutanota.de (w1.tutanota.de [81.3.6.162]) 29 by smtp3.osuosl.org (Postfix) with ESMTPS id 45835605E2 30 for <bitcoin-dev@lists.linuxfoundation.org>; 31 Sat, 1 May 2021 16:59:17 +0000 (UTC) 32 Received: from w3.tutanota.de (unknown [192.168.1.164]) 33 by w1.tutanota.de (Postfix) with ESMTP id 6F1E6FA0254; 34 Sat, 1 May 2021 16:59:14 +0000 (UTC) 35 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1619888354; 36 s=s1; d=tutanota.de; 37 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; 38 bh=FFXJys2wPLFKOnEXRwRxJ+hS9uI4WwRuQnBKyDfomnw=; 39 b=3P7pawp1x9Lp8nGBVkrLePOMsMIeG1FsVKuhyeIUg6aEBu3KMHgpSo3VbTDFxAK7 40 qDAp86vSKkxqBpsTZDiv9JxC1n+5pTnWOY97egzlV63Sw68VdgH0GGqdTHVjAH8EaSr 41 zO+v7E5UdQs+xSfdg/+OaQWhh3HVh5wBDmK0Q4lh7c3J4GuzsShgQPWpb87MOYMMK+T 42 KMBqEHN0dafzJtyyZigStcSifoS2VF+9Bf/UaESaO1alQaESSAm43FwfbW3WjWSgwJY 43 b44YUEZ16L9rB/xvLWPSiEdN3OL3tN3b/jm7kVVGCrNuIgaIk2VaWWOrb57U8YY6olb 44 s7zRnjJVSg== 45 Date: Sat, 1 May 2021 18:59:14 +0200 (CEST) 46 From: Prayank <prayank@tutanota.de> 47 To: Jeremy <jlrubin@mit.edu> 48 Message-ID: <MZcrehR----2@tutanota.de> 49 In-Reply-To: <CAD5xwhhCipMiOSHd3Ff_SJPkkjGFh44G_A3nARQ3M_OfhjqoUA@mail.gmail.com> 50 References: <MZZT0_o--3-2@tutanota.de> 51 <CAD5xwhhCipMiOSHd3Ff_SJPkkjGFh44G_A3nARQ3M_OfhjqoUA@mail.gmail.com> 52 MIME-Version: 1.0 53 Content-Type: multipart/alternative; 54 boundary="----=_Part_67712_99364510.1619888354429" 55 X-Mailman-Approved-At: Sat, 01 May 2021 18:04:34 +0000 56 Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> 57 Subject: Re: [bitcoin-dev] Fee estimates and RBF 58 X-BeenThere: bitcoin-dev@lists.linuxfoundation.org 59 X-Mailman-Version: 2.1.15 60 Precedence: list 61 List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> 62 List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 63 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> 64 List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> 65 List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> 66 List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> 67 List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 68 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> 69 X-List-Received-Date: Sat, 01 May 2021 16:59:19 -0000 70 71 ------=_Part_67712_99364510.1619888354429 72 Content-Type: text/plain; charset=UTF-8 73 Content-Transfer-Encoding: quoted-printable 74 75 Thanks Jeremy for sharing this link:=C2=A0https://lists.linuxfoundation.org= 76 /pipermail/bitcoin-dev/2020-September/018168.html 77 78 Trying to understand everything mentioned and "fee-only" wallet sounds inte= 79 resting. 80 --=20 81 Prayank 82 83 May 1, 2021, 05:41 by jlrubin@mit.edu: 84 85 > Hi Prayank, 86 > 87 > Very glad to hear you are weathering the storm OK, wishing you and yours = 88 safety in the weeks ahead. 89 > 90 > I think you'll be interested to see > https://lists.linuxfoundation.org/p= 91 ipermail/bitcoin-dev/2020-September/018168.html> especially with regards t= 92 o background services. 93 > 94 > In the long term, this can be particularly useful since you can use a sep= 95 arate fee-only wallet to arrange the bumps if your main wallet keys are off= 96 line, and you do not disturb any of the on-chain dependants. 97 > 98 > It can also be much cheaper to use this mechanism than actual RBF because= 99 you are not subject to the feerate improvement rule, which forces you to p= 100 ay for the bump on all tx data. 101 > 102 > I would be very interested to see a system whereby you can make a market = 103 (maybe via LN) for someone to get your TX included (using oracle network OK= 104 ) by a particular date. Then you can abstract the whole system a lot better= 105 , so that you can fee bump without having to create any direct on chain tra= 106 ffic, and a sponsor vector can be offered across a number of txns by a serv= 107 ice provider. 108 > 109 > Cheers, 110 > 111 > Jeremy 112 > -- 113 > @JeremyRubin <https://twitter.com/JeremyRubin> <https://twitter.com/Jerem= 114 yRubin> 115 > 116 > 117 > On Fri, Apr 30, 2021 at 2:40 PM Prayank via bitcoin-dev <> bitcoin-dev@li= 118 sts.linuxfoundation.org> > wrote: 119 > 120 >> Hello World,=20 121 >> 122 >> I hope everyone is doing okay. Things are not good in India and even I w= 123 as tested covid positive few days back. Recovered and feeling better now. H= 124 oping everything gets back to normal soon. 125 >> 126 >> There are different estimations used in wallets, explorers and other Bit= 127 coin projects. For example: `estimatesmartfee` in Bitcoin Core (One of the = 128 implementation for Bitcoin which is used more but not official as there is = 129 nothing official in Bitcoin).=C2=A0 Are different estimations misleading an= 130 d affect the way fees are used in Bitcoin transactions? Will it be better i= 131 f we just share mempool stats and user can decide the fee rate accordingly? 132 >> 133 >> If I compare this with BTCUSD orderbook on any exchange, are we trying t= 134 o estimate at what price buy order will get filled in certain time? Does th= 135 at make sense? 136 >> 137 >> Mempool Stats: >> https://i.imgur.com/r4XKk2p.png 138 >> BTCUSD Orderbook: >> https://i.imgur.com/ylGVHJB.png 139 >> 140 >> I consider it misleading because lot of users think a transaction with f= 141 ee rate 1-5 sat/vByte will be included in 1 week or maybe a transaction wit= 142 h X sat/VByte will be included in Y time which is not true. Users can decid= 143 e the fee rate and can do bidding, transaction will be included based on de= 144 mand, supply and miners. 145 >> 146 >> Will it be better if the wallets used this approach? 147 >> 1.Show mempool stats 148 >> 2.Leave the fee rate for user to decide 149 >> 3.RBF every transaction and follow different algorithms for automated bi= 150 dding 151 >> 152 >> A basic algorithm for automated bidding can be: >> https://i.stack.imgur= 153 .com/1SlPv.png 154 >> 155 >> Such RBF algos can be helpful for users when Bitcoin wallets are open in= 156 background. Maybe it will work better for mobile wallets in which you can = 157 see a notification every time transaction is replaced with a new fee rate a= 158 utomatically. 159 >> 160 >> I wanted to know what others think about this approach of creating and u= 161 sing different RBF algos instead of predicting something that is difficult = 162 or doesn't make sense. Also if there was a way we could achieve this even i= 163 f the user goes offline. For example: Alice broadcasts Tx1 with 1 sat/vByte= 164 , its replaced with Tx2 (2 sat/vByte) after 2 blocks because Tx1 was not co= 165 nfirmed. Alice decides to shut down her system or switch off mobile or mobi= 166 le data. Tx2 is still not confirmed after another 2 blocks but it has some = 167 information as one OP_RETURN output which is used by Bitcoin nodes that see= 168 this transaction in the mempool. Bob's node use this information to replac= 169 e the transaction with Tx3 and use fee rate 3 sat/vByte. 170 >> 171 >> -- 172 >> Prayank 173 >> 174 >> _______________________________________________ 175 >> bitcoin-dev mailing list 176 >> >> bitcoin-dev@lists.linuxfoundation.org 177 >> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev 178 >> 179 180 181 ------=_Part_67712_99364510.1619888354429 182 Content-Type: text/html; charset=UTF-8 183 Content-Transfer-Encoding: quoted-printable 184 185 <html> 186 <head> 187 <meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUTF-8= 188 "> 189 </head> 190 <body> 191 <div>Thanks Jeremy for sharing this link: <a href=3D"https://lists.lin= 192 uxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html">https://= 193 lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html<= 194 /a><br></div><div><br></div><div>Trying to understand everything mentioned = 195 and "fee-only" wallet sounds interesting.</div><div><br></div><div>-- <br><= 196 /div><div>Prayank</div><div><br></div><div><br></div><div>May 1, 2021, 05:4= 197 1 by jlrubin@mit.edu:<br></div><blockquote class=3D"tutanota_quote" style= 198 =3D"border-left: 1px solid #93A3B8; padding-left: 10px; margin-left: 5px;">= 199 <div dir=3D"ltr"><div style=3D"font-family:arial,helvetica,sans-serif;font-= 200 size:small;color:#000000" class=3D"">Hi Prayank,<br></div><div style=3D"fon= 201 t-family:arial,helvetica,sans-serif;font-size:small;color:#000000" class=3D= 202 ""><br></div><div style=3D"font-family:arial,helvetica,sans-serif;font-size= 203 :small;color:#000000" class=3D"">Very glad to hear you are weathering the s= 204 torm OK, wishing you and yours safety in the weeks ahead.<br></div><div sty= 205 le=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"= 206 class=3D""><br></div><div style=3D"font-family:arial,helvetica,sans-serif;= 207 font-size:small;color:#000000" class=3D"">I think you'll be interested to s= 208 ee <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-= 209 September/018168.html" rel=3D"noopener noreferrer" target=3D"_blank">https:= 210 //lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.htm= 211 l</a> especially with regards to background services.<br></div><div style= 212 =3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000" c= 213 lass=3D""><br></div><div style=3D"font-family:arial,helvetica,sans-serif;fo= 214 nt-size:small;color:#000000" class=3D"">In the long term, this can be parti= 215 cularly useful since you can use a separate fee-only wallet to arrange the = 216 bumps if your main wallet keys are offline, and you do not disturb any of t= 217 he on-chain dependants.<br></div><div style=3D"font-family:arial,helvetica,= 218 sans-serif;font-size:small;color:#000000" class=3D""><br></div><div style= 219 =3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000" c= 220 lass=3D"">It can also be much cheaper to use this mechanism than actual RBF= 221 because you are not subject to the feerate improvement rule, which forces = 222 you to pay for the bump on all tx data.<br></div><div style=3D"font-family:= 223 arial,helvetica,sans-serif;font-size:small;color:#000000" class=3D""><br></= 224 div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;co= 225 lor:#000000" class=3D"">I would be very interested to see a system whereby = 226 you can make a market (maybe via LN) for someone to get your TX included (u= 227 sing oracle network OK) by a particular date. Then you can abstract the who= 228 le system a lot better, so that you can fee bump without having to create a= 229 ny direct on chain traffic, and a sponsor vector can be offered across a nu= 230 mber of txns by a service provider.<br></div><div style=3D"font-family:aria= 231 l,helvetica,sans-serif;font-size:small;color:#000000" class=3D""><br></div>= 232 <div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:= 233 #000000" class=3D"">Cheers,<br></div><div style=3D"font-family:arial,helvet= 234 ica,sans-serif;font-size:small;color:#000000" class=3D""><br></div><div sty= 235 le=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"= 236 class=3D"">Jeremy<br></div><div><div data-smartmail=3D"gmail_signature" cl= 237 ass=3D"" dir=3D"ltr"><div dir=3D"ltr"><div>--<br></div><div><a target=3D"_b= 238 lank" href=3D"https://twitter.com/JeremyRubin" rel=3D"noopener noreferrer">= 239 @JeremyRubin</a><a target=3D"_blank" href=3D"https://twitter.com/JeremyRubi= 240 n" rel=3D"noopener noreferrer"></a><br></div></div></div></div><div><br></d= 241 iv></div><div><br></div><div class=3D""><div class=3D"" dir=3D"ltr">On Fri,= 242 Apr 30, 2021 at 2:40 PM Prayank via bitcoin-dev <<a href=3D"mailto:bitc= 243 oin-dev@lists.linuxfoundation.org" rel=3D"noopener noreferrer" target=3D"_b= 244 lank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockq= 245 uote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20= 246 4);padding-left:1ex" class=3D""><div><div>Hello World, <br></div><div><br><= 247 /div><div>I hope everyone is doing okay. Things are not good in India and e= 248 ven I was tested covid positive few days back. Recovered and feeling better= 249 now. Hoping everything gets back to normal soon.<br></div><div><br></div><= 250 div>There are different estimations used in wallets, explorers and other Bi= 251 tcoin projects. For example: `estimatesmartfee` in Bitcoin Core (One of the= 252 implementation for Bitcoin which is used more but not official as there is= 253 nothing official in Bitcoin). Are different estimations misleading a= 254 nd affect the way fees are used in Bitcoin transactions? Will it be better = 255 if we just share mempool stats and user can decide the fee rate accordingly= 256 ?<br></div><div><br></div><div>If I compare this with BTCUSD orderbook on a= 257 ny exchange, are we trying to estimate at what price buy order will get fil= 258 led in certain time? Does that make sense?<br></div><div><br></div><div>Mem= 259 pool Stats: <a target=3D"_blank" href=3D"https://i.imgur.com/r4XKk2p.png" r= 260 el=3D"noopener noreferrer">https://i.imgur.com/r4XKk2p.png</a><br></div><di= 261 v>BTCUSD Orderbook: <a target=3D"_blank" href=3D"https://i.imgur.com/ylGVHJ= 262 B.png" rel=3D"noopener noreferrer">https://i.imgur.com/ylGVHJB.png</a><br><= 263 /div><div><br></div><div>I consider it misleading because lot of users thin= 264 k a transaction with fee rate 1-5 sat/vByte will be included in 1 week or m= 265 aybe a transaction with X sat/VByte will be included in Y time which is not= 266 true. Users can decide the fee rate and can do bidding, transaction will b= 267 e included based on demand, supply and miners.<br></div><div><br></div><div= 268 >Will it be better if the wallets used this approach?<br></div><div>1.Show = 269 mempool stats<br></div><div>2.Leave the fee rate for user to decide<br></di= 270 v><div>3.RBF every transaction and follow different algorithms for automate= 271 d bidding<br></div><div><br></div><div>A basic algorithm for automated bidd= 272 ing can be: <a target=3D"_blank" href=3D"https://i.stack.imgur.com/1SlPv.pn= 273 g" rel=3D"noopener noreferrer">https://i.stack.imgur.com/1SlPv.png</a><br><= 274 /div><div><br></div><div>Such RBF algos can be helpful for users when Bitco= 275 in wallets are open in background. Maybe it will work better for mobile wal= 276 lets in which you can see a notification every time transaction is replaced= 277 with a new fee rate automatically.<br></div><div><br></div><div>I wanted t= 278 o know what others think about this approach of creating and using differen= 279 t RBF algos instead of predicting something that is difficult or doesn't ma= 280 ke sense. Also if there was a way we could achieve this even if the user go= 281 es offline. For example: Alice broadcasts Tx1 with 1 sat/vByte, its replace= 282 d with Tx2 (2 sat/vByte) after 2 blocks because Tx1 was not confirmed. Alic= 283 e decides to shut down her system or switch off mobile or mobile data. Tx2 = 284 is still not confirmed after another 2 blocks but it has some information a= 285 s one OP_RETURN output which is used by Bitcoin nodes that see this transac= 286 tion in the mempool. Bob's node use this information to replace the transac= 287 tion with Tx3 and use fee rate 3 sat/vByte.<br></div><div><br></div><div>--= 288 <br></div><div>Prayank<br></div><div><br></div></div><div>_________________= 289 ______________________________<br></div><div> bitcoin-dev mailing list<br><= 290 /div><div> <a target=3D"_blank" href=3D"mailto:bitcoin-dev@lists.linuxfound= 291 ation.org" rel=3D"noopener noreferrer">bitcoin-dev@lists.linuxfoundation.or= 292 g</a><br></div><div> <a target=3D"_blank" rel=3D"noopener noreferrer" href= 293 =3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https:/= 294 /lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br></div></bloc= 295 kquote></div></blockquote><div><br></div> </body> 296 </html> 297 298 ------=_Part_67712_99364510.1619888354429-- 299