From: Weiji Guo <weiji.g@gmail.com>
To: Erik Aronesty <erik@q32.com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?
Date: Wed, 10 May 2023 11:08:15 +0800 [thread overview]
Message-ID: <CA+ydi=KJwPrqn1WcB-AUPsCkbUm69TsbLsVmu_H9cntNrtSD3Q@mail.gmail.com> (raw)
In-Reply-To: <CAJowKgJVAfDiwUEy+6f1Ln45=mua=R7c=KxV5XZOJHvgEHsQhg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 6835 bytes --]
> 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: <hash of the verification key> <scheme_id> OP_ZKP
scriptSig: <pubInput_1> <pubInput_2> ... <pubInput_n> <n>
<proof>
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
>
[-- Attachment #2: Type: text/html, Size: 9271 bytes --]
next prev parent reply other threads:[~2023-05-10 3:08 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-09 8:41 [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes? jk_14
2023-05-09 12:50 ` Erik Aronesty
2023-05-10 3:08 ` Weiji Guo [this message]
-- strict thread matches above, loose matches on Subject: below --
2023-05-12 9:36 jk_14
2023-05-11 13:12 Aleksandr Kwaskoff
2023-05-07 17:22 Ali Sherief
2023-05-08 12:33 ` Michael Folkson
2023-05-08 12:58 ` Erik Aronesty
2023-05-08 17:13 ` Michael Folkson
2023-05-08 19:31 ` Ali Sherief
2023-05-08 19:47 ` Erik Aronesty
2023-05-08 20:36 ` Michael Folkson
2023-05-08 20:59 ` Erik Aronesty
2023-05-08 21:01 ` Erik Aronesty
2023-05-09 15:21 ` Tom Harding
2023-05-08 16:37 ` Melvin Carvalho
2023-11-03 10:15 ` Brad Morrison
2023-11-03 10:39 ` Melvin Carvalho
2023-11-04 9:58 ` ArmchairCryptologist
2023-05-08 22:37 ` Luke Dashjr
2023-05-09 0:02 ` Peter Todd
2023-05-09 1:43 ` Ali Sherief
2023-05-09 16:32 ` Erik Aronesty
2023-05-09 21:06 ` Tom Harding
2023-05-10 20:44 ` Keagan McClelland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CA+ydi=KJwPrqn1WcB-AUPsCkbUm69TsbLsVmu_H9cntNrtSD3Q@mail.gmail.com' \
--to=weiji.g@gmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=erik@q32.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox