Bitcoin Forum
May 13, 2024, 05:57:29 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 [3]  All
  Print  
Author Topic: Nothing at stake in proof of stake  (Read 2934 times)
alkan
Full Member
***
Offline Offline

Activity: 149
Merit: 103


View Profile
January 10, 2017, 08:57:27 PM
 #41

It is usually based on difficulty. Not a first seen basis. It does I suppose have an element of first seen, in that you can only orphan so many blocks.. usually 6 or 12 at a time.

Of course, the primary rule is usually based difficulty or chain length. Afaik, some coins do use "first seen" as a secondary rule to select between chains that have the same difficulty/length.  

If you are within the same modifier interval, then it is actually extremely likely that you will get the same stake kernel on both chains. Why wouldn't you?
The modifier interval is a method applied by some PoS coins in order to protect against N@S attacks. Naive PoS schemes in which the next block's hash target is derived from the previous block, are susceptible for this kind of attack. At least this is how I understand Vitalik's blog post:

Quote
The issue is this: suppose that you have 1% stake, and thus every block there is a 1% chance that you will be able to produce (hereinafter, “sign”) it. Now, suppose there is a fork between chain A and chain B, with chain A being the “correct” chain. The “honest” strategy is to try to generate blocks just on A, getting an expected 0.01 A-coins per block. An alternative strategy, however, is to try to generate blocks on both A and B, and if you find a block on both at the same time then discarding B. The payout per block is one A-coin if you get lucky on A (0.99% chance), one B-coin if you get lucky on B (0.99% chance) and one A-coin, but no B-coins, if you get lucky on both; hence, the expected payout is 0.01 A-coins plus 0.0099 B-coins if you double-vote. If the stakeholders that need to sign a particular block are decided in advance, however (ie. specifically, decided before a fork starts), then there is no possibility of having the opportunity to vote on A but not B; you either have the opportunity on both or neither. Hence, the “dishonest” strategy simply collapses into being the same thing as the “honest” strategy.

This only works if the coin has never had any checkpoints added to it. And even if it hasn't had checkpoints added, then it would have to be a coin that uses coin age, which a lot of the modern PoS clones don't do.

Really all you have to do is add a checkpoint after the coins have had a decent distribution, and then this argument #2 is pretty much void.
I agree, checkpoints (whether centralized or decentralized) can offer a solution against this kind of attack. My post was based on the naive implementation of a PoS coin with no special protective measures against N@S.
"I'm sure that in 20 years there will either be very large transaction volume or no volume." -- Satoshi
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1715623049
Hero Member
*
Offline Offline

Posts: 1715623049

View Profile Personal Message (Offline)

Ignore
1715623049
Reply with quote  #2

1715623049
Report to moderator
1715623049
Hero Member
*
Offline Offline

Posts: 1715623049

View Profile Personal Message (Offline)

Ignore
1715623049
Reply with quote  #2

1715623049
Report to moderator
presstab
Legendary
*
Offline Offline

Activity: 1330
Merit: 1000


Blockchain Developer


View Profile
January 10, 2017, 09:33:38 PM
 #42

If you are within the same modifier interval, then it is actually extremely likely that you will get the same stake kernel on both chains. Why wouldn't you?
The modifier interval is a method applied by some PoS coins in order to protect against N@S attacks. Naive PoS schemes in which the next block's hash target is derived from the previous block, are susceptible for this kind of attack. At least this is how I understand Vitalik's blog post:

Quote
The issue is this: suppose that you have 1% stake, and thus every block there is a 1% chance that you will be able to produce (hereinafter, “sign”) it. Now, suppose there is a fork between chain A and chain B, with chain A being the “correct” chain. The “honest” strategy is to try to generate blocks just on A, getting an expected 0.01 A-coins per block. An alternative strategy, however, is to try to generate blocks on both A and B, and if you find a block on both at the same time then discarding B. The payout per block is one A-coin if you get lucky on A (0.99% chance), one B-coin if you get lucky on B (0.99% chance) and one A-coin, but no B-coins, if you get lucky on both; hence, the expected payout is 0.01 A-coins plus 0.0099 B-coins if you double-vote. If the stakeholders that need to sign a particular block are decided in advance, however (ie. specifically, decided before a fork starts), then there is no possibility of having the opportunity to vote on A but not B; you either have the opportunity on both or neither. Hence, the “dishonest” strategy simply collapses into being the same thing as the “honest” strategy.

I guess what I am saying, is that if there are two chains, why would you not publish the same stake to both chains? If the split happened before the modifier interval has changed (which is the only thing that would alter your utxo hashed kernel value from one chain to the other) then you should have almost identical ability to publish to both chains, assuming that difficulty is relatively similar between the two. You can publish to both chains without modifying a client either, simply all you would need to do is run two nodes, one on each chain.

Projects I Contribute To: libzerocoin | Veil | PIVX | HyperStake | Crown | SaluS
Pages: « 1 2 [3]  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!