* [Bitcoin-development] Proposals for improving Bitcoin mining decentralization
@ 2014-06-17 8:57 Raúl Martínez
2014-06-17 13:58 ` Ron Elliott
` (2 more replies)
0 siblings, 3 replies; 9+ messages in thread
From: Raúl Martínez @ 2014-06-17 8:57 UTC (permalink / raw)
Cc: Bitcoin Dev
[-- 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 --]
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [Bitcoin-development] Proposals for improving Bitcoin mining decentralization
2014-06-17 8:57 [Bitcoin-development] Proposals for improving Bitcoin mining decentralization Raúl Martínez
@ 2014-06-17 13:58 ` Ron Elliott
2014-06-17 14:01 ` Raúl Martínez
2014-06-17 14:20 ` Christophe Biocca
2014-06-17 15:58 ` Isidor Zeuner
2 siblings, 1 reply; 9+ messages in thread
From: Ron Elliott @ 2014-06-17 13:58 UTC (permalink / raw)
To: Raúl Martínez; +Cc: Bitcoin Dev
[-- 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 --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] Proposals for improving Bitcoin mining decentralization
2014-06-17 13:58 ` Ron Elliott
@ 2014-06-17 14:01 ` Raúl Martínez
2014-06-17 14:06 ` Ron Elliott
0 siblings, 1 reply; 9+ messages in thread
From: Raúl Martínez @ 2014-06-17 14:01 UTC (permalink / raw)
To: Ron Elliott; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 3687 bytes --]
Because he cant change the coinbase once the proof of work is done.
El 17/06/2014 15:58, "Ron Elliott" <ronaldbelliott@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@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: 4585 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] Proposals for improving Bitcoin mining decentralization
2014-06-17 14:01 ` Raúl Martínez
@ 2014-06-17 14:06 ` Ron Elliott
0 siblings, 0 replies; 9+ messages in thread
From: Ron Elliott @ 2014-06-17 14:06 UTC (permalink / raw)
To: Raúl Martínez; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 4308 bytes --]
as I understood your proposal the entire block would be created on the
miner rather than just the block header. Currently miners do not receive a
list of transactions, they receive information required to create the block
header, this is how you keep miners honest. if the miner is creating the
full block we are right back to where we were.
I've only worked with implementing the mining process for a few months now
so someone correct me if I have the process wrong
On Jun 17, 2014 7:01 AM, "Raúl Martínez" <rme@i-rme•es> wrote:
> Because he cant change the coinbase once the proof of work is done.
> El 17/06/2014 15:58, "Ron Elliott" <ronaldbelliott@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@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: 5418 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] Proposals for improving Bitcoin mining decentralization
2014-06-17 8:57 [Bitcoin-development] Proposals for improving Bitcoin mining decentralization Raúl Martínez
2014-06-17 13:58 ` Ron Elliott
@ 2014-06-17 14:20 ` Christophe Biocca
2014-06-17 18:25 ` Karel Bílek
2014-06-17 15:58 ` Isidor Zeuner
2 siblings, 1 reply; 9+ messages in thread
From: Christophe Biocca @ 2014-06-17 14:20 UTC (permalink / raw)
To: Raúl Martínez; +Cc: Bitcoin Dev
https://en.bitcoin.it/wiki/Getblocktemplate is supposed to solve most
of the pooling-centralization problems. Unfortunately, it is opt-in,
and GHash.io doesn't support it.
Also most miners don't care and don't do the work to set it up. To do
transaction inclusion themselves, they'd need to run a full node,
which is a bit more work and resources than just pointing hashpower at
a stratum server.
If you figure out a way to make GBT widely used (>50% hashpower), kudos to you.
On Tue, Jun 17, 2014 at 4:57 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
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] Proposals for improving Bitcoin mining decentralization
2014-06-17 14:20 ` Christophe Biocca
@ 2014-06-17 18:25 ` Karel Bílek
2014-06-17 19:01 ` Raúl Martínez
0 siblings, 1 reply; 9+ messages in thread
From: Karel Bílek @ 2014-06-17 18:25 UTC (permalink / raw)
To: Christophe Biocca; +Cc: Bitcoin Dev
On Tue, Jun 17, 2014 at 4:20 PM, Christophe Biocca
<christophe.biocca@gmail•com> wrote:
> https://en.bitcoin.it/wiki/Getblocktemplate is supposed to solve most
> of the pooling-centralization problems.
This. There is no need to create anything new when GBT already exists.
In my opinion.
> Unfortunately, it is opt-in,
> and GHash.io doesn't support it.
Yep. As pools in general are not a part of the bitcoin protocol itself
(nobody cares how the work happened), I am not sure how this can be
forced.
> Also most miners don't care and don't do the work to set it up. To do
> transaction inclusion themselves, they'd need to run a full node,
> which is a bit more work and resources than just pointing hashpower at
> a stratum server.
Also, yep. If the miners cared about 51% attack, they wouldn't join
ghash in the first place. All the miners willingly accept the risk in
joining the big pool.
K. B.
> If you figure out a way to make GBT widely used (>50% hashpower), kudos to you.
>
> On Tue, Jun 17, 2014 at 4:57 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
>>
>
> ------------------------------------------------------------------------------
> 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] Proposals for improving Bitcoin mining decentralization
2014-06-17 18:25 ` Karel Bílek
@ 2014-06-17 19:01 ` Raúl Martínez
0 siblings, 0 replies; 9+ messages in thread
From: Raúl Martínez @ 2014-06-17 19:01 UTC (permalink / raw)
To: Karel Bílek; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 5667 bytes --]
But miners dont want to run full nodes, its better to develop some SPV like
that connects to some nodes.
Also I believe that stratum mining protocol improves some performance
things that GBT lacks.
If a new protocol that requires blocks created by miners is developed and
named in a cool way, miners could ask for protocol support to his favourite
pool.
El 17/06/2014 20:26, "Karel Bílek" <kb@karelbilek•com> escribió:
> On Tue, Jun 17, 2014 at 4:20 PM, Christophe Biocca
> <christophe.biocca@gmail•com> wrote:
> > https://en.bitcoin.it/wiki/Getblocktemplate is supposed to solve most
> > of the pooling-centralization problems.
>
> This. There is no need to create anything new when GBT already exists.
> In my opinion.
>
> > Unfortunately, it is opt-in,
> > and GHash.io doesn't support it.
>
> Yep. As pools in general are not a part of the bitcoin protocol itself
> (nobody cares how the work happened), I am not sure how this can be
> forced.
>
> > Also most miners don't care and don't do the work to set it up. To do
> > transaction inclusion themselves, they'd need to run a full node,
> > which is a bit more work and resources than just pointing hashpower at
> > a stratum server.
>
> Also, yep. If the miners cared about 51% attack, they wouldn't join
> ghash in the first place. All the miners willingly accept the risk in
> joining the big pool.
>
> K. B.
>
> > If you figure out a way to make GBT widely used (>50% hashpower), kudos
> to you.
> >
> > On Tue, Jun 17, 2014 at 4:57 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
> >>
> >
> >
> ------------------------------------------------------------------------------
> > 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: 7181 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] Proposals for improving Bitcoin mining decentralization
2014-06-17 8:57 [Bitcoin-development] Proposals for improving Bitcoin mining decentralization Raúl Martínez
2014-06-17 13:58 ` Ron Elliott
2014-06-17 14:20 ` Christophe Biocca
@ 2014-06-17 15:58 ` Isidor Zeuner
2 siblings, 0 replies; 9+ messages in thread
From: Isidor Zeuner @ 2014-06-17 15:58 UTC (permalink / raw)
To: Christophe Biocca; +Cc: Bitcoin Dev
quote:
> https://en.bitcoin.it/wiki/Getblocktemplate is supposed to solve most
> of the pooling-centralization problems. Unfortunately, it is opt-in,
> and GHash.io doesn't support it.
>
> Also most miners don't care and don't do the work to set it up. To do
> transaction inclusion themselves, they'd need to run a full node,
> which is a bit more work and resources than just pointing hashpower at
> a stratum server.
>
> If you figure out a way to make GBT widely used (>50% hashpower), kudos to you.
>
Well, as soon as miners learn about the merits of controlling the
blocks' contents, this issue may get solved by the market pressure
of miners expecting this kind of service from their pool.
I mean, the dev community constantly has some level of disagreement
about the best policies for what to include in blocks. But seen from
the perspective of some Bitcoin business or another, certain policies
might be more preferable. So if miners start to understand that they
could take a stake for their favourite Bitcoin businesses by choosing
a mining pool which employs a preferable transaction inclusion policy,
the question would not anymore be "which pool gives me the most
Bitcoins or the lowest variance, regardless of the technical
background", but "which pools does the best for my Bitcoin economy
needs". And this may be a very economically driven decision by itself,
considering that the exchange rates for Bitcoins depend on Bitcoin
businesses doing well.
If we get to this point with respect to user (miner) education, then
it is probably only a matter of time until people start to find it
cumbersome to mine on a black-box pool and having to manually verify
that they still have an agreeable transaction inclusion policy, when
they can just mine on a GBT pool and configure things in their mining
software.
> On Tue, Jun 17, 2014 at 4:57 AM, Raúl Martínez <rme@i-rme•es> wrote:
[...]
> > 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.
> >
Bear with me, but this piece of rhetorics struck me. Why even mention
those who think it's not harmful, when your next sentence states
that their opinion should be ignored completely?
Best regards,
Isidor
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] Proposals for improving Bitcoin mining decentralization
@ 2014-06-17 9:23 Mistr Bigs
0 siblings, 0 replies; 9+ messages in thread
From: Mistr Bigs @ 2014-06-17 9:23 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 341 bytes --]
I have been surprised by the lack of discussion of this topic here!
On 6/17/2014 10:57 AM, Raúl Martínez wrote:
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.
[-- Attachment #2: Type: text/html, Size: 495 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2014-06-17 19:01 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-06-17 8:57 [Bitcoin-development] Proposals for improving Bitcoin mining decentralization Raúl Martínez
2014-06-17 13:58 ` 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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox