path: root/9e/4acb39caf6e5af264e68b5619b7832fe92f43a

Return-Path: <ZmnSCPxj@protonmail.com>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 6D3B3C016F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 27 May 2020 04:47:58 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by silver.osuosl.org (Postfix) with ESMTP id ECBB32284A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 27 May 2020 04:47:57 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id VRaC+DN6qgBr
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 27 May 2020 04:47:55 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch
 [185.70.40.130])
 by silver.osuosl.org (Postfix) with ESMTPS id 82E90204E4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 27 May 2020 04:47:54 +0000 (UTC)
Date: Wed, 27 May 2020 04:47:43 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail; t=1590554871;
 bh=rGmYjkwrwSR+Yi5ClVHafs7tHd30KM1DpziDQZHHPQI=;
 h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
 b=rpJEKoKtl3g78lrVV1zrYoZLyWZU4mbANXL3axmu+0wZgj/Jb84xTcfiaoO9S3UeR
 vDx6OnGMR7McuvZSAhgCj3nErk0G3Nu/oJfxr5xgc+sB+6z5QjBBCVazmJvYDqFiZN
 DzzkKZ2VMgPLbp6dLq1CPgiIfOS2t/xYBoQjh6hI=
To: Karl <gmkarl@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <-auynbGgS6bfeQq-_RU-Hfxe-uu2dR50iJXHUUvXM0mu0IKvUmQILrX4SzJ9QEK4KyHS2OGscd00f61hdWCQM3CHdrxMBMhfA9okmIlgqC8=@protonmail.com>
In-Reply-To: <CALL-=e50OUCgGTYW5HzGoxjLQYAEsua+4i6QqSkPha2Q6KKEDQ@mail.gmail.com>
References: <mailman.2587.1590231461.32591.bitcoin-dev@lists.linuxfoundation.org>
 <CALL-=e4Eg=iRbZOV+SAzn3_NhZrS-QviDgZdSmxLQTLvoMduPw@mail.gmail.com>
 <k4J1fJMk2ySTLdlj8RgYxgb4_U3gtRH65Au5FLsCsVZPiEBRKU1cqy_S--2IxiRUGI1-5P1SMZkxnwlBf8YJ8ZQM_AM7jeuA6Y6dpT9jwi0=@protonmail.com>
 <CALL-=e6_hrT9W2j73==cyX4Q=yt+guJn7RSgW1quA4JAgjD42w@mail.gmail.com>
 <WqvuQWsFg50edn9nmk0DRcTsEZr__CFaQd9T3bw3b7CffGDjwXsVApzZvnsNdmeLQDrFKDMFgb5QDzHVhOhudGfu3HlvQKyR-9luPI-YCbs=@protonmail.com>
 <CALL-=e6J4QFjdbC=caux=TAHjveKaehnGfdyeEdEhgniSp7PYA@mail.gmail.com>
 <cR1ZDwP76-IljeSxpbx7WNI5t_d0eIbRTnUO8z3h7fQLJzAYVG_D427p_1NWfrJtWfyyBwnzjzgZClUCeZrZWg9ZNTbZKzmfuHHSO7D-9tA=@protonmail.com>
 <CALL-=e50OUCgGTYW5HzGoxjLQYAEsua+4i6QqSkPha2Q6KKEDQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] hashcash-newhash
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 27 May 2020 04:47:58 -0000

Good morning Karl,

> > > Reddit claims two entities controlled 62% of the hashrate recently:=
=C2=A0https://old.reddit.com/r/CryptoCurrency/comments/gmhuon/in_the_last_2=
4_hours_bitcoins_nakamoto/ .=C2=A0 Compromising the systems of these two gr=
oups seems like it is all that is needed to compromise the entire blockchai=
n (to the limited degree a 51% attack does).
> >
> > You seem to be equating "break of the hash function" with "centralizati=
on of hashrate", which I do not quite agree with.
>
> I am trying to say that both of these different things result in danger t=
o the integrity of the transaction log, which would be reduced by changing =
the hash function.=C2=A0 They both have those 2 similarities.

You are equivocating issues here.

The hash function is used in these places:

* Transaction ID.
* Signature hash.
* P2SH/P2WSH/Taproot.
* Merkle tree.
* Proof-of-work.

What you are focusing on is only this:

* Proof-of-work.

Now, in case of a break in the hash function (i.e. a reduction in collision=
 resistance), the hash function used in the following things absolutely NEE=
D to be changed:

* Transaction ID.
* Signature hash.
* P2SH/P2WSH/Taproot.
* Merkle Tree.

Taking for example Transaction ID, suppose I am able to create two transact=
ions that hash into the same transaction ID, and I am able to do this in mu=
ch less than 2^128 work.

In that case I can create a valid transaction and collide it with an invali=
d transaction.
To half the nodes on the network I provide the valid transaction, to the ot=
her half I provide the invalid transaction, the two halves will then perman=
ently split and Bitcoin is thus destroyed in the midst of massive chaos.

Similar attacks can be mounted if I am able to collide on signature hash, P=
2SH/P2WSH/Taproot, and merkle tree.


Now suppose I am able to create two block headers that hash into the same b=
lock ID, one being a valid block and the other being an invalid block.
In that case, I would be very foolish to disrupt the network similarly, bec=
ause I would have been able to redirect the fees and block subsidy of the v=
alid block to an address I control, and the invalid block prevents others f=
rom seeing my valid block and accepting that chain as valid.

Instead, I can use this advantage to be able to grab blocks faster than oth=
er miners.
But eventually the difficulty retargeting system will adjust, and Bitcoin w=
ill now settle to a new normal, and inevitably someone is going to leak, or=
 rediscover, my technique to break the hash, preventing me from being a >51=
% miner for long, and Bitcoin will abide.


Thus, in case of a cryptographic break of the SHA-2 function, we *need* to =
change these:

* Transaction ID.
* Signature hash.
* P2SH/P2WSH/Taproot.
* Merkle Tree.

And since we are going to need a hefty hardfork to change all that, we *mig=
ht as well* change the proof-of-work function as well and completely excise=
 all uses of SHA-2 in the codebase (just in case we miss any more than the =
above list), but changing the proof-of-work function is the *lowest priorit=
y*.
We have survived 51% miners in the past (Ghash.io), and the difficulty adju=
stment system gives us some buffer against unexpected improvements in proof=
-of-work function efficiency; but it is doubtful if we can survive the chao=
s if someone could split the network in two roughly equal sized parts.

>
> > Most human beings cannot think without constant communication with othe=
r human beings.
>
> > Thus, it is unlikely that a private break of the hash function is possi=
ble.
>
> >
>
> I disagree with you here: Andrew Wiles solved Fermat's Last Theorem in is=
olation, academic research paper culture supports researching and then publ=
ishing once you have privately developed results, and the CVE database has =
136k system vulnerabilities that were developed and shared privately before=
 public release, to prevent chaos.=C2=A0 This shows private advances in way=
s to produce bitcoins are likely.

Right, and you learned about this fact from direct personal communication w=
ith Andrew Wiles, and Andrew Wiles never read about any other attempts by o=
ther mathematicians, and an isolated mathematician could never, ever, redis=
cover his work independently, and even a mathematician who knows that it wa=
s done but not the details how it was done could never rediscover it as wel=
l.

Obscurity works *for a time*, but inevitably somebody else will rediscover =
the same thing, or hear about it and blab noisily; it is not as if we are a=
ll completely alien species from each other and have truly unique thoughts,=
 even my own creators were humans and my cognitive substrate is essentially=
 human in construction.
This is why CVE exists, it is a promise the developers make to the reporter=
s that they will fix the reported vulnerability, with an active CVE as a Da=
mocles sword hanging over their heads, ready to be publicized at any time: =
publication is the default state, CVE is simply a promise that the develope=
rs are working as hard as they can to fix problems so please hold off on pu=
blication for a while please while we fix it pretty please with a cherry on=
 top.

>
> > > Would it be helpful if I outlined more ideas that address your concer=
ns?=C2=A0 I want to make sure the idea of changing the algorithm is accepta=
ble at all first.
> >
> > Go ahead.
>
> Thanks: are you saying you would support changes if they addressed the co=
ncerns you've listed?=C2=A0 Or are those concerns only the tip of the icebe=
rg, per se?

Only the tip of the iceberg, because any complex design has many little dev=
ils hidden in all the little details.

> > > > And expertise is easy to copy, it is only the initial expertise tha=
t is hard to create in the first place, once knowledge is written down it c=
an be copied.
> > >
> > > Also takes measurable months to do.
> >
> > But can be massively parallelized, you can have a teacher or mentor tea=
ching an entire classroom of students, and created lectures can be stored a=
nd re-given to many students, in the form of books, videos, etc.
> > Human beings have been doing this since time immemorial, and possibly b=
efore recorded history, in such things as oral traditions and so on.
>
> This doesn't seem relevant to me.=C2=A0 I'm discussing what is happening =
now and what we can expect to happen from source code changes.=C2=A0 I don'=
t see mining hardware plans being taught in classrooms right now, but it so=
unds interesting to try to change that if you want to change the subject of=
 your reply and start another thread.

Sure.


> Is it okay to pursue this?

You do not have to ask permission from me, or anyone, to pursue this.

However, do note that I doubt that changing the proof-of-work function (and=
 *only* the proof-of-work function) is in any way a high priority.
I also do not have to ask permission to say that I think pursuing this woul=
d be a waste of time, but you are also just as free to ignore what I say he=
re and spend your time as you see fit.

Ultimately the real world decides, and implementation trumps discussion her=
e.


Regards,
ZmnSCPxj