Nathan Wilcox [ARCHIVE] on Nostr: 📅 Original date posted:2017-09-28 📝 Original message:On Fri, Sep 29, 2017 at ...
📅 Original date posted:2017-09-28
📝 Original message:On Fri, Sep 29, 2017 at 11:10 AM, Peter Todd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Fri, Sep 29, 2017 at 01:53:55AM +0000, Matt Corallo via bitcoin-dev
> wrote:
> > I'm somewhat curious what the authors envisioned the real-world
> implications of this model to be. While blindly asking users to enter what
> they're willing to pay always works in theory, I'd imagine in such a world
> the fee selection UX would be similar to what it is today - users are
> provided a list of options with feerates and expected confirmation times
> from which to select. Indeed, in a world where users pay a lower fee if
> they paid more than necessary fee estimation could be more willing to
> overshoot and the UX around RBF and CPFP could be simplified greatly, but
> I'm not actually convinced that it would result in higher overall mining
> revenue.
>
> Note too that the fee users are willing to pay often changes over time.
>
> My OpenTimestamps service is a perfect example: getting a timestamp
> confirmed
> within 10 minutes of the previous one has little value to me, but if the
> previous completed timestamp was 24 hours ago I'm willing to pay
> significantly
> more money because the time delay is getting significant enough to affect
> the
> trustworthyness of the entire service. So the fee selection mechanism is
> nothing more than a RBF-using loop that bumps the fee every time a block
> gets
> mined w/o confirming my latest transaction.
>
> This kind of time sensitivity is probably true of a majority of Bitcoin
> use-cases, with the caveat that often the slope will be negative
> eventually:
> after a point in time completing the transaction has no value.
>
>
Wouldn't this RBF loop behave pretty much the same in the Monopolistic
Price Mechanism? (I haven't grokked RSOP yet.)
In fact, so long as RBF works, isn't it possible to raise Pay-Your-Bid fees
and Monopolistic Price fees over time to express the time curve preference?
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170929/a7352e52/attachment.html>;
📝 Original message:On Fri, Sep 29, 2017 at 11:10 AM, Peter Todd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Fri, Sep 29, 2017 at 01:53:55AM +0000, Matt Corallo via bitcoin-dev
> wrote:
> > I'm somewhat curious what the authors envisioned the real-world
> implications of this model to be. While blindly asking users to enter what
> they're willing to pay always works in theory, I'd imagine in such a world
> the fee selection UX would be similar to what it is today - users are
> provided a list of options with feerates and expected confirmation times
> from which to select. Indeed, in a world where users pay a lower fee if
> they paid more than necessary fee estimation could be more willing to
> overshoot and the UX around RBF and CPFP could be simplified greatly, but
> I'm not actually convinced that it would result in higher overall mining
> revenue.
>
> Note too that the fee users are willing to pay often changes over time.
>
> My OpenTimestamps service is a perfect example: getting a timestamp
> confirmed
> within 10 minutes of the previous one has little value to me, but if the
> previous completed timestamp was 24 hours ago I'm willing to pay
> significantly
> more money because the time delay is getting significant enough to affect
> the
> trustworthyness of the entire service. So the fee selection mechanism is
> nothing more than a RBF-using loop that bumps the fee every time a block
> gets
> mined w/o confirming my latest transaction.
>
> This kind of time sensitivity is probably true of a majority of Bitcoin
> use-cases, with the caveat that often the slope will be negative
> eventually:
> after a point in time completing the transaction has no value.
>
>
Wouldn't this RBF loop behave pretty much the same in the Monopolistic
Price Mechanism? (I haven't grokked RSOP yet.)
In fact, so long as RBF works, isn't it possible to raise Pay-Your-Bid fees
and Monopolistic Price fees over time to express the time curve preference?
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170929/a7352e52/attachment.html>;