Quote from: Chronikka on July 05, 2014, 04:44:00 PM

Quote from: Nite69 on July 05, 2014, 12:59:33 PM

I'm still wondering these problems that are related to coinjoin in general. There are 2 main problems: If there is not any other transaction to join, there won't be any nitesend/coinjoin transaction. The other problem is that when generating the joined transaction, someone who peeks and logs *all* transaction offers 24/8 would find out some information about coin owners.

But there are solutions to fix these. One idea to fix the first would be 'spontaneous nitesend mixer'. The basic idea is to allow wallets to collectively mix their coins to a brand new, first time used coins. This mixing transaction could happen either on predefined time or after wallets collectively find enought participants. In practise that would mean: you check the 'mix my wallet' checkbox. Wallet broadcasts a mixing request and counts all received requests. When a treshold has been reached, all wallets send one transaction with random sized newly generated output coins. This could be repeated just as often as wanted.

What about block chain bloat? Implementing this solution in a way that isn't easy to trace will require a lot of "mixing" transactions. It will take time for those transactions to confirm, slowing the overall nitesend transaction time and adding extra "bloat" to the block chain.

Of course, it will fill the blockchain with some extra transactions, but I would not be worried about it's effect on the size. If we look at the transaction amount on bitcoin, there will be no problem.
One would not need to do it very often. If you mix your complete wallet and distribute it to 20 different coins, and 10 other ppl are doing the same, it mixes the taint analysis quite well.
But I originally noted they should be random sized; actually defined size is better. Otherwise peeker would be able to count which input group sums upp to what output group. But if there is 200 coins of size 0.01, it is impossible to tell which output was coming from what input.

Quote from: Chronikka on July 05, 2014, 04:44:00 PM

Quote from: Nite69 on July 05, 2014, 12:59:33 PM

Another idea to prevent peeking the nitesend transactions would be using crypted communication. In this case, we could use for example hyperboria (cjdns) technology; combined with sync, that would mean all sync coins would have an own ipv6 address and an encrypted communication link! Nitesend transaction could be collected by sending the offers throught these kind of links, securing them from all peekers. Actually, the whole comunication between peers could be done throught private hyperboria network. I guess it would be better than TOR and vpn together.

What do you think? The problem is that these (specially nr 2) need some work to do and I really am not sure if they are worth implementing. Would they add enought anonymity to be worth implementing?

This to me seems ambitious. Not going to say impossible because I don't know much about cjdns, just what it does. I think this could work but it would not be simple. The first question to ask, does this mean each of the smallest fractions of sync (i.e. 1 satoshi) will have an ipv6? Who initially determines the table and how is it verified? In order for it to work if I understand, there is a distributed hash table with all of the stored network addresses, so how do you drop that on the network?

No, not every satoshi has an ipv6 address, but every sync address has also an ipv6 address. In cjdns the address is practically a public key of a secret key. And the secret key of an sync address implicitely already have a cjdns ipv6 address.
You are right, it would not be simple. But if done, it would bring the benefits of TOR and vpn, and also UDP communication instead of TCP.