consequences of using proof of stake.

Previous topic - Next topic


I agree to: money spend into mining (MSIM) = reward for miners (rfm).
This holds true for POW and POS.

However, for POW it is important that the MSIM is at least a decent fraction of the total coin market cap. For POS this is not necessary. Instead a high coin market cap helps to secure the consensus/network.

Might it be that you are assuming a POS implementation where you have to "burn" money to get votes? Note that this is not necessary - proof of control is enough.


Quote from: psztorc on November 29, 2014, 10:28:30 PM
I would be happy to attend the presentation this Tuesday.

Nice, this will become an interesting discussion. Zack, can you possibly join as well?


I would love to attend a meeting about proof of stake.
Here is my unfinished implementation:

I am in California, have a plane ticket to Texas on the 2nd.
I can't afford to get myself to New York, or back to Texas after.
Neither do I have anywhere to stay in New York.

NXT has lasted so long. Maybe it is easier to put truthcoin onto an existing POS instead of writing a new one?
They have a pretty big bounty to find bugs, and no one is finding any.
I don't program java yet, so I am not sure how feasible this plan is.
Maybe the Jython compiler would let us use the same code from the truthcoin implementation.

I would be sad if the majority of the profit from truthcoin went to NXT people instead of people like psztorc who actually worked on truthcoin.


What a pity.
I could have helped out with a place to stay.

Have you somewhere written down the conceptual details of slasher?
From Vitaliks latest post: - what of the option discussed here do you use? Or do you use different one?


this is the only writing about slasher I did:

I use a lot of Vitalik's ideas.
From this essay:
1) his algorithm for selecting signers from the coin-holders, with a small adjustment.
2) the punitive transaction type.

from the essay you linked I took:
1) weak subjectivity (I haven't implemented this yet)

from here
1) the low influence random number generator

I use something similar to Daniel Larimer's transactions as proof of stake. Every transaction must reference the hash of one of the 10 most recent blocks.

from this essay:
1) creating a new block should cost a large fee. A negative block reward. (The only part of slasher that I personally invented.)
2) I use something similar to his idea (7), quote: "If there is an insufficient number of signers to sign at a particular block height h, a miner can produce a block with height h+1 directly on top of the block with height h-1 by mining at an 8x higher difficulty (to incentivize this, but still make it less attractive than trying to create a normal block, there is a 6x higher reward). "
But instead of charging POW, I charge a fee.

from here
1) I took the idea to use Patricia trees so that users can efficiently prove how much money they had at any point in history.

An idea that Vlad Zamfir explained to me:
The total amount of money spent in a block must be less than or equal to the total amount of safety deposits left by the people who signed on that block. That way, any double-spend attack ends up costing more money than can be stolen. All the safety deposits are deleted.

My slasher will have 4 transaction types:
1) spend money
2) sign on a block to help make the next valid block.
3) punish someone who signed on contradictory chains.
4) redeem your reward for having signed 3000 blocks ago.

It will NOT have a forth-like scripting language like bitcoin.