Bitcoin Forum
September 27, 2018, 11:18:33 PM *
News: ♦♦ New info! Bitcoin Core users absolutely must upgrade to previously-announced 0.16.3 [Torrent]. All Bitcoin users should temporarily trust confirmations slightly less. More info.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Solution for "The Filter Issue" and "dark" data stored in blockchain  (Read 747 times)
jmoon
Newbie
*
Offline Offline

Activity: 17
Merit: 0


View Profile
June 02, 2013, 10:33:59 PM
 #1

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
1538090313
Hero Member
*
Offline Offline

Posts: 1538090313

View Profile Personal Message (Offline)

Ignore
1538090313
Reply with quote  #2

1538090313
Report to moderator
1538090313
Hero Member
*
Offline Offline

Posts: 1538090313

View Profile Personal Message (Offline)

Ignore
1538090313
Reply with quote  #2

1538090313
Report to moderator
Make a difference with your Ether.
Donate Ether for the greater good.
SPRING.WETRUST.IO
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1538090313
Hero Member
*
Offline Offline

Posts: 1538090313

View Profile Personal Message (Offline)

Ignore
1538090313
Reply with quote  #2

1538090313
Report to moderator
1538090313
Hero Member
*
Offline Offline

Posts: 1538090313

View Profile Personal Message (Offline)

Ignore
1538090313
Reply with quote  #2

1538090313
Report to moderator
amincd
Hero Member
*****
Offline Offline

Activity: 772
Merit: 500


View Profile
June 03, 2013, 10:03:46 AM
 #2

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.
jackjack
Legendary
*
Offline Offline

Activity: 1134
Merit: 1013


May Bitcoin be touched by his Noodly Appendage


View Profile
June 03, 2013, 10:22:26 AM
 #3

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

Own address: 19QkqAza7BHFTuoz9N8UQkryP4E9jHo4N3 - Pywallet support: 1AQDfx22pKGgXnUZFL1e4UKos3QqvRzNh5 - Bitcointalk++ script support: 1Pxeccscj1ygseTdSV1qUqQCanp2B2NMM2
Pywallet: instructions. Encrypted wallet support, export/import keys/addresses, backup wallets, export/import CSV data from/into wallet, merge wallets, delete/import addresses and transactions, recover altcoins sent to bitcoin addresses, sign/verify messages and files with Bitcoin addresses, recover deleted wallets, etc.
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!