Author

Topic: Solution for "The Filter Issue" and "dark" data stored in blockchain (Read 817 times)

legendary
Activity: 1176
Merit: 1257
May Bitcoin be touched by his Noodly Appendage
We all know bitcoin can be used as a means to store "dark" data in the block chain.

Most of the ideas I tumbled across are based on recipient's address filtering.

This concepts seems to me nothing but absurd, since whatever filter is implemented, there will always be a way to fool such filtering process, and store data.

Here, I propose a method that:
 - Eliminates arbitrary data-storage in the blockchain
 - Eliminates lost money due to mistyped addresses (if ever anyone types an address)

The solution is as simple as this, both payer and receiver must sign the transfer. This could've brought up the double-spending issue again,
but here is how to solve it.

Bob wants to pay Alice

Bob sends transfer to Alice's address

Such transfer is confirmed in the blockchain

After such confirmation, Alice must sign such transfer within the next N block confirmations (e.g by re-transfering the money to another (her's) address, or by creating a new type of packet "transfer confirm")

if after N blocks no-one confirmed the receipt of the money, bob is allowed to spend it again. Such transaction can then be removed.

How does this attenuate the "dark" data storage?
The person that wants to store data, sending to a fake address (which contains the given data) needs to have the private key of that address - > which is pretty complicated.
Nevertheless, it is still possible (and will always be) to store data using a vanity address...

How does this solve "mistyped" addresses?
The receiver cannot sign the receipt, and as such the money goes back to the sender


What do you think about this proposal?


Edit: made some makeup on text
So one would need to know he has been paid to actually receive money? He loses everything otherwise?
Even banks are more practical than that
hero member
Activity: 772
Merit: 501
It would prevent people from sending to an offline address, which can be very useful for security purposes. Say for example you have a savings account, and the private key for it is in cold storage. You could still send BTC to the savings account if you had the bitcoin address for the private key, without having to take the private key out of storage. Losing the ability to do that would be a big loss in utility.
newbie
Activity: 17
Merit: 0
We all know bitcoin can be used as a means to store "dark" data in the block chain.

Most of the ideas I tumbled across are based on recipient's address filtering.

This concepts seems to me nothing but absurd, since whatever filter is implemented, there will always be a way to fool such filtering process, and store data.

Here, I propose a method that:
 - Eliminates arbitrary data-storage in the blockchain
 - Eliminates lost money due to mistyped addresses (if ever anyone types an address)

The solution is as simple as this, both payer and receiver must sign the transfer. This could've brought up the double-spending issue again,
but here is how to solve it.

Bob wants to pay Alice

Bob sends transfer to Alice's address

Such transfer is confirmed in the blockchain

After such confirmation, Alice must sign such transfer within the next N block confirmations (e.g by re-transfering the money to another (her's) address, or by creating a new type of packet "transfer confirm")

if after N blocks no-one confirmed the receipt of the money, bob is allowed to spend it again. Such transaction can then be removed.

How does this attenuate the "dark" data storage?
The person that wants to store data, sending to a fake address (which contains the given data) needs to have the private key of that address - > which is pretty complicated.
Nevertheless, it is still possible (and will always be) to store data using a vanity address...

How does this solve "mistyped" addresses?
The receiver cannot sign the receipt, and as such the money goes back to the sender


What do you think about this proposal?


Edit: made some makeup on text
Jump to: