path: root/72/f3e08092fa87cda7bb77b06340016bf2cecd95

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