Topic: Feedback needed for "stable coin" idea, especially from security experts (Read 1383 times)
March 01, 2015, 03:38:24 AM
I've only skimmed it but it sounds like just another disitrbuted consensus model. Ripple calls them validators, orthers call them Masternodes, you call them time helpers.
February 28, 2015, 03:06:14 PM
Hmm seems pretty tight at first glance. Could potentially be a gamebreaking idea, it seems quite interesting. I'll take a closer look later when I have time and see if I have any more useful feedback. Although there are probably more qualified people around.
Good luck!
Good luck!
February 26, 2015, 09:12:29 AM
I have been thinking about how you could create a coin that is stable in terms of fiat currency for a while now and for different reasons I don't believe long term in any of those currently out there.
The whole idea fundamentally hinges on something I call "proof of trust", which is an alternative to "proof of work" and "proof of stake". In fact this idea gets rid of the need to compensate anyone with newly mined coins, thus getting rid of a cause for inflation on the system.
I have written this part for the layman as best I could:
The crypto currency I propose is similar to Bitcoin in the way it uses public key cryptography for address control and how it uses a chain of verifiable transactions to make sure what addresses, owns what tokens of value.
What is different is how the double spend problem is solved, i.e how the chronology of transactions is established. If an account with only 1 token to it sends two transactions of 1 token to different accounts, then it is essential for peers to be able to reliably create consensus of which transaction is valid and which one is not. And pragmatically, the first one received by the network should be the one that becomes accepted, because if the latter became the accepted one, peers would in effect be able to reverse previously verified transactions. The question is how to establish the order transactions were received by the network. In short, "proof of work" protocols (like Bitcoin) establishes time or chronology by relying on the time it takes for CPU consuming operations to be solved by the network. The "proof of stake" protocol relies on the idea that peers with most value on the network have less incentive to be dishonest and break the network. Both fundamentally rely on the trust of something on the network, be it the majority of CPU donated to the network being honest or the majority of sizable stakeholders being honest.
Instead of relying on either of those two methods, my scheme would use what I call “time helpers”. Any peer can start their own time helper and peers can decide for themselves what time helpers they wish to trust. What a time helper will do on request of peers is to evaluate the validity of a transaction and sign the transaction with its own private key in case it is valid. When evaluating the validity of the transaction the time helper will check that there is enough coins on the account and that the transaction is properly signed by the sender etc. Additionally in the transactions data, the sender will have included a number signifying what number in the sequence of transactions this is. Again the time helper will only verify transactions with correct sequence number.
When a transaction is signed by a time helper, it will immediately share the signed transaction on the network, to make sure it is known on the network that this transaction was made. Any peer receiving a transaction will always get the transaction verified by at least two time helpers it trusts, before it will consider the transaction completed.
This would in practice likely work much like how root certificates work in browsers. When you download any modern browser it will come with a default set of trusted “root certificates” representing the entities that ultimately make HTTPS connections possible. Any user can change what entities to trust, but most users are unaware of this or don’t bother changing it. This would presumably change fast, in case users trust was being maliciously exploited by any of these entities. This safeguard mechanism is probably enough in and of itself to discourage the majority of abuse.
There are still cases where double spend transactions are possible though:
A double spend occurs on the system when the transaction value originating from an address exceeds the value received by that address, leaving a negative balance, or when a sequence number is out of order.
Double spend transactions can become verified by time helpers in one of two ways:
1 A malicious peer sends his transaction to two or more honest time helpers simultaneously and they verify the transaction, before discovering the transaction that was sent to the other time helper.
2 A malicious time helper knowingly verifies a fraudulent transaction.
In case sequence numbers are in a correct order but a transaction verified by a time helper leaves the account with a negative balance, all transactions from the first one causing the balance to become negative and forward, are considered invalid. In this case it would be very obvious that the account holder was colluding with the time helper, but peers would not acknowledge the transaction causing the negative balance.
If on the other hand the attackers create a duplicate sequence number, things are not as simple. In case 2 above, an attacker can chose any sequence number he likes, but in case 1 he cannot.
The way other peers would interpret account balances (their own or otherwise) resulting from a set of double sequence transactions depends on how many of the transactions are verified by trusted time helpers:
• If two or more of the sequence conflict transactions are verified by trusted time helpers, those transactions are all voided and the remaining amount on the account is seen as 0.
• If only one of the sequence conflict transactions are verified by a trusted time helper, only that transaction is seen as valid. The other double sequence transactions are voided and the value of the voided transactions is destroyed.
• If there are no trusted time helpers, all transactions are voided and the transaction amount is destroyed.
These rules also apply for all transactions with higher sequence numbers than the conflicting ones.
Lets examine what happens in different double spend scenarios:
If a malicious peer sends tokens to two verified time helpers at the same time and he thereby manages to create a set of transactions with duplicate sequence numbers, his tokens would be lost. The receiver, for example a merchant, expecting one of the transactions would only have to wait a little longer to make sure no double spends has occurred with the transaction. If no double spend has occurred after a few seconds the first transaction will have propagated the network (automatically handled by the software) and the attack is no longer possible. From the attacker’s point of view, this attack besides from not working, is not very interesting, as he loses his tokens no matter what.
In the case that an honest user somehow manages to send two transactions to two different time helpers in less time than it takes them to communicate, his tokens will not be lost. The software will not allow spending more than is in the users account, so the spend will result in a positive balance and additionally, the transaction data will include different sequence numbers.
If a malicious user utilizes his untrusted time helper to craft and verify a transaction with a fake sequence number, the receiver of the other transaction in the double spend has presumably already made sure that transaction was verified by trusted time helpers, so this new untrusted double spend transaction will have no effect. (See sequence conflict with only 1 trusted transaction above).
If a malicious user somehow manages to get his time helper trusted or hacks a trusted time helper etc. he can actually carry out an attack. That is he can transfer money to another user and then destroy those tokens, even after the receiver had verified that he had received the tokens. He can do this by maliciously signing a new duplicate sequence transaction, which will result in both transactions being voided and the tokens lost. The attacker would need to spend tokens under his own control for this to work though. And again, this is a rather pointless attack, it will cost the attacker money to spend the tokens that he later wants destroy. Further the unlucky receiver that has had his received tokens voided will now have evidence that a certain time helper is malicious. He can show this to other peers and people will very quickly come start distrusting this time helper. And as the users program will always make sure every transaction is double verified on receiving transactions, the “destruction” of the tokens is reversed, when people stop trusting the certificate of the malicious time helper.
I am very interested in constructive criticism, please try and find a flaw in the scheme and let me know if you can. But I am not very interested in the whole "good luck with your shit scam coin" type of feedback. If your negative feedback doesn't include logical arguments, then please refrain from posting it. Thanks.
The whole idea fundamentally hinges on something I call "proof of trust", which is an alternative to "proof of work" and "proof of stake". In fact this idea gets rid of the need to compensate anyone with newly mined coins, thus getting rid of a cause for inflation on the system.
I have written this part for the layman as best I could:
The crypto currency I propose is similar to Bitcoin in the way it uses public key cryptography for address control and how it uses a chain of verifiable transactions to make sure what addresses, owns what tokens of value.
What is different is how the double spend problem is solved, i.e how the chronology of transactions is established. If an account with only 1 token to it sends two transactions of 1 token to different accounts, then it is essential for peers to be able to reliably create consensus of which transaction is valid and which one is not. And pragmatically, the first one received by the network should be the one that becomes accepted, because if the latter became the accepted one, peers would in effect be able to reverse previously verified transactions. The question is how to establish the order transactions were received by the network. In short, "proof of work" protocols (like Bitcoin) establishes time or chronology by relying on the time it takes for CPU consuming operations to be solved by the network. The "proof of stake" protocol relies on the idea that peers with most value on the network have less incentive to be dishonest and break the network. Both fundamentally rely on the trust of something on the network, be it the majority of CPU donated to the network being honest or the majority of sizable stakeholders being honest.
Instead of relying on either of those two methods, my scheme would use what I call “time helpers”. Any peer can start their own time helper and peers can decide for themselves what time helpers they wish to trust. What a time helper will do on request of peers is to evaluate the validity of a transaction and sign the transaction with its own private key in case it is valid. When evaluating the validity of the transaction the time helper will check that there is enough coins on the account and that the transaction is properly signed by the sender etc. Additionally in the transactions data, the sender will have included a number signifying what number in the sequence of transactions this is. Again the time helper will only verify transactions with correct sequence number.
When a transaction is signed by a time helper, it will immediately share the signed transaction on the network, to make sure it is known on the network that this transaction was made. Any peer receiving a transaction will always get the transaction verified by at least two time helpers it trusts, before it will consider the transaction completed.
This would in practice likely work much like how root certificates work in browsers. When you download any modern browser it will come with a default set of trusted “root certificates” representing the entities that ultimately make HTTPS connections possible. Any user can change what entities to trust, but most users are unaware of this or don’t bother changing it. This would presumably change fast, in case users trust was being maliciously exploited by any of these entities. This safeguard mechanism is probably enough in and of itself to discourage the majority of abuse.
There are still cases where double spend transactions are possible though:
A double spend occurs on the system when the transaction value originating from an address exceeds the value received by that address, leaving a negative balance, or when a sequence number is out of order.
Double spend transactions can become verified by time helpers in one of two ways:
1 A malicious peer sends his transaction to two or more honest time helpers simultaneously and they verify the transaction, before discovering the transaction that was sent to the other time helper.
2 A malicious time helper knowingly verifies a fraudulent transaction.
In case sequence numbers are in a correct order but a transaction verified by a time helper leaves the account with a negative balance, all transactions from the first one causing the balance to become negative and forward, are considered invalid. In this case it would be very obvious that the account holder was colluding with the time helper, but peers would not acknowledge the transaction causing the negative balance.
If on the other hand the attackers create a duplicate sequence number, things are not as simple. In case 2 above, an attacker can chose any sequence number he likes, but in case 1 he cannot.
The way other peers would interpret account balances (their own or otherwise) resulting from a set of double sequence transactions depends on how many of the transactions are verified by trusted time helpers:
• If two or more of the sequence conflict transactions are verified by trusted time helpers, those transactions are all voided and the remaining amount on the account is seen as 0.
• If only one of the sequence conflict transactions are verified by a trusted time helper, only that transaction is seen as valid. The other double sequence transactions are voided and the value of the voided transactions is destroyed.
• If there are no trusted time helpers, all transactions are voided and the transaction amount is destroyed.
These rules also apply for all transactions with higher sequence numbers than the conflicting ones.
Lets examine what happens in different double spend scenarios:
If a malicious peer sends tokens to two verified time helpers at the same time and he thereby manages to create a set of transactions with duplicate sequence numbers, his tokens would be lost. The receiver, for example a merchant, expecting one of the transactions would only have to wait a little longer to make sure no double spends has occurred with the transaction. If no double spend has occurred after a few seconds the first transaction will have propagated the network (automatically handled by the software) and the attack is no longer possible. From the attacker’s point of view, this attack besides from not working, is not very interesting, as he loses his tokens no matter what.
In the case that an honest user somehow manages to send two transactions to two different time helpers in less time than it takes them to communicate, his tokens will not be lost. The software will not allow spending more than is in the users account, so the spend will result in a positive balance and additionally, the transaction data will include different sequence numbers.
If a malicious user utilizes his untrusted time helper to craft and verify a transaction with a fake sequence number, the receiver of the other transaction in the double spend has presumably already made sure that transaction was verified by trusted time helpers, so this new untrusted double spend transaction will have no effect. (See sequence conflict with only 1 trusted transaction above).
If a malicious user somehow manages to get his time helper trusted or hacks a trusted time helper etc. he can actually carry out an attack. That is he can transfer money to another user and then destroy those tokens, even after the receiver had verified that he had received the tokens. He can do this by maliciously signing a new duplicate sequence transaction, which will result in both transactions being voided and the tokens lost. The attacker would need to spend tokens under his own control for this to work though. And again, this is a rather pointless attack, it will cost the attacker money to spend the tokens that he later wants destroy. Further the unlucky receiver that has had his received tokens voided will now have evidence that a certain time helper is malicious. He can show this to other peers and people will very quickly come start distrusting this time helper. And as the users program will always make sure every transaction is double verified on receiving transactions, the “destruction” of the tokens is reversed, when people stop trusting the certificate of the malicious time helper.
I am very interested in constructive criticism, please try and find a flaw in the scheme and let me know if you can. But I am not very interested in the whole "good luck with your shit scam coin" type of feedback. If your negative feedback doesn't include logical arguments, then please refrain from posting it. Thanks.
Jump to: