Bitcoin Forum
May 02, 2024, 09:52:29 PM *
News: Latest Bitcoin Core release: 27.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 51002 times)
tacotime
Legendary
*
Offline Offline

Activity: 1484
Merit: 1005



View Profile
November 11, 2013, 04:48:12 PM
 #201

You're wrong: nobody does that

I think you mean you don't do that.



Quote
E.g., take
the one whose last block hash is smaller. This way all miners choose the
same chain, and the guarantees of our solution hold.

This is not a new idea at all.  As far as public postings, it's been on this page on the bitcoin wiki for at least six months, and there was definitely a mention of it on bitcoin-dev about a year ago (I will post the reference when I find it).  And, as I've mentioned, it's pervasive in the modified clients used by large mining operations, although those are not public so you're welcome to shout "liar liar pants on fire" all you like and I won't get upset Smiley



I think the people who wrote this paper took Satoshi's original whitepaper too literally:

Quote
Nodes always consider the longest chain to be the correct one and will keep working on extending it. If two nodes broadcast different versions of the next block simultaneously, some nodes may receive one or the other first. In that case, they work on the first one they received, but save the other branch in case it becomes longer. The tie will be broken when the next proof- of-work is found and one branch becomes longer; the nodes that were working on the other branch will then switch to the longer one.

Mining strategy has evolved and adapted, as it must in any incentive-driven system.  For example, Satoshi's whitepaper predicted that transaction fees would be a meaningful incentive, and it's pretty obvious it hasn't turned out that way.

This has been proposed for MC2 for a very long time too.. when you have a hybrid PoW/PoS system there needs to be strongly deterministic means of blockchain selection, but I guess this now benefits the chain in a different way.

Code:
XMR: 44GBHzv6ZyQdJkjqZje6KLZ3xSyN1hBSFAnLP6EAqJtCRVzMzZmeXTC2AHKDS9aEDTRKmo6a6o9r9j86pYfhCWDkKjbtcns
1714686749
Hero Member
*
Offline Offline

Posts: 1714686749

View Profile Personal Message (Offline)

Ignore
1714686749
Reply with quote  #2

1714686749
Report to moderator
1714686749
Hero Member
*
Offline Offline

Posts: 1714686749

View Profile Personal Message (Offline)

Ignore
1714686749
Reply with quote  #2

1714686749
Report to moderator
You get merit points when someone likes your post enough to give you some. And for every 2 merit points you receive, you can send 1 merit point to someone else!
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1714686749
Hero Member
*
Offline Offline

Posts: 1714686749

View Profile Personal Message (Offline)

Ignore
1714686749
Reply with quote  #2

1714686749
Report to moderator
1714686749
Hero Member
*
Offline Offline

Posts: 1714686749

View Profile Personal Message (Offline)

Ignore
1714686749
Reply with quote  #2

1714686749
Report to moderator
1714686749
Hero Member
*
Offline Offline

Posts: 1714686749

View Profile Personal Message (Offline)

Ignore
1714686749
Reply with quote  #2

1714686749
Report to moderator
David Rabahy
Hero Member
*****
Offline Offline

Activity: 709
Merit: 501



View Profile
December 22, 2013, 04:07:08 PM
 #202

So this is more of a miners issue right?  How are orphan block rewards handled now?  What I mean is if I solve a block and get the reward and go gamble it at satoshi dice immediately does this "attack" somehow nullify that block reward afterwards and basically I succeeded at a double spend?  Or the block never hits the blockchain and the "attack" is designed for me to waste my hashing power?
As I understand it, the block reward cannot be spent right away.  There have to be a certain number of blocks built upon it, 6?, before it can be spent.
kjj
Legendary
*
Offline Offline

Activity: 1302
Merit: 1024



View Profile
December 24, 2013, 06:08:33 AM
 #203

As I understand it, the block reward cannot be spent right away.  There have to be a certain number of blocks built upon it, 6?, before it can be spent.

100 by protocol.  120 by convention.

17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8
I routinely ignore posters with paid advertising in their sigs.  You should too.
johoe
Full Member
***
Offline Offline

Activity: 217
Merit: 238


View Profile
July 05, 2015, 06:34:37 AM
 #204

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?

Doesn't work.  They need double the hashing power.  If they have that, the selfish mining strategy would work much better with one chain.    Basically, the subpools would attack each other.

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?

Holding one block for some period is not good for a miner.  Selfish miners lose some blocks by doing this.   What makes selfish mining profitable is that as soon as they get two blocks ahead they will always win and can wait until the remaining network catches up to kill all the blocks that the honest miners produced.

A selfish mining attack is clearly visible.  You get forks that are several blocks long.  Bitcoin users can no longer trust confirmed transactions. A miner with enough hashing power to make such an attack should hopefully realize that the damage to Bitcoin and the resulting price drop will make him earn less and make his huge investment in mining hardware almost worthless.  Even if they just rented the equipment and would try to monetize their profit fast, it wouldn't work.  They only profit after two weeks when the difficulty is adjusted.  Before that, they would only lose a lot.

Donations to 1CF62UFWXiKqFUmgQMUby9DpEW5LXjypU3
dbeberman
Newbie
*
Offline Offline

Activity: 3
Merit: 0


View Profile
July 06, 2015, 05:30:08 PM
 #205

Thanks for the response.
Clears it up very well.

Cheers
Skybuck
Full Member
***
Offline Offline

Activity: 384
Merit: 110


View Profile
June 20, 2018, 05:18:22 AM
Last edit: June 20, 2018, 06:36:36 AM by Skybuck
 #206

Fun to bring this thread back alive !

The story continues with a new paper:

https://webusers.imj-prg.fr/~ricardo.perez-marco/publications/articles/OnSelfishMining20.pdf

This one examines the profiteability of selfish-mining and seems to come to the conclusion that the difficulty calculation is a bit broken and could be fixed Smiley

Haven't read the paper (yet) but did read this where I found it:

https://btcmanager.com/researchers-propose-a-solution-for-selfish-mining-attacks/

Read it... somewhat interesting.

It uses Poisson Process to model it:

http://www.randomservices.org/random/poisson/index.html

https://www.probabilitycourse.com/chapter11/11_1_2_basic_concepts_of_the_poisson_process.php

(Haven't seen this in a while ! Smiley ^ Statistics ^ Smiley)

And something I have not seen before or forgot about Smiley

Doob’s theorem

In short this paper describes what I already suspected long ago... selfish-mining becomes profiteable after a difficulty adjustment.... which is pretty logical, since some hashing power is kept secret Wink so difficulity is a bit lower... but how it exactly works... well you'll have to read and understand the paper for that... amazing though that apperently now there is some proof for this... there was some doubt though Wink

Another topic was trying to dominate blockchain with 33% hash power or something, but I don't think that was related to these documents ? Can't remember clearly (thought it was though) and maybe it is Wink Smiley

Ok read that reddit link on page 1 from this thread... it was indeed about this 33% attack Wink Smiley funny stuff ! =D
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!