Gavin Andresen [ARCHIVE] on Nostr: 📅 Original date posted:2016-01-08 📝 Original message:On Fri, Jan 8, 2016 at ...

📅 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>;