giszmo



Offline



Activity: 1722

Merit: 1037





WalletScrutiny.com







LegendaryActivity: 1722Merit: 1037WalletScrutiny.com Re: I taint rich! (Fun with raw transactions and disrupting 'taint' analysis) January 29, 2013, 12:15:47 PM #24 Quote from: Red Emerald on January 29, 2013, 03:27:47 AM Quote from: gmaxwell on January 29, 2013, 03:00:48 AM Quote from: casascius on January 29, 2013, 02:39:18 AM Such traffic could be broken into multiple IRC messages to avoid need for pastebin. It could also do direct client to client communications. Ideally it should be some meeting point over TOR so that there is no incentive to try to record IPs. Though I'd prefer instead of opportunistically swapping that it rather had lots of people indicate an intent to swap, and then when you want to make a transaction, you'd jointly create a swap and pay transaction. This avoids bloating the blockchain with a bunch of pure swapping and would further improve privacy as you wouldn't know _which_ outputs were swapping and which were payments. Payments to common anonymous donation addresses could even be merged.

Ideally it should be some meeting point over TOR so that there is no incentive to try to record IPs. Though I'd prefer instead of opportunistically swapping that it rather had lots of people indicate an intent to swap, and then when you want to make a transaction, you'd jointly create a swap and pay transaction. This avoids bloating the blockchain with a bunch of pure swapping and would further improve privacy as you wouldn't know _which_ outputs were swapping and which were payments. Payments to common anonymous donation addresses could even be merged.



Is there a legitimate usage for a bot like this besides confusing taint analysis? I'm not sure if you guys really care at this point or even at all, but running software designed essentially to launder coins sounds like it could potentially get someone in trouble.

This is an interesting idea.Is there a legitimate usage for a bot like this besides confusing taint analysis? I'm not sure if you guys really care at this point or even at all, but running software designed essentially to launder coins sounds like it could potentially get someone in trouble.

Call it money laundering and you repel people. Call it fungibility and people tend to support this basic nature bitcoin needs to be cash. If my bitcoins get deducted x% of their value when paying a governmental entity due to containing x% coins from their daily updated black list of transactions, I will think twice if bitcoin failed as a whole. Prevent that from happening means talking about the dangers of taint analysis.

I guess it will be kind of trivial to have some transaction merging being done with every payment once the network gets busier and I also think this should be done (opt out) by the client.

(BitcoinSpinner style A->B+A transactions definitely are a pain. After having done business with 10 or so people through my Android I get very much aware of it.)



Basically we could have 1 transaction per block but involving more entities to forge a transaction will make it more prone to people never signing it. Also the 1 transaction per block would lead to having the true transaction data being public but outside of the blockchain. Similarly some "agency" could heavily advertise to merge transactions with its transactions just to be able to gather intelligence for later taint analysis. Therefore the best strategy for now would be to seek signing partners only in very small groups of maybe not more than 2. Call it money laundering and you repel people. Call it fungibility and people tend to support this basic nature bitcoin needs to be cash. If my bitcoins get deducted x% of their value when paying a governmental entity due to containing x% coins from their daily updated black list of transactions, I will think twice if bitcoin failed as a whole. Prevent that from happening means talking about the dangers of taint analysis.I guess it will be kind of trivial to have some transaction merging being done with every payment once the network gets busier and I also think this should be done (opt out) by the client.(BitcoinSpinner style A->B+A transactions definitely are a pain. After having done business with 10 or so people through my Android I get very much aware of it.)Basically we could have 1 transaction per block but involving more entities to forge a transaction will make it more prone to people never signing it. Also the 1 transaction per block would lead to having the true transaction data being public but outside of the blockchain. Similarly some "agency" could heavily advertise to merge transactions with its transactions just to be able to gather intelligence for later taint analysis. Therefore the best strategy for now would be to seek signing partners only in very small groups of maybe not more than 2. ɃɃ WalletScrutiny.com Is your wallet secure? (Methodology)

WalletScrutiny checks if wallet builds are reproducible, a precondition for code audits to be of value. ɃɃ

gmaxwell

Legendary



Offline



Activity: 3192

Merit: 4301









StaffLegendaryActivity: 3192Merit: 4301 Re: I taint rich! (Fun with raw transactions and disrupting 'taint' analysis) January 29, 2013, 04:24:58 PM #25 Quote from: giszmo on January 29, 2013, 12:15:47 PM Basically we could have 1 transaction per block but involving more entities to forge a transaction will make it more prone to people never signing it. Also the 1 transaction per block would lead to having the true transaction data being public but outside of the blockchain. Similarly some "agency" could heavily advertise to merge transactions with its transactions just to be able to gather intelligence for later taint analysis. Therefore the best strategy for now would be to seek signing partners only in very small groups of maybe not more than 2. It's quite possible to have a cryptographic protocol which can safely and completely anonymously combine between parties.



Warning: Very complicated cryptographic protocol below.

(fortunately this stuff just gets put in software and a user clicks the button)



To participate in this system you must first have a fidelity bond:



You construct a



People interested in forming an anonymous joint transaction join some broadcast communication channel (e.g. IRC over tor).



Every message they send is signed with their fidelity bond key.



They each put up coins they'd like to include and come to an agreement about the transaction. They each form a message about what output address they'd like to send the funds to, and



The group then performs a group blind signature for each of the blinded messages.



The users unblind their messages, and advertise keys for a



After cycling through all users several times, they decrypt, and the result is a randomly ordered set of output address messages which have all been signed by the whole group, but they cannot tell which users authored which. A transaction is created conforming to the agreed inputs and outputs, and all users sign.



If any any point a user refuses to sign in order to jam the process their misbehavior can be proven to anyone who cares to know by showing them the signed messages from a failed round. After seeing a proof they blacklist the misbehaving fidelity bond key, and so DOS attacking this can be made expensive.



I've omitted a lot of complex details (secure group random number agreement for consensus, constructing the ZKPs to show that someone isn't jamming the mix, etc) and waved my hands at things (like group blind signatures)... but its clear to me that it's certainly possible to construct such a thing. The engineering would be quite hard, as this kind of very lock-stepy everything proven algorithm is quite fragile compared to even Bitcoin. So, I don't expected it any time soon but I'm happy to know that it's possible if it ever actually is needed. In reality, I expect few are going to try to gum up this sort of thing, so in practice people could get away with much simpler protocols.

It's quite possible to have a cryptographic protocol which can safely and completely anonymously combine between parties.Very complicated cryptographic protocol below.To participate in this system you must first have a fidelity bond:You construct a specially formed transaction that gives away some coins as fees in a way that proves you didn't receive them. A key committed to as part of doing this is your fidelity bond key.People interested in forming an anonymous joint transaction join some broadcast communication channel (e.g. IRC over tor).Every message they send is signed with their fidelity bond key.They each put up coins they'd like to include and come to an agreement about the transaction. They each form a message about what output address they'd like to send the funds to, and blind it, and send it to the group. They each advertise a key for blind signing.The group then performs a group blind signature for each of the blinded messages.The users unblind their messages, and advertise keys for a reencryption mix . A first user generates some padding messages and their real unblinded token, permutes and encrypts them all, and advertises the result (In reality, he may need to do this many times, for a zero knowledge proof that he isn't screwing it up). Then a next user takes the result, adds their own blinded message, permutes the set, and reencrypts it all, and so on.After cycling through all users several times, they decrypt, and the result is a randomly ordered set of output address messages which have all been signed by the whole group, but they cannot tell which users authored which. A transaction is created conforming to the agreed inputs and outputs, and all users sign.If any any point a user refuses to sign in order to jam the process their misbehavior can be proven to anyone who cares to know by showing them the signed messages from a failed round. After seeing a proof they blacklist the misbehaving fidelity bond key, and so DOS attacking this can be made expensive.I've omitted a lot of complex details (secure group random number agreement for consensus, constructing the ZKPs to show that someone isn't jamming the mix, etc) and waved my hands at things (like group blind signatures)... but its clear to me that it's certainly possible to construct such a thing. The engineering would be quite hard, as this kind of very lock-stepy everything proven algorithm is quite fragile compared to even Bitcoin. So, I don't expected it any time soon but I'm happy to know that it's possible if it ever actually is needed. In reality, I expect few are going to try to gum up this sort of thing, so in practice people could get away with much simpler protocols.