Cryptocurrency:

[other.arkitech]

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, June 9, 2020 5:23 AM, Zenaan Harkness <zen at freedbms.net> wrote:

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

isn't it in the 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!

Let's assume the netowrk runs with chaff traffic.
knowing your IP4 doesn't mean knowing your tx activity.


>
> > > > 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.

What is this sentence about?
now you listen, any hard problem can be decomposed so each part is simpler.


>
> 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."

What's the problem mate? you think I can write a paper on each answer?

>
> 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...
>

I wont. it looks like I am begging for feedback. I am not.



> > > > 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.


I use the term anonymous when in the context I use it it doesn't exist a way to discover the identity, or it is not supposed to exist unless a glitch, or if the potential breach comes from traffic analysis where chaff overlay is responsible to address.
Pseudo-anonymous, when there exist a complex but possible way to breach anonymity.

Sometimes I use anonymous meaning pseudoanonymous, but only when the context is not focusing on anonymity.

Now you can explain why did you say it.




>
> Perhaps create some new, more verbose, and less misleading and hopefully actually accurate terms, e.g.:
>
> -   account bound to IPv4 address

accounts and IP addresses are necer linked

> -   account not bound to IPv4 address

all accounts

> -   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.

I think we might at the same level of accuracy in the terminology, aren't we? Unless you want me to use 3 adjectives each time I have to refer to something

>
>
> > > 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.

Coming with your complain on my accuracy I see how unclear is your statement, because you could be more precise and state the biggest concern the topic suggests to you, instead of saying I dont understand anything)

>
> > 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.

IP address doesnt connect with your addresses, even if you do traffic analysis (bcs of chaff traffic).





>
> > 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!

By the time they are prepared and incentivized to run 10K nodes the network would be 10M. Those big-but-slow players are not a concern to me. They will be offseted by honest players.



>
> > 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?

I can see that you cannot find any circumstance for this sentence to be correct.

Let's assume I know your Ip address.
And assume I know who you are bcs I am your neighbour, the hacker.
I learn you are having traffic using some TCP ports and exchange some encrypted messages with others.
I disconver easily you are running an USPS node.
I run one as well, and eventually I make my node connect with yours as a neigbout.
The I see in clear our p2p communication.
Particularly I capture a tx coming from you stating a disclosed amount is transfered from account A to B.
the system uses chaff traffic, so in the unlikely but possible case I work for your ISP or the Cybercrime dept I could do traffic analysis, examining your IO activity.

Now Zen you can continue to explain how do I do in this assumption to learn more about your financials because I am short of ideas at this point.



>
> > > 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.
>

I have not any secret sauce, I have just a codebase, which is kept not public until all conditions are met.
Some self-help (I want to call it that way) adding nodes will help opening the sources and with it the possibility of network forks.
The bigger the network is the more comfortable I'll find myself to open the code.



> 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?

Sorry I cont have a clue of what the problem is, is it the subject?
"Re: Cryptocurrency:"

is it the address? cypherpunks at lists.cpunks.org