Topic: AI Coin Development Diary - page 4. (Read 49308 times)

What's happened to this project?

Interesting ideas, and difficult to read even when read twice, learning a lot here.

Any thoughts already about what algorithm to use?
You are talking about hardforking Bitcoin (when/if A.I. Coin is succesfull and accepted by the community), does that mean it will most likely be a sha265 algorithm?

Wish I had time to follow this, seems very interesting.. good luck. I already learned alot just reading through this post.

P.S. C programmers are heros*

A.I. Coin will launch with a minimum of five super peers, located in geographically dispersed datacenters.  The founding super peer operators will vet candidates that become new super peers when needed due to growing transaction volume.

A joining node cannot become a super peer otherwise.

I didn't realize such persistence was a requirement of your design.  I was thinking about certificates that are regenerated by a node every time its IP changes, enhancing anonymity and reducing the ability of an adversary to recreate a historical network state.   It may not have been relevant after all. 

Thanks for your reply.

But what are the (objective) criteria by which the mint role is assigned? My worry is that there is no valuable/scarce resource necessary to become the mint and therefore control the network...

The most valuable ressources (for an attacker) seem to be "node-stake" and the quantity of nodes since everyone seems to be able to become a super peer no matter of his stake size (correct?). Isn't this much easier to achieve than pure stake?

Each distributed agent/role has a self-signed X.509 certificates for digital signatures and for SSL/TLS communication channel encryption. The tamper-evident data structures, e.g. agent logs, are signed by X.509 certificates. I plan to use the solar flux chaos value as you suggested in the KSI scheme which ties together all the distributed tamper-evident data structures into a temporal merkel tree whose root hash value is widely known.

Could you help me understand how transient IPv6 addresses can be used to sign hashes? The system needs the X.509 certificates to establish unique agent/role identity that persists over time.

I really appreciate the thought that you have given to this project.

A design where IP addresses are transient and used to sign hashes, wherein the next IP to be assigned to a given node is random, would seem to be harder for an adversary with unlimited computing power to precompute and attack.  This extremely-dynamic IP assignment is built into IPv6.  That was the thought.

Yes, each full node votes the stake of its operator, which may be offline in a cold wallet. The stake is composed of the unspent transaction outputs that are controlled by the full node operator.


The peer that hosts the mint is selected by the configuration agent from among the super-peers. The simplest method is to take-turns round-robin. The duration of the mint responsibility is a parameter that can be adjusted. Given that the mint hosting schedule can be efficiently published in advance to all peers, then the mint hosting duration could be anywhere from 10 minutes to perhaps one week.


CPOS is designed similar to a conventional financial network, except that hardware and operations are provided by unrelated parties. The direct attack would be to compromise 51% of the stake-weighted peers.

The least expensive and perhaps least effective attack is a DDoS attack on certain network IP addresses. The super peers will be located in datacenters which have DDoS protection services. The ordinary peers should be too numerous to effectively attack, which is the defense that Bitcoin uses.


The main advantage of CPOS is that there is single mint and one version of the blockchain, leading to immediate transaction settlement.
The main disadvantage of CPOS is that its design has not yet been tested in production.

Thanks for thinking about this project when reading about related tech!

Privacy Extensions for Stateless Address Autoconfiguration in IPv6

The A.I. Coin network is connected via known TCP IP addresses. A client joining the network uses a built-in list of seed IP addresses to reach one or more full-nodes which provide configuration information that includes more IP addresses.

Could you elaborate on the positive implications?

At the Hasher's United Conference, I spoke about Cooperative Mining. The conference was recorded, and Kris Stinson has uploaded my talk to YouTube.

What is Cooperative Mining Bitcoin? Stephen Reed. Filmed at Hashers United Oct. 10/14

The corresponding six slides (PDF) are here.

At the conference after my talk, Drew Hingorani and I decided to co-found A.I. Coin for launch in March 2015.

My current short term A.I. Coin development goal is to get three Docker containers running A.I. Coin, accepting transactions and creating new blocks.

Hello Stephen,

I went through your whitepaper. Thanks for your contributions to move this technology forward! I have a few questions.

How does a case look like where stake weighted voting is required? Isn't it "node-stake" weighted voting (as indicated at the end of 6.9)?

How is the mint (s)elected or is the mint role being passed around among all super peer nodes? For how long does one node host the mint?

To estimate how secure a system is it makes sense to describe the weakest link and estimate what the costs are to exploit it. (assuming: there is no perfect system; every system has attack vectors). What would you say is the cheapest / easiest way to attack[attack meaning a) a political attack (destroy the system to people loose the trust in it) or b) an economically motivated attack like a double spend attack] a CPOS system?

What are the ad- and disadvantages of CPOS compared to DPOS (http://wiki.bitshares.org/index.php/DPOS_or_Delegated_Proof_of_Stake)?

I was reading up on IPv6 and thought of this project when I read this:

http://datatracker.ietf.org/doc/rfc4941/

RFC4941 Privacy Extentions allows for nodes to randomly shift their IPv6 addresses in order to foil MAC and IP tracking.  I intuit that there are some positive implications for using IP addresses to sign hashes, especially in a KSI regime.

Scumby

Perhaps I can change that opinion. I suppose that because Bitcoin Core was written by Satoshi in C++, that language is the traditional approach in cryptocurrency. C++ is arguably more performant than Java, but the latter's many security and productivity advantages are well known.

For example ....

1. Java has a number of excellent Integrated Development Environments which enable the faster design, writing, debugging and regression testing of applications. In contrast, Bitcoin Core developers often use command line tools.

2. Java is inherently safer than C++ in that security is provided by a runtime environment which abstracts the underlying operating system and hardware.

3. Java encourages reuse. Notably, I use the Bouncy Castle cryptography library in this project.

4. Java source code is easier to read and understand than the same behavior written in C++. Please look at the source for BitcoinJ on GitHub vs the Bitcoin Core source on GitHub. More programmers have been taught Java than C++. Unfortunately, I believe that Satoshi received a Computer Science degree before Java was popularized in the late 1990's.

5. The community you speak of probably does not develop applications for Android, the world's dominant mobile device operating system, which because of the reasons I mention, strongly favors their rebranded Java language.

Bitcoin Core developers are stuck with the messy C++ code Satoshi left them, and have been forced to rewrite half of it, according to Gavin Andressen. In this project I have made very modest changes to C++ Bitcoin Core to repurpose its testing behavior, allowing the creation of a new block every 10 minutes with a trivial proof-of-work. I treat bitcoind as a slave process entirely controlled and proxied on the network by Java software agents. Thus this project retains full feature and bug fidelity with the Bitcoin protocol, and compatibility with existing wallets and processors via a set of TexaiCoin seed IP addresses and port.

Writing in Java, i.e the NetBeans IDE on Ubuntu, enables me to swiftly explore alternative implementations of new features.

As suggested in a prior post by Scumby, I am currently working on keyless signature infrastructure as part of the tamper-evident log module. I am using SHA-512 hashing as provided by Bouncy Castle. Each full node's logs will be temporally salted with the current Solar Flux indicator and hashed into a network-wide, timestamped merkle tree whose root value is widely known and archived, e.g. into an operators' mail list. This prevents equivocation misbehavior by a peer which cannot undetectably report an incorrect version of its state to an attesting peer, who verifies the target peer's version state hash in the distributed provenance merkle hash tree.

I am so glad to be using Java.

Because the CryptoCoin community is mostly composed by geeks (who can't tell the difference between Java, Java plugin, and Javascript), and not professional developers. There are also many C and Python fanboys who fall into the "heroic programming" category (hint: this isn't something desirable).

Java isn't really seen in a good light in the CryptoCoin community.

Nothing I wrote was false. Nxt is secure; no-one has successfully attacked it (as opposed to attacking exchanges or individuals). If you read the quote you linked to, here, Gregory Maxwell was very clearly being specific to Peercoin and Peercoin's flaws. He may have written other things elsewhere; I just commented on the bit you linked.

We looked at Chord as well.
Have you looked into Whānau DHT?
What is Whānau? It means "extended family".
http://en.wikipedia.org/wiki/Whānau

These are some of the techniques described by Chris Lesniewski-Laas and M. Frans Kaashoek from the MIT: Computer Science and Artificial Intelligence Laboratory.

http://pdos.csail.mit.edu/papers/ton:chord/paper-ton.pdf

Regards,

Self-signed X.509 Certificate Transparency

In this project I need a tamper-evident log-store of X.509 certificates replicated in, or otherwise available to, each container. I could simply trust a remote peer's certificate upon first use, but that method does not prevent a man-in-the-middle attack. A better alternative is a replicated tamper-evident log-store that is checked by the sender for correct listing of its IP address and certificate. The message recipient verifies the message signature of the message using the certificate looked up, or previously cached, for the sender's qualified role name: container-name.agent-name.role-name.

Each peer agent/role that communicates beyond its container to a remote agent/role will generate its own self-signed X.509 certificate and safeguard the private key in the local container encrypted keystore. I am thinking about following the keyless signature infrastructure (KSI) design suggested by Scumby in which a growable binary merkle hash tree timestamps and stores the certificates along with a Solar Flux Index chaos value. An index over the log-store records keys consisting of the qualified role name, and values consisting of the IP address and certificate of a peer agent/role. A later-dated entry for a peer supersedes an earlier-dated entry in the log-store, which permits container operators to occasionally migrate from one IP address to another. I expect paid super peers to have static, seldom changing IP addresses. Lesser-paid, blockchain archiving nodes, may execute using a residential internet connection having a dynamic IP address, which would not be recorded in the certificate log-store.

 The tamper-evident log for the certificates would be part of the downloaded container for a new installation, and would be updated securely by polling a sufficient number of peers once connected to the network.

The previous version of Texai used a Chord distributed hash table to contain the certificates. But for TexaiCoin I have removed the Chord library as it was another moderately complex attack surface that could be avoided by using a simple tamper-evident distributed data structure.

My intent in introducing KSI is it is an example of a design along the same lines where

a) a central "mint" can be trusted but verified by peers
b) peers can be trusted because their transactions must signed by the central mint, so you can have a canonical blockchain (blocktree?)
c) there's no replaying of the blockchain possible thanks to information partitioning, but integrity can still be checked by everyone by verifying the hierarchical hash tree calculations. 

If you make the mint nomadic, and you add public chaos to handicap anyone who somehow could forecast the blockchain, I think you would have something better than Bitcoin.