Cryptocurrency:

[Zenaan Harkness]

(BTW, to be useful to more people, we ought generally keep such conversations on list.)

On Sat, Jun 06, 2020 at 11:11:31AM +0000, other.arkitech wrote:
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Saturday, June 6, 2020 2:07 AM, Zenaan Harkness <zen at freedbms.net> wrote:
> 
> > On Fri, Jun 05, 2020 at 11:28:30PM +0000, other.arkitech wrote:
> >
> > > In USPS, as long as the network is big, it makes harder -not impossible- to reconstruct the state from recorded transactions because nodes handle only a fraction of the traffic.
> > > Still, addresses are anonymous,
> >
> > I don't believe this statement to be correct.
> 
> the last one?, why?
> anonymous in the sense of bitcoin, where there is no easy link between addresses and people.

Let's keep it clear that "anonymous" in that sense is marketing guff at best, deceptive and misleading at worst.

Re useful anonymity, IPv4 addresses give you, literally, less than 'none' - they are -good- for tracking people and transactions!


> > > and nodes mix all of them as they arrive,
> >
> > Your mixing protocol will need to be well documented at some point, this is not the easiest problem.
> 
> Not easy, not trivial. Good thing is that I've gone through it already. So I speak about it backed with my impl that works as I expect.
> 
> 
> > For example, can a mixing protocol help to handle rogue clients (CIA writes their own USPS client) which does things it should not do, or does not do things it should do?
> 
> The system has been built knowing there's gonna exist evil tweaks to the code. So it is all about honest nodes dealing with untrusted nodes that are 'telling lies' or not following the protocol.
> 
> 
> > Some issues can be handled by protocol - as in, verifiable/ enforced by other clients - some cannot, and so those fail paths must be considered - are they important, do they only matter when predator nodes reach 50%+1, or whatever...
> 
> issues that cannot be verifiable/enforced by other nodes shouldn't be issues at all, but without mentioning any of those failpaths I cannot narrow a better answer to this.
> If -colluding- predators acquire >50% voting power, the network failed and the system burns in flames, collapses, eaten by a dark hole.
> Meaning that the situation is for an aeronautical engineer equivalent to an air crash where people die.

Listen - in computer communication land, any relevant privacy, any relevant anonymity, wallet safety, and much more, is really hard.

Every challenging question to you, is another opportunity for you to strut your stuff - NOT a benefit to the asker of the question (in general) -- so every brushed off question (e.g. "without you giving me really precise question, I won't put my mind to this further"), every non-answer (e.g. "it's all about honest nodes," "the design knows there are evil nodes" etc) is sort of telling us "I'm not going to explain the design further until I release it, y'all just have to trust me till then."

And that's OK - you are of course free to ask folks to wait, just test it, and trust you till then.

But please don't complain again that you are getting insufficient feedback, then wonder why the next conversation once again fell flat...


> > > making the equivalent of a big tx with many inputs-many outputs
> > > on every consensus cycle.
> >
> > Mixing may be good, may also have downside (?), but needs analysis by a number of people to assess benefits/problems.
> >
> > > Still yes, individual tx can be recorded as they arrive with a trivial patch. This would allow to follow the money across anonymous accounts. And this could lead to potential associations with separate events (e.g. I buy something and then I buy other thing; an observer could find a parallelism using time and sequence to narrow or find out addresses belonging to me).

As an aside, and by the way, I strongly, as in STRONGLY, suggest that you stop using the misleading term 'anonymous' in the contexts in which you continue to use that term.

Perhaps create some new, more verbose, and less misleading and hopefully actually accurate terms, e.g.:

   - account bound to IPv4 address

   - account not bound to IPv4 address

   - by default not recorded, node-internal mixing transactions

   - node-external non-mixing txn

etc etc

Some folks tend to take your lack of accurate terminology as deceptive, or at least as blatant marketing ... to state the obvious.


> > Also, IPv4 addresses are directly mapped to end users by ISPs therefore governments. ISTM that this mandatory use of IPv4 address actually precludes the possibility of true/proper/possible anonymous transactions - if this view/intuition is true, then this feature would make USPS a non starter for many folks ...
> >
> > > I have ideas to tackle these cases which are very real theoretically, although only for a minority of people would result of some real concern (to me is a concern))
> > > To be added in the future, as the concern grows bigger, a mixer implemented as a public algorithm (my name for ~smart contract). With this feature one could use it anytime they can break the potential traceability of their money moves, which is already difficult if the network is big.
> > > Privacy to me falls more on the ability to do real P2P end2end (real end2end) encrypted trades between 2 nodes without awareness of the rest.
> >
> > Except for time being, AIUI, you are demanding at the protocol level, an IPv4 address to transact...
> 
> IPv4 doesn't mean a privacy violation.
> Bcs IP can be traced to people, which is correct.
> But the think you learn from that tracing is that you are running a node of the network (and its address, which you dont need to use in your private activity).

These three sentences are unfortunately very unclear.


> You cannot trivially map any transaction, any other address observed in the system to any IP address.

But because of your IP address requirement, a node/client can trivially map all tx he processes.  You may not agree, but for those hunting for "better than BTCes" riches, that right there is an instant and easy elimination of USPS from their consideration set.


> If you could study traffic, you could deduce thing from patterns in traffic, which can be treated with a complimentary measure like chaff traffic.

Which is not of great concern to those who can afford to run 1000s or even 10s of 1000s of high capacity (read, naturally preferenced) USPS clients!


> Knowing that you run a node, it does not mean your activity is exposed

That is not correct.

This one is very important for you to understand - can you see why your statement is not correct?


> > Good luck,
> 
> HTH

Dude! these qustions are for you - they're what you need to answer sufficiently, or must answer via code or design doc, if you want the hope of seeing any relevant "market traction"...

If you are being seen (in the minds of the one's interested in USPS) an dodging or unable to answer foundational questions, they will likely wait a while for starters.

If you must keep your secret sauce private for a time, well OK, that's where you're at ... but again, may be don't complain too loudly when the conversation goes a bit flat.

Good luck.


PS: keep the tech convo on-list, time is precious and it's unfair to put the burden of assisting you onto one person. If you forget, is it ok in future to forward such emails to the list for you?