Quote from: monsterer2 on February 22, 2018, 09:21:57 AM

Quote from: Blinknet on February 21, 2018, 08:41:35 PM

Sorry, but what you're describing doesn't really apply, since the locker responsible for signing transaction is the same entity, and won't accidentally sign a transaction conflicting with another transaction he signed anymore than someone can crack a private key from the public key by accident. The case when two conflicting transactions take place in consecutive rounds is more complicate, and there's an analysis for it in the paper, please read it before trying to design attacks.

i could find no such analysis. Please can you direct me to it?

"The protocol assumes the nodes are not necessarily up to date with the state of all the
accounts, but they should be when it comes to those accounts for which they are
supposed to act as lockers. To achieve consistency, the nodes that are lockers for the same
account in consecutive rounds will communicate with each other. The old locker will
pass on the state of the account to the new locker.
Should the network have a low trust in lockers, at the expense of a small increase in
bandwidth and CPU usage, transactions can also be signed by the lockers of the current
round and also by the lockers of the previous round. This would ensure that no
transactions could ever be invalidated when lockers from consecutive rounds are not in
sync"

This part could probably be better emphasized.

Quote from: Virus ICO on February 22, 2018, 10:26:14 AM

good luck to you, I hope this project will be on top! By the way the name is super!

Thanks for that, glad you like the name.