Let's stop the speculation and analyze the white paper instead
could be interesting; much better than Visacoin's white paper though.
I am going to skip the "blah blah" part and go to the meat. I think the block generation logic is flawed but I can't really get through this English to be sure I can understand what the author means. It is not really POW or POS. One thing though this kind of writing does not belong to someone frequently writes scientific papers in English. So it is better to wait to the Q&A part to see if the authors know what he is doing.
-----------------------------------------------------
3.7 Block generation and chain details A new block is built every 10 minutes. This is not an estimated value – it is a fixed setting (does not
rely on dynamic difficulty instead uses a timer and eXo network time). Since miners do not build the
chain the calculation of the very next block is not hard to find for any CPU in the range of some
milliseconds. This is crucial – otherwise the chain would not go on. To prevent someone building up
his own chain by just adding some hundreds blocks and claiming in the network that he has got the
largest chain (bitcoin for instance assumes that the largest chain is the most valid one because
adding new valid elements is extremely difficult) – eXocoin cannot rely on the largest chain. Like a
shared network time is found on the net by a majority (including trustlevel) it is the same algorithm
for the block chain.
Not only will the length of the block chain be calculated. If they have agreed on the correct length
they have to check the very latest block if they are identical (hash of serialized block data including all
transactions and so on). To face latency dependent inconsistencies (e.g. one node appends a
transaction right before a block end and another node would add it in the next block):
- Some seconds (e.g. 10) before a block is about to end all nodes will stop sending new
transactions. They will delay those transactions to the next block.
- Nodes will not stop appending transactions at any time
- If an attacker circumvents the “stop sending” barrier it would depend on luck if it gets
processed (=included in block) at all. An attacker, however, does not have any advantages in
doing so 12
eXocoin includes transaction fees. Transaction fees are essential to prevent transaction flooding. The
fees (sum) are stored together with the transactions in a block.
Since eXocoin do not want to be associated with terms like “mining” and “forging” for the PoS part of
the system (of course we have a PoW part..) there is no block generation node that has to be chosen
by random or something. For us it is a cleaner and more intuitive way (especially for non-IT users
since it is similar to bank accounts) to sum up all fees of the last month. The nodes generate
themselves a special monthly interest transaction that has to be confirmed by the network. The
interest depends on their balance on each second of the month (like banks calculate things). To
prevent a massive transaction flooding caused by this system the nodes themselves will choose a
random amount to wait for this action (say anywhere between the first and fifth day of the next
month). This way we can ensure that every node will get a monthly paid interest (note: this part is as
of now only conceptual. It is not integrated yet)
3.9 Nodes vs Accounts While talking about nodes in the last (and next) chapters we are aware of the fact that we cannot
rely on nodes without any further proof. Let us explain it a bit more (conceptional state as for now):
In theory one attacker could more or less easily spawn many instances of the program (he could
circumvent our protection that you can launch the client only once) each with a different port so that
all of them are considered as nodes in the network. At least at the start of eXocoin he can gain a
majority (even with trustlevels considered) and can manipulate everything he wants. He could use
bot-networks as well. We are considering to only allow nodes to participate in the network as
“active” node (who answers GET_TIME requests and similar) if they have a certain minimal amount
of EXO in their wallets. A second (maybe additional) option would be a lower trustlevel for a new
node. They would have to proof that they cooperate with the network (correct block/time no spam
etc) and would gain the default trustlevel afterwards (could be decreased again if something
happens).
More information can be expected within whitepaper version 1.1 or 1.2.
