public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Ron Elliott <ronaldbelliott@gmail.com>
To: "Raúl Martínez" <rme@i-rme.es>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposals for improving Bitcoin mining decentralization
Date: Tue, 17 Jun 2014 06:58:53 -0700	[thread overview]
Message-ID: <CAMEND1hS2j6dSjwvRSmVn_=UV-r7gujJ+Wo1VLH3nH54F3vBmQ@mail.gmail.com> (raw)
In-Reply-To: <CA+8=xuKmE2rgNK+Q4g+Gqvy3QuYAXzVRYtWKC2VttuB_LJmyMA@mail.gmail.com>

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

In this scenario how do you ensure the miner solving the block cannot
reapportion the subsidy to himself rather than the pool?
On Jun 17, 2014 2:09 AM, "Raúl Martínez" <rme@i-rme.es> wrote:

> 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.
>
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

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

  reply	other threads:[~2014-06-17 13:59 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-17  8:57 [Bitcoin-development] Proposals for improving Bitcoin mining decentralization Raúl Martínez
2014-06-17 13:58 ` Ron Elliott [this message]
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='CAMEND1hS2j6dSjwvRSmVn_=UV-r7gujJ+Wo1VLH3nH54F3vBmQ@mail.gmail.com' \
    --to=ronaldbelliott@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=rme@i-rme.es \
    /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