I spoke to him on skype. He is a very nice person
I will invite him in for sure.

Thanks Evo, yeah this is the first discussion I've seen about Qointum anywhere =)

I would be interested to know more about QDPOS in relation to our DPOS.

I just read up on what the fine folk of BitShares have been doing recently, and there are some significant differences.

Take PoS and the goal of earning stake interest offline and then add two stake deposits: one for registering stake to any public address, and a larger one for registering to become a block producer at a public address. You end up with a system that resembles BitShares' DPoS. That's why this algorithm name contains "DPoS", it involves delegating the task of producing blocks to others so stake interest can be earned offline. I believe Nxt has something similar as well, they call it "Account Leasing".

I called it "Queued DPoS" to emphasize the idea that delegates are known ahead of time, instead of PoS which is fully random, and DPoS could also be fully random. BitShares has a sort of queue as well but the mechanism is entirely different. You want a balance -- too much determinism could allow delegates to collude to attack on consecutive blocks, too much randomness and you forfeit the ability for consecutive delegates to come together as a quorum for network optimization. Qointum uses blockchain entropy to randomly schedule the next X minutes of delegates, and scheduled positions don't change so the network can be optimized.

I'll head off the main argument here: yes, human voting through DPoS is an essential foundation to mitigate attacks, but it's a slow process and not entirely preventative. In order to scale across the web to thousands of smaller chains you need to automate your system as much as possible by providing game-theoretic incentives to prevent attacks.

In Qointum the stakeholder votes for delegates are (un)registration blocks, as opposed to transactions. Because they're blocks, no one has authority over your vote, you can boot up a dead branch or spin off a branch from any block and become the only delegate (provided that enough time has passed so that other delegates have been deemed inactive and forcefully unregistered on that branch). There are also wait times for (un)registration so entropy can take hold and prevent queue manipulation. Unregistration also carries a qoin penalty on the deposit as the blocks can't be discarded in blockchain compression.

QDPoS with its block registration system goes hand-in-hand with our block-header-only "Maximally Vetted Delegate Chain" consensus algorithm. By having a consensus algorithm that operates well with headers only you open yourself up to multi-chain capability (Qointum's Entangled Chains).

QDPOS looks to have a very large amount of possible delegates, DPOS has 101 delegates.

In Qointum stake assigned to a delegate is held as a deposit. Because it's a deposit we can apply all sorts of game-theoretic incentives by automatically rewarding or penalizing both stakeholders (who may vote maliciously) and delegates. For example, we can penalize double block creation to minimize branching, without relying on slower human intervention (voting). Also, we can penalize short ephemeral registrations by stakeholders to minimize block overhead. The number of delegates is then limited by the required deposit. I expect only a small percentage of qoins, maybe 10%, to be tied up in a registration deposit earning interest, as qoins must be kept liquid for storage/transaction fees and economic activity. So I'm targeting only ~200 delegates at any given time even though the upper bound is 2K delegates with 100% of qoins registered. This is for the main chain, every chain can specify its own QDPoS parameters.

If everybody can be a delegate in QDPOS as long as they have the minimum stake requirements won't this make it a lot cheaper to disrupt the network compared to DPOS?

In a manner similar to BitShares, smaller players are weeded out by tuning the minimum stake requirements so that very few entities without external votes could be reasonably expected to become delegates. You can find a safe initial setting but there's no perfect setting -- as a chain matures and its asset becomes distributed into more hands you can afford to have less of it tied up in registration deposits. This is where decentralized governance comes in with each chain's "founding qointract" -- smart contract law that lets stakeholders vote to tune the QDPoS parameters dynamically.

How does the system scale? How many transactions a second are possible?

That is outlined in the Design Document. Due to the large quantum-secure signatures and Python transaction scripting, I have a realistic target of about 5 transactions per second max (40 KB/sec, 200ms per transaction). That should be sufficient for now as even Bitcoin is only pushing 2 or 3 per second currently. There's a Python LLVM / JIT implementation by Dropbox called "Pyston" under development, it could really help us out in the future.