path: root/24/df25f33669da7d4d0a90e898e3d17d3c67c984

Return-Path: <jlrubin@mit.edu>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id B63C9C0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  1 May 2021 00:11:58 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id A454541CA1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  1 May 2021 00:11:58 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 7Fv0GoU_XmXA
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  1 May 2021 00:11:56 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
 by smtp4.osuosl.org (Postfix) with ESMTPS id A9BE341C75
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  1 May 2021 00:11:56 +0000 (UTC)
Received: from mail-il1-f172.google.com (mail-il1-f172.google.com
 [209.85.166.172]) (authenticated bits=0)
 (User authenticated as jlrubin@ATHENA.MIT.EDU)
 by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 1410BrP0012173
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
 for <bitcoin-dev@lists.linuxfoundation.org>; Fri, 30 Apr 2021 20:11:54 -0400
Received: by mail-il1-f172.google.com with SMTP id e14so2540475ils.12
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 30 Apr 2021 17:11:53 -0700 (PDT)
X-Gm-Message-State: AOAM5328c5h6q9nB2kA75RYFnaPzDYLCJX/wrMPX45muznO/XgA1JNpW
 N9VoO/wvjXmDgJX1GsxQE+rRHrVXlck6VuGf6i0=
X-Google-Smtp-Source: ABdhPJyB4zsPJ41GQPPUt51ERaDd0449SUr9eyVONWjmgUZn1o9+ogPCFrAvTqwu7nbtblvDn8sml+H00kEu+98aKis=
X-Received: by 2002:a05:6e02:1d16:: with SMTP id
 i22mr5992603ila.164.1619827913212; 
 Fri, 30 Apr 2021 17:11:53 -0700 (PDT)
MIME-Version: 1.0
References: <MZZT0_o--3-2@tutanota.de>
In-Reply-To: <MZZT0_o--3-2@tutanota.de>
From: Jeremy <jlrubin@mit.edu>
Date: Fri, 30 Apr 2021 17:11:42 -0700
X-Gmail-Original-Message-ID: <CAD5xwhhCipMiOSHd3Ff_SJPkkjGFh44G_A3nARQ3M_OfhjqoUA@mail.gmail.com>
Message-ID: <CAD5xwhhCipMiOSHd3Ff_SJPkkjGFh44G_A3nARQ3M_OfhjqoUA@mail.gmail.com>
To: Prayank <prayank@tutanota.de>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000005d480f05c13993e6"
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 00:11:58 -0000

--0000000000005d480f05c13993e6
Content-Type: text/plain; charset="UTF-8"

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
>

--0000000000005d480f05c13993e6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000">Hi Prayank,</div><div cla=
ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"fo=
nt-family:arial,helvetica,sans-serif;font-size:small;color:#000000">Very gl=
ad to hear you are weathering the storm OK, wishing you and yours safety in=
 the weeks ahead.</div><div class=3D"gmail_default" style=3D"font-family:ar=
ial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div clas=
s=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-si=
ze:small;color:#000000">I think you&#39;ll be interested to see <a href=3D"=
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/0181=
68.html">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-Septe=
mber/018168.html</a> especially with regards to background services.</div><=
div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif=
;font-size:small;color:#000000"><br></div><div class=3D"gmail_default" styl=
e=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">=
In the long term, this can be particularly useful since you can use a separ=
ate fee-only wallet to arrange the bumps if your main wallet keys are offli=
ne, and you do not disturb any of the on-chain dependants.</div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:#000000">It can al=
so be much cheaper to use this mechanism than actual RBF because you are no=
t subject to the feerate improvement rule, which forces you to pay for the =
bump on all tx data.</div><div class=3D"gmail_default" style=3D"font-family=
:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div c=
lass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font=
-size:small;color:#000000">I would be very interested to see a system where=
by 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 creat=
e any direct on chain traffic, and a sponsor vector can be offered across a=
 number of txns by a service provider.<br></div><div class=3D"gmail_default=
" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#00=
0000"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,hel=
vetica,sans-serif;font-size:small;color:#000000">Cheers,</div><div class=3D=
"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:s=
mall;color:#000000"><br></div><div class=3D"gmail_default" style=3D"font-fa=
mily:arial,helvetica,sans-serif;font-size:small;color:#000000">Jeremy<br></=
div><div><div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail=
_signature"><div dir=3D"ltr">--<br><a href=3D"https://twitter.com/JeremyRub=
in" target=3D"_blank">@JeremyRubin</a><a href=3D"https://twitter.com/Jeremy=
Rubin" target=3D"_blank"></a></div></div></div><br></div><br><div class=3D"=
gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Apr 30, 2021 at =
2:40 PM Prayank via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.lin=
uxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex">
 =20
   =20
 =20
  <div>
<div>Hello World, <br></div><div><br></div><div>I hope everyone is doing ok=
ay. Things are not good in India and even I was tested covid positive few d=
ays back. Recovered and feeling better now. Hoping everything gets back to =
normal soon.<br></div><div><br></div><div>There are different estimations u=
sed in wallets, explorers and other Bitcoin projects. For example: `estimat=
esmartfee` 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 and affect the way fees are used in Bi=
tcoin transactions? Will it be better if we just share mempool stats and us=
er can decide the fee rate accordingly?<br></div><div><br></div><div>If I c=
ompare this with BTCUSD orderbook on any exchange, are we trying to estimat=
e at what price buy order will get filled in certain time? Does that make s=
ense?<br></div><div><br></div><div>Mempool Stats: <a href=3D"https://i.imgu=
r.com/r4XKk2p.png" target=3D"_blank">https://i.imgur.com/r4XKk2p.png</a><br=
></div><div>BTCUSD Orderbook: <a href=3D"https://i.imgur.com/ylGVHJB.png" t=
arget=3D"_blank">https://i.imgur.com/ylGVHJB.png</a><br></div><div><br></di=
v><div>I consider it misleading because lot of users think a transaction wi=
th 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 d=
ecide the fee rate and can do bidding, transaction will be included based o=
n 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></div><div>3.RBF every=
 transaction and follow different algorithms for automated bidding<br></div=
><div><br></div><div>A basic algorithm for automated bidding can be: <a hre=
f=3D"https://i.stack.imgur.com/1SlPv.png" target=3D"_blank">https://i.stack=
.imgur.com/1SlPv.png</a><br></div><div><br></div><div>Such RBF algos can be=
 helpful for users when Bitcoin wallets are open in background. Maybe it wi=
ll work better for mobile wallets 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 to know what others think about this approach o=
f creating and using different RBF algos instead of predicting something th=
at is difficult or doesn&#39;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 be=
cause Tx1 was not confirmed. Alice decides to shut down her system or switc=
h off mobile or mobile data. Tx2 is still not confirmed after another 2 blo=
cks but it has some information as one OP_RETURN output which is used by Bi=
tcoin nodes that see this transaction in the mempool. Bob&#39;s node use th=
is information to replace the transaction with Tx3 and use fee rate 3 sat/v=
Byte.<br></div><div><br></div><div>--<br></div><div>Prayank<br></div><div><=
br></div>  </div>

_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--0000000000005d480f05c13993e6--