📅 Original date posted:2016-01-08
📝 Original message:On Fri, Jan 8, 2016 at 10:50 AM, Gavin Andresen <gavinandresen at gmail.com>
wrote:
> But as I said earlier in the thread, there is a tradeoff here between
> crypto strength and code complexity, and "the strength of the crypto is all
> that matters" is NOT security first.
I should be more explicit about code complexity:
The big picture is "segwitness will help scale in the very short term."
So the spec gives two ways of stuffing the segwitness hash into the
scriptPubKey -- one way that uses a 32-bit hash, but if used would actually
make scalability a bit worse as coins moved into segwitness-locked
transactions (DUP HASH160 EQUALVERIFY pay-to-script-hash scriptpubkeys are
just 24 bytes).
And another way that add just one byte to the scriptpubkey.
THAT is the code complexity I'm talking about. Better to always move the
script into the witness data, in my opinion, on the keep the design as
simple as possible principle.
It could be a 32-byte hash... but then the short-term scalability goal is
compromised.
Maybe I'm being dense, but I still think it is a no-brainer....
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160108/49bd0b02/attachment.html>;
Gavin Andresen [ARCHIVE] /
npub1s4…d44kw
2023-06-07 17:47:46
in reply to nevent1q…hvfn
Author Public Key
npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kwPublished at
2023-06-07 17:47:46Event JSON
{
"id": "4ba3c87b784bf402ca6006f10e4c8f3b0cfe4112ed2846bf3b637ffdf5fa504c",
"pubkey": "857f2f78dc1639e711f5ea703a9fc978e22ebd279abdea1861b7daa833512ee4",
"created_at": 1686160066,
"kind": 1,
"tags": [
[
"e",
"e1f46f49861d474f81d81bf43d690af02c9b35e1c9c4fe5cc415112a34c1c041",
"",
"root"
],
[
"e",
"c0af060afa735f9d728092de53e426e143055cd537a6a9b92076b9506cf9d116",
"",
"reply"
],
[
"p",
"857f2f78dc1639e711f5ea703a9fc978e22ebd279abdea1861b7daa833512ee4"
]
],
"content": "📅 Original date posted:2016-01-08\n📝 Original message:On Fri, Jan 8, 2016 at 10:50 AM, Gavin Andresen \u003cgavinandresen at gmail.com\u003e\nwrote:\n\n\u003e But as I said earlier in the thread, there is a tradeoff here between\n\u003e crypto strength and code complexity, and \"the strength of the crypto is all\n\u003e that matters\" is NOT security first.\n\n\nI should be more explicit about code complexity:\n\nThe big picture is \"segwitness will help scale in the very short term.\"\n\nSo the spec gives two ways of stuffing the segwitness hash into the\nscriptPubKey -- one way that uses a 32-bit hash, but if used would actually\nmake scalability a bit worse as coins moved into segwitness-locked\ntransactions (DUP HASH160 EQUALVERIFY pay-to-script-hash scriptpubkeys are\njust 24 bytes).\n\nAnd another way that add just one byte to the scriptpubkey.\n\nTHAT is the code complexity I'm talking about. Better to always move the\nscript into the witness data, in my opinion, on the keep the design as\nsimple as possible principle.\n\nIt could be a 32-byte hash... but then the short-term scalability goal is\ncompromised.\n\nMaybe I'm being dense, but I still think it is a no-brainer....\n\n-- \n--\nGavin Andresen\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160108/49bd0b02/attachment.html\u003e",
"sig": "bd5a05ec3a2a72b899a823097fc6b97a8562455d22de814c5a79549bbfce972ac5135349881c6cfe3730e91fd91a7dac52a40a832dc235f5e962c8645f88a60a"
}