I'm still trying to get caught up on all the new stuff (I haven't made it through all the white papers yet), so just direct me to the right part of them if these points are addressed there.
There has been a big emphasis in your posts here on getting community involved in the writing and documentation over the last couple months. I see no wiki. Is there any action on this front? Are you waiting until you can build one Aether before starting this effort? I assumed the Whitepapers up on githhub were an attempt at this, but I don't see any calls for editors, and my pull request for some edits as just sat there for ~1 week now. I figured I might as well contribute edits as I read the docs, but if you aren't ready for that I'll read+edit them later. I'd be happy to setup a wiki if you want one and give you admin rights on it. I can't offer much of my time to moderate or administrate it though.
Proof of stake elections and 51% attacks: If you want to resist 51% attacks, is it really a good idea to give a party with a majority of the coins the power to do what ever they want with the source code? Would your mentioned plan of putting the source in the blockchain be used to push out auto-installed patches? (Developer elections -> put horrible malware in code -> store source in blockchain -> everyone update to malware). Any automation of patches is asking for someone to send out a steal all the private keys patch, but it could be a bot net patch aswell.... With deterministic wallets, you are pretty screwed if something like that slips in (most users will just have one key you need to steal, and then legit and attacker transactions are indistinguishable).
From a security perspective, it is your view that having exactly 1 implementation of skycoin is the best option, correct? (Just a clarifying your view here)
Given that you are looking at running downloaded code securely (at least I think thats what your application stuff is for), have you looked at
http://genode.org/? They do nice things like per processes virtual file systems, have a secure microkernel etc. Run it as an is or vm/application on your host OS, and run your services inside it and you get robust isolation of native code. They have some done some nice work making their ports identified by a hash of their inputs lately (
http://nixos.org/ style): it seems like a platform that might interest you.
The meshnet is intended to be a nice privacy tool with benefits comparable to tor, but lower latency correct?
The meshnet is intended to allow funding nodes via micropayments in skycoin to cover bandwidth costs correct? Doesn't this leave force all node operators to record detailed and published logs (on their personal block chains) describing all the transactions which inherently correspond to everyone who send data through their node? This seems like it would allow any third party to do traffic correlation attacks much like the ones on tor, except you don't need access to the connections. Even if they don't end up being publicly inspectable, logging everything seems like it might have some real issues (it can be requested by law enforcement, and takes up a lot of space)
The initial version is going to ship with centralized route finding server correct? This means if you want to connect to someone, you have to tell a third party about it, correct? It seems like this is not a Tor like privacy service until that's fixed. Is there reason to believe you will find a solution to this soon (or ever: its hard)?
How do you find a route to this trusted third party which will do route finding for you? I assume you will just special case it (don't use sender side route selection), but I'm curious if you have another design.
Most of the time I check out the master branch it is horribly broken. With the impending IPO, are you going to have stable release branches, which will generally work and have few (easy to review) changes? I have no interest in blindly running binary someone ships, or being stuck with some random old revision that happens to be known good and miss any fixes.
Can you guys please provide better commit messages? Looking at
https://github.com/skycoin/skycoin/commits/master shows lots of commits with the same message just referring simple to something that I don't know what it is, some project area, of even just "changes", or "test". The last 3 were better: please continue that trend.
I expect a lot of nodes (say my phone) will want to simply ask a bunch of random nodes for the network state (block chain, and consensus status). It doesn't seem like there is an incentive for nodes to spend the bandwidth to inform anyone who asks of their consensus state, upload blocks etc. Are you just assuming enough people will bother to run nodes that provide these services that things will work? (It seems like a reasonable assumption, bitcoin nodes do exactly this, I just wanted to check). I suppose such requests could come prepaid for return bandwidth, though that just makes nasty lazy nodes that don't respond make money...
Is this the right place to post such questions? Should I just pose such things here, or is there a place not buried on 60+pages of overlapping discussions for addressing such topics? For stuff thats more issue like than question like I can post issues to github, but my issue there hasn't been responded to:
https://github.com/skycoin/whitepapers/issues. Should I post such issues here as well?
Are you using cryptographic accumulators at all? I have to wonder if there is some neat cryptographic accumulator trick that could accumulate signatures.
To check that a given claim some node made in the past (some signed block from their personal block chain) is in the block chain they are currently publishing, you need to ask for the current node then get (at least the headers) of all the nodes back to the node you are interested in so you can check the hashes, correct? It seems you may have thought of this, but in-case you haven't, you know you could put the hash of the node 100 nodes back, and one 10000 nodes back etc. in each node (or just every 100th and 10000th etc respectively) and effectively get a skip list for fast checks. It seems like minimizing the cost of checking this kind of thing will be pretty important as part of making random audits of nodes cheap and easy.
Anyway, so far the consensus process using the personal block chains seems like a pretty robust/secure design. I'm looking forward to reading further into the whitepapers to see the details: getting it to be efficient storage, bandwidth and computation wise seems like an interesting challenge.
Yes. Please figure out some way we can streamline communication.
The original plan was to put it on Aether, however it will be months before that is working. The networking refactor was a major headache, was a massive amount of work and ended up going nowhere, but took four months. The upside is that we have a very clear architecture now.
The current plan, is that the IPO prospectus is being written. It is about 200 pages. It lays out each component in the Skycoin project, in the details required for implementation. Then coin bounties will be assigned for implementation.
Then we will focus on the meshnet/darknet implementation, put bounties on what we can and focus on the consensus mechanism implementation once the libraries we need are ready.
Skycoin is written as a series of libraries. The libraries are general and reusable. There libraries for networking/rpc, for parsing a blockchain, for replicating blocks between peers, for cryptography and so on. The problem is that writing good libraries requires significantly more design effort than writing blobs of code that merely work.
The community has to take over as much as it can and operate independently of the developers. Maybe we can use a ticket system for bounties?
We can quickly get the software working for transport and encryption working, but the meshnet development has to be on a ticket/bounty system to get all the components in place. We are scoping out the meshnet requires right now and writing up documentation/guidance.
Then there are other organizational issues. We have coordinate with the meshnet hardware groups, do testing, share results, hardware selection, ordering and coordinate local community meshes to get long distance backhaul connections setup. We need software for mapping the meshnet nodes, for reporting connection statistics and allowing node operators to optimize their deployment topologies.
For instance, we need someone to construct a platform that rotates in x/y plane and has controllable tilt. We need to put an antenna on the platform fed with standardized power level and need to put a hackrf 20 ft away and need to measure transmitted power density at the receiver, as a function of angle for different antenna configurations. This data will tell us minimum power we need to transmit with for line of sight to reach a given bandwidth over a given distance with a given noise floor for the receiver.
We need a way of locating Skywire nodes in physical space. We need a cheap active phased array element circuit for inducing phase shifts in a 2.4 Ghz signal. A system might use a GPS and two antennas and measure signal strength from a Skywire node using a HackRF as a function of the induced phase shift between the antennas. That would give us a direction. Multiple readings from multiple positions would give us a spatial position for node. Then people have to put these on their cars and collect data as they are driving around.
Data like this, would probably be uploaded to an aether store as its collected and then aggregated by other applications which expose it over APIs over which other applications can be built for visualization.
We need terrain topological maps. We need to be able to determine which mesh sites a person has line of sight to if they are in third floor on the south side of a building in a particular location. We have to identify collocation sites that are neural and can provide backhaul, so we are not reliant upon comcast and have to establish long distance links spanning out from those sites.
We need nodes to automatically report bandwidth and connectivity statistics (probably into an Aether store). We need reporting for fine grained performance statistics on noise floor, signal strength, connection reliability, throughput and latency. Then we have to aggregate and expose this data on an API for applications.
The earliest network will just be nodes peered over internet. Then a physical mesh will be built out with fixed, point to point directional antennas using commodity 802.11 wifi. Then we move into specializations of commodity 802.11 hardware and eventually a full Software Defined Radio (SDR) network.
The ideal network is going to be point-to-point with directional "pencil beams". By using multiple antennas and inducing a phase shift between the signals through each antenna, we can do active signal rejection so we are only receiving signals coming from a particular direction. Active signal rejection also enables us to triangulate node positions in physical space. We can also transmit highly directional beams that focus most of the beam power on the receiver instead of irradiating it into space.
An ideal hardware configuration, would be something like a 16x16 cm flat sheet with a 4x4 antenna array that someone can just hang out their window, place in window or put on a roof.
A six antenna 2.4 Ghz phased array setup may be as simple as a few variable capacitors a transistor and a $4 arduino or it may be significantly more complicated. Hardware manufactures are reluctant to produce chipsets for the 802.11af whitespace that just opened up because of the FCC requirements. Chinese companies have released extremely powerful $15 to $35 USB Software Defined Radio (SDR) devices that are the size of a USB stick, but which can only receive. We may need custom ASICs or to partner with company building the devices.
We are also trying to standardize on UniPro bus standard for our hardware and we need an open source UniPro bus IP core. UniPro will be able to handle everything except the communication between the ADC and FPGA block.
Then there are questions about whether we should do the Quadrature Amplitude Modulation in the Analog to Digital Converter (ADC) block or whether we should just capture the signal and handle it in the FPGA block. Then there are cost questions, such as whether we can get by with an 8-bit resolution on the ADC.
Ideally we want something going up to 900 Mhz with at least 20 MHz bandwidth around the base band and at least four antenna ports, with ability to modulate phase shifts on the antennas ports and it should be single chip, then we would feed that into an FPGA. Even with an open source design, it will cost at least $120,000 to get something like this at minimum order volumes.
So the meshnet has multiple components. Meshnet will have many more teams than the coin/software side and the requirements are much more specialized. The hardware component of the meshnet effort is going to be an absolute decentralized mess, but will workout. People will have to form their own teams and manage them. The only thing we can offer is funding and guidance.
The objective is to get the price down as low as possible, so we want multiple providers, open source hardware. We do not want to be a position like the Trezor, where you have a piece of hardware that everyone needs and its $700 when it should be $5. We are talking to several hardware vendors and offering coin subsidies to offset the large cost of minimum hardware quantities.
The software, we are confident we are on track for meeting requirements for the coin. Even if it is taking significantly longer than intended. The meshnet to be more than a toy however is going to require massive organization on the ground at community level.
== Project Org ===
We have no idea how this is going to be organized. I think
- write up project spec in detail for each component, at level required for implementation
- launch coin
- assign bounties on sub-projects. setup ticketing system for managing sub-projects
- Get aether working as a wiki and for publishing webpages
- Get aether working as discussion board
- Get messaging users by public key working, so we can have email/bitmessage type system
- Move project management in Aether/Darknet
