Quote from: Fuserleer on October 17, 2015, 02:14:41 PM

TPTB no disrespect to the work you are doing, its important nonetheless, just my thoughts. Its good to see at least something tangible coming out from your end finally

Thank you.

Quote from: Fuserleer on October 17, 2015, 02:14:41 PM

Quote from: r0ach on October 17, 2015, 01:31:48 PM

Larimer thinks you can have anonymity in such a system already:

For once I agree with you, if most transactions take place off chain/ledger/whatever then the majority of transactions are "anonymous" as they are not publicly recorded.

Smooth and I discussed this I believe in 2014 and the conclusion is that everything sent to the internet can be recorded, so there is no such thing as off chain anonymity (CoinShuffle excepted, and also CoinJoin if jamming and DoS is not your worry) if you are referring to protection against national security agencies and government capital controls.

And if for a business or high net worth individual, then you may also want to be very safe against espionage and mobsters, so again your upstream ISP, masternode/delegated node, or what ever might be compromised.

Also one of the most important points is that only on chain anonymity obeys the End-to-end principle of networks. The means your anonymity is orthogonal to any agent in the network. This is critical for scalability, redundancy, and resilience.

So please enough with the off chain anonymity. It is highly inferior. It is a hack that got some play in terms of quick way to get anonymity rolling (e.g. Dash), but it is not the future. If the internet had been invented without the end-to-end principle, then TCP/IP wouldn't work and we'd not have the scalable, resilient internet we have today that enables to even be here.

Except for CoinShuffle, Off chain mixing = trusting someone (node/server) you can't prove you can trust.

Here follows the section from my white paper on this topic.

Quote from: my whitepaper

1.2 Non-autonomous strategies

Non-autonomous strategies for achieving untraceability and unlinkability require interaction between third parties; whereas, autonomous strategies are non-interactively and autonomously constructed by the originator. Non-autonomous strategies violate the end-to-end principle because the intermediariesbetween the originator and the construction of a transaction to the destinationare capable of harm, not substitutable, or not fungible. Put more abstractly, the intermediaries are not idempotent, referentially transparent, transitive, and commutative.

Centralized mixing services such as coin mixers and VPNs require unprovable trust. The user must trust but cant prove that the operator of the service is honest, hasn't been covertly forced to sign a national security gag order or other form of coercion, and the service hasnt been compromised by its employees, hosting provider, or a powerful adversary. Coin mixers are also susceptible to transaction graph analysis^[Mös13].

Low-latency, decentralized mixing networks such as Tor and I2P are littered with anonymity holes such as Sybil attacks on relay nodes, traffic correlation^[Tor09], asymmetric correlation[VLR14] identifying up to 91% of circuits^[SEV15] with mitigation at best 5.1%^[NSZ15], ephemeral intersection^[I2P10], vulnerable hidden services^{[Tor13, Tor14]}, and relay lookup leaks^[WMB10]. Additionally these networks open gaping holes in anonymity when combined with the reputation based DoS protection in Bitcoin^[BP14] and other cryptocurrencies.

The state-of-the-art of non-autonomous strategies is CoinShuffle^[RMK14], which provides unconditional security of the anonymity set for all non-colluding, non-adversarial participants of the mixed transaction; and is guaranteed to complete after sufficient blame rounds. CoinShuffle lacks unlinkability; and it suffers the same implications of Cryptonotes requirement of equal denominations for the mixed inputs. All CoinJoin^[Max13] derivatives including CoinShuffle suffer from a simultaneity requirement which has implications on useability. Although denial-of-service is filtered in the blame rounds, it could theoretically exacerbate delays impacting viability of completing a complex multi-party interactive protocol over the extended duration. Permanently banning a blamed input from all CoinShuffle mixes would destroy fungibility, because for example an input could be spent to another address which could be an innocent third party.

Quote from: Fuserleer on October 17, 2015, 02:14:41 PM

Its kind of a catch-22 though I feel, as high anon + scaling to high load is very difficult and I don't think concealing the value of a transaction is going to play nice with scalability.

I solved that, but that is not what I am going to release now nor discuss now.

Quote from: Fuserleer on October 17, 2015, 02:14:41 PM

I'm betting on decoupling the sender from the receiver being the best workable solution to achieving high anon + high scalability, where the sender is unable to discover where exactly the payment ended up in the ledger nor discover any information about the receivers account (balance, historic transactions).

Well I have more surprises up my sleeve. This white paper isn't the only one.