From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 57304EDC for ; 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 ; 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 To: Enrique =?iso-8859-1?Q?Ariz=F3n?= Benito , Bitcoin Protocol Discussion Message-ID: <5e93f4b0e82ddf4eba5f1f54923e153f@nym.zone> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3kvnteadjxh7ktr3" Content-Disposition: inline In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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--