He thinks that this solution is better because it doesn't require a code change to eliminate the 10 trusted nodes when they are no longer needed. Oh no! Not a code change. There's no way RealSolid can force that on everyone!
TL/DR: The stupidest part is the claim it would require breaking changes to protocol is false, granted it is a horrible excuse and KingRealScam hasn't worried about breaking protocol changes that transfered wealth from others to himself but the excuse isn't even factual.
Long version:Personally I don't like this kind of centralization but lets say you wanted/needed the trust nodes of ScamCoin but done in a nonscammy cryptographically secure methods which eliminates the need for single absolute control and massive premine.
1 ) Pick x people (could be 10 like in ScamCoin but the # could be open to public debate) to be "trustees". This is the part most manipulatable but if x is relatively large it reduces the risk. Some of those x entities could be pseudo random (lottery) to prevent concentration of power and seleciton bias issues. The key thing is a public open, and honest discussion. Satoshi took a year from his whitepaper to the genesis block and took advice, corrections, and improvements over that timeframe. Granted the community was much smaller but it was a public development.
2 ) Have those trustees (not a single person) privately and securely (offline computer, live distro) generate a public/private key pair (the exact method isn't important it could be as simple as a regular ECC public/private keypair).
3 ) Those x people (trustees) now publicly publish their PUBLIC KEY. Developer(s) will include them in the genesis block. The protocol is now protected by x trust nodes but no single entity has control over more than 1 of them. If x is relatively large it would require significant collusion to force any undesirable changes on the network. No doubt it is centralization but I will take centralization in hands of 20-30 unaligned parties than centralization in the hands of an all powerful tyrant any day.
4 ) We will call the x initial trust nodes "transition trust nodes" due to their limited nature and lifespan. The protocol is written so that clients maintain a list of current trust node public keys and use them to verify any trust node blocks. This will require a public list of trust nodes with timestamped irrevocable changes. Hmm where could we put that? Oh yeah the blockchain.
5 ) Written into the protocol is criteria for
"native trust nodes". It could be 1 million coins, or it could be x% of outstanding coins. The cutoff could change based on the block #. These rules can be debated publicly and openly before the genesis block. Changing those rules after launch would require collusion among 51% of trustees.
6 )
Wait CoinHunter/RealSolid says there is no method to handle transition to "native trust" nodes unless it involves coins. This is beyond foolish. Each node that meets criteria for trust node (see #5) would use a transaction to elevate itself and announce its public "trust key" to the network. Once included in a block, clients on the network will see this and update their list of trusted nodes. To avoid issues with re-orgs the elevation could be delayed 120 blocks just like generated coins are. The protocol (once again public and open debate) would include rules that allow native nodes to supersede transition nodes. So if the # of trust nodes is y and y is > x then (y-x) trust nodes are deactivated. Since clients follow the rules of the protocol without any breaking change they can simply mark transition nodes as disabled by predetermined rules. As one new native trust nodes comes online it will displace a single transition trust node. When there are x ACTIVE "native" trust nodes none of the transition trust nodes have any effect.
7 ) When 1 native node comes online the method to determine which transition trust nodes to displace should also be open and public. It could be deterministic random (based on combining the x public keys), it could be realtime random (based on a future block after native nodes goes online). It could be predetermined by the community with those having the most interest staying "live" the longest and hardcoded by a priority value in the public key (clients would disable nodes in order of priority).
8 ) Once all "transition" trust nodes have been permanently disabled, the relevant portions of the codebase could be deprecated and updated version of client issued which reduce the code footprint.
Optional ways to improve the system further:A)
Have revocation codes. Similar to SSL. Each trust node could generate at time of creation a cryptographically secure revocation code. If the trust node is ever compromised the owner could issue a transaction to the block chain signed by the revokation code which permanently kills that trust node. Much like SSL revocation once it propagates the blockchain and network, any compromised node becomes useless to an attacker. As long as all x initial nodes aren't compromised they system can still function even w/ some nodes revoked. When the client detects a block with one of these revocation transactions it will update its internal list of trust nodes to exclude the compromised ones.
B)
Allow transferring trust nodes cryptographically. KingRealScam says he gave access to the private keys. Of course this requires implicit trust which is asinine is a cryptocurrency. Even if he DID give the private keys he still retains them and could use them. One could build into the protocol a transaction in the block chain which would allow transferring control of a transition trust node permanently and irrevocably. When the client detects a block containing one of these "transfer" transactions it will update its list of transition trust nodes, adding the public key of the new node and and ignore commands from old node going forward.
C)
Have a hard block # of transition trust node termination. The use of trust nodes should be a community decision. If nobody wants them the transition trust nodes shouldn't stay in power forever. So after block z the hardcoded nodes simply cease to have any function. Alternatively one could have it that every z blocks one node is permanently disabled. This created an situation where native nodes must eventually "step up". Today if Bitcoin had a system like this I would imagine an entity like Bitpay, or MtGox would step up and pay the cost of being a trust node simply because they have a lot to lose if Bitcoin goes down. Having a termination date/block prevents allowing the network to be secured by the initial group forever.
D) Financial compensation for transition trust nodes. To provide compensation for service in protecting the network during the early blocks a "retirement" payment (generated from ungenerated coins) could be the output of the transaction that shuts down a transition trust node. Thus operators have an incentive to safeguard the network to collect their retirement.
E)
Blockchain generating trust nodes. Have trust node private keys generated deterministic and randomly by block signing. One implementation (obviously parameters should be studied and analyzed) every 1000 blocks if the block hash is above some "super difficulty" threshold then the public key in the coinbase (or largest if multiple exist) is elevated to a trust nodes. Clients detecting this will add this public key to their internal list of trust nodes. By having it occur only every x blocks prevents working in private to guarantee a trust node key. The logic being that while an attacker may by chance gain one trust node key it won't gain 51% of them randomly. Having the trust node keys generated only every 1000 blocks and at higher difficulty puts an upper limit on number of keys that can be generated this way. Bitcoin for example would only have 167 trust keys. If the "super difficulty" was 10x normal difficulty then on average only 16.7 would have been generated so far. To further protect this one would make a minimum "super difficulty" (say 1 million so that even if difficulty is 1 then super difficulty is still 1 million).
Had KingRealScam decided to make SolidCoin open and public these kinds of alternatives could have been discussed. His "rational" is that secrecy was necessary. Security through obscurity is no security at all. WEP, CSS, GSM were all kept secret to make them secure and all were flawed implementations.Once again I don't like the centralization this created but a system that was
a) allowed cryptographically secure transfers
b) ensures no single party has access to all "control codes"
c) doesn't involve millions of coins
is obviously superior to a system that
a) has no verifiable way to transfer ownership/control
b) ensures a single party will retain access to all "control codes" into perpetuity.
c) has the trust issue of millions of coins. Even people with good intentions can be tempted/corrupted.
