Prayank [ARCHIVE] on Nostr: đź“… Original date posted:2022-02-21 đź“ť Original message:> note how ETH has quite ...
đź“… Original date posted:2022-02-21
đź“ť Original message:> note how ETH has quite high on chain fees for basic transactions,> because there are so many use-cases where the per-tx value can afford much> higher fees. That kind of expansion of use-case also arguably harms Bitcoin as> a whole by providing more fuel for a future contentious blocksize debate.
>i second this argument
I disagree with this argument, Satoshi won't agree with it either if still active and it make no sense. Fees will be the incentives for miners as subsidy decreases after every 210,000 blocks and it will depend on demand for block space.
There is nothing harmful in it just because something similar is happening in an altcoin which has several other issues. Example: if a user has to pay fees with 100 sat/vbyte fee rate to open and close channels it will be good for Bitcoin in long term.
If this is the reason to stop/delay improvements in bitcoin, maybe it applies for Taproot as well although I don't remember reading such things in your posts or maybe missed it.
--
Prayank
A3B1 E430 2298 178F
Feb 21, 2022, 00:05 by erik at q32.com:
> > note how ETH has quite high on chain fees for basic transactions,
> > because there are so many use-cases where the per-tx value can afford much
> > higher fees. That kind of expansion of use-case also arguably harms Bitcoin as
> > a whole by providing more fuel for a future contentious blocksize debate.
>
> i second this argument
>
> ideally, all extensions should be explicit use cases, not generic/implicit layers that can be exploited for unknown and possibly harmful use cases
>
> also timing is critical for all bitcoin innovation.  look at how lightning ate up fees
>
> to keep bitcoin stable, we can't "scale" too quickly either
>
> i'm a fan of, eventually (timing is critical), a lightning-compatible mimblewible+dandelion on-chain soft fork can reduce tx size, move us from l2 to l3, vastly improve privacy, and get more small transactions off-chain.
>
> but it probably shouldn't be released for another 2 years
>
>
> On Fri, Feb 18, 2022 at 6:41 PM Peter Todd via bitcoin-dev <> bitcoin-dev at lists.linuxfoundation.org> > wrote:
>
>> On Tue, Jan 18, 2022 at 02:57:30AM +0100, Prayank wrote:
>> > Hi Peter,
>> >
>> > > that current lacks compelling use-cases clearly beneficial to all users
>> >
>> > All the use cases shared in below links look compelling enough to me and we can do anything that a programmer could think of using such restrictions:
>> >
>> >Â >> https://utxos.org/uses/
>> >
>> > >> https://rubin.io/archive/
>>
>> Again, what I said was "compelling use-cases _clearly_ beneficial to _all_
>> users", not just a small subset. I neither think the use-cases in those links
>> are clearly compelling in the current form, and they of course, don't benefit
>> all users. Indeed, the Drivechains use-case arguably *harms* all users, as
>> Drivechains is arguably harmful to the security of Bitcoin as a whole.
>> Similarly, the various new uses for on-chain transactions mentioned as a
>> use-case arguably harms all existing users by competing for scarce blockchain
>> space - note how ETH has quite high on chain fees for basic transactions,
>> because there are so many use-cases where the per-tx value can afford much
>> higher fees. That kind of expansion of use-case also arguably harms Bitcoin as
>> a whole by providing more fuel for a future contentious blocksize debate.
>>
>> Bitcoin is an almost $1 trillion dollar system. We have to very carefully weigh
>> the benefits of making core consensus changes to that system against the risks.
>> Both for each proposal in isolation, as well as the precedent making that
>> change sets.
>>
>> --
>> >> https://petertodd.org>>; 'peter'[:-1]@>> petertodd.org <http://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/20220221/45889d89/attachment.html>;
đź“ť Original message:> note how ETH has quite high on chain fees for basic transactions,> because there are so many use-cases where the per-tx value can afford much> higher fees. That kind of expansion of use-case also arguably harms Bitcoin as> a whole by providing more fuel for a future contentious blocksize debate.
>i second this argument
I disagree with this argument, Satoshi won't agree with it either if still active and it make no sense. Fees will be the incentives for miners as subsidy decreases after every 210,000 blocks and it will depend on demand for block space.
There is nothing harmful in it just because something similar is happening in an altcoin which has several other issues. Example: if a user has to pay fees with 100 sat/vbyte fee rate to open and close channels it will be good for Bitcoin in long term.
If this is the reason to stop/delay improvements in bitcoin, maybe it applies for Taproot as well although I don't remember reading such things in your posts or maybe missed it.
--
Prayank
A3B1 E430 2298 178F
Feb 21, 2022, 00:05 by erik at q32.com:
> > note how ETH has quite high on chain fees for basic transactions,
> > because there are so many use-cases where the per-tx value can afford much
> > higher fees. That kind of expansion of use-case also arguably harms Bitcoin as
> > a whole by providing more fuel for a future contentious blocksize debate.
>
> i second this argument
>
> ideally, all extensions should be explicit use cases, not generic/implicit layers that can be exploited for unknown and possibly harmful use cases
>
> also timing is critical for all bitcoin innovation.  look at how lightning ate up fees
>
> to keep bitcoin stable, we can't "scale" too quickly either
>
> i'm a fan of, eventually (timing is critical), a lightning-compatible mimblewible+dandelion on-chain soft fork can reduce tx size, move us from l2 to l3, vastly improve privacy, and get more small transactions off-chain.
>
> but it probably shouldn't be released for another 2 years
>
>
> On Fri, Feb 18, 2022 at 6:41 PM Peter Todd via bitcoin-dev <> bitcoin-dev at lists.linuxfoundation.org> > wrote:
>
>> On Tue, Jan 18, 2022 at 02:57:30AM +0100, Prayank wrote:
>> > Hi Peter,
>> >
>> > > that current lacks compelling use-cases clearly beneficial to all users
>> >
>> > All the use cases shared in below links look compelling enough to me and we can do anything that a programmer could think of using such restrictions:
>> >
>> >Â >> https://utxos.org/uses/
>> >
>> > >> https://rubin.io/archive/
>>
>> Again, what I said was "compelling use-cases _clearly_ beneficial to _all_
>> users", not just a small subset. I neither think the use-cases in those links
>> are clearly compelling in the current form, and they of course, don't benefit
>> all users. Indeed, the Drivechains use-case arguably *harms* all users, as
>> Drivechains is arguably harmful to the security of Bitcoin as a whole.
>> Similarly, the various new uses for on-chain transactions mentioned as a
>> use-case arguably harms all existing users by competing for scarce blockchain
>> space - note how ETH has quite high on chain fees for basic transactions,
>> because there are so many use-cases where the per-tx value can afford much
>> higher fees. That kind of expansion of use-case also arguably harms Bitcoin as
>> a whole by providing more fuel for a future contentious blocksize debate.
>>
>> Bitcoin is an almost $1 trillion dollar system. We have to very carefully weigh
>> the benefits of making core consensus changes to that system against the risks.
>> Both for each proposal in isolation, as well as the precedent making that
>> change sets.
>>
>> --
>> >> https://petertodd.org>>; 'peter'[:-1]@>> petertodd.org <http://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/20220221/45889d89/attachment.html>;