From: Gavin Andresen <gavinandresen@gmail•com>
To: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Time to worry about 80-bit collision attacks or not?
Date: Fri, 8 Jan 2016 10:59:21 -0500 [thread overview]
Message-ID: <CABsx9T34htMaC-uoE0Tk3tb1KEct7hk=s=eyY-94+CLCcN2_EQ@mail.gmail.com> (raw)
In-Reply-To: <CABsx9T0WRXz54LZnyU7Fr=_ZgwF5armj0Z8uwYcFy2x+BWooxg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1111 bytes --]
On Fri, Jan 8, 2016 at 10:50 AM, Gavin Andresen <gavinandresen@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
[-- Attachment #2: Type: text/html, Size: 1828 bytes --]
next prev parent reply other threads:[~2016-01-08 15:59 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-07 19:02 Gavin Andresen
2016-01-07 19:13 ` Matt Corallo
2016-01-07 19:19 ` Adam Back
2016-01-07 20:56 ` Dave Scotese
2016-01-07 21:06 ` Gavin Andresen
2016-01-07 22:56 ` Ethan Heilman
2016-01-07 23:39 ` Gavin Andresen
2016-01-08 1:26 ` Matt Corallo
2016-01-08 1:54 ` Gavin Andresen
2016-01-08 17:38 ` Pieter Wuille
2016-01-08 18:41 ` Peter Todd
2016-01-07 20:40 ` Ethan Heilman
2016-01-07 23:52 ` Pieter Wuille
2016-01-08 1:00 ` Gavin Andresen
2016-01-08 1:27 ` Watson Ladd
2016-01-08 3:30 ` Rusty Russell
2016-01-08 3:41 ` Matt Corallo
2016-01-08 12:02 ` Rusty Russell
2016-01-08 12:38 ` Gavin Andresen
2016-01-08 14:34 ` Watson Ladd
2016-01-08 15:26 ` Adam Back
2016-01-08 15:33 ` Anthony Towns
2016-01-08 15:46 ` Gavin Andresen
2016-01-08 15:50 ` Gavin Andresen
2016-01-08 15:59 ` Gavin Andresen [this message]
2016-01-11 20:32 ` Jorge Timón
2016-01-08 16:06 ` Gavin Andresen
2016-01-11 3:57 ` Rusty Russell
2016-01-11 6:57 ` Peter Todd
2016-01-11 23:57 ` Tier Nolan
2016-01-12 0:00 ` Tier Nolan
2016-01-12 12:08 ` Gavin Andresen
2016-01-12 23:22 ` Zooko Wilcox-O'Hearn
2016-01-08 18:52 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CABsx9T34htMaC-uoE0Tk3tb1KEct7hk=s=eyY-94+CLCcN2_EQ@mail.gmail.com' \
--to=gavinandresen@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox