us - public system

grarpamp grarpamp at gmail.com
Thu Dec 26 03:14:01 PST 2019


On 12/13/19, other.arkitech <other.arkitech at protonmail.com> wrote:
> I'd like to receive more feedback

Some old, some new...

> closed sources running in a dedicated environment = no risk regarding security.
> For those concerned about running a node behind a firewall there is always the option to isolate it
> remote login ... ssh port 16671

DMZ or not, the box is internet connected, and nobody
knows what it's doing or can do. Even if not connected,
you could be trojaning their flash / firmware / microcode.
It's not your box, undisclaimed this would be unethical
positioning, especially for money environments, doubly
when it's not your money either.
If you need logins, run your own nodes,
and ask for $ if you need for buying them.

Sure people can be asked to accept the risks.
But missing the risks is not making crypto optics.

> But this is like disconnecting your OS from automatic updates.

If this is the reason, make sure people know
it's important for development that they pull
down their own updates. Besides, the ongoing
network will have so many old and hacked up attack
versions that now is good time to experience and
deal with that in protocol. Else the network will fall
apart on day one.


> It is fully AGPL only of the software is executed on a licenced mainnet
> The restriction is that if you want to run a private system ot generate another public genesis you have to be licenced.

A rather anti-fork iron-fist approach :)
Real crypto money is by nature anti-statist, and must be
generally anon to survive long term, else just admit fiat
and go use that. And who are you that is going to
stand and sue the planet, with what money (tax?).
And how are you going to sue when users take it on darknet
and screw your license anyway. What about how top-secret
actors and govcorp lawmakers won't care about abusing even
the HESSLA license to abuse users, or try to shut it down.
What about clean reversing and cloning the protocols.
Are you hoping to sell product to govcorp, that will be funny.
A real cryptocurrency should stand on its own
such that forks are not tempting or relavant.

Users don't want to sign up (aka: leak info) to
some central to run their money either.

And they won't want to be seen hooked to clearnet IP
broadcasting their transactions and traffic patterns into
trivially network analyzed clearnet. They will want TLS and
compatibility with onion / i2p / cjdns / socks5 and whatever
else happens to give at least some cases better than clearnet.



> Sybil / IPv4

Sybil attacks are mostly a human problem with mostly a
human solution, some web of trust. People have no idea how
easy it is for agents to spin up IP nodes worldwide, IPv4 is not
an obstacle for them.
Even Tor can nuke 100 fakeass nodes a month. Roll human
solutions into the node culture, and or pump adoption numbers
so high that Sybil becomes negligible irrelavant ratio, then
Sybil gives up and goes home, to run its own legit node
so it doesn't starve to death.
Politicians are a Sybil too, until you show them how to get
unstoppable decentral Swiss Bank on their own Phone :)

Also, there are millions of legit and desirable users behind NATs,
tens to thousands behind one IP... schools, corp workers,
phones, roomates, hotels, VPN's, tor... and users transporting
their nodes all over with them, etc. They'd end up blocked out.



> If in the Tor network the entry/guard nodes (who are witnesses of your IP4 address) could forward a hashed version of the IP4, I would solve the sybil protection based on IP4 without exposing the real IP4 address. I don't (initially) think it would compromise anonymity

Rainbow tables for all IPv4 IP's already exist.


> secp256k1

https://safecurves.cr.yp.to/
https://en.wikipedia.org/wiki/Post-quantum_cryptography
Sure BTC and a lot use secp256k1 so there can be
motivation there, but if for purely to follow potential
legacy BTC choice, that choice should probably
seek some review before deploy.

> As part of scalability solution I am spinning around the following idea:
> what problems I am not foreseeing this approach imply?

Seems to get into things like DHT, message routing
between clusters, etc. Not clear if you are seeking
potential solutions, or have potential one for review.

> mainnet beta 50 nodes now

So what is the launch mechanism...
Beta is a premine, no new genesis, leadtime till genesis, etc?


> Sounds impossible.
> In order to find the current state you need to process the blockchain.

This is legacy first implementation default ideation.
Seek ways to make what is thought impossible... possible.
It may be possible to do away with backhistory
and simply maintain a UTXO db. There were generic
posts on "UTXO" here, and some "history chain since
genesis not needed" "UTXO database" whitepapers do
exist out there on the subject, you will have to find and
post them please.

> investigate more on how cheaper a public system could
> be compared to current ones.

#OpenFabs and #GuerrillaNetworks


Publishing a philosophy and technical overview whitepaper
would assist all the understanding, review, and development
processes, and answer a lot of people's questions. Without
paper, or source code, it's hard to see what you propose.

Covering classic scaling, coin privacy, economics, consensus,
etc... all the usual issues, plus whatever your value add is.
Protocol modularity and ability to smoothly transition
any parts of the system as needed. etc.


You see how all the cryptocurrencies fight.
If you are creating something unique, just ignore everyone,
else they will take away the unique and any solution it offers.


I think I understand some picture of your coin philosophy,
and look forward to whitepaper for more. Thanks.


More information about the cypherpunks mailing list