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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
authenticated cooperating agents rather than anonymous competing nodes.
Who authenticates them? And how? The DAC? I have a self-signed root X.509 certificate that I use to generate intermediate certificates that in turn allow distributed servers ( GitHub) to generate X.509 certificates for each node, i.e. the operator, and for each agent role. There will be numerous certificates in the system. I use TLS/SSL to authenticate both endpoints of a network connection, so each party knows who it is communicating with - knows the other node, knows the software agent in the node, and knows the role, e.g. skill set, that the particular agent is using. End users with an SPV wallet, i.e. not a full node, connect without additional encryption to DDoS-protected portals that are certain paid full nodes in the system. |
|
|
|
|
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.
|
|
|
|
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. |
|
|
|
|
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.
|
|
|
|
It seems quite complex, By constructing the network link adjacency matrix, we can compute the Eigenvalue centrality measure which measures the influence of each node. We can cluster the graph and find the influential subclusters of nodes and then sampling nodes from the subclusters can determine if global consensus has been reached. and as some wise person probably once said, A complex system can fail in an infinite number of ways. I haven't read the full Skycoin manual, but I sounds pretty much like a copy-paste coin based on PTS or BTSX ideas (/code?) ... Is my assumption right or wrong? I studied the introduction to the Skycoin paper and skimmed the rest. It may indeed prove better than Satoshi's Bitcoin with regard to securing the network at lower cost. 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, network operations centers, security intrusion detection and mitigation, customer service, etc. |
|
|
|
Young Genius vs Old MasterThe 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.
|
|
|
|
Information Security For Cloud Services - Article SnippetsCatastrophe in the cloud: What the AWS hacks mean for cloud providersOrganisations 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 iThe 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.
|
|
|
|
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.  |
|
|
|
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. $ 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.  |
|
|
|
Thanks for sharing these Peter, they are awesome. |
|
|
|
Here is the two year chart of the adjusted number of bitcoin transactions from Blockchain.info. Note that in the past few days the smoothed log graph has turned downwards. The seven day moving average removes most of the noise caused by day-of-week variation, but looking back over the history of the chart it appears there are noisy movements remaining. So I will be closely watching this latest trend of the transaction quantity to see whether it reverses sharply over the next week to move higher, or whether it continues downwards. I believe that there is currently a divergence in the relationship between bitcoin price and number of transactions. The transaction quantity is now above March 2014 levels but the price is not. Let's see how this situation resolves.  |
|
|
|
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 ... -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. |
|
|
|
|
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.
|
|
|
|
Here is the coinmarketcap.com list of crypto-currencies sorted by 24-transaction volume. There is certainly no surprise that bitcoin and litecoin have the first two places. It is interesting that BitsharesX and BitcoinDark have rallied this week when others were weaker. Supply figures with an asterisk indicate that the coin cannot be mined, i.e. not proof-of-work. Interesting too, how many of these are ranking higher this month.  |
|
|
|
Here is the one-week resolution chart of Litecoin / Yuan as reported by the very liquid OKCoin exchange. The rightmost candle now has a technical shape that suggests indecision, and with relatively high volume indicates that the recent price capitulation has either ended or paused. As the resistance downtrend line from the November 2013 peak has not yet been convincingly pierced to the upside, conventional TA wisdom says the down trend from the peak has not yet reversed.  |
|
|
|
Industrial miners will seek the least expensive power, cooling and labor. ASIC fabrication plants have the ability to continue scaling in spite of impending lithography limits by advancing to 3-dimensional monolithic circuits. I expect that even small advances in hashing per watt will induce industrial miners to replaced their older rigs in less than a year, because of the relentless pace of difficulty increases in PoW coins. As Tim Swanson well describes in his recent book, the marginal profit gained by miners when PoW coin prices increase is swiftly accommodated by an equal rise in the mining difficulty as competing miners add to their existing capacity. I recall solo mining a couple of bitcoin blocks back in June 2010 after a popular tech blog brought Bitcoin coin to my attention. Within a few weeks, I shut down my quad core CPU miner as, on this forum, system administrators were bragging that they had installed bitcoind on hundreds, if not thousands, of computers at their workplaces. Difficulty soared back then, not because of any new mining tech, but rather because the capacity could be added and it was. |
|
|
|
So I keep watching the XC chat thread. Those guys over there remind me of dogers except almost worse. Their structure and optimism and complete ... ADHD of features just kinda fascinates me. They just announced XAdvertise (decentralized/blockchainified advertisement) or something.
. . .
It's just ... really weird weird coin/chat/advertising platform/whatever it is. Anybody have any insight?
I do not have an opinion on whether their project as a whole has any merit, but I do like certain ideas that are shared with my own project. Namely, paying full node operators to secure the network. I believe that Satoshi PoW coins mis-allocate their block rewards which could be better spent elsewhere, provided the blockchain is secured in a free, distributed, transparent, and trustless manner as Satoshi required for Bitcoin. Perhaps Satoshi believed back in 2009 that Bitcoin users would generate bitcoins on their own personal computers so that each user ran a full node, securing the network, and receiving appropriate remuneration by way of bitcoins mined. But, by 2011 in his last posts on this forum, Satoshi came to believe that industrial mining was the future, with the vast majority of non-generating users connected to a few centralized miners, e.g. the big pools that we have today, with the current 7000 Bitcoin volunteer full nodes unpaid, and mining few if any bitcoins. |
|
|
|
|
Show Posts
