path: root/39/c211f9b2af251f34293efb383e07e808b6fb7b

Return-Path: <nullius@nym.zone>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 57304EDC
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 16 Jan 2018 00:11:00 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mx2.mailbox.org (mx2.mailbox.org [80.241.60.215])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 02FA3124
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 16 Jan 2018 00:10:58 +0000 (UTC)
Received: from smtp1.mailbox.org (smtp1.mailbox.org [80.241.60.240])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mx2.mailbox.org (Postfix) with ESMTPS id 52C61411E0;
	Tue, 16 Jan 2018 01:10:57 +0100 (CET)
X-Virus-Scanned: amavisd-new at heinlein-support.de
Received: from smtp1.mailbox.org ([80.241.60.240])
	by hefe.heinlein-support.de (hefe.heinlein-support.de [91.198.250.172])
	(amavisd-new, port 10030)
	with ESMTP id Eyzw3xkiAw3D; Tue, 16 Jan 2018 01:10:53 +0100 (CET)
Date: Tue, 16 Jan 2018 00:10:38 +0000
From: nullius <nullius@nym.zone>
To: Enrique =?iso-8859-1?Q?Ariz=F3n?= Benito <enrique.arizonbenito@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <5e93f4b0e82ddf4eba5f1f54923e153f@nym.zone>
References: <CAD-msxHyN+psv5p94_pUzNMFfZjMX4Jie2=PCt0CeO1cuuCz2A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="3kvnteadjxh7ktr3"
Content-Disposition: inline
In-Reply-To: <CAD-msxHyN+psv5p94_pUzNMFfZjMX4Jie2=PCt0CeO1cuuCz2A@mail.gmail.com>
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Tue, 16 Jan 2018 00:35:36 +0000
Subject: Re: [bitcoin-dev] Proposal to reduce mining power bill
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Tue, 16 Jan 2018 00:11:00 -0000


--3kvnteadjxh7ktr3
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2018-01-15 at 22:47:54 +0000, Enrique Ariz=C3=B3n Benito=20
<enrique.arizonbenito@gmail.com> wrote:
>Hi all,
>
>just new to the list and curious to know if next proposal (or similar)=20
>for reducing mining-power consumption has already been discussed.
>
>The objective is to reduce the power consumption required while keeping=20
>the network safe and the miners "motivated" and cooperative to continue=20
>mining:
>
>The global idea is to introduce the concept of "next-coinbase" for=20
>miners. This will work something like as follow:
>
>- Any miner submitting a block will submit the "next-coinbase" for any=20
>new block mined by itself. (This address can be the same one or=20
>different from the just mined block). The miner keeps the private key=20
>associated with the "next-coinbase" secret.
>
>- The consensus algorithm will add next checks:
> A hash from, for example, the just mined block and the previous one,=20
>will have to match up to N bits for the next "next-coinbase" from the=20
>next block to be valid.
>
> That means that for the next block only 1/2^N bitcoin addresses will=20
>be accepted from the previously submitted "next-coinbase" list.
>
>Since the last previous block hash can be considered random, miners=20
>know in advance whether they will be able to participate or not in the=20
>next block depending on the just submited "next-coinbase". And since=20
>the "punishment" is distributed uniformely random to all miners no one=20
>has any advantage over the other. But the global miner netwok will=20
>consume much less power.
>
>A detail rest: New miners are not allowed in such scheme so next=20
>addition is needed:
>
>- A miner with no previous "next-coinbase" will need to first mine an=20
>special block, "new-miner-block", that instead of normal transactions=20
>will register the new miner and submit a "next-coinbase". This special=20
>block will not be rewarded with new bitcoins. The only reward will be=20
>the permission to mine in following blocks. No reward is applied so=20
>only new miners wanting to "enter" the mining network are expected to=20
>create such block.

Observation:  This totally destroys Bitcoin=E2=80=99s transaction-ordering=
=20
security.  A =E2=80=9C51% attack=E2=80=9D could be executed by any miner wh=
o has >50% of=20
the hashpower *proportionate to miners who are allowed to mine a=20
particular block*, rather than >50% of *global* hashpower.  (I infer=20
that this could be done retroactively, and wave my hands over some of=20
the details since you did not talk about reorgs.)  The same applies as=20
for attacks requiring 33% or 25% of total hashpower.

Potential attack, assuming that N *must* be based partly or wholly on=20
the existing set of =E2=80=9Cnext-coinbase=E2=80=9D addresses:  A large min=
er could=20
gradually push N higher, by progressively committing new =E2=80=9Cnext-coin=
base=E2=80=9D=20
addresses which differ in the next bit for all previously seen=20
combinations of bits.  Large miners would have a vast advantage over=20
small miners, insofar as deliberately incrementing N by one more bit=20
could only be done by a miner who creates 2^(N+1) blocks (=3D 2 * 2^N). =20
By such means, it may be possible for a very large miner to eventually=20
lock out all other miners altogether, and monopolize all Bitcoin mining.

Now, questions:

How is N determined?  By a wave of the hands?

What part of which block hash is matched against N bits?  You were quite=20
unclear about this, and other important details.  (Much of what I say=20
here is based on assumptions and inferences necessary to fill in the=20
blanks.)

How, exactly, are reorgs handled?

How does this interact with the difficulty adjustment algorithm? =20
Indeed, how is difficulty determined at all under your scheme?

What happens to coinbase fees from a =E2=80=9Cnew-miner-block=E2=80=9D?  Th=
e way I read=20
your scheme, the =E2=80=9Cnew-miner-block=E2=80=9D must necessarily have no=
 payout=20
whatsoever.  But you discuss only =E2=80=9Cnew bitcoins=E2=80=9D, which are=
 a=20
diminishing portion of the block reward, and will eventually reach zero. =
=20
Coinbase from fees must go somewhere; but under your scheme, a =E2=80=9Cnew=
=20
miner=E2=80=9D has no payable address.

What if no existing =E2=80=9Cnext-coinbase=E2=80=9D address matches?  Is N =
constrained=20
to be sufficiently short that a match is guaranteed from the existing=20
set, then that makes it trivial for large mining farms to collect=20
addresses and further dominate (or even monopolize) the network in the=20
attack described above.  If it isn=E2=80=99t, then the network could sudden=
ly=20
halt when nobody is allowed to mine the next block; and that would=20
enable *this* attack:

What stops a malicious miner (including a =E2=80=9Cnew miner=E2=80=9D creat=
ing a=20
=E2=80=9Cnew-miner block=E2=80=9D) from deliberately working to create a bl=
ock with a=20
hash which does not have N bits matching any of the existing=20
=E2=80=9Cnext-coinbase=E2=80=9D addresses?  Contra what you say, block hash=
es can=E2=80=99t be=20
=E2=80=9Cconsidered random=E2=80=9D.  Indeed, partial preimage bruteforcing=
 of block=20
hashes is the entire basis of mining POW.

Asking here more generally than as for the attack described above, what=20
stops mining farms with large hashpower from submitting many different=20
=E2=80=9Cnext-coinbase=E2=80=9D addresses in many different blocks?  If N b=
e small, then=20
it should be feasible for a large mining farm to eventually register a=20
set of =E2=80=9Cnext-coinbase=E2=80=9D addresses which match any N.  **This=
 increases=20
mining centralization.**  If N be large, then this creates the=20
possibility (or raises the probability) that no address will match, and=20
nobody will be allowed to mine the next block.

How could miner anonymity be preserved under a scheme whereby each=20
=E2=80=9Cnext-coinbase=E2=80=9D address can be linked to a previous =E2=80=
=9Cnext-coinbase=E2=80=9D=20
address?  The only way to start fresh would be with a prohibitively=20
expensive no-payout block.  Mining can be totally anonymous at present,=20
and must so remain.  Miners are only identified by certain information=20
they choose to put in a block header, which they could choose to change=20
or omit=E2=80=94or by IP address, which is trivially changed and is never a=
=20
reliable identifier.

How does this even save electricity, when there is much mining equipment=20
(especially on large mining farms) which cannot be easily shut down and=20
restarted?  (Allegedly, this is one reason why some big miners=20
occasionally mine empty blocks.)  Though I suppose that difficulty would=20
drop by unspecified means.

Further observations:

This scheme drastically increases the upfront investment required for a=20
new miner to start mining.  To mine even one new block all by oneself,=20
without a pool, already requires a huge investment.  Add to that the=20
uncompensated energy cost of mining that first block with *no* payout,=20
and I expect that the bar would be prohibitive to almost all new=20
entrants.  Mining costs and incentives are delicately balanced by the=20
design of the network.  Whereas incumbents are much favoured by your=20
scheme, further increasing miner centralization.  Large incumbents could=20
also use this to produce a mining permissions market, by selling the=20
private keys to committed =E2=80=9Cnext-coinbase=E2=80=9D addresses.

I have not even tried to imagine what oddball attacks might be possible=20
for any miner with sufficient hashpower to deliberately cause a small=20
reorg.

--=20
nullius@nym.zone | PGP ECC: 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C
Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h | (Segwit nested:
3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG)  (PGP RSA: 0x36EBB4AB699A10EE)
=E2=80=9C=E2=80=98If you=E2=80=99re not doing anything wrong, you have noth=
ing to hide.=E2=80=99
No!  Because I do nothing wrong, I have nothing to show.=E2=80=9D =E2=80=94=
 nullius

--3kvnteadjxh7ktr3
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQSNOMR84IlYpr/EF5vEJ5MVn575SQUCWl1C/AAKCRDEJ5MVn575
STV+AQDr2NzDH1j3EEJCtIiWzkDDxIF+hX7XBwK47QImIjurnAEAitS6t0843n0H
vgj9yBkg2kF3zA9UUwd8CAJuO0oZSA4=
=mrcU
-----END PGP SIGNATURE-----

--3kvnteadjxh7ktr3--