Perhaps little change is needed to implement it, I am not sure...
Bitcoin/transactions/blocks seem to have these "operation codes".
Perhaps a "duplex link" operation code could be introduced which links transactions to each other. (dual link).
Which means the transaction is only accepted if it's counter-transaction is also in the same block.
Perhaps this concept could even be extended to "multi link".
All transactions linked together need to be in the same block for them to occur/be accepted by the network, otherwise they are rejected.
Topic: Mixing bitcoins proposal and ideas. (duplex transactions) (Read 1304 times)
Hello,
Mixing bitcoins in a hopefully sufficient way could be done as follows:
The bitcoin client subtracts small ammounts of money/bitcoins from it's own bitcoin addresses.
These are then sent into some uncompleted transactions to other bitcoin clients.
Those other bitcoin clients will complete the transaction but receiving those small ammount of bitcoins and sending them back and re-encoding them with their own bitcoin addresses.
Preferably also mixing bitcoins which they received from as many other clients/bit coin addresses as possible.
The only rule is that the input and the output cannot come from the same bitcoin address, therefore money cannot be send back directly, so there is no direct link.
This way the entire bitcoin network starts to mix small ammounts of bitcoins/money, so that it becomes practically untraceable.
There would be so many links/paths/transactions to follow that it makes no sense for super computer to analyze.
An example of how a certain ammount of money is mixed:
BitCoinAddressA has 100 bitcoins.
BitCoinAddressA splits this up into 10000 transactions over time with empty destination addresses, these are broadcasted to the network.
BitCoinAddress0 to 9999 pickup these empty transactions and put their own BitCoinAddress0 to 9999 into it.
BitCoinAddress0 to 9999 create a new transaction where they transfer money/bitcoins for the same ammount from BitCoinAddress0 to 9999 back to BitCoinAddressA in such a way that the bitcoins that were selected for this transfer did not originate from any BitCoinAddress owned by BitCoinAddress0 to 9999 to prevent local cycles. This ensures more mixing from BitCoinAddresses which served as true inputs from outside the client.
To add to the mix, the bitcoins which will be selected should be as many as possible and subtract small ammounts from their bitcoin addresses where they received money on, not originating from BitCoinAddressA.
There is some potential for small cyclic links to occur in the order of 2 or 3 indirect links, however ultimately as more clients perform this behaviour the mixing will become longer and better and deeper.
This leaves the problem of making sure that BitCoinAddressA gets a transfer back for his splitted up money.
They way this could work is as follows:
The bitcoin client which offered the mixing services sends back the completed transaction to BitCoinAddressA plus the transaction which transfers the money back to BitCoinAddressA.
I think it's pretty clear that that bitcoin client technology needs a new form of transaction to facilitate this behaviour.
These transactions could be called "duplex transactions" where a money transfer can only occur if the same ammount of money flows in both directions but from different addresses as to mix it.
The duplex transaction is only accepted by the network if both keys from A and the helper are used to sign it.
These duplex transactions will need to be something special and cannot consist out of 2 normal transactions, since one of them could betray the other and not come through with one of the transactions.
So the duplex transaction prevent that from occuring, it's an all or nothing deal, both direction transfers happen or not at all.
Introducing a duplex transaction makes following/analyzing mixing a bit more easy, but because of the design above this will be futile, the transactions are so small, and so many that ultimately it becomes more like water, it's totally mixed after a while, this mixing could continue endlessly.
Currently some estimate: 100.000 bitcoin clients, mixing 10.000 transactions over time, perhaps some weeks or months, is 1.000.000.000 mixes per weeks or months.
This is not a large number for a super computer, however the mixing is so intense that no logic can probably make sense of it, as bitcoin becomes more populair this mixing will intensivy.
The drawback is that the blockchain's size will grow even faster. This could be a positive thing, this will also force a balance sheet approach/solution to be used, which might be somewhat more efficient.
By expanding/growing/inflating the blockchain at such a rapid paste it could become unfeasible even for a super computer to store it, or to keep track of information. So there is some interesting value in expending the size of the block chain as fast as possible.
Bye,
Skybuck.
Mixing bitcoins in a hopefully sufficient way could be done as follows:
The bitcoin client subtracts small ammounts of money/bitcoins from it's own bitcoin addresses.
These are then sent into some uncompleted transactions to other bitcoin clients.
Those other bitcoin clients will complete the transaction but receiving those small ammount of bitcoins and sending them back and re-encoding them with their own bitcoin addresses.
Preferably also mixing bitcoins which they received from as many other clients/bit coin addresses as possible.
The only rule is that the input and the output cannot come from the same bitcoin address, therefore money cannot be send back directly, so there is no direct link.
This way the entire bitcoin network starts to mix small ammounts of bitcoins/money, so that it becomes practically untraceable.
There would be so many links/paths/transactions to follow that it makes no sense for super computer to analyze.
An example of how a certain ammount of money is mixed:
BitCoinAddressA has 100 bitcoins.
BitCoinAddressA splits this up into 10000 transactions over time with empty destination addresses, these are broadcasted to the network.
BitCoinAddress0 to 9999 pickup these empty transactions and put their own BitCoinAddress0 to 9999 into it.
BitCoinAddress0 to 9999 create a new transaction where they transfer money/bitcoins for the same ammount from BitCoinAddress0 to 9999 back to BitCoinAddressA in such a way that the bitcoins that were selected for this transfer did not originate from any BitCoinAddress owned by BitCoinAddress0 to 9999 to prevent local cycles. This ensures more mixing from BitCoinAddresses which served as true inputs from outside the client.
To add to the mix, the bitcoins which will be selected should be as many as possible and subtract small ammounts from their bitcoin addresses where they received money on, not originating from BitCoinAddressA.
There is some potential for small cyclic links to occur in the order of 2 or 3 indirect links, however ultimately as more clients perform this behaviour the mixing will become longer and better and deeper.
This leaves the problem of making sure that BitCoinAddressA gets a transfer back for his splitted up money.
They way this could work is as follows:
The bitcoin client which offered the mixing services sends back the completed transaction to BitCoinAddressA plus the transaction which transfers the money back to BitCoinAddressA.
I think it's pretty clear that that bitcoin client technology needs a new form of transaction to facilitate this behaviour.
These transactions could be called "duplex transactions" where a money transfer can only occur if the same ammount of money flows in both directions but from different addresses as to mix it.
The duplex transaction is only accepted by the network if both keys from A and the helper are used to sign it.
These duplex transactions will need to be something special and cannot consist out of 2 normal transactions, since one of them could betray the other and not come through with one of the transactions.
So the duplex transaction prevent that from occuring, it's an all or nothing deal, both direction transfers happen or not at all.
Introducing a duplex transaction makes following/analyzing mixing a bit more easy, but because of the design above this will be futile, the transactions are so small, and so many that ultimately it becomes more like water, it's totally mixed after a while, this mixing could continue endlessly.
Currently some estimate: 100.000 bitcoin clients, mixing 10.000 transactions over time, perhaps some weeks or months, is 1.000.000.000 mixes per weeks or months.
This is not a large number for a super computer, however the mixing is so intense that no logic can probably make sense of it, as bitcoin becomes more populair this mixing will intensivy.
The drawback is that the blockchain's size will grow even faster. This could be a positive thing, this will also force a balance sheet approach/solution to be used, which might be somewhat more efficient.
By expanding/growing/inflating the blockchain at such a rapid paste it could become unfeasible even for a super computer to store it, or to keep track of information. So there is some interesting value in expending the size of the block chain as fast as possible.
Bye,
Skybuck.
Jump to: