Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 97FAFC002A for ; Wed, 10 May 2023 03:08:31 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 8090A8143B for ; Wed, 10 May 2023 03:08:31 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 8090A8143B Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20221208 header.b=dq9pxwL5 X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1oiKqppK49yn for ; Wed, 10 May 2023 03:08:28 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 81CC480F66 Received: from mail-vk1-xa29.google.com (mail-vk1-xa29.google.com [IPv6:2607:f8b0:4864:20::a29]) by smtp1.osuosl.org (Postfix) with ESMTPS id 81CC480F66 for ; Wed, 10 May 2023 03:08:28 +0000 (UTC) Received: by mail-vk1-xa29.google.com with SMTP id 71dfb90a1353d-4501ca552a3so3201218e0c.2 for ; Tue, 09 May 2023 20:08:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683688107; x=1686280107; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Vd011O4dapKJMUp5EXMlC0jTJPCzujrNTpdygt3VcFU=; b=dq9pxwL5qXe5/Bdzco1iecEgLMjuR6mATO4RJNNJO/AxEJeAN9EbKbJRkxq1aFqB3f ebi4WNA80ThESyem18O3q8IiTBwiJ8KfN5ubSnI2101Xhe0HLd4suyCNJwnTpdy/H52r EOTMbHyorxblMV6uMXJH1rp98CznW1Yj0nWn8ysmD/sl2r/8n7oYrQlPgLrHWXTzcSij TPmB1/JWn/Ke6nh3r/embRwVEIHQLhvPdIVc6tLwgpX6JUoUeunJBvwx/t/6hfCZ8pr3 fw1VYnHOjpwIjx6SulE3cYcL7RJw1//mozWo2zB8OS48Mhw2VAwU1PlhndisbFGDxvA3 gBXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683688107; x=1686280107; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Vd011O4dapKJMUp5EXMlC0jTJPCzujrNTpdygt3VcFU=; b=Paufp/zlnv7Zmo3M9fHeRjofBKQmvDOGKAkfzQYLau9GylOJdjSnjk8iUQKAAkS2ww K2ujHWQE1T3rRtau6EZLfB9MqoXjaagsWyvWpXCo4Cjjdena0LFbIfRem5gr5zr8UCnu d6xfVav5KCT9NXrySTqGhFYRg3ogqTSSS9zAbMKI/2i+76C7Q3jWd7Omii/boqSejZRf KFSeehzGcxYFCXap/Wice4++NK35sWk/mlnq3wogGwnv3UBUi+caZaOSJO2ePi6E4JW/ nio+c99xnX+g8kwBk80M3Fqk6j25gWxAe1TrYjijpNMExUJ35+G6IZ3Z8jpUNSLLn0zt wUMg== X-Gm-Message-State: AC+VfDzOvhQBtohxd4Pc7pCAMV1Z32DTsnggnyYnB8OHOTYv4kkdDrt7 J2WzANdmpX3BcuvgdVmI5VSBPoowKwwLPSTEFv4= X-Google-Smtp-Source: ACHHUZ5ca/oLS2ecbvAX4Gs9jBFRaoPJwNL2QWcUilHtCruzPdgZcWqsGDbAJ1A+ffvp7SOrmTfyobcfC6z6pmzg2kE= X-Received: by 2002:a1f:60c9:0:b0:452:a751:eacf with SMTP id u192-20020a1f60c9000000b00452a751eacfmr3433076vkb.8.1683688107169; Tue, 09 May 2023 20:08:27 -0700 (PDT) MIME-Version: 1.0 References: <183080646-e0c2bb9eaf62640f6c5d6c34f66db1d9@pmq7v.m5r2.onet> In-Reply-To: From: Weiji Guo Date: Wed, 10 May 2023 11:08:15 +0800 Message-ID: To: Erik Aronesty , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000008a5ce505fb4e2f92" X-Mailman-Approved-At: Wed, 10 May 2023 16:51:33 +0000 Subject: Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes? X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2023 03:08:31 -0000 --0000000000008a5ce505fb4e2f92 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > 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=E2=80=AFPM 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 relate= d > 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 netwo= rk >> 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" du= e >> 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 use= rs >> as free-riders - isn't fun, too >> >> 4. by ignoring Bitcoin long-term security budget problem - "we indirectl= y >> allowed this to happen, which previously wasn't possible before. So we a= lso >> 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 - tha= t >> 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=C5=BCytkownik Luke Dashjr via bitcoin-dev < >> bitcoin-dev@lists.linuxfoundation.org> napisa=C5=82: >> >> 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 exist= ing >> filters weren't extended to Taproot transactions. We can address that, o= r >> try a more narrow approach like OP_RETURN (ie, what "Ordisrespector" doe= s). >> 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 ou= t >> 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 intend= ed >> 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, a= nd >> 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 - sho= uld >> similar action be taken now, in the form of i) BIPs and/or ii) commits i= nto >> the Bitcoin Core codebase, to curtail the loophole in BIP 342 (which >> defines the validation rules for Taproot scripts) which has allowed thes= e >> 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 Tapr= oot >> 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 w= e >> need to find a solution for this that fits everyone's common ground. We >> indirectly allowed this to happen, which previously wasn't possible befo= re. >> So we also have a responsibility to do something to ensure that this kin= d >> 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 > --0000000000008a5ce505fb4e2f92 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> I would like to point out that I'm not an advocat= e for doing anything at this point aside from working on l2

<= div>Speaking of L2, I had recently proposed a new opcode OP_ZKP to enable p= ayments based on ZKP proof. I wonder if it has drawn enough attention but i= t seems to me a viable way to address transaction=C2=A0fee issues, in addit= ion to enabling more smart contracts. And it will be a Bitcoin native L2, n= ot a side chain, not pegging.=C2=A0

=C2=A0 =C2=A0 =C2=A0 scriptPu= bKey: <hash of the verification key> <scheme_id> OP_ZKP=C2=A0
=C2=A0 =C2=A0 =C2=A0 scriptSig:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<p= ubInput_1> <pubInput_2> ... <pubInput_n> <n> <proof= >=C2=A0

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.
<= span style=3D"font-family:font0000000029fd134e;font-size:10pt">
<= /div>
T= hanks,
Weiji

On Tue, May 9, 2023 at 8:51=E2=80=AFPM Erik = Aronesty via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
I would l= ike to point out that I'm not an advocate for doing anything at this po= int aside from working on l2

j= ust to make it inconvenient for people

I just think the discussion of outputs and fees is interesti= ng and related to the game theory portion of Bitcoin



On Tue, May 9, 2023, 8:23 AM Jarosla= w via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:<= br>


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 compensat= e 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&q= uot; due to lack of block subsidy and due to exorbitant $40 tx fees as an e= ffect 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 pa= ssive users as free-riders - isn't fun, too

4. by ignoring Bitcoin long-term security budget problem - "we indirec= tly 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 so= lution - weren't implemented on time

6. "we need to find a solution for long-term horrible fees problem - t= hat 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 situ= ation.


Regards,
Jaroslaw





W dniu 2023-05-09 00:37:57 u=C5=BCytkownik Luke Dashjr via bitcoin-dev <= bitcoin-dev@lists.linuxfoundation.org> napisa=C5= =82:

Action should have been taken months ago. Spam filtration has been a standa= rd part of Bitcoin Core since day 1. It's a mistake that the existing f= ilters weren't extended to Taproot transactions. We can address that, o= r try a more narrow approach like OP_RETURN (ie, what "Ordisrespector&= quot; does). Since this is a bugfix, it doesn't really even need to wai= t 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 mempoo= l 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 sinc= e 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 - tha= t's how its creator described them[1]) tokens threaten the smooth and n= ormal 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 use= rs. Considering that miners are largely the entities at fault for allowing = the system to be abused like this, the harmony of Bitcoin transactions is b= eing disrupted right now. Although this community has a strong history of n= ot putting its fingers into pies unless absolutely necessary - an example b= eing 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 codeb= ase, 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 T= aproot transactions. This will be easier to implement, but won't hit th= e 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 a= llowed this to happen, which previously wasn't possible before. So we a= lso have a responsibility to do something to ensure that this kind of conge= stion can never happen again using Taproot.


-Ali


---


[1]:=C2=A0https://www.coindesk.com/consensus-mag= azine/2023/05/05/pump-the-brcs-the-promise-and-peril-of-bitcoin-backed-toke= ns/






_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--0000000000008a5ce505fb4e2f92--