Re: [bitcoin-dev] Fee estimates and RBF

[Jeremy via bitcoin-dev]

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 



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
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Fee estimates and RBF

[Prayank via bitcoin-dev]

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

Re: [bitcoin-dev] Proposed BIP editor: Kalle Alm

[Jameson Lopp via bitcoin-dev]

On Fri, Apr 30, 2021 at 7:59 AM Amir Taaki via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> A committee to guide the committee? You guys truly have lost the plot.
>
> All the good minds and cryptographers have left Bitcoin. What remains is
> an empty echo chamber.
>
> Truth is these problems start with lack of vision and long-term roadmap,
> not with the processes themselves.
>
> And the Bitcoin Core monopoly created this situation; one coin, one
> client, one vision. And the inevitable infighting for ultimate power.
>
> Really if we want to go down this route, there should be a long period
> of self reflection about where the problems began rather than patching
> some process and moving on.
>
> I propose Bitcoin Core is dissolved as the official Bitcoin project.


Nonsense, as it is not the official Bitcoin project. There is no such thing.

The community is free to elect their preferred version of Bitcoin.


Individuals have voted with their feet and are free to continue to do so.
It's anarchy, I tell you!


> And most importantly, Bitcoin developers commit to a fully specced
> standard that
> all implementations move towards using.
>

Who decides the spec? Perhaps... a committee of some sort?


>
> On 4/28/21 12:30 AM, Jaime Caring via bitcoin-dev wrote:
> > Kalle should not be made an editor by an ad-hoc process. I reiterate
> > Greg's NACK.
> >
> > I propose that we form a stewardship committee of frequent contributors,
> > including you, Greg, and 21 others. The stewards appoint a small set of
> > editors with permanent oversight by the stewards. A defined process
> > prevents this controversy from arising in the future and makes
> > proceedings clear.
> >
> > My proposal has been moderated off of this list, but may be viewed here:
> > https://github.com/bitcoin/bips/pull/1113
> > 
> >
> > I care not for the role of initial transitory editor. I would be pleased
> > should any responsible community member shoulder this onus in my stead.
> >
> > Peace be upon you,
> >
> > JC
> >
> > On Mon, 26 Apr 2021 at 00:37, David A. Harding via bitcoin-dev
> >  > > wrote:
> >
> > On Sat, Apr 24, 2021 at 04:42:12AM +, Greg Maxwell via
> > bitcoin-dev wrote:
> > > I am opposed to the addition of Kalle Alm at this time.  Those who
> > > believe [this] will resolve the situation [...] re: PR1104 are
> > > mistaken.
> >
> > PR1104 has been merged.  Do you continue to oppose the addition?
> >
> > Thanks,
> >
> > -Dave
> > ___
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > 
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > 
> >
> >
> > ___
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposed BIP editor: Kalle Alm

[Karl via bitcoin-dev]

A good solution here is to make it clear to visitors that facilitation,
mediation, and organisation help is badly needed in the core development
team.

People with such expertise can even be hired directly.

A good facilitator opens communication paths between all parties, leaving
everyone satisfied with decisions.  Don't accept a compromise if you can
look for something better.

On Fri, Apr 30, 2021, 8:00 AM Amir Taaki via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> A committee to guide the committee? You guys truly have lost the plot.
>
> All the good minds and cryptographers have left Bitcoin. What remains is
> an empty echo chamber.
>
> Truth is these problems start with lack of vision and long-term roadmap,
> not with the processes themselves.
>
> And the Bitcoin Core monopoly created this situation; one coin, one
> client, one vision. And the inevitable infighting for ultimate power.
>
> Really if we want to go down this route, there should be a long period
> of self reflection about where the problems began rather than patching
> some process and moving on.
>
> I propose Bitcoin Core is dissolved as the official Bitcoin project. The
> community is free to elect their preferred version of Bitcoin. And most
> importantly, Bitcoin developers commit to a fully specced standard that
> all implementations move towards using.
>
> On 4/28/21 12:30 AM, Jaime Caring via bitcoin-dev wrote:
> > Kalle should not be made an editor by an ad-hoc process. I reiterate
> > Greg's NACK.
> >
> > I propose that we form a stewardship committee of frequent contributors,
> > including you, Greg, and 21 others. The stewards appoint a small set of
> > editors with permanent oversight by the stewards. A defined process
> > prevents this controversy from arising in the future and makes
> > proceedings clear.
> >
> > My proposal has been moderated off of this list, but may be viewed here:
> > https://github.com/bitcoin/bips/pull/1113
> > 
> >
> > I care not for the role of initial transitory editor. I would be pleased
> > should any responsible community member shoulder this onus in my stead.
> >
> > Peace be upon you,
> >
> > JC
> >
> > On Mon, 26 Apr 2021 at 00:37, David A. Harding via bitcoin-dev
> >  > > wrote:
> >
> > On Sat, Apr 24, 2021 at 04:42:12AM +, Greg Maxwell via
> > bitcoin-dev wrote:
> > > I am opposed to the addition of Kalle Alm at this time.  Those who
> > > believe [this] will resolve the situation [...] re: PR1104 are
> > > mistaken.
> >
> > PR1104 has been merged.  Do you continue to oppose the addition?
> >
> > Thanks,
> >
> > -Dave
> > ___
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > 
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > 
> >
> >
> > ___
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposed BIP editor: Kalle Alm

[Amir Taaki via bitcoin-dev]

A committee to guide the committee? You guys truly have lost the plot.

All the good minds and cryptographers have left Bitcoin. What remains is
an empty echo chamber.

Truth is these problems start with lack of vision and long-term roadmap,
not with the processes themselves.

And the Bitcoin Core monopoly created this situation; one coin, one
client, one vision. And the inevitable infighting for ultimate power.

Really if we want to go down this route, there should be a long period
of self reflection about where the problems began rather than patching
some process and moving on.

I propose Bitcoin Core is dissolved as the official Bitcoin project. The
community is free to elect their preferred version of Bitcoin. And most
importantly, Bitcoin developers commit to a fully specced standard that
all implementations move towards using.

On 4/28/21 12:30 AM, Jaime Caring via bitcoin-dev wrote:
> Kalle should not be made an editor by an ad-hoc process. I reiterate
> Greg's NACK.
> 
> I propose that we form a stewardship committee of frequent contributors,
> including you, Greg, and 21 others. The stewards appoint a small set of
> editors with permanent oversight by the stewards. A defined process
> prevents this controversy from arising in the future and makes
> proceedings clear.
> 
> My proposal has been moderated off of this list, but may be viewed here:
> https://github.com/bitcoin/bips/pull/1113
> 
> 
> I care not for the role of initial transitory editor. I would be pleased
> should any responsible community member shoulder this onus in my stead.
> 
> Peace be upon you,
> 
> JC
> 
> On Mon, 26 Apr 2021 at 00:37, David A. Harding via bitcoin-dev
>  > wrote:
> 
> On Sat, Apr 24, 2021 at 04:42:12AM +, Greg Maxwell via
> bitcoin-dev wrote:
> > I am opposed to the addition of Kalle Alm at this time.  Those who
> > believe [this] will resolve the situation [...] re: PR1104 are
> > mistaken.
> 
> PR1104 has been merged.  Do you continue to oppose the addition?
> 
> Thanks,
> 
> -Dave
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
> 
> 
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev