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.
Yes I potentially could, and I assume you think I am evil. but still the unique point for raising concerns is the network activity, since who cares what is going on in the raspberry pi apart from how much electricity is taking or how much heat is dissipating. Think what do you know about the software running in your router, likely proprietary software, same thing. Regarding network activity all you'd see is around 15 connections to other nodes exchanging around 10kbps of encrypted packets. Particulrly you are able to verify the node is niether scanning the LAN not attempting to connect to any local computer. You can even run it in different vlan to prevent it. So, even when I am firmly an open-source advocate and the whole source code of the system will be released, this won't happen before I have enough user-base to justify the creation of a dev-community.
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.
Updates are pulled by an script on the node that retrieves signed binaries from other nodes. I do not need, as the one who is compiling the binaries, to have access to nodes. If I do during alpha development is only for development purposes and any possibility of anyone accessing your node including me is controlled exclusively by the node-owner.
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 :)
Indeed, although I support nodes working for different forks, I don't want to lose the mainnet (I call it channel 0) In fact I have running two forks. There are nodes working in both channel 0 and channel 4348 which is a licensed private network, different blockchains. I'd like to see a big number of forks with different ledger structures running different local economies. All nodes securing other blockchain also secure channel 0 blockchain, this is the main licence restriction, it is not about paying money for acquiring licences, to make a big public system.
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.
I am not enforcing licences. Think microsoft, they dont pursue home piracy, they just make sure big corps are paying for their software.
Users don't want to sign up (aka: leak info) to some central to run their money either.
This is anonymous system as far as underlying tech allows (IP4 transport).
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.
Information travels encrypted end2end, aka node2node
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 :)
My algorithm just enforces there are no more than 6 nodes per IP4. Enough measure to safely grow to million nodes from the perspective of 51% attack. Once reached millions, more nodes can be allowed per IP or even IP6 can gradually be enabled. The system doesn't care whether there are many people running a single node, or there is one person running multiple nodes. The global economy is run on the basis of nodes/addresses for the shake of anonymity. It can be assumed the network would stabilise on a node-human ratio distinct of 1:1. Which is fine. No need to enforce 1:1. Enforcing 1:1 would require disclosure of identities breaking anonymity.
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.
Innocent people could be prevented from running a node given the IP4 restriction mentioned above. But this would be happening only while the network grows in size. Reached a point, preventive countermeaures could be relaxed allowing the participation of more people.
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.
I am not tackling specially the problem beyond IP4 disclosure. I first solve the system assuming IP4 disclosure is OK for 80% of the people. If the demand goes big enough a separate work on how to hide IP4 addresses can be undertaken without invalidating any of the work done so far.
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?
The program is: genesis block, Node #1 - Nov-2018 FFF arounf the world invided to collaborate. alpha-rc6, Node #50 - Apx Feb-2019 Told everyone to not spread the word, so I keep maneageable network size for dev. alpha-11, around ~60 Nodes (Jan 2020) ... (more nodes, I invite more people, YOU?) beta ... 1.0
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.
For the shake of leveraging my effort I am not writing much literature yet. Will do as caring about the impl is less needed and can allocate more time to doc.
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.
That's how I am going on : )
I think I understand some picture of your coin philosophy, and look forward to whitepaper for more. Thanks.
Thanks to you, Cheers OA