Topic: Hash-based chainless transactions theory - page 2. (Read 3977 times)
BUMP.
This is an idea I have thought of while exploring hashing functions, what if you could store the entire transaction history and make payments by using a very small set (a small graph) of hashes, with no need to track individual transactions, no need to store the transaction history, and reduced need to be connected to the network to make a transaction? But you have to have the history of each transaction to be able to prove a transaction is acceptable, right? I don't think so, if you can hash the history (so it still exists, but you can't read it).
You don't make the block network a linear directed graph, make each individual's transactions an acyclic directed graph that is (usually) linear.
Here is the introduction: Each person starts off with the same initial block. After that, each transaction records a block of the state of the network at that time. Each transaction contains information that modifies the block in such a way that double-spending will not "cleanly" apply (that is, double-spending and the like is detected by examining the resulting hash), and furthermore, will incorperate all the information for all the transactions that came before it. Each person has the private key that can create a transaction that will cleanly apply for only an amount not greater than their current balance.
Here is how it might work: Define a hashing function GETTHEBLOCK( inputs ) which takes the entire list of private keys and how much they hold, and produces a very large number based on it, in such a way a private key with a balance of zero passed to the input does not affect the output, and additionally such that an examination of the hash can securely reveal how many total units of currency it embodies. All numbers are unsigned (since they are simply bit arrays like any computer), so there cannot be a negative balance. Create a public/private key pair "ORIGIN", and define that private key to own T units of currency (T being the maximum number that the configuration of the algroithm permits). Create the first block B0 by passing that private key/balance pair to GETTHEBLOCK to produce the prime block B0.
Produce a second public/private key pair "A". Create an acyclic directed graph with a single node of value B0, this represents A's first "transaction" formally giving that private key a balance of zero. That is, by taking the private key/balance pair of ORIGIN and the private key/balance pair of A, A can re-create B0.
Now here is the magic. GETTHEBLOCK is defined in such a way that ORIGIN can pass a message to A, that allows A to modify the block to what GETTHEBLOCK would produce if ORIGIN had x less currency and A had x more currency (maybe they have to negotiate the actual change that happens interactively, who knows). If ORIGIN has transactions that A does not have and vice versa and can be merged "cleanly", the clients also exchange this information (probably beforehand). Each side enters the transaction into their transaction history graph as a decedent of the most recent block that the transaction will cleanly apply to.
Clients will not be able to re-create the updated block because they do not have each individual's private key (except maybe for ORIGIN once that balance is zero, so they can verify B0 for themselves). But they can still verify that they have an increased balance, and that the total number of currency has not changed so it must have come from someone else's private key, presumably the person they are making the exchange with.
There is no need to download the block chain, and you can (probably) compress an indefinite number of transactions into a constant size hash, that is no less insecure than modern private key cryptography.
There is no central authority here, no block chain. However, there is no risk of counterfeiting, since individuals will not accept an increased money supply by definition (it could be technically impossible too if the money supply is the limit for the storage container, an unsigned int64 or whatever). The only real problem (if possible at all--see below) is double spending. If A decides to double-spend the entire balance to B and C, from the same block, B and C will not be able to make a transaction with each other because they cannot "cleanly" do so, they may be forced to apply a transaction to an older block, and one of them will have to invalidate their transaction with A. Possibly there could be two separate histories now, one where B got the "actual" transaction and one where C got the "actual" transaction. Or as I calculate it, eventually no one will want to exchange with the second B or C block because they will already have the other key has already gotten the currency, and the only option B or C will have is to transact against an older block where they have less balance. This could all be mitigated with a central clearing network that broadcasts transactions instantly to everyone connected (or can do it quickly distributed like the current block chain, doesn't matter), so the receiving party merely needs to wait a few seconds before finishing the transaction to see that everyone in sight accepts the transaction.
Now GETTHEBLOCK might not even exist, it could be impossible. Most of the functionality should be possible. You could make it satisfy the first condition, that private keys with a balance of zero do not affect the output, possibly by signing the balance with that private key, then multiplying that number (treating it as a number) by the balance. But could you make it satisfy the second condition, that you can verify how much currency it embodies by examining it? You don't even have to return a number, just a true/false that it is the same number that it was the previous transaction (and since everyone will know the ORIGIN private key, they can determine how much currency was in the B0 block). You might need to so something creative like using an alternative public-private key algorithm, where the sum of the individual bytes or bits is a constant, so key×balance carries the same pattern.
You don't make the block network a linear directed graph, make each individual's transactions an acyclic directed graph that is (usually) linear.
Here is the introduction: Each person starts off with the same initial block. After that, each transaction records a block of the state of the network at that time. Each transaction contains information that modifies the block in such a way that double-spending will not "cleanly" apply (that is, double-spending and the like is detected by examining the resulting hash), and furthermore, will incorperate all the information for all the transactions that came before it. Each person has the private key that can create a transaction that will cleanly apply for only an amount not greater than their current balance.
Here is how it might work: Define a hashing function GETTHEBLOCK( inputs ) which takes the entire list of private keys and how much they hold, and produces a very large number based on it, in such a way a private key with a balance of zero passed to the input does not affect the output, and additionally such that an examination of the hash can securely reveal how many total units of currency it embodies. All numbers are unsigned (since they are simply bit arrays like any computer), so there cannot be a negative balance. Create a public/private key pair "ORIGIN", and define that private key to own T units of currency (T being the maximum number that the configuration of the algroithm permits). Create the first block B0 by passing that private key/balance pair to GETTHEBLOCK to produce the prime block B0.
Produce a second public/private key pair "A". Create an acyclic directed graph with a single node of value B0, this represents A's first "transaction" formally giving that private key a balance of zero. That is, by taking the private key/balance pair of ORIGIN and the private key/balance pair of A, A can re-create B0.
Now here is the magic. GETTHEBLOCK is defined in such a way that ORIGIN can pass a message to A, that allows A to modify the block to what GETTHEBLOCK would produce if ORIGIN had x less currency and A had x more currency (maybe they have to negotiate the actual change that happens interactively, who knows). If ORIGIN has transactions that A does not have and vice versa and can be merged "cleanly", the clients also exchange this information (probably beforehand). Each side enters the transaction into their transaction history graph as a decedent of the most recent block that the transaction will cleanly apply to.
Clients will not be able to re-create the updated block because they do not have each individual's private key (except maybe for ORIGIN once that balance is zero, so they can verify B0 for themselves). But they can still verify that they have an increased balance, and that the total number of currency has not changed so it must have come from someone else's private key, presumably the person they are making the exchange with.
There is no need to download the block chain, and you can (probably) compress an indefinite number of transactions into a constant size hash, that is no less insecure than modern private key cryptography.
There is no central authority here, no block chain. However, there is no risk of counterfeiting, since individuals will not accept an increased money supply by definition (it could be technically impossible too if the money supply is the limit for the storage container, an unsigned int64 or whatever). The only real problem (if possible at all--see below) is double spending. If A decides to double-spend the entire balance to B and C, from the same block, B and C will not be able to make a transaction with each other because they cannot "cleanly" do so, they may be forced to apply a transaction to an older block, and one of them will have to invalidate their transaction with A. Possibly there could be two separate histories now, one where B got the "actual" transaction and one where C got the "actual" transaction. Or as I calculate it, eventually no one will want to exchange with the second B or C block because they will already have the other key has already gotten the currency, and the only option B or C will have is to transact against an older block where they have less balance. This could all be mitigated with a central clearing network that broadcasts transactions instantly to everyone connected (or can do it quickly distributed like the current block chain, doesn't matter), so the receiving party merely needs to wait a few seconds before finishing the transaction to see that everyone in sight accepts the transaction.
Now GETTHEBLOCK might not even exist, it could be impossible. Most of the functionality should be possible. You could make it satisfy the first condition, that private keys with a balance of zero do not affect the output, possibly by signing the balance with that private key, then multiplying that number (treating it as a number) by the balance. But could you make it satisfy the second condition, that you can verify how much currency it embodies by examining it? You don't even have to return a number, just a true/false that it is the same number that it was the previous transaction (and since everyone will know the ORIGIN private key, they can determine how much currency was in the B0 block). You might need to so something creative like using an alternative public-private key algorithm, where the sum of the individual bytes or bits is a constant, so key×balance carries the same pattern.
Jump to: