ZeroLink v2?

[nopara73]

Revisiting the original assumptions on ZeroLink may result in ZeroLink v2:

1. Originally, ZeroLink relied on the Bitcoin network fees to be at least $1. Today the fees are hitting $10, they are rapidly growing with no sign of stopping.
   A. High fees bring up the need for more elaborate fee estimation, because in a ZeroLink transaction everyone must agree on the fee rate. Loosely related issue about RBF: #56 B. High fees probably can simplify our current DoS and Sybil protection strategies.

2. In ZeroLink's prototype, its performance was unexpectedly good. A ZeroLink transaction happened within 30 seconds. Works are underway in the underlying Tor library that will likely result in near instant transactions.

3. New research directions they may be game changers: SNICKER #46 , Byzantine Cycle Mode #50 , Clusterfuck Wallet #42

4. Byzantine Cycle Mode #50 may relax the constraint of common denominations for CoinJoins.

5. In practice, it turned out completely preventing inputs to be joined together after the mix is not practical.

6. A Clusterfuck Wallet #42 may relax the prevention of input joining constraint.

7. Opening Lightning Network channels #58 via coinjoin is another interesting research territory. LN channel openings with common coinjoin denominations rarely results any convenience loss for the user. This can also help relaxing the input joining constraint. At this point, more research is needed about its pros and cons.

8. At the beginning ZeroLink was intended to work with both low and high anonymity sets. However for low anonymity set privacy solutions there is already JoinMarket, Monero and with its current usage patterns, ZCash. ZeroLink could compete much more effectively if its anonymity set would be high (100ish) from the beginning.
   Huge anonymity set also helps mitigating the risk of input joining.

9. There is a need to be able to send coinjoins into specified custom addresses. The Clusterfuck Wallet can mitigate the risk of possible privacy loss due to this.

10. While the community support was unprecedented, adoption from other developers were not as expected. Samourai wallet is aiming to build its own implementation, Breeze is written in the same programming language as HiddenWallet, so there are little to no costs to keep two implementations in sync, the DarkWallet developer who contacted me doesn't seem to be active anymore, other wallet developers were showing no interest.
    ZeroLink made many tradeoffs in order to facilitate its implementations across competing wallets. Also to maintain compatibility ZeroLink also specified many uniformity requirements, for example utilization of extpubkeys and the whole set of Wallet Uniformity Requirements. Such requirements can be safely removed.

11. ZeroLink needs more specific networking mechanism to be specified. Such works are underway, see ToT protocol.

12. It seems like there is a trend of people starting to be able to afford running their own full node. As the transaction fees are growing, people who can afford to use the first layer of Bitcoin are increasingly the ones who can afford to run a full node. If this trend keeps up, works on privacy preserving light wallets may be unneccessary.

[Pheromon]

10$ fees are a bad estimation: fees are much, much higher because they are paid to offchain services to accelerate the inclusion of an otherwise stuck transaction. I know people doing a tx with 5$ fees and then paying 120$ (in Bitcoin Cash) to "accelerate" it.

Anyway, I have a question: what is needed to port ZeroLink to Bitcoin Cash?

I would like to make some experiments there, since fees are about 1 cent per transaction and that means we can do a lot of mixing paying very little.

[nopara73]

@Pheromon

Anyway, I have a question: what is needed to port ZeroLink to Bitcoin Cash?

Higher fees for DoS and Sybil protection. ZeroLink assumes around $1 BTC fees. There are other defenses, but they are complex and must be figured out.

https://github.com/nopara73/HiddenWallet/issues/132 https://github.com/nopara73/ZeroLink/issues/32 https://github.com/nopara73/ZeroLink/issues/6

[Pheromon]

ZeroLink assumes around $1 BTC fees

So it's unusable in Bitcoin where fees are way higher, in the range from 50 too 100$ (probably more in the future, if Bitcoin will still be relevant).

To make it work on Bitcoin Cash so you could just require transactions with a minimum satoshis per byte, would it work as an antispam measure? (i.e.: simply ignore transactions with a lower fee)

[nopara73]

For DoS protection the higher the fees are the better it is.

To make it work on Bitcoin Cash so you could just require transactions with a minimum satoshis per byte, would it work as an antispam measure?

It's the other way around. Consider someone registers to a round with the intention of pulling out to DoS and break this round for everyone else. In this case the server bans that utxo that's been registered with and some relative utxos as well. Nevertheless, the main takeaway is: the attacker must make Bitcoin transactions to be able to register new coins into the mix. This DoS protection depends on if these outside of the mix transactions are expensive enough.

As I said, there are many workable ideas (https://github.com/nopara73/ZeroLink/issues/6) on DoS defense, yet, because fees are high, there is no need to overcomplicate it. Simple utxo banning can go a long way.

[darkrevive]

can you expand on point 5? I did not see that explanation from your post-article.

[nopara73]

@darkrevive, just to make sure do you mean the issue #5 or the point number 5 (In practice, it turned out completely preventing inputs to be joined together after the mix is not practical.)?

[jonathancross]

Note: bitcoin tx fees have dropped and stayed quite low for several weeks: https://bitinfocharts.com/comparison/bitcoin-transactionfees.html#6m (segwit tx are generally less than 10 cents now)

[nopara73]

@jonathancross It was unexpected and I worried about it, but then I realized fees will eventually go over $1 and stay there. Or in other words, if they don't that's the equivalent of the failure of Bitcoin, since that'd mean people don't want to use it.
I can think of a few things why fees went down so much:

1. The spam attack stopped.
2. The hype waters calmed down.
3. Segwit, batching, etc...
4. Better fee estimation algos, due to Bitcoin Core improvements. There was a problem that wallets were trying to outbid each other in a very aggressive way (eg. if the best fee to pay for the next block is $10, then they were rather paying $20, just to be sure.) Such strategy was not viable anymore and they switched to smarter algos(eg. if the best fee to pay for the next block is $10, then they are now paying $11 at the very maximum.)

Anyway, there are many strategies explained in the README.md that works against DoS attacks and if another DoS protection is needed, then so be it.

[darkrevive]

@nopara73 Sorry, I edited my post. I meant point 5: In practice, it turned out completely preventing inputs to be joined together after the mix is not practical.

We already knew that it wasnt practical, but I'd like to know more about the conclusions about preventing post-mix input joining. For example, is it hard to prevent or is it not as necessary after so many hops (eg 2 inputs from the mix could eventually fall into the same address but under control from 2 different people)

[nopara73]

@darkrevive In order that the user not to start kicking his computer, because of this, there are two conditions must be fulfilled:

1. The user must use Bitcoin a lot.
2. The user must be rich.

The reasoning is: they need to have a bunch of UTXOs.

However I was doing some napkin calculations about privacy loss of not MyMonero users against MyMonero. I've came to the realization that such privacy loss is tiny, even if MyMonero would do a big chunk of the on chain transactions.
We can apply this to ZeroLink, if input joining is discouraged enough, then it's probably ok, because others won't loose privacy.
Eg, here is an example on input joining discouragement: https://medium.com/@nopara73/coin-control-is-must-learn-if-you-care-about-your-privacy-in-bitcoin-33b9a5f224a2

As you may have noticed there are "maybe-s and probablies" in this answer of mine, it is because I was doing napkin calculations and to come to a strong conclusion I need to look into it deeper.

[darkrevive]

are there any studies about the growing number of hops from one address to another final address makes chain analysis more expensive? I think i remember something like that by reading about the Richochet feature that Samourai wallet uses.

I was thinking after so many hops post mix that it would be unproductive/expensive to come to conclusions about the original participants in the mix. in terms of UI, that could happen automatically.

[nopara73]

I'm not entirely convinced if that's useful.