AI Coin Development Diary

[CIYAM]

As I have stated the CA system is *flawed* because of *trust* (just search for "ca certificates hacked") to get a start (do I really need to post the links?).

The Finney attack is nothing new and so I don't see why it is relevant especially as you have shown no way to avoid it (apart from relying upon the CA system which is flawed).

[SlipperySlope]

As I have stated the CA system is *flawed* because of *trust* (just search for "ca certificates hacked") to get a start (do I really need to post the links?).

Thanks for the search tip. You are awesome CIYAM!

I spent the last 50 minutes watching an informative video on certificate man-in-the-middle attacks that linked in the OP. Fortunately, I can use SSLSniff to attack the network and trace the certificate validation through the Bouncy Castle source code to ensure that this particular attack vector is closed. I already set the X.509 Basic Constraints properly for the root, intermediate and end-user certificates. An additional hurdle for an attacker is that my system has client as well as server certificates, which I will test with the SSLSniff tool. I searched the Docker registry for a container with this already built, but it should be easy given these instructions.

SSLSniff works on a LAN, e.g. public WiFi network. This design somewhat protected by virtue of white-listed IP addresses for known full nodes.

I suppose the best defense against man-in-the-middle attacks is to use the same techniques as does the bitcoin protocol in which transaction messages are signed by the sender with their private key. I can modify the expected node heartbeat messages to include a signed hash of the inbound and outbound traffic which a network operations agent can check for omitted or extraneous messages performed by a man-in-the-middle attacker.

A goal now is to accumulate a suite of attack tools such as SSLSniff, Metasploit, etc., and record TexaiCoin responses to those attacks to back up my claim that a cooperative coin network is as secure , if not more secure, than Satoshi's Bitcoin.

[flipperfish]

There have already been documented cases of private keys being compromised (not sure if that led to the shutting down of any CA but it might have).

The fundamental problem is that CA is *not decentralised* therefore it is a weakness and not something that can possibly *improve* the idea of Bitcoin (in terms of the Byzantine Generals problem and its solution).

Ok. In this system each full node has a copy of the root certificate. The distributed certificate servers use an intermediate X.509 certificate. Validation by TLS/SSL endpoints at the full nodes perform validation of the chain from root --> intermediate --> end-user, which is a software agent role.

Suppose the root key is lost somehow. The chain validation still works. The software does not check for certificate revocation. Bad nodes are simply banned.

How do you plan to detect bad nodes?

Peer agents perform remote attestation of each other's behavior. Tamper-evident logs record context, inputs, actions, and outputs, which when replayed by a validating peer, confirm good behavior or detect bad behavior, e.g. a byzantine fault.

Don't you need special hardware to do remote attestation? The common known remote attestation schemes use a central service to certify the hardware.

The research that I referenced in the May whitepaper for this technique gives the math proving overall good behavior with up to 50% of the nodes faulty. In contrast, Satoshi's Bitcoin can be corrupted by a single mining node with 51% of the network hashing power.

What about sybil attacks? In satoshi's Bitcoin a single node either has the economic power to lift a 51% attack or it doesn't. It doesn't matter over how many nodes this is distributed. A counter measure to sybil attacks would be to have signed each node by a CA. The other nodes verify this signature and won't allow more than one node with the same identifier. But then again the system is centralized.

[SlipperySlope]

Don't you need special hardware to do remote attestation? The common known remote attestation schemes use a central service to certify the hardware.

I will not be performing remote attestation at the BIOS and kernel level until such time as the project is successful enough to employ a specialist.

TrouSerS FAQ

Rather, my approach is to perform remote attestation at the application level. Peers inspect each other's tamper-evident logs verifying expected good behavior and detecting faults.

What about sybil attacks? In satoshi's Bitcoin a single node either has the economic power to lift a 51% attack or it doesn't. It doesn't matter over how many nodes this is distributed. A counter measure to sybil attacks would be to have signed each node by a CA. The other nodes verify this signature and won't allow more than one node with the same identifier. But then again the system is centralized.

The Texai system works as you describe it as each node has an X.509 certificate. The system has a self-signed root certificate and is its own certificate authority. De-centralized Intermediate certificates are used to create the end-entity certificates for the nodes/roles. These intermediate certificates are widely distributed in the system. Each node has a copy of the root certificate, but not its private key.


Note that Bitcoin Core allows TLS and X.509 certificates already for RPC calls and for the new Payment Protocol. Texai does not need certificates for nodes to ensure third-party verification of the association of a public key with either a web domain name nor an operator's real name. The certificate is used to contain and publish the public key and to permit TLS authorization and encryption of the network traffic. Each operator, indeed each communicating role in the network has a unique UUID that is its identity. The certificate guarantees that whoever uses it has the private key in their possession. I believe that each user could hypothetically create a self-signed certificate and the Texai system would still work OK.

When generating x509 version 3 certificates I use RSA with a key length of 3072 bits and SHA256 with RSA as the signature algorithm. This works on Java 1.8 with the high encryption strength policy enabled, and also works to encrypt websocket traffic to Android and IOS clients. As certificate validation is entirely in my control, e.g at both endpoints of a TLS version 1.2 connection and with all the entries of the certificate available, I believe that the Texai network is resistant to Sybil attacks.

[SlipperySlope]

I am working on the minimal set of Texai software agents that will operate a bitcoind instance on my Ubuntu laptop for hallway demonstration at the Hashers United Conference to be held in Las Vegas in October.

Meanwhile, I learned about the Raft distributed consensus algorithm that provides an off-the-shelf solution to how to robustly select the mint agent from among the set of candidate peers. There is an implementation in Java at GitHub that I linked in the OP. And here is an animated illustration of the algorithm as prepared by Ben Johnson ...

http://thesecretlivesofdata.com/raft/

This algorithm is robust against failing nodes and partitioned networks, but not against byzantime, e.g. malicious peers. I will handle the latter using Nick Szabo's method of remote attestation of peer behavior by inspecting their respective tamper-evident log files.

[prophetx]

interesting 

[flipperfish]

Don't you need special hardware to do remote attestation? The common known remote attestation schemes use a central service to certify the hardware.

I will not be performing remote attestation at the BIOS and kernel level until such time as the project is successful enough to employ a specialist.

TrouSerS FAQ

Rather, my approach is to perform remote attestation at the application level. Peers inspect each other's tamper-evident logs verifying expected good behavior and detecting faults.

How can you detect tampering with logs on remote peers? I mean a peer not controlled by yourself could send you anything as logfile.

I currently also fail to see how remote attestation on application level could work. As far as I know, remote attestation is only reliable, if there is more or less sealed hardware envolved, that acts as a root for a chain of trust up to the application. So the user performing the remote attestation has to trust in the inability of the attestee to change the sealed hardware and employ his own root. Do you have any ressources to point me to, where remote attestation on application level is explained?

What about sybil attacks? In satoshi's Bitcoin a single node either has the economic power to lift a 51% attack or it doesn't. It doesn't matter over how many nodes this is distributed. A counter measure to sybil attacks would be to have signed each node by a CA. The other nodes verify this signature and won't allow more than one node with the same identifier. But then again the system is centralized.

Note that Bitcoin Core allows TLS and X.509 certificates already for RPC calls and for the new Payment Protocol. Texai does not need certificates for nodes to ensure third-party verification of the association of a public key with either a web domain name nor an operator's real name. The certificate is used to contain and publish the public key and to permit TLS authorization and encryption of the network traffic. Each operator, indeed each communicating role in the network has a unique UUID that is its identity. The certificate guarantees that whoever uses it has the private key in their possession. I believe that each user could hypothetically create a self-signed certificate and the Texai system would still work OK.

But if each user can create his own certificate (more ore less for free), doesn't this open the door for Sybil attacks?

[mr_random]

Nice selection of links in the OP! Bookmarked!

[SlipperySlope]

Don't you need special hardware to do remote attestation? The common known remote attestation schemes use a central service to certify the hardware.

I will not be performing remote attestation at the BIOS and kernel level until such time as the project is successful enough to employ a specialist.

TrouSerS FAQ

Rather, my approach is to perform remote attestation at the application level. Peers inspect each other's tamper-evident logs verifying expected good behavior and detecting faults.

How can you detect tampering with logs on remote peers? I mean a peer not controlled by yourself could send you anything as logfile.

I currently also fail to see how remote attestation on application level could work. As far as I know, remote attestation is only reliable, if there is more or less sealed hardware envolved, that acts as a root for a chain of trust up to the application. So the user performing the remote attestation has to trust in the inability of the attestee to change the sealed hardware and employ his own root. Do you have any ressources to point me to, where remote attestation on application level is explained?

Here is the link to the academic reference used in my white paper: Remote Attestation on Program Execution . Essentially, the idea is to embed digital signatures of the log's hash to that point by attesting remote peers into a given peer's own log. The researchers call this technique entanglement, but I understood it more readily as peer-notarized logs that prove whether or not a particular log has been tampered with.

What about sybil attacks? In satoshi's Bitcoin a single node either has the economic power to lift a 51% attack or it doesn't. It doesn't matter over how many nodes this is distributed. A counter measure to sybil attacks would be to have signed each node by a CA. The other nodes verify this signature and won't allow more than one node with the same identifier. But then again the system is centralized.

Note that Bitcoin Core allows TLS and X.509 certificates already for RPC calls and for the new Payment Protocol. Texai does not need certificates for nodes to ensure third-party verification of the association of a public key with either a web domain name nor an operator's real name. The certificate is used to contain and publish the public key and to permit TLS authorization and encryption of the network traffic. Each operator, indeed each communicating role in the network has a unique UUID that is its identity. The certificate guarantees that whoever uses it has the private key in their possession. I believe that each user could hypothetically create a self-signed certificate and the Texai system would still work OK.

But if each user can create his own certificate (more ore less for free), doesn't this open the door for Sybil attacks?

As a result of my rewarding conversation with CIYAM above, I recently decided to have each node operator be their own certificate authority. My scheme does not rely on a chain of trust from a central certificate authority, indeed I want to preserve that part of the Satoshi Social Contract which says there are no trusted third parties in Bitcoin. I need X.509 certificates to identify a peer solely by their published public key, and to encrypt traffic between nodes via TLS 1.2.  I do not need a chain of trust to tie a real name and address to the system nor to the certificate holder.

There is a security concept called Trust On First Use (TOFU), which allows peers to record received self-signed certificates and trust them from that point forward. That is a relatively weak method which I plan to eventually augment by providing an easy to use method of emailing peer self-signed certificates from the peer to an archiving Texai software agent before first use. To identify a peer in the Texai network, I would  use the certificate, which cannot be forged due to the public/private key math, together with the IP address of the peer and to use encrypted email for out-of-band communication with the peer. For example a peer operator should receive a periodic digitally signed email from the system detailing their fair share of the  mining reward paid to their supplied address. This manual oversight by the operator precludes man-in-the-middle attacks that would divert the reward to another address.

Sybil attacks may occur in Satoshi's Bitcoin . . .

Weaknesses

Sybil attack
An attacker can attempt to fill the network with clients controlled by him, you would then be very likely to connect only to attacker nodes. Although Bitcoin never uses a count of nodes for anything completely isolating a node from the honest network can be helpful in the execution of other attacks.

This state can be exploited in (at least) the following ways:

The attacker can refuse to relay blocks and transactions from everyone, disconnecting you from the network.
The attacker can relay only blocks that he creates, putting you on a separate network. You're then open to double-spending attacks.
If you rely on transactions with 0 confirmations, the attacker can just filter out certain transactions to execute a double-spending attack.
Low-latency encryption/anonymization of Bitcoin's transmissions (With Tor, JAP, etc.) can be defeated relatively easy with a timing attack if you're connected to several of the attacker's nodes and the attacker is watching your transmissions at your ISP.
Bitcoin makes these attacks more difficult by only making an outbound connection to one IP address per /16 (x.y.0.0). Incoming connections are unlimited and unregulated, but this is generally only a problem in the anonymity case, where you're probably already unable to accept incoming connections.

Looking for suspiciously low network hash-rates may help prevent the second one.

Full nodes in Satoshi's bitcoin identify themselves only by IP address. In the Texai network, that weak identity is strongly augmented by X.509 certificates. Software agents keep track of the uptime and verified good behavior of the network nodes.

Satoshi's proof-of-work method makes it hard for an attacker to obtain 51% of the hashing power to attack the network. I plan for the occasional voting among Texai peers to be weighted according to respective peer stakes and each such vote shall be paid for by the system in proportion to the stake. Thus an attacker would have to obtain 51% of the aggregate stake, which has been proven to be more expensive for the attacker than obtaining 51% of the hashing power in a proof-of-work coin. To my knowledge, no proof-of-stake coin has been compromised in a 51% attack, in comparison ...

List of Historical 51% Attacks on Altcoins

[hbadger]

To my knowledge, no proof-of-stake coin has been compromised in a 51% attack

Peercoin has been successfully attacked. The reason these PoS coins are still up and running today is because they either use checkpoints (which makes them 100% centralized and pointless, which is the case of Peercoin), or they are continually making changes which makes attacking them annoying or hard, but is just another form of centralization (they depend on the continuous updates that everyone must accept blindly, as opposed to a stable protocol that rarely changes. Someone compared this to the whack-a-mole game).

[Scumby]

[Lurker decloak]
This thread has reached the point where it could use an injection of keyless signature infrastructure, as invented by Ahto Buldas of Guardtime (I am not associated with them):

http://en.wikipedia.org/wiki/Linked_timestamping

Some forms of global coordination, such as a stochastic cooperative signal that is widely observable, are compatible with decentralized paranoia.  Just ask neurons and ants.

Perhaps Mr. Reed might reconsider his resignation to PKI and central servers with this information.
[/Decloak]

[SlipperySlope]

[Lurker decloak]
This thread has reached the point where it could use an injection of keyless signature infrastructure, as invented by Ahto Buldas of Guardtime (I am not associated with them):

http://en.wikipedia.org/wiki/Linked_timestamping

Some forms of global coordination, such as a stochastic cooperative signal that is widely observable, are compatible with decentralized paranoia.  Just ask neurons and ants.

Perhaps Mr. Reed might reconsider his resignation to PKI and central servers with this information.
[/Decloak]

Thanks for the help, Scumby!

I wanted to offer a document timestamping API which would not necessarily be evidence in a court of law but would provide a distributed, robust service implemented with micropayments. This is an excellent implementation suggestion for this skill, which is required by the nomadic mint which timestamps incoming transactions. I would then be easy to expose this skill as a money-making microservice API. Apparently the Bouncy Castle cryptography library I use has a time stamp protocol server that I will evaluate.

Keyless Signature Infrastructure is interesting. I understand Merkle trees and this is similar. I will stay with self-signed X.509 certificates for identification, digital signatures for messages, and message channel encryption.

[Scumby]

I have only a basic understanding of Bitcoin's internals, so if there is nonsense here due to my own ignorance I apologize.  I think you are doing a tour-de-force job of assimilating a wide cross-disciplinary breadth of ideas here, but I am concerned that the TexAI/Cyc ontology stuff is so alien to most developers that it could torpedo your adoption if you make it too front-and-center.  The AI integration into the CPOS "stew" feels a bit forced; it's evidently a treasured ingredient in your own intellectual "refrigerator" and provides you continuity with your AI work, but you're going to have a hard enough time getting mindshare without having to also persuade engineers that symbolic programming with ontologies is worthwhile for cryptocurrencies.  My .02.

******

I think of KSI as envisioned above as a skip list of Merkle trees, with the skip list built around hashing that is one-way not only in calculation, but also in time.  It does this in a way that is far more bandwidth-efficient than replicating massive blockchains around like Bitcoin.  Guardtime markets this to governments as a way of signing documents and Linux OS log entries with keys that can't be tampered with, in order to defeat future Edward Snowdens from modifying system logs.  I think this same concept could be used for ledger integrity for micropayments as you note, or just about any kind of ledger for that matter.

The implementation envisions a newspaper or central service that would broadcast a top level hash, and providing this service (or enabling a central government agency to provide it, as is done in Estonia) is how Guardtime thinks it will make money.  A nomadic mint performing this function would seem to be preferable to a fixed commercial or government source. 

What has not been explored AFAIK, is what if the nomadic mint's KSI calculation had a publicly visible component that could be cross-checked by any client?  I.e. if the hash function had to mix in a widely observable source of chaos, such as the S&P 500 index closing price or solar flux index.  People might relax about cooperation if the public could "trust, but verify" the calculations of the population of nomadic mints subject to attack by a powerful adversary.  KSI + chaos could be immutable in the past (cannot reconstruct a historical hash with KSI) and the future (chaotic processes are immune to time series forecasting). 

[SlipperySlope]

I have only a basic understanding of Bitcoin's internals, so if there is nonsense here due to my own ignorance I apologize.  I think you are doing a tour-de-force job of assimilating a wide cross-disciplinary breadth of ideas here, but I am concerned that the TexAI/Cyc ontology stuff is so alien to most developers that it could torpedo your adoption if you make it too front-and-center.  The AI integration into the CPOS "stew" feels a bit forced; it's evidently a treasured ingredient in your own intellectual "refrigerator" and provides you continuity with your AI work, but you're going to have a hard enough time getting mindshare without having to also persuade engineers that symbolic programming with ontologies is worthwhile for cryptocurrencies.  My .02.

Indeed.

For reason you mention, I have stripped out the work-in-progress, natural language dialog and face-recognition aspects of Texai from the code that I am committing to GitHub for TexaiCoin. When I talk with coin developers at the Hasher's United conference in Las Vegas next month, I will be talking about a multi-agent software system which can cooperate to mine coins with no effort and still be as secure as Bitcoin.

My approach to artificial general intelligence is to follow Alan Turing's advice back in 1950, which is to create a system capable of being taught skills and then to teach it. My implementation uses the robotic-inspired architecture described by James Albus, in which his hierarchical control network of software agents has been elaborated by me to model a human organization. For TexaiCoin, I have 27 simple agents which cooperate and will check each other to operate an altcoin network with no trusted third parties.

I could have implemented these agents for TexaiCoin using any one of several agent frameworks, but it was the security aspects that motivated me to repurpose my existing AI code. Concerned about the need to ensure Friendly AI in a distributed network operated by anyone downloading the code, I designed the AI code years ago to be secure against intruders and hackers. I incorporated X.509 certificates for that purpose. Currently, I plan to use tamper-evident logs and remote attestation to strengthen Texai against attackers.

I will be able to market TexaiCoin as having genuine artificial intelligence, thus helping this altcoin and its innovations to be distinguished from other thousand-plus altcoins. I do not plan to say much initially about the OpenCyc knowledge base that is part of each deployed container.

TexaiCoin ideally will become a platform upon which third-party developers can add vetted skilled agents, and receive payment in TexaiCoin for the benefits gained by the collective infrastructure, or from the proceeds of services for sale, e.g. an API. I will start with the document timestamp service as a demonstration.

I will add a high level goal to the system to pursue self-improvement, e.g. to increase revenue and coin value via tasks performed by paid developers. Humans will be able to perform tasks specified in the same manner as for software agents, but with a secure web form or secure email as the communication channel. I think that the system paying one person to perform the task, and paying two non-affiliated others to check the work should be safe.

[SlipperySlope]

What has not been explored AFAIK, is what if the nomadic mint's KSI calculation had a publicly visible component that could be cross-checked by any client?  I.e. if the hash function had to mix in a widely observable source of chaos, such as the S&P 500 index closing price or solar flux index.  People might relax about cooperation if the public could "trust, but verify" the calculations of the population of nomadic mints subject to attack by a powerful adversary.  KSI + chaos could be immutable in the past (cannot reconstruct a historical hash with KSI) and the future (chaotic processes are immune to time series forecasting).  

Scumby,

What you say is very interesting. Satoshi designed the current Bitcoin proof-of-work system to prevent an adversary from presenting a forged blockchain as legitimate. My approach makes that difficult by having only one canonical version of the blockchain, in which the current hash is widely known, in which participants are identified by certificates, and in which misbehavior is detected by verifying peers.

KSI + chaos could be immutable in the past (cannot reconstruct a historical hash with KSI) and the future (chaotic processes are immune to time series forecasting).  

This is a desirable property for the blockchain or agent logs. I want to understand the circumstances allowing an adversary to forge such a blockchain. I seem to comprehend how a KSI + chaos blockchain could be tamper-evident, but the forgery attack is one in which the adversary replays transactions from some point in the history, with some change in their own favor, recalculating the merkle trees and block hashes at each step. The forged block chain is thus internally consistent with no evidence of tampering unless compared with the final block hash of the legitimate blockchain.

Does KSI as you understand it somehow make replaying of the blockchain building process impossible - as I described that process above?

Even if not, your mentioning of a public chaos value is a good idea for convincing observers that the blockchain was not constructed prior to the timestamp associated with the public chaos value. I could use the daily radio flux at 10.7 cm as reported by the U.S. Dept. of Commerce, NOAA, Space Weather Prediction Center, or can anyone suggest something published and archived by a more international source?

[Scumby]

Let's go back to Satoshi's original paper:

The problem of course is the payee can't verify that one of the owners did not double-spend the coin. A common solution is to introduce a trusted central authority, or mint, that checks every transaction for double spending. After each transaction, the coin must be returned to the mint to issue a new coin, and only coins issued directly from the mint are trusted not to be double-spent. The problem with this solution is that the fate of the entire money system depends on the company running the mint, with every transaction having to go through them, just like a bank. We need a way for the payee to know that the previous owners did not sign any earlier transactions. For our purposes, the earliest transaction is the one that counts, so we don't care about later attempts to double-spend. The only way to confirm the absence of a transaction is to be aware of all transactions. In the mint based model, the mint was aware of all transactions and decided which arrived first. To accomplish this without a trusted party, transactions must be publicly announced [1], and we need a system for participants to agree on a single history of the order in which they were received. The payee needs proof that at the time of each transaction, the majority of nodes agreed it was the first received.

You have already shown Satoshi's counterfactual assumptions here were wrong.  You have solved the problem of a central company controlling the mint with your nomadic mint.  The payee gets proof by cooperating in electing a dynamic superpeer hierarchy and trusting it to prevent double-spend, without seeing every transaction.  Instead of mining independently, the nodes can cross-check the calculations of their superpeer and shoot him if a majority discover he's a turncoat.  The superpeer can in turn try to identify bad nodes to be shunned by the network, and broadcasts intermediate signature hashes for consumption by end nodes.  Superpeers could be spontaneously elected for a term of office.  You are inspired by what mining pools are already doing in practice, but now are incorporating it into a self-organizing cooperative system.  Cool stuff!

The proof-of-work also solves the problem of determining representation in majority decision making. If the majority were based on one-IP-address-one-vote, it could be subverted by anyone able to allocate many IPs. Proof-of-work is essentially one-CPU-one-vote.

We now know that one-CPU-one-vote didn't work out too well once ASICs got into the action.  CPOS solves the majority decision making representation problem by spontaneous election of trusted nodes/mints, and then all the other nodes watch them for misbehavior.  The superpeers, in turn, need to watch out for Sybil attacks and rally honest nodes against them.  This is a more biologically-supported approach than Santoshi's competitive gold mining, if you think about it (think bees and neurons).

What you say is very interesting. Satoshi designed the current Bitcoin proof-of-work system to prevent an adversary from presenting a forged blockchain as legitimate. My approach makes that difficult by having only one canonical version of the blockchain, in which the current hash is widely known, in which participants are identified by certificates, and in which misbehavior is detected by verifying peers.
...
This is a desirable property for the blockchain or agent logs. I want to understand the circumstances allowing an adversary to forge such a blockchain.

I seem to comprehend how a KSI + chaos blockchain could be tamper-evident, but the forgery attack is one in which the adversary replays transactions from some point in the history, with some change in their own favor, recalculating the merkle trees and block hashes at each step. The forged block chain is thus internally consistent with no evidence of tampering unless compared with the final block hash of the legitimate blockchain.

Does KSI as you understand it somehow make replaying of the blockchain building process impossible - as I described that process above?

Here's what Satoshi says:

To modify a past block, an attacker would have to redo the proof-of-work of the block and all blocks after it and then catch up with and surpass the work of the honest nodes. We will show later that the probability of a slower attacker catching up diminishes exponentially as subsequent blocks are added.

The cryptographic proof-of-work blockchain approach used in Bitcoin inherently suffers from replayability and being determinate, which Satoshi solved by starting a computing arms race chasing an exponential function.  POS has the same weaknesses from what I can tell.  In KSI, the blockchain is one-way in time, and cannot be replayed by an adversary, because the complete ledger is not visible to all nodes.  That's a feature, originally designed to enforce a centralized signature upon a single node's transaction, for integrity purposes.  There is a hierarchical summarization by special nodes (like CPOS superpeers and nomadic mints) that broadcast digest hashes, which each end node has to sign onto its own transactions.  Superpeers can be nomadic and elected (that would be an extension of KSI), and are responsible for supervising the nodes within their hash space and time.  The system is still dependent upon 51% honest nodes.

By adding a chaotic parameter into the blockchain hash, I think it would be harder to "surpass the work of honest nodes" in Satoshi's parlance, because it would increase the dimensionality of the precalculation necessary, and hopefully make it harder to design an ASIC around.

I could use the daily radio flux at 10.7 cm as reported by the U.S. Dept. of Commerce, NOAA, Space Weather Prediction Center, or can anyone suggest something published and archived by a more international source?

My own research indicates that the DRAO at Penticton, BC Canada is the gold standard for 10.7 cm flux, and has been tracking it since the 1950s.  You could define the chaos broadcast as an average of several world observatories.  I think it would be neato if the nomadic mint published the summary Merkle hash, the solar flux value that can be cross-checked, and the resulting hash value.  Not even the NSA can control the Sun.  I don't know how much additional security solar chaos really adds, but it just feels good, doesn't it?

[SlipperySlope]

Does KSI as you understand it somehow make replaying of the blockchain building process impossible - as I described that process above?

Here's what Satoshi says:

To modify a past block, an attacker would have to redo the proof-of-work of the block and all blocks after it and then catch up with and surpass the work of the honest nodes. We will show later that the probability of a slower attacker catching up diminishes exponentially as subsequent blocks are added.

The cryptographic proof-of-work blockchain approach used in Bitcoin inherently suffers from replayability and being determinate, which Satoshi solved by starting a computing arms race chasing an exponential function.  POS has the same weaknesses from what I can tell.  In KSI, the blockchain is one-way in time, and cannot be replayed by an adversary, because the complete ledger is not visible to all nodes.  That's a feature, originally designed to enforce a centralized signature upon a single node's transaction, for integrity purposes.  There is a hierarchical summarization by special nodes (like CPOS superpeers and nomadic mints) that broadcast digest hashes, which each end node has to sign onto its own transactions.  Superpeers can be nomadic and elected (that would be an extension of KSI), and are responsible for supervising the nodes within their hash space and time.  The system is still dependent upon 51% honest nodes.

By adding a chaotic parameter into the blockchain hash, I think it would be harder to "surpass the work of honest nodes" in Satoshi's parlance, because it would increase the dimensionality of the precalculation necessary, and hopefully make it harder to design an ASIC around.

I could use the daily radio flux at 10.7 cm as reported by the U.S. Dept. of Commerce, NOAA, Space Weather Prediction Center, or can anyone suggest something published and archived by a more international source?

My own research indicates that the DRAO at Penticton, BC Canada is the gold standard for 10.7 cm flux, and has been tracking it since the 1950s.  You could define the chaos broadcast as an average of several world observatories.  I think it would be neato if the nomadic mint published the summary Merkle hash, the solar flux value that can be cross-checked, and the resulting hash value.  Not even the NSA can control the Sun.  I don't know how much additional security solar chaos really adds, but it just feels good, doesn't it?

Thanks Scumby for your articulate understanding of my work.

I examined the DRAO website and have written a message to their webmaster asking about why the displayed solar flux index is months old instead of current. Another potential micro-revenue service for TexaiCoin would be to wrap an API around the daily solar flux measurement and its recent archived values.

I am constrained to keep the blockchain structure unchanged so as to maximise the opportunity that my changes will someday be incorporated into Bitcoin Core. But that does not keep me from creating a parallel data structure as you describe for KSI, which I now somewhat comprehend because of your explanation. The blockchain must remain a public ledger in its entirety, but I can envision a KSI process as you describe to irreversibly record blockchain hashes at each new block.

And here is a link to a recent Ahto Buldas' paper which at first glance may be what you are describing ...

Keyless Signatures’ Infrastructure: How to Build Global Distributed Hash-Trees

Could you elaborate on the non-shared portion of the KSI hash tree? This appears to be the key to irreversibility. If an adversary had more than 50% of the nodes in his control, then he could out vote the legitimate nodes - right?

I believe that I can publicly publish the blockchain hash as well as the KSI top hash when each new block is created as a trust anchor. For example it would be easy to automatically publish those in a dedicated forum such as Yahoo or Google groups in append-only style where the account is administered by TexaiCoin core developers. Likewise the system could append hash value entries to an otherwise readonly Google Docs spreadsheet. Then an adversary would have to hack each of these public records to maintain integrity with his forged blockchain.

[Scumby]

And here is a link to a recent Ahto Buldas' paper which at first glance may be what you are describing ...

Keyless Signatures’ Infrastructure: How to Build Global Distributed Hash-Trees

Could you elaborate on the non-shared portion of the KSI hash tree? This appears to be the key to irreversibility. If an adversary had more than 50% of the nodes in his control, then he could out vote the legitimate nodes - right?

I think in this scheme, the issue is that the 51% adversary could rig the elections of superpeers.  It's no longer about protecting the historical blockchain from rewriting.  Buldas essentially encodes time into the blockchain in a way that he says is provably resistant to backdating *and* independently verifiable by third parties that do not have access to the full ledger.  For the application he had in mind (signing every syslog entry of every Linux machine in the world) it would have been impractical to distribute every single transaction around.  Here is the summary in the paper you linked to:

Underlying data structures guarantee that it is not possible to issue fake, backdated or otherwise mis- leading signature tokens—even where rogue client and rogue service provider collaborate. Committing into globally unique and public Hash Calendar makes tampering with the system, especially with the clock value, highly visible to all users. The system security does not depend on the long-term secrecy of the private keys as it is not possible to prove that the keys were not actually leaked. Underlying cryptographic primitives may be easily changed, e.g. in case of apparent weakening of the algorithms. There may be occassions when the infrastructure must be stopped—if the system integrity or clock accuracy is in doubt. The signature token itself is independently verifiable by third parties using only public information and algorithms; verification must be possible even after the service provider ceases the operations.
In order to provide highly available service single points of failure are eliminated. The requirements on system reliability are different: a globally unique core cluster must be operated by the best trust authority practices, but the service delivery network may use commodity virtual servers without much requirements on operating environment, like a reliable “wall clock” or persistent storage. Privacy and confidentiality risks are minimal, because the infrastructure handles only aggregate hashes.

I'm rejecting Buldas' statement in bold, which  I believe to be motivated by his commercial ambitions, and substituting your nomadic mint.

I believe that I can publicly publish the blockchain hash as well as the KSI top hash when each new block is created as a trust anchor. For example it would be easy to automatically publish those in a dedicated forum such as Yahoo or Google groups in append-only style where the account is administered by TexaiCoin core developers. Likewise the system could append hash value entries to an otherwise readonly Google Docs spreadsheet. Then an adversary would have to hack each of these public records to maintain integrity with his forged blockchain.

It may not have been clear that I was rejecting a central newspaper authority like Buldas designed and Satoshi rejected, and glomming onto your nomadic mint to publish the public top-level hash automatically.  Term limits!

*********

Re: Bitcoin Core, I think where this could lead is partitioning the cryptocoin hash space amongst superpeer-led mining pools, and federating/mixing their respective blockchains up the hierarchy.  That would encourage people to start mining pools instead of scamcoins and scamexchanges.

[Brangdon]

To my knowledge, no proof-of-stake coin has been compromised in a 51% attack

Peercoin has been successfully attacked. The reason these PoS coins are still up and running today is because they either use checkpoints (which makes them 100% centralized and pointless, which is the case of Peercoin), or they are continually making changes which makes attacking them annoying or hard, but is just another form of centralization (they depend on the continuous updates that everyone must accept blindly, as opposed to a stable protocol that rarely changes. Someone compared this to the whack-a-mole game).

Nxt doesn't use checkpoints. Although it adds features fairly often, its core model doesn't change often and new features don't make it harder to attack. Even if they did, I don't see how that would affect mounting a 51% attack. Getting to control 51% of Nxt would be implausibly difficult because of the difficulty in acquiring that many coins.

[hbadger]

To my knowledge, no proof-of-stake coin has been compromised in a 51% attack

Peercoin has been successfully attacked. The reason these PoS coins are still up and running today is because they either use checkpoints (which makes them 100% centralized and pointless, which is the case of Peercoin), or they are continually making changes which makes attacking them annoying or hard, but is just another form of centralization (they depend on the continuous updates that everyone must accept blindly, as opposed to a stable protocol that rarely changes. Someone compared this to the whack-a-mole game).

Nxt doesn't use checkpoints. Although it adds features fairly often, its core model doesn't change often and new features don't make it harder to attack. Even if they did, I don't see how that would affect mounting a 51% attack. Getting to control 51% of Nxt would be implausibly difficult because of the difficulty in acquiring that many coins.

So you have already forgotten that one time when a hacker stole 5% of all the coins, and with that, 5% of all the hashing power?

And I don't see what's so "implausible" about buying half of the coins when the market cap is so small. Did you know that you don't even need to own the coins to perform the attack? You just need to have owned them at some point, and begin your forks there. With PoW at least the attacker will have trouble recovering the costs of his mining gear which will become obsolete. With PoS that cost doesn't exist. The attacker can sell all his coins and then start the attack.

See what Gregory Maxwell (nullc) thinks about PoS:

https://www.reddit.com/r/Bitcoin/comments/1uoq6e/what_do_you_guys_think_of_proof_of_stake_mining/cek8epc?context=2

https://news.ycombinator.com/item?id=6798997