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