Topic: Re: Proof of stake instead of proof of work - page 6. (Read 6968 times)

Who or what gets to decide the checkpoint block?
Either you have to have a consensus (back to the
distributed consensus problem), or the protocol
must handle it.  But if the protocol handles it,
you still have the isolated node attack problem.

The difference with the genesis block is that
its not a moving target.  You establish it
as consensus when the reference client is
released.  .(right?)
 

Bitcoin could theoretically work without a hard coded genesis block (although alt-coins based directly on bitcoin would have to have to have genesis blocks because total cumulative difficulty would be lower than bitcoin). Bitcoin's security relies on the fact that it has more hashing power than any other coin based on SHA256d. The full game theory implications of how bitcoin could be attacked by enticing miners to mine on a different chain while shorting/double spending bitcoin has not been extensively explored.

Achieving consensus with bitcoin is dependent on a number of things, knowledge of the protocol, the genesis block etc. but the SPV (simple payment verification) assumption is that one can simply rely on a short chain of blocks with the greatest difficulty. This requires no knowledge of the genesis block or the protocol rules, the only knowledge required is the type of hashing algorithm. If a transaction is buried within the highest difficulty chain then it is highly likely to be valid.

Unfortunately these assumptions do not carry over to PoS coins (forgetting all the other PoS problems) (or even most alt-coins which do not have the greatest difficulty with their type of hashing algorithm). This means that to verify a transaction, the security relies on a longer part of the chain back to the most recent checkpoint in the code and the mechanism of delivering the checkpoints.

The SPV assumption is incredibly important for making clients which will work on low power, low storage or low memory devices without reliance on some central server. Try developing a scalable decentralised PoS wallet for a phone and you will understand why.

Maybe, you can elaborate bit more.


Do you refer to promoting the new release? I remember Bitcoin having also several releases: https://bitcoin.org/en/version-history
I do not see what the problem therein is. Updates might break something or they might cause a change in the protocol at which a hard fork will occur.

That need to be brought to people's attention and then they need to decide for themselves what to do, reviewing the code, verify checkpoints. etc. etc.

Speaking of the 'beginning': just a definition.

There is no need for a dedicated 'beginning'. You can start with any block sufficiently old enough. It makes no difference.

How do you know when setting up a brand-new node if the hard-coded genesis block is the correct one WITHOUT looking it up?


1) The only way I see is that you remember (at least) the hash of the genesis block of the Bitcoin you refer to AND make sure that the software does assume zero accounts at this point.

2) If your node software uses another checkpoint, you have to make sure again that the block is the correct one (by verifying its hash) AND make sure that the software does assume the correct balances for all accounts in existence for that Bitcoin you refer to.


Speaking of computing: this can be done by the very same subroutine:

def start_from_checkpoint(checkpoint_block, balances)

for 1) start_from_checkpoint(genesis_block, [])
for 2) start_from_checkpoint(checkpoint_block5, [...............................])

There is simply no difference, not from an abstract point of view and not from an computing point of view. All differences are made up AFAICT. Maybe, you could prove me otherwise.

And
https://nxtforum.org/general/how-does-nxt-fix-the-nothing-at-stake-problem/msg22968/#msg22968

@ ChuckOne: is this what you mean by "solved by verification, code review etc. etc." when the network can't determine which chain is "best"?

[The quote below is from the Nxt thread (a proof-of-stake coin) and Cryptsy is a foo-coin exchange.]

The genesis block is part of bitcoin.  It is not a checkpoint according to the generally-accepted definition of the word "checkpoint" as applied to computing.  A checkpoint is a point beyond the beginning.

If you make up your own definitions for words, however, you can argue anything you like.  

The thing is, the longest chain is the ONLY proven way to create conensus. 
You can "consult your friends" till the cows come home, and they might
never agree.

Please, do not mix up things. As I told you, we need to separate issues first.

Code review is necessary to ensure, you have the 'right' checkpoints (including the genesis block - for those who cannot imagine the genesis block hard-coded in the node software being a checkpoint), the right consensus rule that everybody has, etc. etc.

In particular the checkpoints are the ones that determine which chains will definitely being sorted out and which ones could win in the future.


See above. Checkpoints are a valid way to do so. A node provider could even introduce custom checkpoints at will.



There is nothing wrong with this rule.

I think you agree that the coins on a fork are worthless to the real world. There can be only one legit chain. So, the real world decides that in the end. The real world are people, exchanges, friends and so on. If my node has two valid chains, I will consult them to find out which one it the right one.

What is wrong with that consensus rule? After that, I am on the same "fork" as the rest of the publicly available world is. I am on the same "fork" where the rest of the publicly available world draws its value from the coin.

If I create a Bitcoin clone, name it Bitcoin and the only difference is the genesis block, it is Bitcoin.

Even, if I would pump billions of GHs in that Bitcoin, no other Bitcoin node would accept my chain (even if it is longer than the first one).

Why, because the default Bitcoin software checks the genesis block. I would call this a checkpoint no matter what Wikipedia says and what unintuitive definition of checkpoint they use. I see no reason to exclude a fixed beginning from being a checkpoint from an abstract point of view.

problem is that theologists can't come to a consensus on whether God is centralized or distributed 

I have not seen anything which shows how deterministic vs random selection makes it more difficult for an attacker to produce an reorg (I assume you mean reorganization not fork).  It is an interesting idea and it does ensure that a node either maliciously or inadvertently doesn't creates a stake and then fail to produce blocks (this can cause oscillations in difficulty an average time between blocks).  As I understand it with deterministic minting, when a node should create the next block but doesn't the value of its stake is reduced to zero.  An attacker is however going to produce blocks and deterministic or random if an attacker has 51% of the stake it will produce the longest chain in the long run.


I don't believe so.  I have not seen any provable decentralized timestamps which work in a network of untrusted peers without using a proof of something.  The security of this model requires the attacker to have less than a majority of the "something".  That isn't to say they are impossible, but it would require some significant out of the box thinking on the order of Satoshi's blockchain solution to transaction ordering.  It is also very likely they would have a different security assumption/limitation.  Baring direct well articulated evidence of such a system, when I read a proposal and the security model assumes that timestamps are valid (or can be validated), so far to date it has been a good indicator that the author lacks the basic knowledge of the problem.  The author might as well build a security model which uses God as a trusted oracle. Imagine a forge proof system with no work, cryptography, or potential flaws.  You get instant verification anywhere in the universe by just asking God if the transaction is valid.

In computing, the definition of a checkpoint is a point beyond the beginning.  For example, "Checkpoint restart, a method for restarting a long software process at a point beyond its beginning."

If you create an entirely new blockchain built from a different genesis block, then it's just an alt-coin.  It's not even a fork.  

All these discussions will end when a smart person creates a StakeUndo pool like the BitUndo service. Old stake owners will contribute their stake to create a longer chain to claim back their stake.  And when StakeUndo accumulates  stake more than current minting stake it will be be obvious to everyone.

Old stake owners will participate because they want to claim their stake back. It is their ownership after all and they want it back!!! Very profitable as well.

On the other hand for PoW old stake owners it will be unprofitable to spend more money to claim their stake back by creating a longest chain.

That is what made bitcoin popular in the first place. PoS solutions are a step backward proposing solutions similar to those existing before bitcoin.

Those are vague nonsense answers. 
Code review?  What CODE will allow you to verify which of two chains is the best if not using criteria that longest chain is best chain.
Verification?  What can you verify to determine which chain is the best if not using the criteria that the longest chain is the best chain.
etc?

Give me specifics.  You are a brand new node bootstraping today you receive from peers two equally valid yet different chains A & B.  The code in the client can be assumed to be without error.   Chain A is longer, thus by the Bitcoin consensus rules a Bitcoin node would report that Chain A is the best chain.  You seem to believe that nodes could reach a consensus that B the shorter chain is "best".  How exactly would a new node reach that conclusion.  Without specifics that is simply imagining the problem away.  Some magical as of yet code will allow the client to pick Chain B because it is the better chain despite being shorter is not a real answer.  What exactly could the new node do to determine that B is the better chain over A?

yeah thx DT.  We must be driving you crazy.
But we are learning a lot.  I wonder how
you learned so much about cryptocurrencies!

Not sure if its worth answering these questions
I posted earlier but here they are again.

Thank you very much for you patience so far.



This makes no sense. The genesis node IS a checkpoint.

How do you verify a checkpoint? Either you do not (so you trust the checkpoint creator) or you verify it in some way.

So, new nodes have to verify the last block some way or another by e.g. asking their neighbors, watching TV, asking their local government, friends etc. etc.

I think we still mix up two different scenarios. This question is also related to NEW NODES:
This is solved by verification, code review etc. etc.


Our merchant runs an EXISTING NODE here he should wait the number of blocks that satisfy his need of security as the blockchain approach leads to eventual consistency.

The genesis node is hardcoded in the client.

No.



Non deterministic behavior of nodes is bad.  If some nodes switch to the longest chain and some stay with the shortest chain then the network is permanently forked.  That is something to be avoided at all cost. While such behavior may make double spends harder, it makes the money you are trying to protect from double spends worthless.  Money can't have value if there isn't a single shared view over who has the money. A permanent fork in the network is a lack of consensus, a disagreement over "who has the money" and it is a worse outcome than the double spend you are trying to avoid.

That line of thinking also assumes that all nodes are online.  They aren't.  The current longest chain is chain A.  Merchant is paid in tx on chain A.   Attacker builds a chain B which double spends merchant and chain B is longer.  Now lets assume all "legit" nodes disregard chain B because it has double spends.  That opens up all kinds of timing and propagation attacks but to keep it simple lets pretend they don't exist.  Now a new node connects to the network and is receives chains A & B.  Both are valid chains with valid transactions.  There are differences between the two chains but neither one is invalid by the rules the node uses to validate transactions and blocks.  B is longer.  The new node would select B as the "best" chain.  Oops the network is now split.  Now imagine the attacker pays this new node using outputs only valid on Chain B.  You now have a permanent split which can't be resolved except with outside force AND entities on both sides of the split who will lose if the other fork is used.


I don't know what you are asking.  However for the last question it indicates a false belief that 100% of nodes receive 100% of blocks in realtime, and have 100% uptime since the genesis block.  That is the only way they can know in all cases which chain is the "best" even if it isn't the longest.  No such system for consensus like that exists.  Sure if the Bitcoin network consisted only of nodes who have been and always will be online and learned of blocks in realtime then forming a consensus would be easy.  However most of the time nodes haven't been online with 100% uptime since the genesis block.  When there are two competing chains they don't know which one came first or which one has the double spend and which one has the "original" spend.  The only thing the node can independently verify is that the two chains are valid but different and one is longer.

Given two chains A & B which are different but equally valid without relying on a trusted third party tell me which one is the "best" chain?

Bitcoin says the longest chain is the best one.   Still this has gone beyond just PoS & PoW.  The same consensus issues remain regardless of what system is used for proof.   The proof forms the longest chain, if nodes can form a consensus on transaction ordering while ignoring the proof then why do you need proof to begin with?   I think we have come full circle.

How does a node verify the genesis block?

Is that not exactly the same as verifying an arbitrary block?


One question still bothers me:

Why should nodes discard blocks (and therefore invalides many transactions?)? Especially those nodes running by merchants that can cross-check if their due transactions are on the blockchain already.

Would it not be more intelligent to distribute the raw transactions as broad as possible? All this assumes an extremely well developed network controlled by the attacker, right?

And if so, why would this extremely well developed network controlled by the attacker be unable to send the new blockchain in time to the merchant's node? Would this not raise awareness on the side of the merchant?