AI Coin Development Diary

[SlipperySlope]

X509 certificate server - provides Texai X509 certificates when installing full nodes
X509 authentication - each agent and each hardware node is assigned an X509 certificate for pseudonymous authentication
SSL/TLS network - communications between authenticated full nodes are encrypted with X509 certificates on both endpoints

Do not mix authentication with authorization.

Let each node be named with a URI (URI-A)
Nodes issue their own certificates with URI-A in the subjectAltName part of the x509
As authentication dereference URI-A to find RDF-data, check for the public key from the x509.
If public key is found, assert that the node "owns" URI-A and thus can use it as an identifier.

This covers authentication and allows each node to revoke and change certificates as it chooses, it also allows nodes to provide more information at the dereferenceable URI and acts as an extension point.

Layer on authorization using ACL, which can also be implemented using RDF.

See webid (formerly foaf-ssl) for more information, see web access control for more on authn.

Consider defining a simple protocol that allows multiple forms of passing keys and establishing identifiers for agents, x509 may need to be replaced, legacy and different networks may need different auth protocols, your suggested approach binds to HTTP+TLS only, when multiple transport level protocol may be required for this.

Webserver - full node statistics and network operations are presented to the operator via HTML pages

I suggest an RDF data API, it will be far more beneficial if the information is machine readable data (possibly with a default HTML view.. RDFa?), then multiple different UIX can be built on top allowing independent innovation and it'll be readily extensible by using new classes and properties in the rdf.

I did not know about Web ID. Your ideas are great. I was using UUIDs (random) as subject UIDs in the X.509 certificates I generate. I can revise the server to accept a Web ID from the user, and return the certificate as you suggest. Actually I have intermediate X.509 certificates that issue the end-user certificates. The root certificate is self-signed for texai.org - so no dependency on a trusted third party as a Certificate Authority.

The full node will host multiple agents and each agent can have skillful roles. The roles message other agent-roles in the network and need certificates to sign their messages if leaving the full node and going across the network. I can use UUID subject certificates for this purpose. I use a single IANA port already reserved for Texai, over which I will run TLS/SSL encrypted messages for Bitcoin, plus HTTPS for network operations, and BitTorrent for rapid provisioning of new full nodes.

For the past couple of days, I have been upgrading the Bouncy Castle Java cryptographic libraries to the newest versions. When those unit tests all work again, I will add the TLS/SSL networking code from Texai, and after that the agent framework from Texai.

An RDF API would be straight forward. I use the Sesame quad store to contain RDF statements. I will leave bitcoind and the blockchain alone, but the quad store will contain the OpenCyc knowledge base, and persisted java objects. I wrote an RDF entity manager which persists Java objects analogous to how Hibernate does it with a relational database.

[1715189521]

1715189521

[1715189521]

1715189521

[1715189521]

1715189521

[1715189521]

1715189521

[1715189521]

1715189521

[coinsolidation]

X509 certificate server - provides Texai X509 certificates when installing full nodes
X509 authentication - each agent and each hardware node is assigned an X509 certificate for pseudonymous authentication
SSL/TLS network - communications between authenticated full nodes are encrypted with X509 certificates on both endpoints

Do not mix authentication with authorization.

Let each node be named with a URI (URI-A)
Nodes issue their own certificates with URI-A in the subjectAltName part of the x509
As authentication dereference URI-A to find RDF-data, check for the public key from the x509.
If public key is found, assert that the node "owns" URI-A and thus can use it as an identifier.

This covers authentication and allows each node to revoke and change certificates as it chooses, it also allows nodes to provide more information at the dereferenceable URI and acts as an extension point.

Layer on authorization using ACL, which can also be implemented using RDF.

See webid (formerly foaf-ssl) for more information, see web access control for more on authn.

Consider defining a simple protocol that allows multiple forms of passing keys and establishing identifiers for agents, x509 may need to be replaced, legacy and different networks may need different auth protocols, your suggested approach binds to HTTP+TLS only, when multiple transport level protocol may be required for this.

Webserver - full node statistics and network operations are presented to the operator via HTML pages

I suggest an RDF data API, it will be far more beneficial if the information is machine readable data (possibly with a default HTML view.. RDFa?), then multiple different UIX can be built on top allowing independent innovation and it'll be readily extensible by using new classes and properties in the rdf.

I did not know about Web ID. Your ideas are great. I was using UUIDs (random) as subject UIDs in the X.509 certificates I generate. I can revise the server to accept a Web ID from the user, and return the certificate as you suggest. Actually I have intermediate X.509 certificates that issue the end-user certificates. The root certificate is self-signed for texai.org - so no dependency on a trusted third party as a Certificate Authority.

The full node will host multiple agents and each agent can have skillful roles. The roles message other agent-roles in the network and need certificates to sign their messages if leaving the full node and going across the network. I can use UUID subject certificates for this purpose. I use a single IANA port already reserved for Texai, over which I will run TLS/SSL encrypted messages for Bitcoin, plus HTTPS for network operations, and BitTorrent for rapid provisioning of new full nodes.

For the past couple of days, I have been upgrading the Bouncy Castle Java cryptographic libraries to the newest versions. When those unit tests all work again, I will add the TLS/SSL networking code from Texai, and after that the agent framework from Texai.

An RDF API would be straight forward. I use the Sesame quad store to contain RDF statements. I will leave bitcoind and the blockchain alone, but the quad store will contain the OpenCyc knowledge base, and persisted java objects. I wrote an RDF entity manager which persists Java objects analogous to how Hibernate does it with a relational database.

Great to hear.

I believe somebody has already marked up the blockchain as RDF if that would be of use, indeed a few of us have been working on bitcoin+semantic-web for a few years, nothing vastly productive to show for it, but we've certainly prototyped and mapped the architecture out. They are a powerful match!

[SlipperySlope]

I completed upgrading the Bouncy Castle cryptographic libraries. I added two more modules from Texai now that their dependencies are in the project. The first is support for bittorrent messages, which is required by the SSLBitTorrent module to be added after the Network module is added. And the second is support for the Albus Hierarchical Control Network - AlbusHCN module, that is the Texai agent framework.

Over 300 unit tests are running OK on my local continuous integration server, which automatically rebuilds the project whenever I push new updates to the GitHub source code repository. Over 32,000 lines of Java source code have been added to the project, not including the regression tests.

I expect that I will add less than 10 more modules from Texai before I am ready to begin coding the first Bitcoin CPoS test case, which simply runs two slave full nodes that take turns hosting the nomadic mint agent which creates new blocks, without yet performing the required verification of the peer tamper-evident logs.

[coinsolidation]

Can I ask if you could take some time to define a dictionary of terms used in your posts somewhere. I'm familiar with many but only because I have pre existing knowledge. It is hard to distinguish between what is a technology, and innovation, a third party piece of software, a component of the system, and so forth.

Do keep up the good work, I'll be watching this closely.

[SlipperySlope]

Can I ask if you could take some time to define a dictionary of terms used in your posts somewhere. I'm familiar with many but only because I have pre existing knowledge. It is hard to distinguish between what is a technology, and innovation, a third party piece of software, a component of the system, and so forth.

Do keep up the good work, I'll be watching this closely.

Another great idea. I will add a glossary to the OP.

[SlipperySlope]

I have migrated a few more code modules from the Texai system over to the Texai CPoS code repositories on GitHub. Notably there is an implementation of BitTorrent over TLS/SSL which I will later use for rapid blockchain update of new full nodes.

Texai previously used the Chord distributed hash table to find peers, but I want to replace this mechanism with something else that can connect the CPoS network and be subject to remote verification by peers. Continuing the pattern I set by a single writer to the canonical blockchain, which is then widely replicated, I suppose that the MessageRouter will use a shared dictionary of full node IDs and IP addresses. This shared tamper-evident dictionary would be maintained by a single writer and widely replicated. Changes to the dictionary should be verifiable by peers.

I will think about this feature and also the tamper-evident logs required by the blockchain operations. I believe that there is a Java abstraction that both these use-cases may inherit from.

Here is my contribution activity chart from GitHub. The migrated and tested code from Texai now totals 42,000 lines of Java source code, not including the 450 regression test methods.

[kutaka]

How can someone contribute? Is the project in a stage where more devs can join?

[mhps]

Can I ask if you could take some time to define a dictionary of terms used in your posts somewhere. I'm familiar with many but only because I have pre existing knowledge. It is hard to distinguish between what is a technology, and innovation, a third party piece of software, a component of the system, and so forth.

Do keep up the good work, I'll be watching this closely.

Another great idea. I will add a glossary to the OP.

Why not use the wiki feature on github?

[coinsolidation]

Why not use the wiki feature on github?

This is a good idea, and the approach I am taking with Bitmark.

[fran2k]

Interesting, reading..

[coine_smithe]

I'm posting this to commit myself to reading everything including all references in this thread some day soon. The work going on here is phenomenal. I want to reach a level where I can comprehend what's going on here and possibly have a part in it. Thanks for making such an awesome topic OP. 

[bubble83]

PoS coin blockchains seem to grow faster than PoW coin blockchains. Will a CPoS bitcoin fork's blockchain grow faster than bitcoin's?

[SlipperySlope]

Can I ask if you could take some time to define a dictionary of terms used in your posts somewhere. I'm familiar with many but only because I have pre existing knowledge. It is hard to distinguish between what is a technology, and innovation, a third party piece of software, a component of the system, and so forth.

Do keep up the good work, I'll be watching this closely.

Another great idea. I will add a glossary to the OP.

Why not use the wiki feature on github?

Thanks for the tip!
-Steve

[SlipperySlope]

PoS coin blockchains seem to grow faster than PoW coin blockchains. Will a CPoS bitcoin fork's blockchain grow faster than bitcoin's?

CPOS Bitcoin will create a new block exactly every 10 minutes, so on average the CPOS Bitcoin blockchain should be equal in length to the original Satoshi Bitcoin blockchain after the fork. Transaction counts per block will differ because of the relative popularity of the two forks.

Additionally I want CPOS Bitcoin to reliably accept low fee transactions and especially microtransactions to highlight an important advantage of CPOS.

[SlipperySlope]

After returning from vacation I found that the disk drive on my server crashed. When rebuilding the system I decided to make it identical to my development desktop and use Docker to contain the Jenkins continuous integration application that I used to run on the server. Having a second development computer makes it easier to bring one along on vacation, and also a documented and scripted build for developers that this project will ultimately pay to enhance CPOS Bitcoin.

Docker is a Linux based technology that enables applications to run efficiently in secure containers. I created a Docker container for running Java continuous integration with Jenkins, Maven, Java 8, and Git. This is a generally useful contribution to the Java development community.

The repository for my container is https://registry.hub.docker.com/u/stephenreed/java8-jenkins-maven-git-nano/

And here is a screenshot . . .

[SlipperySlope]

Hashers United Conference

I will be participating in a panel discussion at the Hashers United Conference to be held in Las Vegas, Nevada, USA on October 10-11. The panel topic concerns mining algorithms and my modest role will be to briefly describe Cooperative Proof of Stake for Bitcoin. Sharing the podium will be notable crypto coin designers.

This is a great chance to meet up. If you like, PM me.

http://hashersunited.com/

[kutaka]

Damn, wish it was in Europe;/

[ahmed_bodi]

Hashers United Conference

I will be participating in a panel discussion at the Hashers United Conference to be held in Las Vegas, Nevada, USA on October 10-11. The panel topic concerns mining algorithms and my modest role will be to briefly describe Cooperative Proof of Stake for Bitcoin. Sharing the podium will be notable crypto coin designers.

This is a great chance to meet up. If you like, PM me.

http://hashersunited.com/

I'm attending there!

[SlipperySlope]

August 18, 2014 Status and Thoughts.

I have about half of the Texai cognitive architecture migrated to GitHub. The knowledge base repositories are larger than GitHub guidelines, so I need to find another more appropriate cloud data server, e.g. Dropbox for those. I configured three separate computers in my lab with the same development environment to ensure redundancy and to document the build recipe. The configuration for developers is . . .

• Ubuntu 14.04 LTS on bare metal
• Oracle Java 8 with JCE highest level security policy
• Netbeans 8.0 Java IDE
• Maven 3
• Docker

The Docker platform is currently used to host a Jenkins continuous integration server that I uploaded to the Docker container registry.

My GitHub page is https://github.com/StephenLReed?tab=repositories.

My Docker repository page is https://registry.hub.docker.com/u/stephenreed/jenkins-java8-maven-git/.

I would like to have bitcoind in an agent-controlled, non-verifying proxy by early October, 2014, for hallway demonstration at the Hashers United conference in Las Vegas. Consequently, I will upload broken aspects of Texai that have no relationship to Cooperative Proof-of-Stake, as the agents I need to write are dependent upon working code embedded in those otherwise broken dialog modules.

------------

Here are my latest thoughts about how CPOS will work.

I am considering hard-forking the popular Satoshi blockchains: Bitcoin, Litecoin, Dogecoin and Namecoin. They would operate on networks separate from the Satoshi originals and be branded respectively CPOS-B, CPOS-L, CPOS-D and CPOS-N. Users would be required to configure their respective client wallets, payment processors, mixing services, etc., to respective CPOS seed node addresses - that's all. There are no changes required to the client protocols I believe.

The forks could come much earlier than January 2016, depending upon the ambition of the network and the state of system testing.

I would use a portion of block rewards to pay geographically dispersed operators to run full nodes for these plus a Tor relay. Each operator would be required to provision a high-availability enterprise server in a datacenter having redundant high bandwidth Internet connections. Specifications for the server will include protection against DDoS attacks.

As operators will be relatively well compensated, I expect to add new servers only with increased market capitalization and transaction traffic. VisaNet runs the majority of the world's credit card transactions with only two datacenters, so less than ten geographically distributed servers with likewise separate ownership may be adequate to start. Supposing that CPOS grows to the same market capitalization that Bitcoin has currently, then 10,000 distributed paid servers could be justified.

I would choose either CoreOS or Ubuntu LTS for the base operating system, and use Docker containers for the cryptocoin bitcoind software, where each coin gets its own container. Likewise the tor relay gets its own container. Each server would run the latest identical software and as the network grows in size, there are existing softwares to manage the worldwide deployment of Docker containers. Unpaid volunteers could download and run the CPOS agent software to record blockchains and verify peer agent behavior, but would not be permitted to operate agents that mint new blocks or that provide support services to other agents.

Governance of the CPOS network will be performed by the Texai cognitive architecture, in which simple transparent algorithms enforce policies decided at periodic meetings of the node operators. Each operator will be required to purchase a commercial membership in their local Bitcoin Foundation. A portion of the block rewards will fund developers tasked via the Texai cognitive architecture. Each paid person performing a task for the system will have at least two other non-affiliated paid persons check their work. A portion of the block rewards will fund development of the Texai architecture, Bitcoin Core, and relevant altcoin features. Supposing that CPOS coins grow to the current market capitalization of bitcoin, then 300+ developers could be supported. Paid human participants in the CPOS system, e.g. operators and human agents, could be anonymous but would be required to possess X.509 certificates for digital signatures and network authentication. Likewise they must provide verifiable contact information. All communications in the network are digitally signed, TLS/SSL encrypted, and logged. We want the network to be trustless in the sense that Satoshi's Bitcoin is trustless, but paid participants must be held responsible for their behavior via cyrptographic credentials and tamper-evident logs.

I expect the block rewards of the CPOS coins to greatly exceed the transaction revenue with respect to paying for the system. Consequently, I would set transaction fees to the lowest sensible values which I believe are 100x less than what bitcoin charges. Rather than $.05 fee at today's bitcoin price, I would set CPOS transaction fees at the equivalent of $.0005 which encourages the use of microtransactions.

As an example of "eating your own dog food", the Texai software agents will pay each other for services rendered using bitcoin microtransactions. This will encourage software developers to write skills for the system, as they will receive the net earnings of software skill they provide in accordance with a scheme to maximize innovation.

In accordance with the precedent set by Satoshi's Bitcoin, the CPOS network will not be a legal entity in any jurisdiction. The network, despite Tor anonymity capabilities, will not place servers in jurisdictions where their operation would be against the local law. The network will pass through all earnings, e.g. block rewards, transactions fees, and software agent income, to human participants who will pay taxes according to their local jurisdictions.

[hbadger]

Litecoin, Dogecoin

The forks could come much earlier than January 2016

This part makes no sense. Why would you want to do that? Do you realize by 2016, those coins might not even exist anymore? Both of them have been falling in BTC price non-stop as expected from their lack of usefulness, and will probably be displaced by non-Bitcoin clones like Monero for example, which at least adds *something* new (true decentralized anonymity thanks to the use of ring signatures).

http://coinmarketcap.com/currencies/litecoin/

http://coinmarketcap.com/currencies/dogecoin/

If you don't know much about what happened in the dogecoin world you should read this:

http://www.dailydot.com/business/moolah-dogecoin-alex-green/

There's also this leaked video:

http://www.liveleak.com/view?i=e63_1404777061

About Litecoin: The tale that Scrypt made it ASIC resistant is now proven to be false. It's being mined by ASICs, and even the creator of Scrypt himself said "they used it poorly", because it was supposed to use a lot of RAM, but it didn't. So it's basically just another Bitcoin clone with nothing new, less adoption, less investment in mining gear, less security, less brain power working on it, less venture capital, less companies, less network effect, less market capitalization, less everything.