public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Raúl Martínez" <rme@i-rme.es>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: [Bitcoin-development] Proposals for improving Bitcoin mining decentralization
Date: Tue, 17 Jun 2014 10:57:06 +0200	[thread overview]
Message-ID: <CA+8=xuKmE2rgNK+Q4g+Gqvy3QuYAXzVRYtWKC2VttuB_LJmyMA@mail.gmail.com> (raw)

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

First of all I apologice due to the possible mistakes in my writing below,
I am not a Bitcoin developer but I have some knowledge about it.

----

We all know the recent news, Ghash pool controlling 51% of the hashrate.
While some consider it a threat others think that is not harmful.

The thing is that we have to do something to stop this from happening again.

My proposal is to start thinking about miners that join a pool like
independent miners and not slave miners, this includes creating a new
mining protocol that does not rely on the pool sending the list of
transactions to include in a block. Each individual miner has to collect
transactions by his own and mine that, this can be achieved by running a
full node or by running a SPV like node that ask other nodes for
transactions.

Once this protocol is developed and standarised we as a community could
require all pools to use it (because its better, because is more
trustless...), not by imposing it but by recommending it.

Pool owners could send some instructions using this protocol to the miner
about how many transactions to include per block (some pools want small
blocks), how many 0 fee transactions to include, how much is the minimum
fee per Kb to include transactions and some info about the Coinbase field
in the block.

This way is impossible to perform some of the possible 51% attacks:

   - A pool owner cant mine a new chain (selfish mining) (pool clients have
   a SPV or full node that has checkpoints and ask other peers about the
   length of the chain)
   - A pool owner can't perform double spends or reverse transactions (pool
   clients know all the transactions relayed to the network, they know if they
   are already included on a block)
   - A pool owner cant decide which transactions not to include (but they
   can configure the minimum fee).
   - A pool owner cant get all the rewards by avoiding other pools from
   mining blocks (Because the pool client knows the last block independently
   that is from his pool or other).


The only thing that a 51% pool owner can do is to shut down his pool and
drop the hashrate by 51% because he does not control the miners.

If the pool owner owns all the hardware in the pool my proposal is not
valid, if the pool clients dont use this protocol my proposal is not valid.


I want to know if this is possible or its been developed or there is
already a working protocol that works like this, also I want to read other
people's ways to address this threat, thanks for reading.

[-- Attachment #2: Type: text/html, Size: 2849 bytes --]

             reply	other threads:[~2014-06-17  9:04 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-17  8:57 Raúl Martínez [this message]
2014-06-17 13:58 ` [Bitcoin-development] Proposals for improving Bitcoin mining decentralization Ron Elliott
2014-06-17 14:01   ` Raúl Martínez
2014-06-17 14:06     ` Ron Elliott
2014-06-17 14:20 ` Christophe Biocca
2014-06-17 18:25   ` Karel Bílek
2014-06-17 19:01     ` Raúl Martínez
2014-06-17 15:58 ` Isidor Zeuner
2014-06-17  9:23 Mistr Bigs

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='CA+8=xuKmE2rgNK+Q4g+Gqvy3QuYAXzVRYtWKC2VttuB_LJmyMA@mail.gmail.com' \
    --to=rme@i-rme.es \
    --cc=bitcoin-development@lists.sourceforge.net \
    /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