npub1wl6kysagynfz2ulmw4wa2trnc9ycd52upjv9zt297n0tpr5ls7dqk5caw8
hex
da9e787d46b3c40adf9770ec9e5fa567c1691959d9d345366c1cd2242034bb84nevent
nevent1qqsd48nc04rt83q2m7thpmy7t7jk0stfr9van569xekpe53yyq6thpqprpmhxue69uhhyetvv9ujuem4d36kwatvw5hx6mm9qgs80atzgw5zf539w0ah2hw493euzjvx69wqexz394zlfh4s360c0xszc4plaKind-1 (TextNote)
By @SteveSimple
A "Key Takeaway" of how Taproot was advertised to the community was:
"Tapscript removes the 10,000-byte script size limit and 201-opcode cap from legacy Script, enabling more complex contracts while using a per-script signature operations budget for DoS protection"
spark.money/glossary/bip-342
Removing these limits was based on Taproot's clever avoidance of the primary denial of service (DoS) attack vector in pre-Taproot scripts.
Specifically, Taproot disabled Segwit's inefficient multisig method, and redesigned its script resource accounting, so those DoS concerns were gone.
With the DoS no longer in play, the justifications for raising the limit were:
- it enables more complex contracts (widely stated), or
- there's no reason not to (why not?)
That rationale was over four years ago.
Taproot was activated in November 2021. To date there have been 424,471 Taproot scripts larger than 10KB that have been revealed through spending.
The analysis script (which you can verify from your node using the GitHub link) evaluates all scripts of this type to date. Every revealed Taproot script-path spend over 10KB is evaluated, none excluded.
The results are clear. Of the 424,471 scripts to date:
-
99.98% were data storage.
-
99.89% placed their payload in a branch that can never execute (OP_FALSE OP_IF provably dead code).
-
0.091% were bulk data-push scripts that did not use the dead-code method (no dead code but >50% of the bytes in the script were pushes of data larger than 80 bytes).
-
0.018% can be classified as complex executable contracts (not data storage). Almost all of these are BitVM-like scripts.
-
Exactly one (1) of the complex scripts that were not data storage was a multisig using hundreds of OP_CHECKSIGADD.
In hindsight, we now have overwhelming evidence of how the raised 10KB Taproot script limit was used in practice. It was used for data storage. There was essentially no on-chain verifiable demand for enabling complex spending scripts that were not data storage.
And it isn't free. Every byte sits in the witness of a spend. It's downloaded, validated, and stored forever by every archival node, at the discounted witness rate that makes dumping it cheaper than real transactions.
Removing the cap enabled essentially no complex contracts (0.018%). It externalized a permanent storage-and-bandwidth cost onto everyone running Bitcoin.
And for what. For data-storage scripts that are 99.89% unexecutable dead-code branches.
https://github.com/Unbesteveable/taproot-10kb
原始 JSON
{
"kind": 1,
"id": "da9e787d46b3c40adf9770ec9e5fa567c1691959d9d345366c1cd2242034bb84",
"pubkey": "77f56243a824d22573fb755dd52c73c14986d15c0c98512d45f4deb08e9f879a",
"created_at": 1782501978,
"tags": [
[
"imeta",
"url https://i.postimg.cc/7h59psMB/Steve-2.jpg",
"m image/jpeg",
"x cbb2d19aa7b255c148cdc247f61cf61a1d3fe9fb739a0f3175e978e887cd92df",
"size 74783",
"dim 579x658",
"blurhash TMB3QUR.0iEToe-lIvof%0^fR-9z"
]
],
"content": "https://i.postimg.cc/7h59psMB/Steve-2.jpg\n\nBy @SteveSimple\n\nA \"Key Takeaway\" of how Taproot was advertised to the community was:\n\n\"Tapscript removes the 10,000-byte script size limit and 201-opcode cap from legacy Script, enabling more complex contracts while using a per-script signature operations budget for DoS protection\"\n\nspark.money/glossary/bip-342\n\nRemoving these limits was based on Taproot's clever avoidance of the primary denial of service (DoS) attack vector in pre-Taproot scripts.\n\nSpecifically, Taproot disabled Segwit's inefficient multisig method, and redesigned its script resource accounting, so those DoS concerns were gone.\n\nWith the DoS no longer in play, the justifications for raising the limit were:\n\n1) it enables more complex contracts (widely stated), or\n2) there's no reason not to (why not?)\n\nThat rationale was over four years ago.\n\nTaproot was activated in November 2021. To date there have been 424,471 Taproot scripts larger than 10KB that have been revealed through spending.\n\nThe analysis script (which you can verify from your node using the GitHub link) evaluates all scripts of this type to date. Every revealed Taproot script-path spend over 10KB is evaluated, none excluded.\n\nThe results are clear. Of the 424,471 scripts to date:\n\n1) 99.98% were data storage.\n\n2) 99.89% placed their payload in a branch that can never execute (OP_FALSE OP_IF provably dead code).\n\n3) 0.091% were bulk data-push scripts that did not use the dead-code method (no dead code but \u003e50% of the bytes in the script were pushes of data larger than 80 bytes).\n\n4) 0.018% can be classified as complex executable contracts (not data storage). Almost all of these are BitVM-like scripts.\n\n5) Exactly one (1) of the complex scripts that were not data storage was a multisig using hundreds of OP_CHECKSIGADD.\n\nIn hindsight, we now have overwhelming evidence of how the raised 10KB Taproot script limit was used in practice. It was used for data storage. There was essentially no on-chain verifiable demand for enabling complex spending scripts that were not data storage.\n\nAnd it isn't free. Every byte sits in the witness of a spend. It's downloaded, validated, and stored forever by every archival node, at the discounted witness rate that makes dumping it cheaper than real transactions.\n\nRemoving the cap enabled essentially no complex contracts (0.018%). It externalized a permanent storage-and-bandwidth cost onto everyone running Bitcoin.\n\nAnd for what. For data-storage scripts that are 99.89% unexecutable dead-code branches.\n\nhttps://github.com/Unbesteveable/taproot-10kb",
"sig": "52d27829d618a85b9ffe6144b3390e8385508b9e4c2d86794a33d9d8ba54e42c70387c283816dde350dab9f7f586ccd3a33d17a84f893dacca2994f98cf2c0dc"
}