From: Eric Voskuil <eric@voskuil•org>
To: Alex Morcos <morcos@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP30 and BIP34 interaction (was Re: [BIP Proposal] Buried Deployments)
Date: Thu, 17 Nov 2016 04:22:09 -0800 [thread overview]
Message-ID: <34949746-c0c9-7f14-0e92-69d5a7d44b04@voskuil.org> (raw)
In-Reply-To: <CAPWm=eW9X77+qQZGHkAOjN-k7KFwq06gKS6HOVOTE1+SmYBhWA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1401 bytes --]
On 11/17/2016 03:38 AM, Alex Morcos wrote:
> I think this conversation has gone off the rails and is no longer really
> appropriate for the list.
If this discussion is not appropriate for the Bitcoin Protocol
Discussion list then the list is pointless.
> But just to be clear to any readers. Bitcoin Core absolutely does rely
> on the impossibility of a hash collision for maintaining consensus.
> This happens in multiple places in the code but in particular we don't
> check BIP30 any more since the only way it could get violated is by a
> hash collision.
So the protocol change that I suggested to Peter an hour or so ago was
actually implemented, a year ago, by you:
https://github.com/bitcoin/bitcoin/commit/06d81ad516f1d136da9f03ca2ae823211c0f6988
Given that hash collisions are unquestionably possible, this is a clear
break with BIP30 (irrespective of BIP34) and constitutes a hard fork. Is
there going to be a retroactive BIP for this one at some point as well?
I'm aware that the block hash check is performed against the full chain,
as opposed to the candidate block fork height, and as a result is
insufficient to guard against a block hash collision causing a chain
split (though until now I assumed this was a bug).
Would you care to share the other consensus critical reliances on the
impossibility of hash collision that you are implying?
e
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
next prev parent reply other threads:[~2016-11-17 12:22 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-17 0:06 Jorge Timón
2016-11-17 0:10 ` Eric Voskuil
2016-11-17 0:31 ` Tier Nolan
2016-11-17 0:43 ` Eric Voskuil
2016-11-17 0:53 ` Eric Voskuil
2016-11-17 8:44 ` Peter Todd
2016-11-17 9:58 ` Eric Voskuil
2016-11-17 10:22 ` Tier Nolan
2016-11-17 11:22 ` Eric Voskuil
2016-11-17 11:38 ` Alex Morcos
2016-11-17 12:22 ` Eric Voskuil [this message]
2016-11-17 15:40 ` Johnson Lau
2016-11-17 17:01 ` Eric Voskuil
2016-11-17 17:22 ` Johnson Lau
2016-11-17 17:49 ` Eric Voskuil
2016-11-17 18:08 ` Johnson Lau
2016-11-18 3:20 ` Eric Voskuil
2016-11-18 14:43 ` Johnson Lau
2016-11-18 16:47 ` Eric Voskuil
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=34949746-c0c9-7f14-0e92-69d5a7d44b04@voskuil.org \
--to=eric@voskuil$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=morcos@gmail$(echo .)com \
/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