Hello Stephan
I conceived a method for how a digital PoS currency could possibly have a 10 second average transaction time, if it had a block time of 1 minute. I wrote about this on r/BlackCoin before you published your whitepaper. Adam Kryskow of the BlackCoin Foundation has since told me that my method is essentially the same is your. From what I understand of yours, that is the case. However, I envisioned a much simpler and mush less powerful implementation than your sub-second proposal.
Right. My main theme is to implement Nick Szabo's idea about agents with non-forgable logs, what an academic paper I cite calls tamper-evident logs. The proof-of-stake is used mainly to deter Sybil attacks, as there is only a certain amount of stake in the post-fork bitcoins that will be thus qualified for dividends.
The single nomadic mint is permitted by the notion of cooperating agents that do not trust the mint, but rather allow it to timestamp the incoming new transactions from clients. The peers verify the mint operations by replaying the operations themselves as they each assemble the blockchain replicant locally in canonical timestamp order. The single mint in turn permits a non-forking blockchain and definite transaction acknowledgment back to the client with sub second response time.
I think I can follow what you are saying there, but I am not sure of what exactly you are calling the nomadic mint, the cooperating agent, the client, and peers.
I have enough programming experience and knowledge of data structures that I know that the system that I came up with can work. Furthermore, no one else in the BlackCoin Foundation that I discussed the method with found a problem with it.
My only question at this time concerns the point at which a transaction is initially confirmed in your system. You do no mention waiting until 51% of the nodes with stake at the start of the block have determined that it can be in the block being assembled.
Are you saying that the simple nomadic mint is a part of your program that assembles the master ledger in timestamp order? For it to work this way, it would have to have the sole responsibility to verify that the transaction is legitimate and thus verify it to the network. Thus, it has the responsibility to stop any attempted double spends when presented with the second or subsequent ones.
IMO the two methods accomplish the same thing, but are slightly different in execution
The method that I came up with does not require a centralized mint. I am not trying to argue that one is better than the other, because I have not thought about it. I have no desire to try to start programing either one.