AI Coin Development Diary

[CIYAM]

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).

[SlipperySlope]

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.

[CIYAM]

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.

The issue is not "lost somehow" but "stolen/leaked somehow" - so the system can be "played" if those at the "top" decide to be corrupt (or are cheated).

[SlipperySlope]

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.

The issue is not "lost somehow" but "stolen/leaked somehow" - so the system can be "played" if those at the "top" decide to be corrupt (or are cheated).

I suppose then that the root certificate private key should be destroyed immediately after creating a sufficient number of intermediate certificates. The system treats the root certificate as it treats the blockchain. Each is widely replicated and tamper-evident by way of comparing the local copy with what all the other peers have. This notion is resistant to byzantine faults up to 50% invalid peers.

In contrast to Satoshi's Bitcoin, a cooperative system can use a portion of the block rewards to employ data security firms to perform periodic audits as does the payment card industry. I would have this system at least as secure as the existing payment systems.

[CIYAM]

I suppose then that the root certificate private key should be destroyed immediately after creating a sufficient number of intermediate certificates. The system treats the root certificate as it treats the blockchain. Each is widely replicated and tamper-evident by way of comparing the local copy with what all the other peers have. This notion is resistant to byzantine faults up to 50% invalid peers.

It won't help - the corruption (or cheating) is not possible to stop with any system (that is why Bitcoin is what it is).

Basically you'd need another Bitcoin blockchain to stop any fault with your CA system which means you are back at square one.

[SlipperySlope]

I suppose then that the root certificate private key should be destroyed immediately after creating a sufficient number of intermediate certificates. The system treats the root certificate as it treats the blockchain. Each is widely replicated and tamper-evident by way of comparing the local copy with what all the other peers have. This notion is resistant to byzantine faults up to 50% invalid peers.

It won't help - the corruption (or cheating) is not possible to stop with any system (that is why Bitcoin is what it is).

Basically you'd need another Bitcoin blockchain to stop any fault with your CA system which means you are back at square one.

Not to quibble, but in my two decades of enterprise billing and payment system experience, I found that reasonable data security practices prevented loss of customer funds. I believe a public trial of cooperative Bitcoin will demonstrate its resistance to hacking - or not.

[CIYAM]

Not to quibble, but in my two decades of enterprise billing and payment system experience, I found that reasonable data security practices prevented loss of customer funds. I believe a public trial of cooperative Bitcoin will demonstrate its resistance to hacking - or not.

Sure - you are asking for *trust* so I am just making sure that people are aware of that (if they want to trust your system then that is up to them).

I could mention about my own years of experience (in financial and other fields) but I think it is irrelevant to the discussion.

[SlipperySlope]

Sure - you are asking for *trust* so I am just making sure that people are aware of that (if they want to trust your system then that is up to them).

I claim my cooperative system is trustless in the sense that the source code is open source for inspection, and what few human agents, e.g. developers, network managers, etc., are subject to at least dual control.

The self-signed root X.509 certificate is public except for the private key. Even if the root private key were made public after the issuance of a fixed number of intermediate certificates, I do not see the vulnerability. TLS/SSL traffic is encoded by the end-user (software agent,  not bitcoin user) certificates. Outbound messages from a node are digitally signed using the assigned certificates held by software agent roles hosted by that node.

The chain of trust flows from the root certificate through the intermediate certificate to the end user certificate. The validating endpoint has its own copy of the root certificate which it obtained upon being on-boarded into the network. Sybil attacks, I believe, cannot be accomplished, because both endpoints know each other's certificates in a system in which persistent network connections are managed by distributed, redundant network operation centers.

[SlipperySlope]

I completed modest modifications to Bitcoin Core that allow the mining of a new block with no effort. The source code branch is named no-pow-mods on my fork of the bitcoin repository at GitHub. My code is here.

The new bitcoin configuration option is added to .bitcoin/bitcoin.conf, where the parameter is the height of the blockchain at the moment of the fork...

. . .
# no proof-of-work after block
nopowafter=317661

The command on Linux to create a new block and then return is ...

$ bitcoin-cli setgenerate true

And here is the block reward added to my test wallet ...



Next step is to write a simple Java software agent to send the generate command to the running bitcoin-qt instance every 10 minutes.

[SlipperySlope]

Here is an organization chart design for the nodes within a particular server in the Texai cognitive architecture. Each node contains roles, which are the software agents that collectively perform the node's mission. Roles, in turn, have skills which are Java objects that provide perception and action behavior. Arrows depict the asynchronous task message passing from superior to subordinate roles. Likewise, perceptions, e.g status reports flow upwards from subordinate to superior.

Each node has the following essential roles ...

• GovernanceRole
• HeartbeatRole
• NodeLifeCycleRole
• NodeLoggerRole

The TopFriendshipNode is the topmost node in this hierarchical control network. It's mission is governance, moreover ensuring that the system is friendly.

The NetworkConfigurationNode contains the NetworkConfigurationRole which performs the node's mission of scheduling the nomadic software agents such as the MintRole.

The NetworkOperationsNode contains the NetworkConfigurationRole which performs the node's mission of network operations management. It contains the BootstrapRole which has the skills to on-board a new server into the Texai network. It contains the RecoveryManagementRole which supervises recovery from a fault. It contains the SoftwareProvisioningManagementRole which supervises software provisioning, e.g. version upgrades.

Cryptocoin operation nodes may contain the following roles ...

• CoinSeedRole - Uses the Texai encrypted torrent library to seed new servers with the cryptocoin's blockchain
• BlockchainArchiveRole - replicates the canonical blockchain with new blocks created by the nomadic mint agent
• MintRole - The nomadic cryptocoin minting agent
• RewardAllocationRole - The nomadic cryptocoin block reward allocation agent
• FinancialAccountingAndControlRole - The nomadic agent which balances the blockchain against processed transactions, and provides traffic statistics to network operations
• PrimaryAuditRole - the nomadic agent which has primary responsibility for verifying the behavior of the MintRole and RewardAllocationRole
• SecondaryAuditRole - has secondary audit responsibility
• SoftwareProvisioningRole - performs software provisioning for a particular cryptocoin's Docker container
• RecoveryRole - has the responsibility for a particular cryptocoin's recovery from a fault
• CoinPortalRole - has the responsibility of public communication with a cyptocoin's native protocol to client wallets and transaction processors.
  

The TorRelayNode contains the TorRelayRole which has the simple skill of running a Tor relay instance that encrypts and obfuscates network traffic for those cryptocoin clients that wish additional anonymity by using Tor.

[SlipperySlope]

Here is an illustration of how a server in the Texai network will be configured with Docker containers that provide isolation between cryptocoin daemons, e.g. bitcoind, and the Texai software agents that control them ...

[SlipperySlope]

TexaiCoin

After completing the minimal required changes to my fork of the Bitcoin Core code for creating new blocks with trivial effort, I have been reflecting on how best to demonstrate the technology. Today I am re-branding this thread accordingly as TexaiCoin.

Note that the May 2013 whitepaper describes a hard fork of bitcoin. That cannot possibly happen unless Coopcoin is successful and subsequently convinces the Bitcoin community that a good alternative exists for the current industrial mining method. Furthermore, the current approach is not proof-of-stake, rather the block rewards are used to pay for network infrastructure, developers and community support, e. g. through institutions such as the Bitcoin Foundation.

I would like to demonstrate TexaiCoin at the Hashers United Conference in early October. It will not then have all the features needed for a public release but I can say that when released, TexaiCoin will have the same parameters as Bitcoin and will launch with a genesis block and no premine. This coin is to be marketed as a cryptocurrency especially suited for microtransactions and immediate acknowledgement that the accepted transactions will appear in the next block.

[SlipperySlope]

TexaiCoin is designed to run within a Docker container on the Linux operating system. If you want to run this but have only Windows or a Mac, then the VirtualBox software environment can be installed to allow Linux to run on your computer.

[SlipperySlope]

This diagram supersedes the one posted earlier. Note that I do not plan to fork any existing proof-of-work coins, rather I am demonstrating an alternative approach that I hope will one day be adopted by Bitcoin, Litecoin, Dogecoin, Namecoin ect. developers.

[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?

[SlipperySlope]

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. 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.

In addition to remote attestation of peer behavior, TexaiCoin will include a distributed network operations center equipped with a suite of open source information security tools that will detect intrusion and unauthorized changes to the host operating system and the Docker containers in which TexaiCoin full nodes execute. As funding from block reward permits, TexaiCoin network portals, that connect to wallets and external processors, will be protected against DDoS attacks by a traffic filtering service.

[CIYAM]

Again - you trust the CA system which has been *proven* to be flawed.

We just have to somehow *trust you*?

Let's see your papers and how they are reviewed before you ask for any funds please.

BTW - this:

-   Does not permit double-spending, whereas Satoshi's Bitcoin sometimes does.

is *wrong* (if you want to be taken seriously then I'd suggest that you remove it).

[SlipperySlope]

Again - you trust the CA system which has been *proven* to be flawed.

We just have to somehow *trust you*?

Let's see your papers and how they are reviewed before you ask for any funds please.

BTW - this:

-   Does not permit double-spending, whereas Satoshi's Bitcoin sometimes does.

is *wrong* (if you want to be taken seriously then I'd suggest that you remove it).

Respectfully, I ask you to elaborate a bit on both your points.

I use the X.509 v3 certificate generation facilities provided by the well known Bouncy Castle Java library. I use the optional high encryption strength encryption policy settings provided by Oracle java. I use a self-signed root certificate that each node receives, and do not check for revocation when verifying certificate paths because in my system the certificate serves to digitally sign messages, to encrypt traffic, and to identify the full node. The subject item in the certificate is a UUID, not a real name to preserve the anonymity of the node's owner yet retain identity to preclude Sybil attacks.

Bitcoin Core already includes X.509 infrastructure for remote procedure calls, therefore that technology has been vetted by them and run in production.

Code:

-rpcssl                                  Use OpenSSL (https) for JSON-RPC connections
 -rpcsslcertificatechainfile=<file.cert>  Server certificate file (default: server.cert)
 -rpcsslprivatekeyfile=<file.pem>         Server private key (default: server.pem)
 -rpcsslciphers=<ciphers>                 Acceptable ciphers (default: TLSv1.2+HIGH:TLSv1+HIGH:!SSLv2:!aNULL:!eNULL:!3DES:@STRENGTH)

Regarding double spending, I use a single nomadic mint agent that timestamps each accepted transaction and broadcasts it back into the network for archival and verification. That is a so-called single-writer to the canonical blockchain, which prevents double spending. Right?

Regrading the peer review of my May 2013, whitepaper, the Bitcoin developers that I have contacted prefer to see working code and the test suite. All are skeptical that my cooperative ideas solve the distributed consensus problem.

[CIYAM]

Bitcoin Core already includes X.509 infrastructure for remote procedure calls, therefore that technology has been vetted by them and run in production.

Bitcoin does not use X.509 for anything important (it was added for merchants and has nothing to do with the core operations).

Regarding double spending, I use a single nomadic mint agent that timestamps each accepted transaction and broadcasts it back into the network for archival and verification. That is a so-called single-writer to the canonical blockchain, which prevents double spending. Right?

Your statement about "sometimes allowing double-spends" is *completely false* - please show me 1 example of a *double spend* in the Bitcoin blockchain to back up your claim (and yes I know *you can't because there is no such thing*).

[SlipperySlope]

Bitcoin Core already includes X.509 infrastructure for remote procedure calls, therefore that technology has been vetted by them and run in production.

Bitcoin does not use X.509 for anything important (it was added for merchants and has nothing to do with the core operations).

Might I beg some more clarification on the X.509 attack surface given the details I provided?

Regarding double spending, I use a single nomadic mint agent that timestamps each accepted transaction and broadcasts it back into the network for archival and verification. That is a so-called single-writer to the canonical blockchain, which prevents double spending. Right?

Your statement about "sometimes allowing double-spends" is *completely false* - please show me 1 example of a *double spend* in the Bitcoin blockchain to back up your claim (and yes I know *you can't because there is no such thing*).

Thanks for your clarification. I will amend my claim accordingly to "double-spending fraud attacks, e.g. BitUndo".

Double-spending

Bitcoin has some exposure to fraudulent double-spending when a transaction is first made, with less and less risk as a transaction gains confirmations.

Here is the well known example of the Finney attack which is based upon double spending. To be clear, what I mean by double spending is the issuance of two or more bitcoin transactions such that at the time of issuance each receiver believes the transaction to be good, yet because the longest blockchain will only contain one copy of the transaction, there is the opportunity for fraud. The appearance of this service caused a great deal of consternation on the Bitcoin core developers mail list ...

BitUndo

Contrary to popular belief, your mistakes might not be forever. Until a transaction appears in the blockchain (aka is confirmed) no demonstrable work has been done, or needs to be undone in order to change it. Bitundo incentivizes miners to undo your mistake transaction, by including a transaction that would conflict with it (aka having a conflicting input).