Topic: I taint rich! (Raw txn fun and disrupting 'taint' analysis; >51kBTC linked!) - page 3. (Read 22832 times)

This could also be used to reduce the damage from deanonymization attacks, like this appears to be: https://bitcointalk.org/index.php?topic=254615.40

I think so too, although "taint analysis" tools should be able to exclude those transactions really simply as not being indicative of all the inputs having the same owner. Though if the point is to demonstrate how simplistic the tools are at this stage, that might be good to try anyway just to force them to adapt.

If we use "SINGLE|ANYONECANPAY" then we can each make a transaction with 1 input and 1 output which just sends our BTC to ourselves, and gmaxwell can combine them all into a single transaction.  I think.

"SINGLE" meaning "I don't care who else gets paid, so long as I get my BTC", and "ANYONECANPAY" meaning "I don't care who else pays, so long as I pay my BTC".

Couldn't we use some of the more interesting signature types (ANYONECANPAY or something like that)? People could sign a transaction with their one input they're putting in, their output to themselves that they care about, 1 BTC to you, and you then just add your 1 BTC input from any transaction you want.

This is a great point, not often mentioned.  It's not just individuals or druggies who need privacy.

Sounds good to me.

If multiple people sign for the same output I can only accept one.  After the first couple collisions I ended up listing a bunch of outputs to make collisions less likely.

This capability is essential for Bitcoin.  I can think of very few companies that would like the thought of anyone, especially their competitors, being able to obtain intelligence regarding their financial transactions via blockchain analysis.  While it might be useful for criminals trying to hide illegal activity, it's table stakes for any corporation wanting to use Bitcoin in a substantial way.  Not only does this capability need to be available, its use needs to be easy and widespread.

Perhaps it would be better I try to explain in laymanish what I did understand and someone correct me.

Originally I figured he just meant that if you have X bitcoin and he has X bitcoin, together you can mix the bitcoin and redistribute them in such a way that multiple inputs and an obfuscated list of multiple outputs removes the ability to trace the output address to the original input address...

Say we both have a single bitcoin. We put it in a shared wallet (which we both sign) with a list of respective output wallets. After both bitcoins have been collected, we both sign the transaction to distribute each bitcoin to each wallet. Someone looking from the outside wouldn't know which wallet is whose (in this case they'd have a 50-50 chance of guessing). Of course, when there are more than two involved, I understand there is some way to ensure that each participating member doesn't know which output wallet is whose - but I don't understand how.

Another thing I don't understand is that if all participating members have to sign the outgoing transaction, wouldn't that be a system prone to abuse? I'd put my bitcoin in the pool, but if there are 1,000 other participants I can just forget my bitcoin and never agree to sign a txn that would free those bitcoins and everyone loses.

So where in all this did I misunderstand?

I guess he didn't want to promise to sign transactions from everyone.  What if too many people responded?  He's going to chose the 'best' ones in some way.  Each of his 1 BTC outputs can only be spent once after all.  It appears the demand has been less than overwhelming, so I expect he's just signed all the transactions he has received.

What I don't understand is the following:


If the point is confusing those analyzing the blockchain, then why do we have to make attractive offers? I was definitely going to try until I read that.

I can try.  How's this?

Can someone please explain all this to the layman?

Another email received transaction a511bea3b5dc09609c4853d817cde909fdcdc06cc9558500f155ca821d0d511b, spends vout:8

Deleting these 2 lines from the source allows createrawtransaction to make transactions with duplicate output addresses:

I literally wrote the transaction hex by hand— the format of a transaction is all byte aligned, and it's not actually too hard to just type one in. (Obviously I didn't sign or convert the addresses to hex160 by hand, but I just copied them from createrawtransaction output and used the regular signrawtransaction command). This comic is relevant.

While I'm here— c3962bbe60d5a22a67e6814b28342e3affdc07357cae2e9abab3f2bc01f251eb  is a 1000 BTC transaction someone sent to me.

Do you mind sharing what tool you used to do that? bitcoind doesn't allow the duplicate in createrawtransaction

The following tiny patch allows me to send to the same address multiple times from the reference client:

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 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.

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.