New version of the whitepaper is out. Download from the front page.
Changes:
- New consensus-model PoS system added, old PoS system removed
- Section on Coloured Coins added
- Section on lightweight client added
- Lots of typos fixed
I have not had a chance to read over it yet and fixed typos in the last couple of sections, so forgive me if you find a bunch (they are probably present).
My brain is toast from working on this for almost 10 hours straight, so I'm going to go relax.
BILLIONS OF PEOPLE MESSAGING ME VIA PM -- I HAVE NOT HAD TIME TO REPLY TO MESSAGES BUT WILL GET BACK TO YOU ASAP. THANKS.
Hello, had to stop posting in these forums to ration my time and brainpower. However, I'm impressed and excited by your paper. I'm believe you can accomplish something here.
COMMENTS:
The ticketing system seems basically solid. I like it. But ...
1) Let's Review Yay/Nay voting?
If I vote Nay and the block is accepted, then my stake gets used and the reward is confiscated. If I vote Yea and the block is accepted, I get a stake reward.
If I vote Nay and the block is rejected, then my stake gets used and the reward is confiscated. If I vote Yea and the block is rejected, then my stake gets used and the reward is confiscated.
Voting Yay is the dominant strategy. Therefore, why have Yay/Nay voting at all? Why not just require unanimous Yay's or reject the block?
Fault tolerance (it's not guaranteed that you will find exactly the same hash) and because if you reject blocks with only one Nay vote you may not invalidate any block you'd like to with only 20%. 10% stake means half the blocks, etc. You also don't want to invalidate blocks based one one or two MIA signatories, as with 3 signatories the chain still works fine.
You also add a very easy attack vector by unanimous voting requirement, as you only need to DDoS one node per block to control the chain.
This brings up another important point, though. As described in the paper the system of ledger hashes only works well if transaction volume is relatively small. Ideally, you need a system which records the time of all incoming transactions then compares it to the list of transactions in the block, and decides what the probability is that the PoW miner saw precisely those transactions. For instance, if it saw only one new stake transactions but you saw five, and you saw these all five seconds from each other right after the previous block had been solved, the probability that the PoW miner is manipulating the chain by excluding PoS submission transactions is very high.
2) Have you have specified what happens when winning ticket holder(s) abstain?
Does this mean no block is mined? That's what should happen I think.
Unredeemed tickets are ignored. If 3/5 ticket holders vote Yea on the block, the block is considered secure. If 2/5 ticket holders vote Yea on the block and the others abstain, the block is kept but should not be considered a hard confirmation. Tickets expire after 2^16 blocks unless the ticket is never called upon by the lottery, in which case a brief extension is allowed until the ticket comes up. However, if the ticket comes up in the lottery and the stakeholder is MIA, the ticket expires after 2^16 blocks.
3) Ticket extensions
You also do not want afk tickets to accumulate, so the extension thing worries me a bit. Accumulation of afk tickets eventually converges to a breakdown of the blockchain. To avoid this you need to purge afk ticket holders from the voting rolls. Perhaps you plan to have predictable auditing of afk ticket holders via the extension process? That's a good start, but random auditing provides stronger incentives and saves blockchain space. My suggestion is to add one optional signature to each valid block. If you provide it, then the subsequent block gets a PoW difficulty subsidy. If you fail to provide it, the block is still valid, but the afk ticket gets invalidated. (The difficulty subsidy provides an incentive for PoW miners to recognize his signature if it appears.)
Well, it's equally easy to destroy unclaimed tickets right after the lottery block if you wanted to, for instance if you thought people were hoarding them for a malicious attack. I guess, really this is the easiest way to do so and may add it into the next draft.
4) Inflation voting for the distant future
PoW voting does not have a precedent and worries me. Why wouldn't PoW voters continuously vote to up the PoW rewards, redistributing all the wealth to themselves. This could be a huge problem.
PoS voting has a precedent in corporations and I am comfortable with it. PoS voters benefit by voting down PoW issuance below the optimal level (market cap maximizing). You are not letting them mess with the PoW/PoS issuance ratio much, so they will do this by voting against inflation. This a very minor issue. PoS voters wouldn't do anything that threatens the currency. Therefore, I think PoS voting will work well even if the incentives are not quite perfect.
If you mix the two voting types, let PoS voters have a majority of votes (say two-thirds or more).
This is the most controversial aspect of the blockchain and will probably require more input from economists.
I think the assumption that PoS workers wouldn't do anything to threaten the currency is naive; for instance, if a 51% PoS minter doesn't like a pool on the network, they can simply invalidate all the blocks it solves on the network and destroy it without massively affecting the function of the blockchain.
I need to look over that paper some more before I can give some more feedback as to the system it proposes. The method I proposed should be very fast for both the accession of values and the manipulation of values for the lightweight client.
