AI Coin Development Diary

[Brangdon]

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?

A hack of an exchange is not a 51% attack. 5% is not enough coin to mount an attack. The hack had no effect on block-chain security; the hacker couldn't do anything that Bter couldn't have done.

And I don't see what's so "implausible" about buying half of the coins when the market cap is so small.

If you try to buy so many, the price will rise. If you succeed, you will find you are attacking yourself.

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.

You have to have owned them within the last 12 hours or so, because although Nxt doesn't have checkpoints, it does disallow block-chain reorganisations past 720 blocks. This means to do what you suggest you have to acquire 51% of Nxt and then sell them all off within 12 hours. Dumping in such volume would crash the price, and you'd lose a lot of money.

With PoW at least the attacker will have trouble recovering the costs of his mining gear which will become obsolete.

The mining gear can be used for other PoW coins that use the same ASICs.

See what Gregory Maxwell (nullc) thinks about PoS:

He's talking about Peercoin. It's a different algorithm. His comments don't apply to Nxt.

[1715222238]

1715222238

[1715222238]

1715222238

[1715222238]

1715222238

[1715222238]

1715222238

[1715222238]

1715222238

[1715222238]

1715222238

[hbadger]

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?

A hack of an exchange is not a 51% attack. 5% is not enough coin to mount an attack. The hack had no effect on block-chain security; the hacker couldn't do anything that Bter couldn't have done.

And I don't see what's so "implausible" about buying half of the coins when the market cap is so small.

If you try to buy so many, the price will rise. If you succeed, you will find you are attacking yourself.

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.

You have to have owned them within the last 12 hours or so, because although Nxt doesn't have checkpoints, it does disallow block-chain reorganisations past 720 blocks. This means to do what you suggest you have to acquire 51% of Nxt and then sell them all off within 12 hours. Dumping in such volume would crash the price, and you'd lose a lot of money.

With PoW at least the attacker will have trouble recovering the costs of his mining gear which will become obsolete.

The mining gear can be used for other PoW coins that use the same ASICs.

See what Gregory Maxwell (nullc) thinks about PoS:

He's talking about Peercoin. It's a different algorithm. His comments don't apply to Nxt.

No, he's talking about PoS too. If you have any doubts go ask him yourself. He's always in the #bitcoin-wizards IRC channel. PoS is not considered a viable alternative to PoW yet. There will have to be another breakthrough to make it workable.

[SlipperySlope]

[Gregory Maxwell] talking about PoS too. If you have any doubts go ask him yourself. He's always in the #bitcoin-wizards IRC channel. PoS is not considered a viable alternative to PoW yet. There will have to be another breakthrough to make it workable.

I briefly chatted with Gregory Maxwell on #bitcoin-wizards last spring as I was publishing my whitepaper on Bitcoin Cooperative Proof-of-Stake. Certainly the Bitcoin core developers are skeptical that anything other than proof-of-work can solve the distributed consensus problem. He graciously wished me well with regard to my approach, and I believe that the core developers, e.g. those chatting in #bitcoin-wizards IRC channel, will have more pointed questions and comments when this project's working code is deployed into production, vs commenting on a whitepaper.

Satoshi designed bitcoin, I think, by adapting a napster style peer-to-peer network, e.g. omitting the central index server, to support an anonymous digital currency. His envisioned users were also operators who mined bitcoins using their laptops, from residential internet connections, while joining and leaving the network at will. This is the context of how core developers view distributed consensus.

In contrast, this design fits the Satoshi Social Contract into a conventional distributed enterprise-style financial network, e.g. omitting central control. Its envisioned users are wallet owners and payment processors. Its envisioned operators are non-affiliated paid system administrators who securely provision identical software containers on bare metal dedicated servers in geographically disparate datacenters. The system is innovatively managed by peer-verified software agents having no single point of failure. The nomadic mint agent builds a canonical non-forking blockchain, which is widely copied, and allows immediate transaction processing without confirmations.

Andytoshi, a core developer and mathematician here in Austin, said to me over lunch: "But this is not Bitcoin!". He elaborated to say that a single mint was opposite of what Satoshi wanted. Andytoshi was not then persuaded by my argument that a peer-verified nomadic mint solved the problem of trusting a central mint. Rather he was interested in the vulnerabilities my scheme might have with regard to attacks and network faults in which the system must come to agreement on the correct or optimal version of system state, e.g. who gets to be the mint, and what happens if there are forged blockchains. That is why this project needs to reach production for such fault scenarios to be designed, tested and reported.

[hbadger]

[Gregory Maxwell] talking about PoS too. If you have any doubts go ask him yourself. He's always in the #bitcoin-wizards IRC channel. PoS is not considered a viable alternative to PoW yet. There will have to be another breakthrough to make it workable.

I briefly chatted with Gregory Maxwell on #bitcoin-wizards last spring as I was publishing my whitepaper on Bitcoin Cooperative Proof-of-Stake. Certainly the Bitcoin core developers are skeptical that anything other than proof-of-work can solve the distributed consensus problem. He graciously wished me well with regard to my approach, and I believe that the core developers, e.g. those chatting in #bitcoin-wizards IRC channel, will have more pointed questions and comments when this project's working code is deployed into production, vs commenting on a whitepaper.

Satoshi designed bitcoin, I think, by adapting a napster style peer-to-peer network, e.g. omitting the central index server, to support an anonymous digital currency. His envisioned users were also operators who mined bitcoins using their laptops, from residential internet connections, while joining and leaving the network at will. This is the context of how core developers view distributed consensus.

In contrast, this design fits the Satoshi Social Contract into a conventional distributed enterprise-style financial network, e.g. omitting central control. Its envisioned users are wallet owners and payment processors. Its envisioned operators are non-affiliated paid system administrators who securely provision identical software containers on bare metal dedicated servers in geographically disparate datacenters. The system is innovatively managed by peer-verified software agents having no single point of failure. The nomadic mint agent builds a canonical non-forking blockchain, which is widely copied, and allows immediate transaction processing without confirmations.

Andytoshi, a core developer and mathematician here in Austin, said to me over lunch: "But this is not Bitcoin!". He elaborated to say that a single mint was opposite of what Satoshi wanted. Andytoshi was not then persuaded by my argument that a peer-verified nomadic mint solved the problem of trusting a central mint. Rather he was interested in the vulnerabilities my scheme might have with regard to attacks and network faults in which the system must come to agreement on the correct or optimal version of system state, e.g. who gets to be the mint, and what happens if there are forged blockchains. That is why this project needs to reach production for such fault scenarios to be designed, tested and reported.

I agree and have high expectations for what you are doing. You seem to know your crypto and at the same time you are one of the few who actually uses professional development techniques.

I was just pointing out a few false statements that I have seen here, like "Peercoin has never been attacked", "Nxt is [cryptographically] secure", "Gregory Maxwell was only talking about Peercoin", etc.

[Scumby]

Andytoshi, a core developer and mathematician here in Austin, said to me over lunch: "But this is not Bitcoin!". He elaborated to say that a single mint was opposite of what Satoshi wanted. Andytoshi was not then persuaded by my argument that a peer-verified nomadic mint solved the problem of trusting a central mint.

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. 

[SlipperySlope]

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.

[ASIC-8Tile]

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,

[Brangdon]

I was just pointing out a few false statements that I have seen here, like "Peercoin has never been attacked", "Nxt is [cryptographically] secure", "Gregory Maxwell was only talking about Peercoin", etc.

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.

[beitris.dwlul]

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

[hbadger]

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

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

[SlipperySlope]

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

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.

[Scumby]

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

[delulo]

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

[SlipperySlope]

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.

[SlipperySlope]

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

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?

[SlipperySlope]

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

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.

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?

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.

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?

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.

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

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.

[Scumby]

Could you elaborate on the positive implications?

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.

[SlipperySlope]

Could you elaborate on the positive implications?

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.

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.

[delulo]

Thanks for your reply.

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.

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?

[Scumby]

The system needs the X.509 certificates to establish unique agent/role identity that persists over time.

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.