Bitcoin Forum
December 14, 2024, 06:00:16 PM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Scripts to explore relations (privacy)  (Read 1178 times)
eckes (OP)
Newbie
*
Offline Offline

Activity: 8
Merit: 0


View Profile
June 03, 2011, 08:56:41 PM
 #1

I was impressed to find out, that Transactions can have a pretty complex scripting logic (and they typically dont need to use that feature). One thing which catched my attention was the sample that you can require multiple signatures to be present. So if I sent a bitcoin transaction with a script which contains a "check if receiver has keya and keyb" I can determine if two addresses have the same owner - or more specifically are in the same wallet.

Is this correct, is this considered a privacy problem?

How (besides having multiple wallets) can I protect against that. Is there a way to not accept transactions with some scripts. Who is actually executing those scripts, and how are they asking me for the proof signatures? If my client is executing the script, can I lie about the interpretation result (since it is hashed in the block, but not necesarily possible to be repeated).

Greetings
Bernd
ene
Newbie
*
Offline Offline

Activity: 42
Merit: 0


View Profile
June 03, 2011, 09:03:41 PM
 #2

Due to the implementation of IsStandard, such transactions don't exist on the main bitcoin network. Also current bitcoin clients do not support redeeming these transactions at all. So currently you have nothing to worry about.

Quote
if I sent a bitcoin transaction with a script which contains a "check if receiver has keya and keyb" I can determine if two addresses have the same owner - or more specifically are in the same wallet.

This would be a total shot in the dark - you would see two people on different forums, which have posted different receiving addresses, and wonder whether they're the same person. So you make a transaction which requires both addresses, and you send it out.

Whether they're the same person or not, you'll never get your money back! You may also have had to pay a fee just to get it into a block; you lose that too.


In the future there might be a special user interface for redeeming such transactions, who knows.
unk
Member
**
Offline Offline

Activity: 84
Merit: 10


View Profile
June 03, 2011, 09:22:58 PM
 #3

Is this correct, is this considered a privacy problem?

no and no.

'script' is an unfortunately chosen word. 'condition' would be better. scripted payments are just conditional payments containing idempotent instructions regarding the completion of a transaction. they don't 'run' in your client in any way that would be detectable on the block chain. if you didn't want to expose that you had multiple signatures, for example, then even in a system that supported bitcoin 'scripting' you'd simply decline to spend the resulting coins. it doesn't work like code injection.
eckes (OP)
Newbie
*
Offline Offline

Activity: 8
Merit: 0


View Profile
June 03, 2011, 09:32:57 PM
 #4


'script' is an unfortunately chosen word. 'condition' would be better. scripted payments are just conditional payments containing idempotent instructions regarding the completion of a transaction.[/quote]

Exactly, so I can (if IsStandard is not used, which I dod not know that it exists) state a condition and I will see if the condition is true by observing if the money is spent or not. This is the privacy issue (which is solved by turning the feature off it seems).

Maybe you dan decline - I just dont know how in the standard client.

(And I am still searching for some background info who (besides the receipient of a transaction) can evaluate the condition for verification).

Gruss
Bernd
theymos
Administrator
Legendary
*
Offline Offline

Activity: 5404
Merit: 13498


View Profile
June 03, 2011, 09:41:37 PM
 #5

The current client wouldn't even recognize the script as being sent to you. It doesn't know how to solve it, so it just ignores it. You can't possibly spend such scripts unless you modify Bitcoin.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!