Topic: Hash based confidential txn chains.. - page 2. (Read 3115 times)
How do you propose generating a random number? Unless your computer is hooked up to a hardware random number generator it could be producing pseudorandom numbers which are unsuitable for sensitive applications like cryptography.
I originally posted this in General.. but it went down as well as a pulled pork sandwich at a vegan convention..
Hope it's OK to post here.
..
This is something I've been thinking about since gmaxwell blew all our brains out with his homomorphic confidential txn implementation.
It is a very simple idea and NOT as powerful as CT, but it does hide the values when you make a spend (from most people). And is quantum secure as well, as it only relies on hash functions.
Basically - when you create a TXN, you also generate a random number.
You then hash the outputs with that random number. You and the receiver know what the random number is, and so can decode what the outputs of the txn are, and so can check that the sum of the inputs equals the sum of the outputs. A valid txn.
When you want to spend a hidden output, you would need to provide the complete txn chain for each input (random value+outputs), going all the way back to a coinbase txn, which is never hidden. You would not need to provide the complete txn tree from the coinbase, just the branch that your input/output is on.
This means that everyone spending an output, would know the complete history that led to it. But on the chain, all that would be stored is a mass of hash values.
You can't cheat the system, as the receiver would not accept a txn that had an invalid history as valid, and since the txn would be mined as usual whether it was valid or not, since the miners can't tell (and mine the txn regardless), if you did try and cheat all you would do is lock up the funds in a spendable-yet-invalid output. That no one would accept as payment.
If, for now, txns had 1 input and 2 outputs, you would need to store the random value(32 bytes), and the value of both outputs, (32 * 3 bytes) for each TXN in the chain leading back to the coinbase. Multiple inputs could, and probably would, go back to different coinbase txns. So if there were 10 txns in all in the chain, that's an extra 960 bytes.
I am not sure how many txn's on average are in the chain going back to the coinbase.. Anyone ?
This data would start small but could grow to be quite large. Unless you are 'hodling' the coins.
I was thinking that at some point in the future you could 'cash-in' an output, by providing the complete history to the miners, and that would then create a NOT hidden output to you in the coinbase. This would remove the anonymity for that chain of txns of course, but could be done years later. You would then have a spendable output that required no txn chain as proof, as it's not a hidden value.
I really don't know if this is actually useful / practical / doable, but wanted to throw it in the 'bit-pit', in case anyone can see something cool that I've missed..
( For instance - can you prove the output and it's value are valid without exposing all the hidden data in the chain ? )
Hope it's OK to post here.
..
This is something I've been thinking about since gmaxwell blew all our brains out with his homomorphic confidential txn implementation.
It is a very simple idea and NOT as powerful as CT, but it does hide the values when you make a spend (from most people). And is quantum secure as well, as it only relies on hash functions.
Basically - when you create a TXN, you also generate a random number.
You then hash the outputs with that random number. You and the receiver know what the random number is, and so can decode what the outputs of the txn are, and so can check that the sum of the inputs equals the sum of the outputs. A valid txn.
When you want to spend a hidden output, you would need to provide the complete txn chain for each input (random value+outputs), going all the way back to a coinbase txn, which is never hidden. You would not need to provide the complete txn tree from the coinbase, just the branch that your input/output is on.
This means that everyone spending an output, would know the complete history that led to it. But on the chain, all that would be stored is a mass of hash values.
You can't cheat the system, as the receiver would not accept a txn that had an invalid history as valid, and since the txn would be mined as usual whether it was valid or not, since the miners can't tell (and mine the txn regardless), if you did try and cheat all you would do is lock up the funds in a spendable-yet-invalid output. That no one would accept as payment.
If, for now, txns had 1 input and 2 outputs, you would need to store the random value(32 bytes), and the value of both outputs, (32 * 3 bytes) for each TXN in the chain leading back to the coinbase. Multiple inputs could, and probably would, go back to different coinbase txns. So if there were 10 txns in all in the chain, that's an extra 960 bytes.
I am not sure how many txn's on average are in the chain going back to the coinbase.. Anyone ?
This data would start small but could grow to be quite large. Unless you are 'hodling' the coins.
I was thinking that at some point in the future you could 'cash-in' an output, by providing the complete history to the miners, and that would then create a NOT hidden output to you in the coinbase. This would remove the anonymity for that chain of txns of course, but could be done years later. You would then have a spendable output that required no txn chain as proof, as it's not a hidden value.
I really don't know if this is actually useful / practical / doable, but wanted to throw it in the 'bit-pit', in case anyone can see something cool that I've missed..
( For instance - can you prove the output and it's value are valid without exposing all the hidden data in the chain ? )
Jump to: