[Bitcoin-development] Proposals for improving Bitcoin mining decentralization

Raúl Martínez rme at i-rme.es
Tue Jun 17 14:01:02 UTC 2014


Because he cant change the coinbase once the proof of work is done.
 El 17/06/2014 15:58, "Ron Elliott" <ronaldbelliott at gmail.com> escribió:

> 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 at 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 at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140617/d5e763e6/attachment.html>


More information about the bitcoin-dev mailing list