Vulnerabilities - Revision history

FellowTraveler: /* Transaction server falsifies an account balance, or a transaction amount */

2013-06-17T10:30:30Z

‎Transaction server falsifies an account balance, or a transaction amount

FellowTraveler: /* Transaction server falsifies an account balance, or a transaction amount */ re-arrange

2013-06-17T10:30:12Z

‎Transaction server falsifies an account balance, or a transaction amount: re-arrange

FellowTraveler: /* Transaction server might inflate the currency */ re-arrange

2013-06-17T10:28:53Z

‎Transaction server might inflate the currency: re-arrange

FellowTraveler: /* Re-using previously valid instruments */ italics added

2013-06-17T10:21:41Z

‎Re-using previously valid instruments: italics added

FellowTraveler: web browser vulnerabilities, more issuer vulnerabilities

2013-06-17T10:20:50Z

web browser vulnerabilities, more issuer vulnerabilities

FellowTraveler: /* Issuer holding gold might lie about the physical gold */ minor re-arrangement of bullet points

2013-06-17T09:16:22Z

‎Issuer holding gold might lie about the physical gold: minor re-arrangement of bullet points

FellowTraveler: /* Issuer holding gold might lie about the physical gold */

2013-06-17T09:15:58Z

‎Issuer holding gold might lie about the physical gold

FellowTraveler: /* Re-using previously valid instruments */ slight textual rearrangement.

2013-06-17T09:14:25Z

‎Re-using previously valid instruments: slight textual rearrangement.

FellowTraveler: added note on re-using previous valid instruments.

2013-06-17T09:13:41Z

added note on re-using previous valid instruments.

FellowTraveler: /* Transaction server might inflate the currency */ newline added

2013-06-17T09:06:30Z

‎Transaction server might inflate the currency: newline added

@@ Line 14: / Line 14: @@
 === Transaction server falsifies an account balance, or a transaction amount ===
-'''Solution:''' Falsified balances are prevented by the use of triple-signed receipts. The OT server cannot do this sort of falsification.
+'''Solution:''' Falsified balances are prevented by the use of triple-signed receipts. (The OT server cannot do this sort of falsification.)
 ''Every receipt is first signed by the client side,'' and then counter-signed by the server. Since the server cannot forge your signature, it cannot forge any receipt. Moreover, since your account balance itself appears on every receipt, ''the server cannot change your account balance.'' And since the receipt also contains a list of all valid transaction numbers for your Nym, neither can previously valid (and validly signed) instruments be used twice.

@@ Line 14: / Line 14: @@
 === Transaction server falsifies an account balance, or a transaction amount ===
-Falsified balances are prevented by the use of triple-signed receipts. The OT server cannot do this sort of falsification. (Inflation--above--is the only possible crime, and that's prevented through auditing.)
+'''Solution:''' Falsified balances are prevented by the use of triple-signed receipts. The OT server cannot do this sort of falsification.
-'''Solution:''' ''Every receipt is first signed by the client side,'' and then counter-signed by the server. Since the server cannot forge your signature, it cannot forge any receipt. Moreover, since your account balance itself appears on every receipt, ''the server cannot change your account balance.'' And since the receipt also contains a list of all valid transaction numbers for your Nym, neither can previously valid (and validly signed) instruments be used twice.
+''Every receipt is first signed by the client side,'' and then counter-signed by the server. Since the server cannot forge your signature, it cannot forge any receipt. Moreover, since your account balance itself appears on every receipt, ''the server cannot change your account balance.'' And since the receipt also contains a list of all valid transaction numbers for your Nym, neither can previously valid (and validly signed) instruments be used twice.
 === Transaction server refuses to process your transactions ===

@@ Line 3: / Line 3: @@
 === Transaction server might inflate the currency ===
-This is prevented through auditing.
+'''Solution:''' This is prevented through [[Auditing|auditing]], which must be utilized, either by the issuer directly, or by the other members of the voting pool.
 While the transaction server cannot lie on your receipts, it can potentially inflate the currency itself by using dummy accounts.<br>
@@ Line 9: / Line 9: @@
 This crime is also permanently detectable until the funds are removed again from circulation.
 If the issuer has directly issued the currency onto the transaction server, then he must also conduct the audit.<br>
 Whereas if the currency is BTC, or if the issuer has used colored coins, then the coins should be uploaded into a voting pool so that the transaction server cannot steal them. In this case, the pool members must audit each other.

@@ Line 71: / Line 71: @@
 === Re-using previously valid instruments ===
-If Alice signs a cheque and gives it to Bob, and he deposits it, what's to stop Bob from depositing the same cheque twice? (The signature is still valid...)
+If Alice signs a cheque and gives it to Bob, and he deposits it, ''what's to stop Bob from depositing the same cheque twice?'' (The signature is still valid...)
 '''Solution:''' Each cheque must have a transaction number on it, which was previously signed-out by the cheque signer. Once the cheque is deposited, a chequeReceipt is placed in the cheque signer's inbox. The same cheque cannot be deposited twice at this point, because there would then be two chequeReceipts in the same inbox, each carrying the same transaction number. And once the cheque signer accepts the chequeReceipt from his inbox, a new balance agreement is signed, which includes the new balance as well as the new list of "valid transaction numbers" for that Nym. Since this new balance agreement removes the cheque's transaction number from the list of valid numbers for that Nym, any further deposits of the same cheque would be invalid, since it now carries an invalid transaction number (one that is no longer signed-out.)

@@ Line 2: / Line 2: @@
 === Transaction server might inflate the currency ===
 While the transaction server cannot lie on your receipts, it can potentially inflate the currency itself by using dummy accounts.<br>
@@ Line 10: / Line 12: @@
 If the issuer has directly issued the currency onto the transaction server, then he must also conduct the audit.<br>
 Whereas if the currency is BTC, or if the issuer has used colored coins, then the coins should be uploaded into a voting pool so that the transaction server cannot steal them. In this case, the pool members must audit each other.
 === Vulnerabilities in C++ code ===
@@ Line 20: / Line 40: @@
 * Data validation in C++ code.<br>
 * Test scripts for data validation.<br>
-* Penetration testing.<br>
+* Penetration testing.
 === Attacker might intercept a message and send it twice (Re-play attacks)  ===
@@ Line 31: / Line 59: @@
 '''Solutions:'''<br>
-* Users must be picky about issuers.
+* Users must be picky about issuers.<br>
 * A physical audit of the issuer's physical gold is the only way to make sure he actually has the gold.<br>
 * A basket currency on OT allows each Nym to distribute the risk of a currency across multiple issuers.
@@ Line 39: / Line 67: @@
 '''Solutions:'''<br>
 * Bitcoins on the blockchain can be audited by any observer. (This is an advantage that Bitcoin has against physical gold.)<br>
-* Store the BTC in a '''voting pool,''' so that there is no longer any "issuer" who must be trusted. (Though the pool itself must be trusted.)<br>
+* Store the BTC in a '''voting pool,''' so that there is no longer any "issuer" who must be trusted. (Though the pool itself must be trusted.)
 === Re-using previously valid instruments ===
@@ Line 48: / Line 76: @@
 This makes it possible to prove which instruments are valid, without storing any transaction history other than the ''last signed receipt.'' That receipt includes a list of the valid transaction numbers for its Nym. (All transactions inside OT use this same mechanism.)

← Older revision		Revision as of 09:13, 17 June 2013
Line 37:		Line 37:
	* Bitcoins on the blockchain can be audited by any observer. (This is an advantage that Bitcoin has against physical gold.)<br>		* Bitcoins on the blockchain can be audited by any observer. (This is an advantage that Bitcoin has against physical gold.)<br>
	* Store the BTC in a '''voting pool,''' so that there is no longer any "issuer" who must be trusted. (Though the pool itself must be trusted.)<br>		* Store the BTC in a '''voting pool,''' so that there is no longer any "issuer" who must be trusted. (Though the pool itself must be trusted.)<br>
		+
		+	=== Re-using previously valid instruments ===
		+
		+	If Alice signs a cheque and gives it to Bob, and he deposits it, what's to stop Bob from depositing the same cheque twice? (The signature is still valid...)
		+
		+	'''Solution:''' Each cheque must have a transaction number on it, which was previously signed-out by the cheque signer. All other transactions use this mechanism. Once the cheque is deposited, a chequeReceipt is placed in the cheque signer's inbox. The same cheque cannot be deposited twice at this point, because there would then be two chequeReceipts in the same inbox, each carrying the same transaction number. And once the cheque signer accepts the chequeReceipt from his inbox, a new balance agreement is signed, which includes the new balance as well as the new list of "valid transaction numbers" for that Nym. Since this new balance agreement removes the cheque's transaction number from the list of valid numbers for that Nym, any further deposits of the same cheque would be invalid, since it now carries an invalid transaction number (one that is no longer signed-out.)
		+
		+	This makes it possible to prove which instruments are valid, without storing any transaction history other than the ''last signed receipt.'' That receipt includes a list of the valid transaction numbers for its Nym.

@@ Line 4: / Line 4: @@
 While the transaction server cannot lie on your receipts, it can potentially inflate the currency itself by using dummy accounts.<br>
-But the inflated funds cannot be spent without flowing into other accounts, where they will show on an '''audit.'''
+But the inflated funds cannot be spent without flowing into other accounts, where they will show on an '''audit.'''<br>
 This crime is also permanently detectable until the funds are removed again from circulation.