AI Coin Development Diary

[SlipperySlope]

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.

The coins I would fork are currently the highest market capitalization Satoshi proof-of-work coins. Perhaps in a few more months, Dogecoin will fall out of that group. Or on the other hand, a rally in Bitcoin might lift most altcoins as happened November 2013.

I understand your points about the relative merits of coins. But, analogous to current industrial mining, I want to position the CPOS system as an agnostic platform that secures the network for a variety of branded coins without controlling their respective business communities, and thus isolated from their behavior. The CPOS system would drop a coin whose block rewards no longer pay for the storage of their blockchain.

CPOS will enable each supported coin to have lower transaction fees and immediate, certain acknowledgement that accepted transactions will be included in their respective blockchain. CPOS operators, as directed by the software, will contribute a significant portion of respective block rewards to the Litecoin and Dogecoin foundations for use as those communities see fit.

Furthermore, CPOS supported coins will not be subject to 51% attacks. Their transactions will be immutable and thus not subject to double spend attacks. All traffic between paid-for full nodes is TLS/SSL encrypted, and because each such full node is identified by a unique X.509 certificate, there will be no Sybil attacks.

To buoy coin prices and to encourage user migration to the CPOS fork, I would establish a CPOS system policy that allocates a modest portion of block rewards to post-fork unspent transaction outputs in the blockchain as a dividend.

Once the system is up and running, new coins can be enrolled in CPOS during the coin's development process by substituting CPOS for the otherwise required mining pool, on the condition that the developers clone Bitcoin Core, i.e. bitcoind, software. Aside from premining, promoters can pay themselves by owning the foundation that CPOS funds via block rewards, or by accepting payment directly from CPOS to add features - again via block rewards.

[pa]

I was wondering whether CPoS has been reviewed, or commented on, by any of the Bitcoin core devs.

[SlipperySlope]

I was wondering whether CPoS has been reviewed, or commented on, by any of the Bitcoin core devs.

Yes, andytoshi personally, and gmaxwell on IRC.

Before writing the whitepaper I met with andytoshi here in Austin, Texas and we discussed the issues of achieving consensus in a distributed system. He believed then that my ideas were not Bitcoin, as I sidestep distributed consensus by not having a Satoshi-style, join-and-leave at will, anonymous, volunteer peer-to-peer system. CPoS has paid-for, authenticated full nodes that are permanently operated by geographically dispersed, non-affiliated system administrators. CPoS is cooperative and achieves trustless behavior via transparent software agents that verify each other's actions. Gmaxwell, I believe, wants to see the working system.

Core developers will likely closely scrutinize the nomadic central mint that enables all CPoS advantages. As I plan to use bitcoind as is, I actually do not need core developer acceptance of a pull request for changes to the Bitcoin Core software. Rather my code encapsulates a slave bitcoind instance and proxies its connections to the secure network CPoS manages.

I plan to explore microtransactions as a route to more general acceptance, as CPoS has benefits for this up-to-now unserved market, namely 100x less transaction fees and immediate acknowledgement  for inclusion in the next block.

Should CPoS prove successful in its forks of the popular PoW coins, then I expect the system to use a portion of the block rewards to hire a relatively large number of developers to join those already working on Bitcoin Core.

I am dropping the idea of paying dividends to existing coin holders, as the system stake is provided by the paid-for full node operators. The block rewards are better spent to improve the coins, and encourage their use in transactions.

[kelsey]

I'm not upto speed on all of this project ie spent about 2 minutes.

However you wish to hardfork BTC beginning of 2016? you want major holders to follow your fork?

Why not just create a new chain?

What is the point of using BTC when for a start even a bitcoin advocate could hardly consider bitcoins current distribution as ideal?

Also well before you finish there will already be a bitcoin pos on its own blockchain (another project with significant backing far removed from this forum).

[hbadger]

I'm not upto speed on all of this project ie spent about 2 minutes.

However you wish to hardfork BTC beginning of 2016? you want major holders to follow your fork?

Why not just create a new chain?

What is the point of using BTC when for a start even a bitcoin advocate could hardly consider bitcoins current distribution as ideal?

Also well before you finish there will already be a bitcoin pos on its own blockchain (another project with significant backing far removed from this forum).

Because he wants his initiative to succeed, not to be just another short lived pump and dump scam. He wants to preserve Satoshi's social contract.

[SlipperySlope]

I'm not upto speed on all of this project ie spent about 2 minutes.

However you wish to hardfork BTC beginning of 2016? you want major holders to follow your fork?

Why not just create a new chain?

What is the point of using BTC when for a start even a bitcoin advocate could hardly consider bitcoins current distribution as ideal?

Also well before you finish there will already be a bitcoin pos on its own blockchain (another project with significant backing far removed from this forum).

Because he wants his initiative to succeed, not to be just another short lived pump and dump scam. He wants to preserve Satoshi's social contract.

That.

Plus the current PoW coins are in a sort of unstable equilibrium, in which their operating situation is locally optimal, even though a hard fork to reallocate the mining reward would be greatly beneficial to the community. As Tim Swanson explains in his recent book, the core developers of Bitcoin do not have the staff nor the consensus to make a great change to how Bitcoin works. Disruption must occur from the outside and start with a market PoW cannot currently address - I will try microtransactions for example.

[othe]

But you noticed that the coins you will issue if you hardfork the chains will simply be owned mainly by:

1) Exchanges
2) Destructive idiots like Mark Karpeles
3) Big investors

My guess is, exchanges/investors will just dump them onto the market.

I can´t see how that is in any spirit of what satoshi had in his mind.

[SlipperySlope]

But you noticed that the coins you will issue if you hardfork the chains will simply be owned mainly by:

1) Exchanges
2) Destructive idiots like Mark Karpeles
3) Big investors

My guess is, exchanges/investors will just dump them onto the market.

That could happen, but I suggest that current holders will simply wait and see what happens to the price of forked coins. The price of a coin, I believe, depends mainly on the quantity of economic transactions its users are willing to make. Metcalfe's Law, as applied to coin prices, says that the price of the coin should be proportional to the square of the number of transactions. My goal therefore is not to get big investors to buy, or even to hold - rather my goal is to get payment processors to accept my forked coins because of their performance - namely immediate acceptance and 100x lower fees. I plan to also use a variety of marketing promotions, allocated from block rewards, to induce users to transact the forked coins.

The first market will be microtransactions, which should lead to high transaction quantity but little in the way of amount.

I can´t see how that is in any spirit of what satoshi had in his mind.

My interpretation of Satoshi's writings are different than yours. He had little to say about the unequal distribution of bitcoin wealth, which is important because he owns so much of it. Obviously, CPoS overturns Satoshi's brilliant solution to the problems of electronic cash, yet I attempt to maintain the Satoshi Social Contract to the greatest extent possible, e.g. no trusted third parties, create a new block every 10 minutes and have a maximum 21 million bitcoins ever.

[SlipperySlope]

Today I completed the revision, testing and upload of the Texai modules that will provide the foundation for cooperative proof-of-stake for Bitcoin. GitHub has the source code files and I have uploaded the large RDF repositories directory and the large Maven artifacts directory to an account I established at Mega. Shortly I will clean up GitHub by removing those large data directories.

Next steps in CPoS development will be to download and study Bitcoinj which I will use as the adapter to communicate with bitcoind. Bitcoinj is written in Java and bitcoind, which I plan to leave mostly unchanged, is written in C++. Texai is written in Java.

[SlipperySlope]

Today I removed the very large data repositories from GitHub as they were beyond the size guidelines of GitHub. I have them hosted at Mega instead.

I am now studying the source code of the Bitcoin Core. I am looking in particular at the -regtest option and how in conjunction with the setgenerate Command Line Interface option, the bitcoind program can be made to generate a block with a single hashing attempt. I plan to introduce a new option ...

Code:

-nopowafter=<n>    After block <n> generate and verify proofs of work with trivial difficulty

My plan for the CPoS nomadic mint agent is to slave a running instance of my modified bitcoind program to a supervising agent that runs in the separate local Texai Java process. The agent will configure the slaved bitcoind with the -nopowafter=317439, for example, and then command the bitcoind instance to generate a new block every ten minutes with the setgenerate 1 CLI command.

I had hoped to leave bitcoind completely untouched but the regtest option is tightly coupled to certain permissive testing behavior that I do not want for CPoS production.

Perhaps I can begin a hard fork of the Bitcoin blockchain for alpha testing September 1 GMT. I plan to open the network to the public when I have it migrated to at least one enterprise server, and have the software agents that proxy bitcoind completed. Note that I have not yet developed the tamper-evident logs that are the key network security feature of CPoS.

When open to the public for beta testing, I expect you to find your bitcoin holdings from before September 1 intact, once you configure a separate Bitcoin wallet to connect to certain IP addresses that I will provide.

Note that bitcoins on the CPoS network are an altcoin - they are not bitcoins on the main network.

[SlipperySlope]

I have two bitcoind instances running in my lab and they tend to utilize excessive upload bandwidth even with one connected only to the other, and with each of them not listening for inbound connections.

On Ubuntu 14.04 LTS I installed trickle which performs network traffic.

Code:

$ cd <directory containing bitcoin-qt>
$ trickle -u 10 -d 20 ./bitcoin-qt -listen=0 -maxconnections=4

These settings allow me to receive updates to my local blockchain replica, while limiting the consumed bandwidth.

[SlipperySlope]

I completed the modifications to bitcoin core C++ code that allow a new command line option -nopowafter=<n>, where n is the blockchain height, i.e. the blocknumber, at the time of the fork.

My additions and changes can be inspected at my GitHub account for TexaiCognitiveArchitecture https://github.com/TexaiCognitiveArchitecture/bitcoin/tree/no-pow-mods in the branch named no-pow-mods.

Next I need to operate bitcoin-qt in a debugging mode in my NetBeans IDE, i.e. C++ integrated development environment, and use bitcoin-cli to send setgenerate commands and see if the block gets created and that the block reward is subsequently present in the bitcoin-qt wallet with a new address.

[SlipperySlope]

Information Security For Cloud Services - Article Snippets

Catastrophe in the cloud: What the AWS hacks mean for cloud providers

Organisations must ensure they have the rudimentaries in place: role-based access control, two factor authentication, encrypted key stores, and remote, offline back-up.

There must be vigilance, with activity monitored and anomalies reported in line with the incident response plan, and regular security audits performed to ensure sufficient controls are in place.

The 2014 cyber security roadmap

... moving towards end-to-end automation of network changes should free up time to concentrate on monitoring all areas of the network.

Controlling the privileged user

Without a doubt, one of the biggest mistakes that organisations make is having insufficient control and oversight of the actions of ‘privileged users’, says Paul Ayers, VP EMEA of security firm Vormetric.

‘In 2014, after the Snowden leaks and other high-profile insider threats and data breaches, I expect organisations to increasingly put in place the security procedures and tools that allow them to audit and control the actions of these users,’ he comments.

With DDoS tools becoming more advanced and pervasive, Bains warns that all IT operations should work under the premise that they will be attacked, and so plan accordingly.

‘Every stack and layer within their purview should be reviewed, and they should identify cost-effective cloud solutions for their DDoS, which provide much better performance and mitigation than expensive hardware.’

Catherine Pearce, security consultant at mobile security firm Neohapsis, predicts that DDoS attackers will accelerate a move from simple volumetric attacks to those that take advantage of a site's specific performance, with the spread of tools that profile specific targets and attack based upon certain weaknesses in configuration or implementation.

‘Customers’ expectations for seamless trusted authentication and the continued dominance of smartphones and smart devices will accelerate the move from legacy hardware one-time password tokens to mobile-friendly, embedded security and contextual access controls,’ says SafeNet’s Jason Hart. ‘We can already see early examples such as Apple’s iTouch of biometric authentication, and investments by vendors such as Samsung to bake enterprise-grade security controls into their KNOX platform.’

Jason Hart of SafeNet reiterates that in the coming year we can expect to see companies move away from the traditional strategy of focusing on breach prevention, and towards a ‘secure breach’ approach.

‘This means accepting that breaches happen and using best practice data protection to guarantee that data is effectively useless when it falls into unauthorized hands,’ he says. ‘So, we can expect to see an increase in the use of encryption that renders any data useless to an unauthorized party.’

3 Critical Best Practices for Encryption Key Management on the IBM i

The top 3 critical best practices are:

Separation of Duties - This is widely known control set in place to prevent fraud and other mishandling of information. Separation of duties means that different people control different procedures so that no one person controls multiple procedures. When it comes to encryption key management, the person the person who manages encryption keys should not be the same person who has access to the encrypted data.

Dual Control - Dual control means that at least two or more people control a single process. In encryption key management, this means at least two people should be needed to authenticate the access of an encryption key, so that no one single person has access to an encryption key

Split Knowledge - Split knowledge prevents any one person from knowing the complete value of an encryption key or passcode. Two or more people should know parts of the value, and all must be present to create or re-create the encryption key or passcode. While split knowledge is not needed to create data encryption keys on the IBM i, it is needed for the generation of master keys which are needed to protect data encryption keys. Any encryption keys that are accessed or handled in the clear in any way should be protected using split knowledge.

The three core controls should always be used when storing or transferring encrypted sensitive data. A certified, hardened security module (HSM) designed to secure data encryption keys and key, or master, encryption keys should implement these controls into the administration of the key manager. NIST FIPS 140-2 validation is an important certification to look for in an encryption key manager. This certification ensures that your key manager has been tested against government standards and will stand up to scrutiny in the event of a breach.

[SlipperySlope]

Young Genius vs Old Master

The New Yorker article from 2008 on late bloomers brought to my attention by HackerNews might, if one were generous, analogously apply to 63 year old me, substituting developer for painter/artist, project for painting ...

... But late bloomers, Galenson says, tend to work the other way around. Their approach is experimental. “Their goals are imprecise, so their procedure is tentative and incremental,” Galenson writes in “Old Masters and Young Geniuses,” and he goes on:

The imprecision of their goals means that these artists rarely feel they have succeeded, and their careers are consequently often dominated by the pursuit of a single objective. These artists repeat themselves, painting the same subject many times, and gradually changing its treatment in an experimental process of trial and error. Each work leads to the next, and none is generally privileged over others, so experimental painters rarely make specific preparatory sketches or plans for a painting. They consider the production of a painting as a process of searching, in which they aim to discover the image in the course of making it; they typically believe that learning is a more important goal than making finished paintings. Experimental artists build their skills gradually over the course of their careers, improving their work slowly over long periods. These artists are perfectionists and are typically plagued by frustration at their inability to achieve their goal.

[SlipperySlope]

The Elevator Pitch For This Project

The system that I'm developing forks Bitcoin and other major PoW coins into separate networks, I avoid the Byzantine Generals problem by using authenticated cooperating agents rather than anonymous competing nodes. If distributed uncoordinated behavior is designed out of the system, then there is no need for distributed consensus.

I take a conventional high performing global financial network architecture, and adapt it to maximally preserve the Satoshi Social Contract, e.g. the user experience. My technique permits instant, certain-to-be-in-the-blockchain transactions with 100x lower fees. How? Because a nomadic mint agent creates new blocks for a widely replicated, non-forking, canonical blockchain with trivial PoW effort. The block reward fees pay qualified full node operators to secure the distributed peer network using conventional data security methods, e.g. TLS/SSL, DDoS filtering, fail-over, digitally signed logs, network operations centers, security intrusion detection and mitigation, customer service, etc.

[CIYAM]

Avoiding the Byzantine Generals problem *doesn't solve it*.

So apart from adding the terms TLS/SSL (that are meaningless in this context) what exactly are you offering as an improvement?

(so far - I don't get it)

[SlipperySlope]

Avoiding the Byzantine Generals problem *doesn't solve it*.

So apart from adding the terms TLS/SSL (that are meaningless in this context) what exactly are you offering as an improvement?

(so far - I don't get it)

Indeed, there no need to solve a problem that can be designed out of the system. From my whitepaper ...

This system uses an attestable unforgeable log organization inspired by Nick Szabo. In particular, this system uses attested append-only memory as described by Chun et. al. [36] who provide mathematical arguments for is properties. It remains correct and keeps making progress even when half the replicas, e.g. blockchain replicas, are faulty. This is an improvement over previous Byzantine Fault Tolerant algorithms lacking a tamper-evident log, which allowed only one third faulty replicas

Note that Satoshi's Bitcoin is designed for frequent disagreement among full nodes as to which is the correct blockchain - because all miners are simultaneously attempting to create the next block. In a cooperative system, only one node creates the block according to a pre-arranged schedule. The other nodes verify the actions of the nomadic mint. Disagreement in this system is not designed in, rather it is the result of a fault or an attack.

The primary user improvement I offer is ...

My technique permits instant, certain-to-be-in-the-blockchain transactions with 100x lower fees.

Transport Layer Security using X.509 certificates issued by the system's distributed Texai certificate authority credentials the system's paid full node operators. Each packet within the network is thus encrypted against tampering and tamper-evident logs at each full node permit remote attestation that allows peers to verify each other's good behavior. The trustless behavior of this system is provided by software agents whose algorithms are open source.

Furthermore,  highly automated network operations management allows this system to react quickly in the face of attack or catastrophe. Customer service is provided to answer user's inquiries.  All of this is paid for by the block rewards at no additional cost to users - who pay 100x lower fees than the Satoshi system.

The Cooperative Bitcoin system is free or low cost to use because it is compatible, given a change in seed IP address, with all existing wallets and services. The source code and non-security-related data are open source and free to download and use. The system, e.g. existing operators, vet new operators according to system administration skills and compliance with the system-specified hardware and software. As block rewards grow in value with increasing adoption by users and subsequent rise in coin price, additional operators can be paid throughout the world. Volunteer full node operators can use the system software to act as blockchain archival nodes, as a last resort disaster recovery of the blockchain and in-flight transactions.

[SlipperySlope]

How I Explain Cooperative Bitcoin Versus Satoshi's Bitcoin

Suppose, in some possible world, that the gathering of transactions, maintenance of the blockchain, and the hashing calculation is performed by humans with calculators in a Satoshi-style proof-of-work system. Bitcoin today is sort of like these humans working independently in unseen chest-high cubicles and when the solution is found the winning miner stands up and claims the reward.

But alternatively, in a single room, the humans could retain their anonymity by masks or other disguise and cooperate to create a new block with no effort by taking turns, round robin, in order to collect the reward on schedule every 10 minutes. Each cooperating miner would maintain their copy of the canonical blockchain for backup.

Intelligent agents permit efficient, verified, cooperative behavior.

Central to my hypothesis, is the notion that Bitcoin is valuable because some people think it is valuable, not because X effort was consumed to create X value in bitcoin.

[CIYAM]

The primary user improvement I offer is ...

My technique permits instant, certain-to-be-in-the-blockchain transactions with 100x lower fees.

Transport Layer Security using X.509 certificates issued by the system's distributed Texai certificate authority credentials the system's paid full node operators. Each packet within the network is thus encrypted against tampering and tamper-evident logs at each full node permit remote attestation that allows peers to verify each other's good behavior. The trustless behavior of this system is provided by software agents whose algorithms are open source.

Thus your "primary user improvement" is achieved by adding in a "centralised" (and known to be *broken* CA) system - it seems to me that your idea isn't going to go down very well on this forum but best of luck with it anyway.

[SlipperySlope]

The primary user improvement I offer is ...

My technique permits instant, certain-to-be-in-the-blockchain transactions with 100x lower fees.

Transport Layer Security using X.509 certificates issued by the system's distributed Texai certificate authority credentials the system's paid full node operators. Each packet within the network is thus encrypted against tampering and tamper-evident logs at each full node permit remote attestation that allows peers to verify each other's good behavior. The trustless behavior of this system is provided by software agents whose algorithms are open source.

Thus your "primary user improvement" is achieved by adding in a "centralized" (and known to be *broken* CA) system - it seems to me that your idea isn't going to go down very well on this forum but best of luck with it anyway.

Would you care to elaborate on the X.509 certificate authority vulnerabilities you mention? For example, I use the Bouncy Castle Java libraries. The routes between super peers of the networks are not public knowledge, only the portal nodes have well known IP addresses.

Here is what Wikipedia has to say ... http://en.wikipedia.org/wiki/X.509#Problems_with_certificate_authorities.