Bitcoin Forum
May 05, 2024, 12:00:46 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Re: Majority is not Enough: Bitcoin Mining is Vulnerable  (Read 814 times)
dbeberman (OP)
Newbie
*
Offline Offline

Activity: 3
Merit: 0


View Profile
July 05, 2015, 04:21:42 AM
 #1

I'm completely new to bitcoin.  I've read all the developer pages, read through the source, the
original Satoshi paper, and several other things.
Ran into the paper that this thread is about, and read it through a couple times, then this thread,
and one thread that spawned off of it.

There doesn't seem to have been a solid conclusion to the thread, but it seems like the
general consensus that even if this were put in practice, it would not destroy bitcoin.

Was there another thread that discussed a full solution for this?

I'd like to throw out a couple theoretical and perhaps very unrealistic questions:

1: If the solution were to randomize what chain to work on in a tie, why wouldn't the selfish pool
try to create multiple chains by having subpools work on finding hashes for separate blocks?
These can then be flooded to the network increasing the odds in favor of the selfish pool even
with the randomizing.
Of course, the processing power in N times the amount to do a single block ahead, where N is the
number of simultaneous blocks being hashed.  Also the probability of even finding two blocks
against the entire network is very low and probably cost prohibitive.

2: In general, holding on to a block for some period after finding it, looks like a potential advantage
is working on the next block.  Why not have all the nodes do this as normal operation?
The longer a node holds onto the block, the higher the risk of getting into a competitive fork situation,
but also increases the opportunity to win the race to the next block.  Seems like this could create
some "safe" gambling type behavior, while nullifying the overall effect of the selfish mining algorithm.

I suspect this also has an impact on the adjustment of the level of difficulty in finding hashes.  If
nodes appear to work both slower and with higher variance, the difficulty level might not be increased
as fast.


Just a couple thoughts on what looks like a dead discussion.
1714867246
Hero Member
*
Offline Offline

Posts: 1714867246

View Profile Personal Message (Offline)

Ignore
1714867246
Reply with quote  #2

1714867246
Report to moderator
"You Asked For Change, We Gave You Coins" -- casascius
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1714867246
Hero Member
*
Offline Offline

Posts: 1714867246

View Profile Personal Message (Offline)

Ignore
1714867246
Reply with quote  #2

1714867246
Report to moderator
achow101
Moderator
Legendary
*
expert
Offline Offline

Activity: 3388
Merit: 6581


Just writing some code


View Profile WWW
July 05, 2015, 03:40:59 PM
 #2

You should include the links to those threads. They aren't linked.

1: If the solution were to randomize what chain to work on in a tie, why wouldn't the selfish pool
try to create multiple chains by having subpools work on finding hashes for separate blocks?
These can then be flooded to the network increasing the odds in favor of the selfish pool even
with the randomizing.
Of course, the processing power in N times the amount to do a single block ahead, where N is the
number of simultaneous blocks being hashed.  Also the probability of even finding two blocks
against the entire network is very low and probably cost prohibitive.
What good would that do? It would cost a lot of processing power and there would be little profit. There would be N times the amount of processing power in order to flood the network with their blocks, but each one different. With that much processing power, it would be more effective and more profitable to mine normally. Instead of finding two blocks simultaneously and getting only a 25 BTC reward, with the same hashrate, they could find two blocks one after each other and get a 50 BTC reward.

2: In general, holding on to a block for some period after finding it, looks like a potential advantage
is working on the next block.  Why not have all the nodes do this as normal operation?
The longer a node holds onto the block, the higher the risk of getting into a competitive fork situation,
but also increases the opportunity to win the race to the next block.  Seems like this could create
some "safe" gambling type behavior, while nullifying the overall effect of the selfish mining algorithm.
The longer a node holds onto a block, the higher the risk of someone else finding that same block and thus orphaning the miner. Unless the miner held a significant portion of the network, he will not be able to mine faster than the rest of the network can and produce a longer chain. Still, the miner that finds a block has a slight advantage over the remaining miners since he has the block before everyone else. Due to network latency and the verification of blocks, the miner who found a block has a slight time advantage over everyone else, but not by much.

dbeberman (OP)
Newbie
*
Offline Offline

Activity: 3
Merit: 0


View Profile
July 06, 2015, 04:57:37 PM
 #3

Hi,

This is the original thread:
https://bitcointalk.org/index.php?topic=324413.0

This it the other thread that was a spinoff:
https://bitcointalk.org/index.php?topic=327292.0

Quote
What good would that do? It would cost a lot of processing power and there would be little profit. There would be N times the amount of processing power in order to flood the network with their blocks, but each one different. With that much processing power, it would be more effective and more profitable to mine normally. Instead of finding two blocks simultaneously and getting only a 25 BTC reward, with the same hashrate, they could find two blocks one after each other and get a 50 BTC reward.

The only difference I was looking at was what the impact on the rest of the network of miner is.
The rest of the network would be more likely to be working on blocks on one of the chains that the selfish pool has a headstart on.
At the sametime, the total processing power of the selfish pool is effectively hidden, so there wouldn't be an update
in the adjustment of difficulty for the hashrate.
This is a theoretical question only, perhaps it shows that the original paper is invalid by extrapolation, I don't know.

Quote
The longer a node holds onto a block, the higher the risk of someone else finding that same block and thus orphaning the miner. Unless the miner held a significant portion of the network, he will not be able to mine faster than the rest of the network can and produce a longer chain. Still, the miner that finds a block has a slight advantage over the remaining miners since he has the block before everyone else. Due to network latency and the verification of blocks, the miner who found a block has a slight time advantage over everyone else, but not by much.

Yes, this is the advantage I was thinking of.  My thought is that all miners ought to do this, at least periodically.
It seems like a way to increase the CPU (or ASIC) utilization by having a slight headstart on the next block.
It is a gamble that might give a slight increase in payoff against the amount of availabe processing power.
It doesn't seem to have any negative effect on the behavior of the network of miners in general.

With respect to the paper on this practice, I don't see how it draws the conclusion that this will create a mining monopoly.
There is no requirement that there is only a single pool that would do this type of holdback, assuming it works.

Regards,
David
Pages: [1]
  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!