That is a good point! And I believe it is true, the number of UTXO would increase indeed. But I don't know by which factor (x100? x1000?) and how bad it would be, what is the size of an UTXO? If small, maybe not a problem to have 1000x more UTXOs.


Yeah, and then end up paying 50% of your bitcoins as transfer fees
Aside from that, you still have the hurdle of doing all of this transfer by yourself. (Okay, here one integrated solution would help).


I think it is more about privacy. Just imagine if all the bank transactions were public and not anonymous, which means, anyone could know exactly how much you have in your account and your payment history.
That is not something we want to share.
In today's Bitcoin it is not so easy to do that, but also not impossible. And this technique would only make it more difficult to get to that, and so improving privacy.


In lot of scenarios we face with the tradeoff invariant, but I believe this might not be the case.

There is already a project being developed to implement a system which makes everything anonymous. The key concept behind it is zero-proof (https://en.wikipedia.org/wiki/Zero-knowledge_proof).
The wiki page has a really cool example to understand it.

Zcash is one currency that is implementing it (https://z.cash/). 
I think they were the same guys under the name of Zerocoin, and both use the Zerocash protocol.

Maybe there are other altcoins doing the same, but I think that Zcash is the main one, where the researcher who proposed the Zerochash protocol is working on it.

For now it is under development. So until there we can keep implementing those 'hacks' to enhance current privacy.

Thanks for all the input!

Thank you!

This is pretty much what I was thinking! He calls Merge Avoidance and I called it Splitting Transactions.
Doing a quick search, i think that this was ignored or postponed by the community... I might look up on this and do some research on the effectiveness of this technique.

Hi amincd,

Do you know what is the current situation on this extension proposal?
I think it was ignored so far or postponed for future milestones...

I just had same idea (described here: https://bitcointalk.org/index.php?topic=1394184.0), and I might go and do some research on the effectiveness of the technique.

Thanks.

Yes, blending is an option, but if you don't need to blend, that would be even better.
CoinJoin you need to trust and find some peers. Using this transaction split, you only need to trust the peer you are dealing with.

This arise some questions, like how feasible and reliable are today's CoinJoin transactions.

Yeah, maybe not hard, but the 'trick' is to arrange with the seller how the transaction is going to be (with multiple transactions with sum of output summing up to original price).


I agree with you, but some scientific support here would be good. This would indicate that using transactions with change addresses is not really a problem.
But I was thinking in the cases where the change address can be easily spotted like say, you buy something from Walmart (and Walmart uses some known address).
That is, it would be nice to know how much of the transactions are like this (easily spotted vs. not so easy).


I think I get you, but it still links all the input addresses. I was working under the assumption that all the input addresses will be linked somehow, and I think this is how naive deanonymizing algorithms work (I was told that BitIodine does that).


Yes sure. This was another thing I thought before, but I was told that mostly transactions on the network with multiple input addresses aren't CoinJoin operations (and from this I was assuming to always link input addresses).

We can also view it this way, instead of trying to use the CoinJoin (which has it's disadvantages) the splitting of the transaction could take place instead.
CoinJoin would mix some entities (and maybe make some algorithms think it its only one entity), while the splitting technique avoids the linking at all.

I will look for some study on this, but I might agree that the case of newly generated change addresses might not be a problem.
However we still have the multi input transaction, where you suggest CoinJoin (which works at some extent) but this here might be another solution.

My goal here is to get more thoughts on the topic and then decide if this is a promising thing or not.
Thanks.

Hi all,

I would like to know the opinion of the community on this idea that I have.
Also I'd like to know if this was ever implemented before, but as far as I have researched I couldn't find any evidence of it.

Background
We know that Bitcoin is not an anonymous system but rather it is a pseudonymous environment.

Take for example, 4chan where users can make posts but there are no usernames or any sort of way of linking between different author's post. (anonymous)
Reddit, on the other hand, there are usernames and actions/posts can be linked because of that. (pseudonymous)

In Bitcoin anyone can have multiple public addresses ('usernames') and because transactions are public we can track everyone's actions.
In a transaction you are either paying or being paid, and that's how we can link different addresses to same entities.

Let's then consider both cases:

1) Receiving payment
Let's consider the case where you are being paid, and you don't want those payments to be linked to you.
An easy solution for this would be, for every new payment, make a new address, receive payment, done. No linking and you got the payment.

2) Issuing a payment
Unfortunately, this is a more complex situation.
Here the linking can happen in a transaction that will generate a payment change output address;
or when you use multiple input addresses to sum up for the amount you need to pay. The input addresses are linked.

We can break it down to 3 cases, depending on how much you need to spent and how much you own for some address.

Let's say you want to pay X bitcoins.

2.1) You have an address with exactly X bitcoins
Easy? Make a single transaction with input = output, however I see that maybe we need to account for transaction fees.
I don't know what is the likelihood of this situation, where you own X + Y bitcoins, where Y is the fee amount for the transaction, resulting in a 'no change' transaction.
This would be the case where no change is needed.
If you don't want this transaction to be linked to your original address, you could them use one of the mixing services before you make the transaction and 'break' the link.

2.2) You have an address with more than X bitcoins
In this case, the naive transaction will result in a change address. The problem is that now this change address will carry the history of this payment.
Also, if your original address was already identified somehow, then the change address will probably be linked to it.
The solution I see, is to breakdown your bitcoins by creating new addresses and distributing among them.
If possible, create one address with X bitcoins, then we are in case 2.1).
Again use some mixing service to 'break' the link with the original address and do the payment with no changes.

However I see it must be really hard to get addresses with the exact amount we want, and some mixing services ask for chunking the bitcoins in some amount they set.
And then we end up on case 2.3)

2.3) You have multiple addresses with less than X bitcoins.
This is where I am concerned on what people currently do.
I believe that users will just make transactions using multiple input addresses and make the payment, possibly with a change output.

If all those multiple addresses you own are originated from a mixing service, then maybe you don't really care that now you are linking again some addresses.
But maybe this linking can be detected and de-anonymized by an attacker because of the value of the transaction or because of the time it happened.
And you will probably end up with a change address that now is linked to all the input used.

But let's say you are WikiLeaks or another entity that gets payments(donations) on new addresses everytime.
If you use a multiple input transaction to make up for the amount you need to pay, you have just created the linking point for an attacker, and he can maybe detect who you are (by side channels) and infer the donors.


My proposal here is to increase the anonymity for users by avoiding the creation of multiple input transactions.

The idea is to breakdown the transaction value X into N smaller transactions with values that match up the buyer's bitcoin amounts.
This could be set with an agreement (maybe smart contract) between the buyer and the seller.
This way we can always try to get N-1 transactions of type (2.1) with no changes and only one with a change.
The advantage here is that there would be no link between those N transactions.

There are some details to analyze:
1) Fees, how many transactions is the user willing to create in order to have this better guarantee of unlinkability, taking into account the fees by transaction.
1.1) Maybe we don't mind linking some addresses, maybe some addresses are more sensitive. So we can split the transaction in various ways.
2) How effective this technique would be in practice, against current de-anonymizing techniques/algorithms.

To summarize I believe that this proposal, together with mixing services, could enhance the system privacy.

Please let me know your thoughts on this.