Pages:
Author

Topic: AI Coin Development Diary - page 7. (Read 49310 times)

hero member
Activity: 686
Merit: 501
Stephen Reed
August 28, 2014, 12:47:20 PM
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.
legendary
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
August 28, 2014, 11:31:28 AM
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).
hero member
Activity: 686
Merit: 501
Stephen Reed
August 28, 2014, 11:23:00 AM
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.
legendary
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
August 28, 2014, 11:15:12 AM
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).
hero member
Activity: 686
Merit: 501
Stephen Reed
August 28, 2014, 09:23:03 AM
The primary user improvement I offer is ...

Quote
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.
legendary
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
August 27, 2014, 11:50:26 PM
The primary user improvement I offer is ...

Quote
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.
hero member
Activity: 686
Merit: 501
Stephen Reed
August 27, 2014, 01:03:02 PM
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.
hero member
Activity: 686
Merit: 501
Stephen Reed
August 27, 2014, 12:41:22 PM
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 ...

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

Quote
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.
legendary
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
August 27, 2014, 10:46:14 AM
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)
hero member
Activity: 686
Merit: 501
Stephen Reed
August 27, 2014, 10:34:59 AM
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.
hero member
Activity: 686
Merit: 501
Stephen Reed
August 27, 2014, 09:19:09 AM
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 ...

Quote
... 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.
hero member
Activity: 686
Merit: 501
Stephen Reed
August 27, 2014, 08:45:38 AM
Information Security For Cloud Services - Article Snippets

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

Quote
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

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

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

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

Quote
‘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.’

Quote
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

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


hero member
Activity: 686
Merit: 501
Stephen Reed
August 26, 2014, 02:45:43 PM
I completed the modifications to bitcoin core C++ code that allow a new command line option -nopowafter=, 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.

hero member
Activity: 686
Merit: 501
Stephen Reed
August 25, 2014, 11:02:04 PM
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 
$ 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.



hero member
Activity: 686
Merit: 501
Stephen Reed
August 25, 2014, 01:23:27 PM
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=    After block  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.
hero member
Activity: 686
Merit: 501
Stephen Reed
August 23, 2014, 05:20:19 PM
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.
hero member
Activity: 686
Merit: 501
Stephen Reed
August 21, 2014, 10:40:33 AM
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.
hero member
Activity: 532
Merit: 500
August 21, 2014, 09:44:34 AM
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.
hero member
Activity: 686
Merit: 501
Stephen Reed
August 21, 2014, 09:30:39 AM
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.
newbie
Activity: 42
Merit: 0
August 21, 2014, 05:23:12 AM
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.
Pages:
Jump to: