Karel BĂlek [ARCHIVE] on Nostr: đź“… Original date posted:2014-06-17 đź“ť Original message:On Tue, Jun 17, 2014 at ...
đź“… Original date posted:2014-06-17
đź“ť Original message:On Tue, Jun 17, 2014 at 4:20 PM, Christophe Biocca
<christophe.biocca at 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 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
>>
>
> ------------------------------------------------------------------------------
> 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
đź“ť Original message:On Tue, Jun 17, 2014 at 4:20 PM, Christophe Biocca
<christophe.biocca at 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 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
>>
>
> ------------------------------------------------------------------------------
> 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