public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: nullius <nullius@nym.zone>
To: "Enrique Arizón Benito" <enrique.arizonbenito@gmail.com>,
	"Bitcoin Protocol Discussion"
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Proposal to reduce mining power bill
Date: Tue, 16 Jan 2018 00:10:38 +0000	[thread overview]
Message-ID: <5e93f4b0e82ddf4eba5f1f54923e153f@nym.zone> (raw)
In-Reply-To: <CAD-msxHyN+psv5p94_pUzNMFfZjMX4Jie2=PCt0CeO1cuuCz2A@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 7668 bytes --]

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

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

Potential attack, assuming that N *must* be based partly or wholly on 
the existing set of “next-coinbase” addresses:  A large miner could 
gradually push N higher, by progressively committing new “next-coinbase” 
addresses which differ in the next bit for all previously seen 
combinations of bits.  Large miners would have a vast advantage over 
small miners, insofar as deliberately incrementing N by one more bit 
could only be done by a miner who creates 2^(N+1) blocks (= 2 * 2^N).  
By such means, it may be possible for a very large miner to eventually 
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 
unclear about this, and other important details.  (Much of what I say 
here is based on assumptions and inferences necessary to fill in the 
blanks.)

How, exactly, are reorgs handled?

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

What happens to coinbase fees from a “new-miner-block”?  The way I read 
your scheme, the “new-miner-block” must necessarily have no payout 
whatsoever.  But you discuss only “new bitcoins”, which are a 
diminishing portion of the block reward, and will eventually reach zero.  
Coinbase from fees must go somewhere; but under your scheme, a “new 
miner” has no payable address.

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

What stops a malicious miner (including a “new miner” creating a 
“new-miner block”) from deliberately working to create a block with a 
hash which does not have N bits matching any of the existing 
“next-coinbase” addresses?  Contra what you say, block hashes can’t be 
“considered random”.  Indeed, partial preimage bruteforcing of block 
hashes is the entire basis of mining POW.

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

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

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

Further observations:

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

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

-- 
nullius@nym.zone | PGP ECC: 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C
Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h | (Segwit nested:
3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG)  (PGP RSA: 0x36EBB4AB699A10EE)
“‘If you’re not doing anything wrong, you have nothing to hide.’
No!  Because I do nothing wrong, I have nothing to show.” — nullius

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

  reply	other threads:[~2018-01-16  0:11 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-15 22:47 [bitcoin-dev] Proposal to reduce mining power bill Enrique Arizón Benito
2018-01-16  0:10 ` nullius [this message]
2018-01-17 22:34   ` Enrique Arizón Benito
2018-01-18  5:22     ` Eric Voskuil
2018-01-18  8:24     ` Damian Williamson
     [not found] ` <CAAt2M1-KTyGPkwaRY=krAfMPUv797JaZyhF1e5g8e8yjjGWhmQ@mail.gmail.com>
2018-01-18 16:25   ` Natanael

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=5e93f4b0e82ddf4eba5f1f54923e153f@nym.zone \
    --to=nullius@nym.zone \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=enrique.arizonbenito@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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