Bitcoin Forum
March 19, 2024, 06:55:40 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1] 2 3 4 5 6 7 8 9 10 11 »  All
  Print  
Author Topic: Majority is not Enough: Bitcoin Mining is Vulnerable  (Read 50997 times)
CanaryInTheMine (OP)
Donator
Legendary
*
Offline Offline

Activity: 2352
Merit: 1060


between a rock and a block!


View Profile
November 04, 2013, 03:11:14 AM
 #1

Saw this on reddit first, reading paper, thought I should share:

http://arxiv.org/abs/1311.0243

http://www.reddit.com/r/Bitcoin/comments/1puk1a/arxiv_paper_majority_is_not_enough_bitcoin_mining/
There are several different types of Bitcoin clients. The most secure are full nodes like Bitcoin Core, which will follow the rules of the network no matter what miners do. Even if every miner decided to create 1000 bitcoins per block, full nodes would stick to the rules and reject those blocks.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1710831340
Hero Member
*
Offline Offline

Posts: 1710831340

View Profile Personal Message (Offline)

Ignore
1710831340
Reply with quote  #2

1710831340
Report to moderator
1710831340
Hero Member
*
Offline Offline

Posts: 1710831340

View Profile Personal Message (Offline)

Ignore
1710831340
Reply with quote  #2

1710831340
Report to moderator
frankenmint
Legendary
*
Offline Offline

Activity: 1456
Merit: 1018


HoneybadgerOfMoney.com Weed4bitcoin.com


View Profile WWW
November 04, 2013, 03:46:26 AM
 #2


Fascinating...reading still right now...but if I get this correct - the concept is that you're mining on something big like btcguild, and copying the entire block header onto your own private pool of work; at the same time, your miner is accepting work and not submitting valid shares to btcguild yet it submits them to the private duplicated pool. 

Anytime a Valid Share is found to have met minimum difficulty and discovers a block, it submits this from the private pool and broadcasts to the network?  Network accepts this and the private pool is fed the newly minted coins instead of btcguild?

jl2012
Legendary
*
Offline Offline

Activity: 1792
Merit: 1087


View Profile
November 04, 2013, 03:59:10 AM
 #3


Fascinating...reading still right now...but if I get this correct - the concept is that you're mining on something big like btcguild, and copying the entire block header onto your own private pool of work; at the same time, your miner is accepting work and not submitting valid shares to btcguild yet it submits them to the private duplicated pool. 

Anytime a Valid Share is found to have met minimum difficulty and discovers a block, it submits this from the private pool and broadcasts to the network?  Network accepts this and the private pool is fed the newly minted coins instead of btcguild?

No, completely wrong. The article is talking something else, and at the same time your strategy does not work at all.

This is a very common noob misconception. Simply speaking, a "share" is bound to the destination of the reward so you can't direct the reward to other address.


Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)
LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
jl2012
Legendary
*
Offline Offline

Activity: 1792
Merit: 1087


View Profile
November 04, 2013, 04:09:26 AM
 #4


I didn't read the maths carefully but I think I read something similar before. I don't think it works in a very effective way as the reason stated in section 6.1. The sybil attack described is also not effective if there are many honest full-nodes. Also, I assume that big pools are connected directly to minimize the stale rate so again such sybil attack won't work.

There are also other solutions, such as forwarding unverified full difficulty block headers, or even partial difficulty headers.


Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)
LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4158
Merit: 8343



View Profile WWW
November 04, 2013, 06:11:37 AM
Last edit: November 05, 2013, 12:30:04 AM by gmaxwell
 #5

I'm short on time, and this was announced to the public without advanced notice to e.g. the bitcoin-security list. Making an informed response fast is hard.

Ideally I'd like to think about it carefully, read the paper a few times, and run some simulations before commenting, but I'll likely be tied up at the IETF all week and people are already panicking and pushing for hasty changes in response to this which may be ill-advised, so I'm going to offer some preliminary comments here.

We've (or, at least, I have, see also Bytecoin's analysis in 2010) evaluated this general attack before but the simplest version of it just doesn't work out (in theory, or in simulation): Without significant hash-rate delaying your blocks ends up increasing the risk that you get orphaned since nodes prefer the first block they heard. The contribution of the paper (to my thinking, at least) is to assume that an attacker can also sybil attack the network, and in doing so can run nodes which will release blocks produced by the attacking miners in response to hearing a new block from the honest miners. So where the sybil attack is successful the delay does not confer a disadvantage and then the attack works (with increasing effectiveness the more effective the sybiling is and the more hashrate the attacker has).

Their proposed solution, which is offered without extensive analysis, is to relay all blocks, even late ones, and then choose the preferred block in ties at random. Ignoring collateral vulnerabilities which a hasty implementations of forward-all might create, I believe this proposal has a problem in that it creates a selfishness advantage even without any sybil attack at all, so long as the selfish miner has enough hashrate.  I believe this is a bad tradeoff because the degree of sybil vulnerability between mining nodes is likely much lower than assumed (many miners pin up connections to well known nodes and each other), and because we already have pools large enough to take advantage of the tradeoff vulnerability this creates.

Perhaps more importantly:  There are much worse vulnerabilities for us if attackers can perform successful large scale sybil attacks against miners.  In particular, if they're able to do that they could partition the network into two 50/50 hashrate groups and then drop blocks between them and hand conflicting transactions to each group and produce many-confirmed double-spends without having any hashrate at all.

As I've posted several times of Bitcointalk: beyond the cryptographic assumptions Bitcoin makes _two_ additional security assumptions: That an attacker doesn't control a majority of the hashrate and, quoting Satoshi, "the nature of information being easy to spread but hard to stifle", effectively— that an attacker can't substantially isolate or partition the honest participants.

With this in mind, rather than rushing in any changes in the consensus algorithm I recommend we take the following actions:

(0) Make a new concerted manual anti-sybil effort to ensure that all large miners are well connected to strong relaying nodes, including a mixture of public and non-public nodes (non-public for DOS resistance), in order to make partitioning miners infeasible.
(1) Evaluate our sybil resistance more generally and consider what measures and automation we could add to make sybil attacks harder (including supporting authenticated peering, or measures like including addr messages in coinbase txns to jam addr message manipulation).
(2) Build better stats collection for monitoring network wide orphaning.
(3) Improve node scalability (e.g. make it possible to support nodes with larger numbers of connections)

(Maybe it would also be useful to instrument miner software to detect block delaying, in the same way bfgminer will detect a pool issuing work that conflicts its own prior work)

It may ultimately make sense to change the consensus preference for _very_ near ties (e.g. ones which arrive with time differences comparable in scale to the difference in latency between your peers), but I think we need to be very careful that we don't trade a potentially irrelevant problem (because its either infeasible or if its not infeasible we have much worse problems) for a practically exploitable one.  Making our infrastructure stronger against sybils has many benefits and has been on and off the radar for a long time, and AFAICT if we prevent miner from being partitioned/intermediated by sybils we close the concerns here.

Thoughts?
pera
Sr. Member
****
Offline Offline

Activity: 532
Merit: 261


­バカ


View Profile
November 04, 2013, 07:51:00 AM
 #6

Thoughts?
Point 0 is just a workaround right?

キタ━━━━(゚∀゚)━━━━ッ!!
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652
Merit: 2164


Chief Scientist


View Profile WWW
November 04, 2013, 09:25:49 AM
 #7

Thoughts?
Point 0 is just a workaround right?

No; miners have a natural incentive to want to be closely connected to as many other miners as possible (to reduce orphan costs).

RE: Evaluating sybil resistance: I would still like to see blocks and transactions being broadcast over another completely different networking protocol, either peer-to-peer or not. More diversity so we're not relying on the one p2p network would be great, and, depending on how it was implemented, might automatically bring sybil resistance.

How often do you get the chance to work on a potentially world-changing project?
gaston909
Sr. Member
****
Offline Offline

Activity: 336
Merit: 250



View Profile
November 04, 2013, 09:54:12 AM
 #8


Beat me to it!
Stephen Gornick
Legendary
*
Offline Offline

Activity: 2506
Merit: 1010


View Profile
November 04, 2013, 10:29:01 AM
 #9

Vitalik Buterin's writeup on this on BitcoinMagazine.com

Selfish Mining: A 25% Attack Against the Bitcoin Network
 - http://bitcoinmagazine.com/7953/selfish-mining-a-25-attack-against-the-bitcoin-network

Unichange.me

            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █


niniyo
Member
**
Offline Offline

Activity: 118
Merit: 10


View Profile
November 04, 2013, 10:32:22 AM
Last edit: November 04, 2013, 10:44:17 AM by niniyo
 #10

I believe that the flaw with this system is that the success rate of your sybil attack has to be the inverse of your share of network hash rate.  For example, if you have 10% of network hash rate, you need your sybil attack to be successful >= 90% of the time in order to profit, otherwise you lose.

Consider:

's' = selfish pools share of network power (eg 0.1)
'o' = honest share of network power (eg. 0.9)
'a' = success rate for a sybil attack ('sybil attack' meaning you intercept an honest block, surpress its propogation, and propogate your own equal-length pre-mined chain which is seen by the mining majority).

The selfish pool will mine on the honest chain until it finds a block, at which point it withholds the block and begins mining on its own private chain.  The honest nodes will find the next block with probility 'o', which triggers a contest.  Eg. where the selfish pool has 10% hash rate, the selfish strategy will require them to execute their sybil attack on 90% of the blocks they mine.

Percentage of selfish pool blocks that will require sybil propogation = o.
Percentage of selfish pool work wasted from ineffective sybil attacks = o(1-a).
(Eg. with 10% hashrate and 50% sybil success rate, the selfish pool will waste 45% of their work.)

Percentage of honest workers blocks that suffer sybil attack = s.
Percentage of honest work wasted due to sybil attack = s*a.
(Eg. with 90% hashrate at 50% sybil success rate, the honest nodes will only waste 5% of their work.)

The reason why I compare the percentage of work wasted, is because that is the way to measure the relative return on hash rate invested.  If the selfish strategy wastes more % of work than the honest strategy, then it doesn't pay off to mine in the selfish pool.

Based on this formula, the selfish pool will only be at an advantage if 'a' (sybil success rate) is greater than 'o' (honest share of hashing power).  In other words, the sybil attack must be successful at a rate inverse to your mining power.

So, basically the main threat here is the sybil attack.

Can anyone spot any flaws in this analysis?
Stephen Gornick
Legendary
*
Offline Offline

Activity: 2506
Merit: 1010


View Profile
November 04, 2013, 11:35:33 AM
Last edit: November 04, 2013, 05:55:45 PM by Stephen Gornick
 #11

Isn't the economic benefit to joining the selfish pool easy to extinguish?

The further ahead the selfish pool is, the greater the cost to them if they lose that race.   The only economic benefit to the selfish miner comes from the block reward subsidy + fees from future blocks on that chain.  But if it becomes known that a selfish pool is operating then an incentive for defecting from the selfish pool/cartel can be offered (in a way so that it is not available to the selfish pool as well).   If those incentives cause mining on the selfish pool to be less rewarding then the selfish pool strategy can be defeated.

Wouldn't it be easy to tell if a block seems to be coming from a selfish pool (as each new block will appear to be laggng since it has no recently arrived transactions)?  So if this lag can be detected then cannot an incentive to honest pools be offered?

A way to offer this incentive so that it is only available to the honest miners is to periodically send a type of marker transaction.  There is a promise to pay an incentive/reward for including the marker transaction within N seconds after it is broadcast.  So the selfish pool's previously mined block would not be able to include this marker transaction promptly, but honest miners are including recent transactions and thus would be able to include it.  And then when that "included within N seconds" condition is true, those offering the incentive then send the incentive payment to the Bitcoin address for the coinbase transaction for that block.

[Edited]

Unichange.me

            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █


Skybuck
Full Member
***
Offline Offline

Activity: 361
Merit: 110


View Profile
November 04, 2013, 01:39:04 PM
Last edit: November 04, 2013, 01:52:45 PM by Skybuck
 #12

Interesting document.

What seems to be missing is when multiple selfish-mining pools exist... what will happen then ? Wink

Maybe one would be a bit faster than the other... though humans tend to want to oppose each other so I am thinking there will always be groups of people trying to defeat the others.

Maybe they would also do it to try and keep the system in balance or so. Then again maybe not.

The change seems simple enough to implement.

(During my first scan/read of the document my system frooze up completely, then I installed a new update of acrobat reader, and no more problems... I did clean my system two days ago or so and it been running all night so could be an issue with that... kinda weird though.. so then I read it in full it's a very interesting document and a very easy attack).

I am glad somebody with more mathematical background and statistical reasoning figured this out... I've wondered for a long time now what kind of benefit keeping the found block secret/private would have and how to exploit it... this document does a fine job of explaining all possibilities, and under all possibilities it's a good/beneficial attack with high likelyhood of working/accepted under the current bitcoin system.

The most funny thing is the parallel nature/exponential nature of it... the more people/miners join it, the better it starts to work... which reminds me of the king and the grain on the checkerboard/chessboard... it starts out small but ends up big Wink Smiley How big I never knew but this document examines it more.

For this too work people would have to be convinced that they pay out on a selfish-mining-pool is greater than "honest" pools...

Also such data may fluctuate over time probably leading to multiple selfish mining pools... what happens then is unclear Wink probably one will win out over the other... or perhaps it's too close too call and both continue to grow bigger, honest nodes/miners would then loose out... I don't really see it as honest vs non-honest... it's just a different way to handle the blockchain and new blocks.

Also I would totally not be surprised if some mining pools already implemented this in one form or another... I would surely have tried to do something like this... so the likelyhood of this already existing in the wild is super high.

Sounds more like this is a document written by somebody that got sick of the cheaters and wants to ratt out on them... to try and prevent system take-over/collapse on the long run protecting it's wealth thereby Wink Smiley =D
(I read the document up to page 7, then skipped some of the state machine analysis and maths also read some page 12 about pool formation and page 13 fixing bitcoin).

Most fun document about bitcoin I have seen so far and it came out this week... lucky me... I just happened to come and see how bitcoin is doing or so Wink I guess I had a hunch something was going on I dont know or I just got lucky wiee Wink Smiley

Will be interesting to see how this plays out... even with the fix... it's going to remain problematic somewhat... apperently now 25% is enough for a selfish pool... but what if multiple selfish-pools exist ? hmmm

Maybe if multiple exists it won't be much of a problem. So that will be my next lookout... a document examining such a scenerio Wink

One question that also remains unanswered in my brain is the following:

How far back (how many blocks) is a client allowed to switch branches ? Only 1 block ? or multiple ? or a fixed number ? Maybe 2048 ? Me rusty on bitcoin...
hannesnaude
Full Member
***
Offline Offline

Activity: 169
Merit: 100

Firstbits : 1Hannes


View Profile
November 04, 2013, 01:59:42 PM
 #13

The contribution of the paper (to my thinking, at least) is to assume that an attacker can also sybil attack the network, and in doing so can run nodes which will release blocks produced by the attacking miners in response to hearing a new block from the honest miners. So where the sybil attack is successful the delay does not confer a disadvantage and then the attack works (with increasing effectiveness the more effective the sybiling is and the more hashrate the attacker has).

I think it is a little worse than that. An effective Sybil attack is necessary to make the attack viable for a small pool, but the larger the pool is,  the less effective the Sybil attack needs to be. For a pool larger than 33% of the network, no Sybil attack is required.

On the other hand, one mitigating factor that is not mentioned in the paper is that the attack buys you more revenue long term, but in the short term you will see a loss of revenue. You are not finding more blocks than before (in fact you are losing some of your blocks) so your income within a difficulty adjustment period will actually drop (but so will everyone else's). The increase in revenue comes later due to the fact that you caused others to lose blocks which makes the difficulty drop (or just rise less than it would have) which then nets you more blocks in the long run.

However, since
 a) The attack can easily be detected (sudden increase in orphaned blocks)
 b) The attack will negatively affect the bitcoin price.
the revenue impact of performing the attack is probably negative even in the long run.
Sergio_Demian_Lerner
Hero Member
*****
expert
Offline Offline

Activity: 549
Merit: 608


View Profile WWW
November 04, 2013, 02:10:03 PM
 #14

I have no time to read carefully the paper but..

Some time ago I posted in http://bitslog.wordpress.com/2013/06/26/the-bitcoin-eternal-choice-for-the-dark-side-attack-ecdsa/ a solution to another attack that may also work to protect from this attack:

Quote
The additional protective measure would be that any chain reorg of n blocks is delayed n seconds.  During that wait period, if another better chain reorg is received, it is processed in the same way. After one period expires, the chain reorg is applied, and a new best chain is created. If a block that extends a waiting chain is received, then the waiting lapse is restarted from zero for that chain. ...

This protocol protects from the appearance of simultaneously competing blocks but also from other attacks that may based on hidden branches. So I'll refer the method as "hidden-branch-protection".

Does it help?
Skybuck
Full Member
***
Offline Offline

Activity: 361
Merit: 110


View Profile
November 04, 2013, 02:32:23 PM
 #15

This document in super short is about:

Keeping found blocks secret, to perform calculations on them so that others cannot, thereby giving a racing adventage. They "secretivers" will have a head start.

When "publicers" announce their block quickly publish the "secret" block to create a tieing situation.

Currently the first block that arrives is picked by miners so the "secretives" have incencitive to "delay public blocks", an incentive to listen in on other mining pools "detect early public block announcement to quick react to it" and to try and inject/publish their secretive block as fast as possible towards other miners that have not yet received a new block.

If the random picking solution is implemented, 50% of "publicers" will choose the "publicer" block, 50% will choose the "secretivers" blocks, while 100% of the "secrectives" pick the "secritive" block. 150% will therefore try and continue on "secretive" block and only 50% on "publicer" block, increasing the likelyhood of "secrective" block to win out, thereby injecting the secretive block into the blockchain, either the next block will be found be a publicer or by a secretiver, the more secretivers there are the more likely it will be found by them especially because of the headstart, leading to an incentive for others to join the "secretivers" also known as "(a)head-starters" Wink  (actual percentages will depend on the size of the pools).

The conditions above describe the secretives being ahead 1 block.

The document continues with being 2 blocks ahead. (now it gets longer and fudgy for me at least):

I am not sure but I think in this case it will publish both secretive blocks if the publicers announce their block, immediatly invalidating their progress, this could also cause other self-ish miners to be in trouble, they could also publish their second block creating a new tie, or perhaps even a third.

These situations could be easy to detect, the second block would be announced immediatly ? perhaps the algorithm can be refined somewehat by introducing a believable delay of a few minutes, though risky if another selfish pool announces it sooner, though keeping the second block secret could also be an option and try and rely on tieing only. Though for many this would not be statisfactory and would probably try the third block strategy and so forth and thus keep immediatly publishing any found blocks immediatly to try and win over the main network.

This last line of thought is described in the last else statement.

If more than 2 blocks ahead, publish all of them to solidify the gains. If this is truely the longest chain then they'll win and be garantueed of the rewards, if this is not truely the longest chain then they will be superseeded/defeatede by another selfish mining pool... so I am in doubt that this last else statement is smart in case of multiple selfish mining pools.

Eventually they would be defeated by another selfish mining pool that may delay their +1 block to try and defeat the other selfish mining pool into wasting their processing time on their private blocks which they hope would be the new public chain... eventually the longer selfish mining pool may win out by delaying their publication of their found blocks.

So I do think the algorithm can be refined somewhat by building in delays to try and defeat other selfish mining pools. Thus if this does get implemented we'll be seeing some kind of time wars... publish to late and one may be superseeded, publish too soon and one may be superseeded, however in this case one would always be superseeded so it makes no sense, and thus always publishing beyond two makes sense... either you truely have most processing power or not, however this does not include luck and by chance...

Perhaps the document describes these lines of thoughts and explains how to handle it or maybe not... maybe it was too difficult to analyze how the algorithm would perform against itself.

For now I shall give it a rest until further notice Wink Smiley

Some points to sum up:

+ Find a block and keep it secret.
+ Find the next block for the secret block.
+ Publish the secret block if a public block is published.
+ Try to get the secret block published sooner.
+ Some honest nodes may work on the published secret block and if they find the next block the secret block wins.
+ Secret block has more chance of winning if random selection is implemented (this could be the true motive for the document, implementors of bitcoin beware ! Wink).
+ Currently fastest announced block seems to win.
+ Incentive to keep public blocks delayed.
+ Incentive to spy on other pools to detect early block announcement.
+ Incentive to detect traitors by selective announcing private blocks found by pool maintainer.
+ Spying on selfish pools is a potential counter-strategy if done in secret somehow.
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4158
Merit: 8343



View Profile WWW
November 04, 2013, 04:25:56 PM
 #16

Currently the first block that arrives is picked by miners so the "secretives" have incencitive to "delay public blocks", an incentive to listen in on other mining pools "detect early public block announcement to quick react to it" and to try and inject/publish their secretive block as fast as possible towards other miners that have not yet received a new block.
Your analysis is pretty incomplete. Their success at winning that "fast as possible" race, along with their total hashrate, is essential. Otherwise a delay is a pure loss.
Waschtel
Newbie
*
Offline Offline

Activity: 18
Merit: 0


View Profile
November 04, 2013, 04:41:51 PM
 #17

Excuse my naiveté, but I was under the impression that the software which coordinates the mining effort of a pool between the pool miners is NOT responsible for claiming the mining prize, but that each lowly pool miner - should he find the correct hash - claims the prize to an account belonging to the pool and immediately broadcasts his success. This way, immediate broadcasting of the new block is assured, and keeping stuff secret would never happen.
Meni Rosenfeld
Donator
Legendary
*
expert
Offline Offline

Activity: 2058
Merit: 1054



View Profile WWW
November 04, 2013, 05:23:06 PM
Last edit: November 04, 2013, 05:54:05 PM by Meni Rosenfeld
 #18

I'd like to point out that a primitive version of this attack is 3 years old:

https://bitcointalk.org/index.php?topic=2227.msg30064#msg30064
https://bitcointalk.org/index.php?topic=2227.msg30083#msg30083

Excuse my naiveté, but I was under the impression that the software which coordinates the mining effort of a pool between the pool miners is NOT responsible for claiming the mining prize, but that each lowly pool miner - should he find the correct hash - claims the prize to an account belonging to the pool and immediately broadcasts his success. This way, immediate broadcasting of the new block is assured, and keeping stuff secret would never happen.
A miner in a traditional pool doesn't have the information needed to publish a block on his own. He has to submit the header w/ nonce to the pool, and then the pool broadcasts the block.

1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr   |   Who am I?   |   bitcoin-otc WoT
Bitcoil - Exchange bitcoins for ILS (thread)   |   Israel Bitcoin community homepage (thread)
Analysis of Bitcoin Pooled Mining Reward Systems (thread, summary)  |   PureMining - Infinite-term, deterministic mining bond
bluemeanie1
Sr. Member
****
Offline Offline

Activity: 280
Merit: 257


bluemeanie


View Profile WWW
November 04, 2013, 05:50:15 PM
 #19

Even of more concern is that IBM has been circling around these areas recently.

IBM has access to enormous computing power.  While they may not aggressively attack Bitcoin per se, they certainly could start brokering privileged positions in the network.  Computing power on that level is very much in the reach of IBM, and they are perhaps the biggest player in high technology for Financial applications.

Just who IS bluemeanie?    On NXTautoDAC and a Million Stolen NXT

feel like your voice isn't being heard? PM me.   |   stole 1M NXT?
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4158
Merit: 8343



View Profile WWW
November 04, 2013, 06:02:35 PM
 #20

A miner in a traditional pool doesn't have the information needed to publish a block on his own. He has to submit the header w/ nonce to the pool, and then the pool broadcasts the block.
They do in the GBT protocol supported by bitcoind, sadly the market chose to use the later stratum protocol over it primarily. Tongue  This, I think, is largely offtopic. There is no reason you wouldn't expect the hashers to be complicit in such a scheme: Even if delayed blocks can't be prevented with non-GBT mining protocols, they still can be trivially detected. (E.g. miners often issuing work with non-public prev, big orphan bursts)
Pages: [1] 2 3 4 5 6 7 8 9 10 11 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!