> I would like to point out that I'm not an advocate for doing anything at this point aside from working on l2 Speaking of L2, I had recently proposed a new opcode OP_ZKP to enable payments based on ZKP proof. I wonder if it has drawn enough attention but it seems to me a viable way to address transaction fee issues, in addition to enabling more smart contracts. And it will be a Bitcoin native L2, not a side chain, not pegging. scriptPubKey: OP_ZKP scriptSig: ... I haven't figured out how to use OP_ZKP to incentivize BRC-20, inscription etc. to move to L2. But I like to bring it up here and I am open to your feedback and comments. Thanks, Weiji On Tue, May 9, 2023 at 8:51 PM Erik Aronesty via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I would like to point out that I'm not an advocate for doing anything at > this point aside from working on l2 > > just to make it inconvenient for people > > I just think the discussion of outputs and fees is interesting and related > to the game theory portion of Bitcoin > > > > On Tue, May 9, 2023, 8:23 AM Jaroslaw via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> >> >> Ok, I need to highlight one important thing well proven by this >> discussion (like it or not)... >> >> Not the spam itself is the real reason of feeling: "something must be >> done" >> The reason is: $30 fee per transaction (I hope you all agree) >> >> >> Let me paraphrase some quotes used in this discussion, then: >> >> 1. Lack of block subsidy long term and necessity of $40 tx fee to >> compensate it - "threaten the smooth and normal use of the Bitcoin network >> as a peer-to-pear digital currency, as it was intended to be used as." >> >> 2. "the harmony of Bitcoin transactions is being disrupted right now" due >> to lack of block subsidy and due to exorbitant $40 tx fees as an effect >> necessary to keep the network security untouched >> >> 3. "Fee spikes aren't fun" and it's obvious that keeping the network >> security only on enormous tx fees of active users and having passive users >> as free-riders - isn't fun, too >> >> 4. by ignoring Bitcoin long-term security budget problem - "we indirectly >> allowed this to happen, which previously wasn't possible before. So we also >> have a responsibility to do something to ensure that this kind of >> tremendous $40 tx fees can never happen again" >> >> 5. "Action against exorbitant fees should have been taken months ago. >> (...) It's a mistake that the" tail emission or other necessary solution - >> weren't implemented on time >> >> 6. "we need to find a solution for long-term horrible fees problem - that >> fits everyone's common ground." >> >> >> Yes, we need - instead of being still in a heavy denial state. >> >> No additional comment then, except this little one: >> Delay of halving in case of 4 years long network difficulty regression >> situation. >> >> >> Regards, >> Jaroslaw >> >> >> >> >> >> W dniu 2023-05-09 00:37:57 użytkownik Luke Dashjr via bitcoin-dev < >> bitcoin-dev@lists.linuxfoundation.org> napisał: >> >> Action should have been taken months ago. Spam filtration has been a >> standard part of Bitcoin Core since day 1. It's a mistake that the existing >> filters weren't extended to Taproot transactions. We can address that, or >> try a more narrow approach like OP_RETURN (ie, what "Ordisrespector" does). >> Since this is a bugfix, it doesn't really even need to wait for a major >> release. >> >> (We already have pruning. It's not an alternative to spam filtering.) >> >> Luke >> >> >> >> >> On 5/7/23 13:22, Ali Sherief via bitcoin-dev wrote: >> Hi guys, >> >> >> I think everyone on this list knows what has happened to the Bitcoin >> mempool during the past 96 hours. Due to side projects such as BRC-20 >> having such a high volume, real bitcoin transactions are being priced out >> and that is what is causing the massive congestion that has arguable not >> been seen since December 2017. I do not count the March 2021 congestion >> because that was only with 1-5sat/vbyte. >> >> >> Such justifiably worthless ("worthless" is not even my word - that's how >> its creator described them[1]) tokens threaten the smooth and normal use of >> the Bitcoin network as a peer-to-pear digital currency, as it was intended >> to be used as. >> >> >> If the volume does not die down over the next few weeks, should we take >> an action? The bitcoin network is a triumvirate of developers, miners, and >> users. Considering that miners are largely the entities at fault for >> allowing the system to be abused like this, the harmony of Bitcoin >> transactions is being disrupted right now. Although this community has a >> strong history of not putting its fingers into pies unless absolutely >> necessary - an example being during the block size wars and Segwit - should >> similar action be taken now, in the form of i) BIPs and/or ii) commits into >> the Bitcoin Core codebase, to curtail the loophole in BIP 342 (which >> defines the validation rules for Taproot scripts) which has allowed these >> unintended consequences? >> >> >> An alternative would be to enforce this "censorship" at the node level >> and introduce a run-time option to instantly prune all non-standard Taproot >> transactions. This will be easier to implement, but won't hit the road >> until minimum next release. >> >> >> I know that some people will have their criticisms about this, >> absolutists/libertarians/maximum-freedom advocates, which is fine, but we >> need to find a solution for this that fits everyone's common ground. We >> indirectly allowed this to happen, which previously wasn't possible before. >> So we also have a responsibility to do something to ensure that this kind >> of congestion can never happen again using Taproot. >> >> >> -Ali >> >> >> --- >> >> >> [1]: >> https://www.coindesk.com/consensus-magazine/2023/05/05/pump-the-brcs-the-promise-and-peril-of-bitcoin-backed-tokens/ >> >> >> >> >> >> >> _______________________________________________ >> 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 >