Mark Friedenbach [ARCHIVE] on Nostr: 📅 Original date posted:2017-12-21 📝 Original message:Every transaction is ...
📅 Original date posted:2017-12-21
📝 Original message:Every transaction is replace-by-fee capable already. Opt-in replace by fee as specified in BIP 125 is a fiction that held sway only while the income from fees or fee replacement was so much smaller than subsidy.
> On Dec 21, 2017, at 3:35 PM, Paul Iverson via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> I agree with Greg. What is happening is a cause for celebration: it is the manifestation of our long-desired fee market in action. That people are willing to pay upwards of $100 per transaction shows the huge demand to transact on the world's most secure ledger. This is what success looks like, folks!
>
> Now that BTC is being phased out as a means of payment nearly everywhere (e.g., Steam dropping BTC as a payment option) (to be replaced with the more-suitable LN when ready), I'd propose that we address the stuck transaction issue by making replace-by-fee (RBF) ubiquitous. Why not make every transaction RBF by default, and then encourage via outreach and education other wallet developers to do the same?
>
> The frustration with BTC today is less so the high-fees (people realize on-chain transactions in a secure decentralized ledger are necessarily costly) but by the feeling of helplessness when their transaction is stuck. Being able to easily bump a transaction's fee for users who are in a hurry would go a long way to improving the user experience.
>
> Paul.
>
>
> On Thu, Dec 21, 2017 at 2:44 PM, Gregory Maxwell via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
> Personally, I'm pulling out the champaign that market behaviour is
> indeed producing activity levels that can pay for security without
> inflation, and also producing fee paying backlogs needed to stabilize
> consensus progress as the subsidy declines.
>
> I'd also personally prefer to pay lower fees-- current levels even
> challenge my old comparison with wire transfer costs-- but we should
> look most strongly at difficult to forge market signals rather than
> just claims-- segwit usage gives us a pretty good indicator since most
> users would get a 50-70% fee reduction without even considering the
> second order effects from increased capacity.
>
> As Jameson Lopp notes, more can be done for education though-- perhaps
> that market signal isn't efficient yet. But we should get it there.
>
> But even independently of segwit we can also look at other inefficient
> transaction styles: uncompressed keys, unconfirmed chaining instead of
> send many batching, fee overpayment, etc... and the message there is
> similar.
>
> I've also seen some evidence that a portion of the current high rate
> congestion is contrived traffic. To the extent that it's true there
> also should be some relief there soon as the funding for that runs
> out, in addition to expected traffic patterns, difficulty changes,
> etc.
>
>
> On Thu, Dec 21, 2017 at 9:30 PM, Melvin Carvalho via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
> > I asked adam back at hcpp how the block chain would be secured in the long
> > term, once the reward goes away. The base idea has always been that fees
> > would replace the block reward.
> >
> > At that time fees were approximately 10% of the block reward, but have now
> > reached 45%, with 50% potentially being crossed soon
> >
> > https://fork.lol/reward/feepct <https://fork.lol/reward/feepct>;
> >
> > While this bodes well for the long term security of the coin, I think there
> > is some legitimate concern that the fee per tx is prohibitive for some use
> > cases, at this point in the adoption curve.
> >
> > Observations of segwit adoption show around 10% at this point
> >
> > http://segwit.party/charts/ <http://segwit.party/charts/>;
> >
> > Watching the mempool shows that the congestion is at a peak, though it's
> > quite possible this will come down over the long weekend. I wonder if this
> > is of concern to some.
> >
> > https://dedi.jochen-hoenicke.de/queue/more/#24h <https://dedi.jochen-hoenicke.de/queue/more/#24h>;
> >
> > I thought these data points may be of interest and are mainly FYI. Though
> > if further discussion is deemed appropriate, it would be interesting to hear
> > thoughts.
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>;
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>;
>
> _______________________________________________
> 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/20171221/d675d05f/attachment-0001.html>;
📝 Original message:Every transaction is replace-by-fee capable already. Opt-in replace by fee as specified in BIP 125 is a fiction that held sway only while the income from fees or fee replacement was so much smaller than subsidy.
> On Dec 21, 2017, at 3:35 PM, Paul Iverson via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> I agree with Greg. What is happening is a cause for celebration: it is the manifestation of our long-desired fee market in action. That people are willing to pay upwards of $100 per transaction shows the huge demand to transact on the world's most secure ledger. This is what success looks like, folks!
>
> Now that BTC is being phased out as a means of payment nearly everywhere (e.g., Steam dropping BTC as a payment option) (to be replaced with the more-suitable LN when ready), I'd propose that we address the stuck transaction issue by making replace-by-fee (RBF) ubiquitous. Why not make every transaction RBF by default, and then encourage via outreach and education other wallet developers to do the same?
>
> The frustration with BTC today is less so the high-fees (people realize on-chain transactions in a secure decentralized ledger are necessarily costly) but by the feeling of helplessness when their transaction is stuck. Being able to easily bump a transaction's fee for users who are in a hurry would go a long way to improving the user experience.
>
> Paul.
>
>
> On Thu, Dec 21, 2017 at 2:44 PM, Gregory Maxwell via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
> Personally, I'm pulling out the champaign that market behaviour is
> indeed producing activity levels that can pay for security without
> inflation, and also producing fee paying backlogs needed to stabilize
> consensus progress as the subsidy declines.
>
> I'd also personally prefer to pay lower fees-- current levels even
> challenge my old comparison with wire transfer costs-- but we should
> look most strongly at difficult to forge market signals rather than
> just claims-- segwit usage gives us a pretty good indicator since most
> users would get a 50-70% fee reduction without even considering the
> second order effects from increased capacity.
>
> As Jameson Lopp notes, more can be done for education though-- perhaps
> that market signal isn't efficient yet. But we should get it there.
>
> But even independently of segwit we can also look at other inefficient
> transaction styles: uncompressed keys, unconfirmed chaining instead of
> send many batching, fee overpayment, etc... and the message there is
> similar.
>
> I've also seen some evidence that a portion of the current high rate
> congestion is contrived traffic. To the extent that it's true there
> also should be some relief there soon as the funding for that runs
> out, in addition to expected traffic patterns, difficulty changes,
> etc.
>
>
> On Thu, Dec 21, 2017 at 9:30 PM, Melvin Carvalho via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
> > I asked adam back at hcpp how the block chain would be secured in the long
> > term, once the reward goes away. The base idea has always been that fees
> > would replace the block reward.
> >
> > At that time fees were approximately 10% of the block reward, but have now
> > reached 45%, with 50% potentially being crossed soon
> >
> > https://fork.lol/reward/feepct <https://fork.lol/reward/feepct>;
> >
> > While this bodes well for the long term security of the coin, I think there
> > is some legitimate concern that the fee per tx is prohibitive for some use
> > cases, at this point in the adoption curve.
> >
> > Observations of segwit adoption show around 10% at this point
> >
> > http://segwit.party/charts/ <http://segwit.party/charts/>;
> >
> > Watching the mempool shows that the congestion is at a peak, though it's
> > quite possible this will come down over the long weekend. I wonder if this
> > is of concern to some.
> >
> > https://dedi.jochen-hoenicke.de/queue/more/#24h <https://dedi.jochen-hoenicke.de/queue/more/#24h>;
> >
> > I thought these data points may be of interest and are mainly FYI. Though
> > if further discussion is deemed appropriate, it would be interesting to hear
> > thoughts.
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>;
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>;
>
> _______________________________________________
> 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/20171221/d675d05f/attachment-0001.html>;