Pages:
Author

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

newbie
Activity: 42
Merit: 0
September 23, 2014, 06:00:19 PM
hero member
Activity: 686
Merit: 501
Stephen Reed
September 23, 2014, 05:21:31 PM
[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.
newbie
Activity: 42
Merit: 0
September 23, 2014, 04:34:11 PM
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.

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

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

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

Quote
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.
sr. member
Activity: 365
Merit: 251
September 23, 2014, 03:37:09 PM
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.

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

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

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

Quote
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.
newbie
Activity: 42
Merit: 0
September 23, 2014, 02:13:14 PM
To my knowledge, no proof-of-stake coin has been compromised in a 51% attack

Peercoin has been successfully attacked. The reason these PoS coins are still up and running today is because they either use checkpoints (which makes them 100% centralized and pointless, which is the case of Peercoin), or they are continually making changes which makes attacking them annoying or hard, but is just another form of centralization (they depend on the continuous updates that everyone must accept blindly, as opposed to a stable protocol that rarely changes. Someone compared this to the whack-a-mole game).
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?

And I don't see what's so "implausible" about buying half of the coins when the market cap is so small. 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. With PoW at least the attacker will have trouble recovering the costs of his mining gear which will become obsolete. With PoS that cost doesn't exist. The attacker can sell all his coins and then start the attack.

See what Gregory Maxwell (nullc) thinks about PoS:

https://www.reddit.com/r/Bitcoin/comments/1uoq6e/what_do_you_guys_think_of_proof_of_stake_mining/cek8epc?context=2

https://news.ycombinator.com/item?id=6798997
sr. member
Activity: 365
Merit: 251
September 23, 2014, 02:07:11 PM
To my knowledge, no proof-of-stake coin has been compromised in a 51% attack

Peercoin has been successfully attacked. The reason these PoS coins are still up and running today is because they either use checkpoints (which makes them 100% centralized and pointless, which is the case of Peercoin), or they are continually making changes which makes attacking them annoying or hard, but is just another form of centralization (they depend on the continuous updates that everyone must accept blindly, as opposed to a stable protocol that rarely changes. Someone compared this to the whack-a-mole game).
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.
newbie
Activity: 8
Merit: 0
September 22, 2014, 09:45:10 AM

And here is a link to a recent Ahto Buldas' paper which at first glance may be what you are describing ...

Keyless Signatures’ Infrastructure: How to Build Global Distributed Hash-Trees

Could you elaborate on the non-shared portion of the KSI hash tree? This appears to be the key to irreversibility. If an adversary had more than 50% of the nodes in his control, then he could out vote the legitimate nodes - right?
I think in this scheme, the issue is that the 51% adversary could rig the elections of superpeers.  It's no longer about protecting the historical blockchain from rewriting.  Buldas essentially encodes time into the blockchain in a way that he says is provably resistant to backdating *and* independently verifiable by third parties that do not have access to the full ledger.  For the application he had in mind (signing every syslog entry of every Linux machine in the world) it would have been impractical to distribute every single transaction around.  Here is the summary in the paper you linked to:

Quote from: Ahto Buldas
Underlying data structures guarantee that it is not possible to issue fake, backdated or otherwise mis- leading signature tokens—even where rogue client and rogue service provider collaborate. Committing into globally unique and public Hash Calendar makes tampering with the system, especially with the clock value, highly visible to all users. The system security does not depend on the long-term secrecy of the private keys as it is not possible to prove that the keys were not actually leaked. Underlying cryptographic primitives may be easily changed, e.g. in case of apparent weakening of the algorithms. There may be occassions when the infrastructure must be stopped—if the system integrity or clock accuracy is in doubt. The signature token itself is independently verifiable by third parties using only public information and algorithms; verification must be possible even after the service provider ceases the operations.
In order to provide highly available service single points of failure are eliminated. The requirements on system reliability are different: a globally unique core cluster must be operated by the best trust authority practices, but the service delivery network may use commodity virtual servers without much requirements on operating environment, like a reliable “wall clock” or persistent storage. Privacy and confidentiality risks are minimal, because the infrastructure handles only aggregate hashes.

I'm rejecting Buldas' statement in bold, which  I believe to be motivated by his commercial ambitions, and substituting your nomadic mint.

Quote from: SlipperySlope
I believe that I can publicly publish the blockchain hash as well as the KSI top hash when each new block is created as a trust anchor. For example it would be easy to automatically publish those in a dedicated forum such as Yahoo or Google groups in append-only style where the account is administered by TexaiCoin core developers. Likewise the system could append hash value entries to an otherwise readonly Google Docs spreadsheet. Then an adversary would have to hack each of these public records to maintain integrity with his forged blockchain.

It may not have been clear that I was rejecting a central newspaper authority like Buldas designed and Satoshi rejected, and glomming onto your nomadic mint to publish the public top-level hash automatically.  Term limits!

*********

Re: Bitcoin Core, I think where this could lead is partitioning the cryptocoin hash space amongst superpeer-led mining pools, and federating/mixing their respective blockchains up the hierarchy.  That would encourage people to start mining pools instead of scamcoins and scamexchanges.
hero member
Activity: 686
Merit: 501
Stephen Reed
September 21, 2014, 10:47:32 PM
Quote from: SlipperySlope
Does KSI as you understand it somehow make replaying of the blockchain building process impossible - as I described that process above?

Here's what Satoshi says:

Quote from: Satoshi
To modify a past block, an attacker would have to redo the proof-of-work of the block and all blocks after it and then catch up with and surpass the work of the honest nodes. We will show later that the probability of a slower attacker catching up diminishes exponentially as subsequent blocks are added.

The cryptographic proof-of-work blockchain approach used in Bitcoin inherently suffers from replayability and being determinate, which Satoshi solved by starting a computing arms race chasing an exponential function.  POS has the same weaknesses from what I can tell.  In KSI, the blockchain is one-way in time, and cannot be replayed by an adversary, because the complete ledger is not visible to all nodes.  That's a feature, originally designed to enforce a centralized signature upon a single node's transaction, for integrity purposes.  There is a hierarchical summarization by special nodes (like CPOS superpeers and nomadic mints) that broadcast digest hashes, which each end node has to sign onto its own transactions.  Superpeers can be nomadic and elected (that would be an extension of KSI), and are responsible for supervising the nodes within their hash space and time.  The system is still dependent upon 51% honest nodes.

By adding a chaotic parameter into the blockchain hash, I think it would be harder to "surpass the work of honest nodes" in Satoshi's parlance, because it would increase the dimensionality of the precalculation necessary, and hopefully make it harder to design an ASIC around.

Quote
I could use the daily radio flux at 10.7 cm as reported by the U.S. Dept. of Commerce, NOAA, Space Weather Prediction Center, or can anyone suggest something published and archived by a more international source?

My own research indicates that the DRAO at Penticton, BC Canada is the gold standard for 10.7 cm flux, and has been tracking it since the 1950s.  You could define the chaos broadcast as an average of several world observatories.  I think it would be neato if the nomadic mint published the summary Merkle hash, the solar flux value that can be cross-checked, and the resulting hash value.  Not even the NSA can control the Sun.  I don't know how much additional security solar chaos really adds, but it just feels good, doesn't it?

Thanks Scumby for your articulate understanding of my work.

I examined the DRAO website and have written a message to their webmaster asking about why the displayed solar flux index is months old instead of current. Another potential micro-revenue service for TexaiCoin would be to wrap an API around the daily solar flux measurement and its recent archived values.

I am constrained to keep the blockchain structure unchanged so as to maximise the opportunity that my changes will someday be incorporated into Bitcoin Core. But that does not keep me from creating a parallel data structure as you describe for KSI, which I now somewhat comprehend because of your explanation. The blockchain must remain a public ledger in its entirety, but I can envision a KSI process as you describe to irreversibly record blockchain hashes at each new block.

And here is a link to a recent Ahto Buldas' paper which at first glance may be what you are describing ...

Keyless Signatures’ Infrastructure: How to Build Global Distributed Hash-Trees

Could you elaborate on the non-shared portion of the KSI hash tree? This appears to be the key to irreversibility. If an adversary had more than 50% of the nodes in his control, then he could out vote the legitimate nodes - right?

I believe that I can publicly publish the blockchain hash as well as the KSI top hash when each new block is created as a trust anchor. For example it would be easy to automatically publish those in a dedicated forum such as Yahoo or Google groups in append-only style where the account is administered by TexaiCoin core developers. Likewise the system could append hash value entries to an otherwise readonly Google Docs spreadsheet. Then an adversary would have to hack each of these public records to maintain integrity with his forged blockchain.
newbie
Activity: 8
Merit: 0
September 21, 2014, 10:06:31 PM
Let's go back to Satoshi's original paper:

Quote from: Satoshi
The problem of course is the payee can't verify that one of the owners did not double-spend the coin. A common solution is to introduce a trusted central authority, or mint, that checks every transaction for double spending. After each transaction, the coin must be returned to the mint to issue a new coin, and only coins issued directly from the mint are trusted not to be double-spent. The problem with this solution is that the fate of the entire money system depends on the company running the mint, with every transaction having to go through them, just like a bank. We need a way for the payee to know that the previous owners did not sign any earlier transactions. For our purposes, the earliest transaction is the one that counts, so we don't care about later attempts to double-spend. The only way to confirm the absence of a transaction is to be aware of all transactions. In the mint based model, the mint was aware of all transactions and decided which arrived first. To accomplish this without a trusted party, transactions must be publicly announced [1], and we need a system for participants to agree on a single history of the order in which they were received. The payee needs proof that at the time of each transaction, the majority of nodes agreed it was the first received.

You have already shown Satoshi's counterfactual assumptions here were wrong.  You have solved the problem of a central company controlling the mint with your nomadic mint.  The payee gets proof by cooperating in electing a dynamic superpeer hierarchy and trusting it to prevent double-spend, without seeing every transaction.  Instead of mining independently, the nodes can cross-check the calculations of their superpeer and shoot him if a majority discover he's a turncoat.  The superpeer can in turn try to identify bad nodes to be shunned by the network, and broadcasts intermediate signature hashes for consumption by end nodes.  Superpeers could be spontaneously elected for a term of office.  You are inspired by what mining pools are already doing in practice, but now are incorporating it into a self-organizing cooperative system.  Cool stuff!

Quote from: satoshi
The proof-of-work also solves the problem of determining representation in majority decision making. If the majority were based on one-IP-address-one-vote, it could be subverted by anyone able to allocate many IPs. Proof-of-work is essentially one-CPU-one-vote.

We now know that one-CPU-one-vote didn't work out too well once ASICs got into the action.  CPOS solves the majority decision making representation problem by spontaneous election of trusted nodes/mints, and then all the other nodes watch them for misbehavior.  The superpeers, in turn, need to watch out for Sybil attacks and rally honest nodes against them.  This is a more biologically-supported approach than Santoshi's competitive gold mining, if you think about it (think bees and neurons).

Quote from: SlipperySlope
What you say is very interesting. Satoshi designed the current Bitcoin proof-of-work system to prevent an adversary from presenting a forged blockchain as legitimate. My approach makes that difficult by having only one canonical version of the blockchain, in which the current hash is widely known, in which participants are identified by certificates, and in which misbehavior is detected by verifying peers.
...
This is a desirable property for the blockchain or agent logs. I want to understand the circumstances allowing an adversary to forge such a blockchain.

I seem to comprehend how a KSI + chaos blockchain could be tamper-evident, but the forgery attack is one in which the adversary replays transactions from some point in the history, with some change in their own favor, recalculating the merkle trees and block hashes at each step. The forged block chain is thus internally consistent with no evidence of tampering unless compared with the final block hash of the legitimate blockchain.

Does KSI as you understand it somehow make replaying of the blockchain building process impossible - as I described that process above?

Here's what Satoshi says:

Quote from: Satoshi
To modify a past block, an attacker would have to redo the proof-of-work of the block and all blocks after it and then catch up with and surpass the work of the honest nodes. We will show later that the probability of a slower attacker catching up diminishes exponentially as subsequent blocks are added.

The cryptographic proof-of-work blockchain approach used in Bitcoin inherently suffers from replayability and being determinate, which Satoshi solved by starting a computing arms race chasing an exponential function.  POS has the same weaknesses from what I can tell.  In KSI, the blockchain is one-way in time, and cannot be replayed by an adversary, because the complete ledger is not visible to all nodes.  That's a feature, originally designed to enforce a centralized signature upon a single node's transaction, for integrity purposes.  There is a hierarchical summarization by special nodes (like CPOS superpeers and nomadic mints) that broadcast digest hashes, which each end node has to sign onto its own transactions.  Superpeers can be nomadic and elected (that would be an extension of KSI), and are responsible for supervising the nodes within their hash space and time.  The system is still dependent upon 51% honest nodes.

By adding a chaotic parameter into the blockchain hash, I think it would be harder to "surpass the work of honest nodes" in Satoshi's parlance, because it would increase the dimensionality of the precalculation necessary, and hopefully make it harder to design an ASIC around.

Quote
I could use the daily radio flux at 10.7 cm as reported by the U.S. Dept. of Commerce, NOAA, Space Weather Prediction Center, or can anyone suggest something published and archived by a more international source?

My own research indicates that the DRAO at Penticton, BC Canada is the gold standard for 10.7 cm flux, and has been tracking it since the 1950s.  You could define the chaos broadcast as an average of several world observatories.  I think it would be neato if the nomadic mint published the summary Merkle hash, the solar flux value that can be cross-checked, and the resulting hash value.  Not even the NSA can control the Sun.  I don't know how much additional security solar chaos really adds, but it just feels good, doesn't it?
hero member
Activity: 686
Merit: 501
Stephen Reed
September 21, 2014, 04:21:26 PM
What has not been explored AFAIK, is what if the nomadic mint's KSI calculation had a publicly visible component that could be cross-checked by any client?  I.e. if the hash function had to mix in a widely observable source of chaos, such as the S&P 500 index closing price or solar flux index.  People might relax about cooperation if the public could "trust, but verify" the calculations of the population of nomadic mints subject to attack by a powerful adversary.  KSI + chaos could be immutable in the past (cannot reconstruct a historical hash with KSI) and the future (chaotic processes are immune to time series forecasting).  


Scumby,

What you say is very interesting. Satoshi designed the current Bitcoin proof-of-work system to prevent an adversary from presenting a forged blockchain as legitimate. My approach makes that difficult by having only one canonical version of the blockchain, in which the current hash is widely known, in which participants are identified by certificates, and in which misbehavior is detected by verifying peers.

Quote
KSI + chaos could be immutable in the past (cannot reconstruct a historical hash with KSI) and the future (chaotic processes are immune to time series forecasting).  

This is a desirable property for the blockchain or agent logs. I want to understand the circumstances allowing an adversary to forge such a blockchain. I seem to comprehend how a KSI + chaos blockchain could be tamper-evident, but the forgery attack is one in which the adversary replays transactions from some point in the history, with some change in their own favor, recalculating the merkle trees and block hashes at each step. The forged block chain is thus internally consistent with no evidence of tampering unless compared with the final block hash of the legitimate blockchain.

Does KSI as you understand it somehow make replaying of the blockchain building process impossible - as I described that process above?

Even if not, your mentioning of a public chaos value is a good idea for convincing observers that the blockchain was not constructed prior to the timestamp associated with the public chaos value. I could use the daily radio flux at 10.7 cm as reported by the U.S. Dept. of Commerce, NOAA, Space Weather Prediction Center, or can anyone suggest something published and archived by a more international source?
hero member
Activity: 686
Merit: 501
Stephen Reed
September 21, 2014, 03:56:32 PM
I have only a basic understanding of Bitcoin's internals, so if there is nonsense here due to my own ignorance I apologize.  I think you are doing a tour-de-force job of assimilating a wide cross-disciplinary breadth of ideas here, but I am concerned that the TexAI/Cyc ontology stuff is so alien to most developers that it could torpedo your adoption if you make it too front-and-center.  The AI integration into the CPOS "stew" feels a bit forced; it's evidently a treasured ingredient in your own intellectual "refrigerator" and provides you continuity with your AI work, but you're going to have a hard enough time getting mindshare without having to also persuade engineers that symbolic programming with ontologies is worthwhile for cryptocurrencies.  My .02.

Indeed.

For reason you mention, I have stripped out the work-in-progress, natural language dialog and face-recognition aspects of Texai from the code that I am committing to GitHub for TexaiCoin. When I talk with coin developers at the Hasher's United conference in Las Vegas next month, I will be talking about a multi-agent software system which can cooperate to mine coins with no effort and still be as secure as Bitcoin.

My approach to artificial general intelligence is to follow Alan Turing's advice back in 1950, which is to create a system capable of being taught skills and then to teach it. My implementation uses the robotic-inspired architecture described by James Albus, in which his hierarchical control network of software agents has been elaborated by me to model a human organization. For TexaiCoin, I have 27 simple agents which cooperate and will check each other to operate an altcoin network with no trusted third parties.

I could have implemented these agents for TexaiCoin using any one of several agent frameworks, but it was the security aspects that motivated me to repurpose my existing AI code. Concerned about the need to ensure Friendly AI in a distributed network operated by anyone downloading the code, I designed the AI code years ago to be secure against intruders and hackers. I incorporated X.509 certificates for that purpose. Currently, I plan to use tamper-evident logs and remote attestation to strengthen Texai against attackers.

I will be able to market TexaiCoin as having genuine artificial intelligence, thus helping this altcoin and its innovations to be distinguished from other thousand-plus altcoins. I do not plan to say much initially about the OpenCyc knowledge base that is part of each deployed container.

TexaiCoin ideally will become a platform upon which third-party developers can add vetted skilled agents, and receive payment in TexaiCoin for the benefits gained by the collective infrastructure, or from the proceeds of services for sale, e.g. an API. I will start with the document timestamp service as a demonstration.

I will add a high level goal to the system to pursue self-improvement, e.g. to increase revenue and coin value via tasks performed by paid developers. Humans will be able to perform tasks specified in the same manner as for software agents, but with a secure web form or secure email as the communication channel. I think that the system paying one person to perform the task, and paying two non-affiliated others to check the work should be safe.



newbie
Activity: 8
Merit: 0
September 21, 2014, 11:21:59 AM
I have only a basic understanding of Bitcoin's internals, so if there is nonsense here due to my own ignorance I apologize.  I think you are doing a tour-de-force job of assimilating a wide cross-disciplinary breadth of ideas here, but I am concerned that the TexAI/Cyc ontology stuff is so alien to most developers that it could torpedo your adoption if you make it too front-and-center.  The AI integration into the CPOS "stew" feels a bit forced; it's evidently a treasured ingredient in your own intellectual "refrigerator" and provides you continuity with your AI work, but you're going to have a hard enough time getting mindshare without having to also persuade engineers that symbolic programming with ontologies is worthwhile for cryptocurrencies.  My .02.

******

I think of KSI as envisioned above as a skip list of Merkle trees, with the skip list built around hashing that is one-way not only in calculation, but also in time.  It does this in a way that is far more bandwidth-efficient than replicating massive blockchains around like Bitcoin.  Guardtime markets this to governments as a way of signing documents and Linux OS log entries with keys that can't be tampered with, in order to defeat future Edward Snowdens from modifying system logs.  I think this same concept could be used for ledger integrity for micropayments as you note, or just about any kind of ledger for that matter.

The implementation envisions a newspaper or central service that would broadcast a top level hash, and providing this service (or enabling a central government agency to provide it, as is done in Estonia) is how Guardtime thinks it will make money.  A nomadic mint performing this function would seem to be preferable to a fixed commercial or government source. 

What has not been explored AFAIK, is what if the nomadic mint's KSI calculation had a publicly visible component that could be cross-checked by any client?  I.e. if the hash function had to mix in a widely observable source of chaos, such as the S&P 500 index closing price or solar flux index.  People might relax about cooperation if the public could "trust, but verify" the calculations of the population of nomadic mints subject to attack by a powerful adversary.  KSI + chaos could be immutable in the past (cannot reconstruct a historical hash with KSI) and the future (chaotic processes are immune to time series forecasting). 
hero member
Activity: 686
Merit: 501
Stephen Reed
September 20, 2014, 11:58:28 PM
[Lurker decloak]
This thread has reached the point where it could use an injection of keyless signature infrastructure, as invented by Ahto Buldas of Guardtime (I am not associated with them):

http://en.wikipedia.org/wiki/Linked_timestamping

Some forms of global coordination, such as a stochastic cooperative signal that is widely observable, are compatible with decentralized paranoia.  Just ask neurons and ants.

Perhaps Mr. Reed might reconsider his resignation to PKI and central servers with this information.
[/Decloak]

Thanks for the help, Scumby!

I wanted to offer a document timestamping API which would not necessarily be evidence in a court of law but would provide a distributed, robust service implemented with micropayments. This is an excellent implementation suggestion for this skill, which is required by the nomadic mint which timestamps incoming transactions. I would then be easy to expose this skill as a money-making microservice API. Apparently the Bouncy Castle cryptography library I use has a time stamp protocol server that I will evaluate.

Keyless Signature Infrastructure is interesting. I understand Merkle trees and this is similar. I will stay with self-signed X.509 certificates for identification, digital signatures for messages, and message channel encryption.

newbie
Activity: 8
Merit: 0
September 20, 2014, 09:16:41 PM
[Lurker decloak]
This thread has reached the point where it could use an injection of keyless signature infrastructure, as invented by Ahto Buldas of Guardtime (I am not associated with them):

http://en.wikipedia.org/wiki/Linked_timestamping

Some forms of global coordination, such as a stochastic cooperative signal that is widely observable, are compatible with decentralized paranoia.  Just ask neurons and ants.

Perhaps Mr. Reed might reconsider his resignation to PKI and central servers with this information.
[/Decloak]
newbie
Activity: 42
Merit: 0
September 20, 2014, 08:44:40 PM
To my knowledge, no proof-of-stake coin has been compromised in a 51% attack

Peercoin has been successfully attacked. The reason these PoS coins are still up and running today is because they either use checkpoints (which makes them 100% centralized and pointless, which is the case of Peercoin), or they are continually making changes which makes attacking them annoying or hard, but is just another form of centralization (they depend on the continuous updates that everyone must accept blindly, as opposed to a stable protocol that rarely changes. Someone compared this to the whack-a-mole game).
hero member
Activity: 686
Merit: 501
Stephen Reed
September 14, 2014, 11:00:47 AM
Don't you need special hardware to do remote attestation? The common known remote attestation schemes use a central service to certify the hardware.

I will not be performing remote attestation at the BIOS and kernel level until such time as the project is successful enough to employ a specialist.

TrouSerS FAQ

Rather, my approach is to perform remote attestation at the application level. Peers inspect each other's tamper-evident logs verifying expected good behavior and detecting faults.

How can you detect tampering with logs on remote peers? I mean a peer not controlled by yourself could send you anything as logfile.

I currently also fail to see how remote attestation on application level could work. As far as I know, remote attestation is only reliable, if there is more or less sealed hardware envolved, that acts as a root for a chain of trust up to the application. So the user performing the remote attestation has to trust in the inability of the attestee to change the sealed hardware and employ his own root. Do you have any ressources to point me to, where remote attestation on application level is explained?


Here is the link to the academic reference used in my white paper: Remote Attestation on Program Execution . Essentially, the idea is to embed digital signatures of the log's hash to that point by attesting remote peers into a given peer's own log. The researchers call this technique entanglement, but I understood it more readily as peer-notarized logs that prove whether or not a particular log has been tampered with.

What about sybil attacks? In satoshi's Bitcoin a single node either has the economic power to lift a 51% attack or it doesn't. It doesn't matter over how many nodes this is distributed. A counter measure to sybil attacks would be to have signed each node by a CA. The other nodes verify this signature and won't allow more than one node with the same identifier. But then again the system is centralized.

Note that Bitcoin Core allows TLS and X.509 certificates already for RPC calls and for the new Payment Protocol. Texai does not need certificates for nodes to ensure third-party verification of the association of a public key with either a web domain name nor an operator's real name. The certificate is used to contain and publish the public key and to permit TLS authorization and encryption of the network traffic. Each operator, indeed each communicating role in the network has a unique UUID that is its identity. The certificate guarantees that whoever uses it has the private key in their possession. I believe that each user could hypothetically create a self-signed certificate and the Texai system would still work OK.

But if each user can create his own certificate (more ore less for free), doesn't this open the door for Sybil attacks?

As a result of my rewarding conversation with CIYAM above, I recently decided to have each node operator be their own certificate authority. My scheme does not rely on a chain of trust from a central certificate authority, indeed I want to preserve that part of the Satoshi Social Contract which says there are no trusted third parties in Bitcoin. I need X.509 certificates to identify a peer solely by their published public key, and to encrypt traffic between nodes via TLS 1.2.  I do not need a chain of trust to tie a real name and address to the system nor to the certificate holder.

There is a security concept called Trust On First Use (TOFU), which allows peers to record received self-signed certificates and trust them from that point forward. That is a relatively weak method which I plan to eventually augment by providing an easy to use method of emailing peer self-signed certificates from the peer to an archiving Texai software agent before first use. To identify a peer in the Texai network, I would  use the certificate, which cannot be forged due to the public/private key math, together with the IP address of the peer and to use encrypted email for out-of-band communication with the peer. For example a peer operator should receive a periodic digitally signed email from the system detailing their fair share of the  mining reward paid to their supplied address. This manual oversight by the operator precludes man-in-the-middle attacks that would divert the reward to another address.

Sybil attacks may occur in Satoshi's Bitcoin . . .

Weaknesses

Quote
Sybil attack
An attacker can attempt to fill the network with clients controlled by him, you would then be very likely to connect only to attacker nodes. Although Bitcoin never uses a count of nodes for anything completely isolating a node from the honest network can be helpful in the execution of other attacks.

This state can be exploited in (at least) the following ways:

The attacker can refuse to relay blocks and transactions from everyone, disconnecting you from the network.
The attacker can relay only blocks that he creates, putting you on a separate network. You're then open to double-spending attacks.
If you rely on transactions with 0 confirmations, the attacker can just filter out certain transactions to execute a double-spending attack.
Low-latency encryption/anonymization of Bitcoin's transmissions (With Tor, JAP, etc.) can be defeated relatively easy with a timing attack if you're connected to several of the attacker's nodes and the attacker is watching your transmissions at your ISP.
Bitcoin makes these attacks more difficult by only making an outbound connection to one IP address per /16 (x.y.0.0). Incoming connections are unlimited and unregulated, but this is generally only a problem in the anonymity case, where you're probably already unable to accept incoming connections.

Looking for suspiciously low network hash-rates may help prevent the second one.

Full nodes in Satoshi's bitcoin identify themselves only by IP address. In the Texai network, that weak identity is strongly augmented by X.509 certificates. Software agents keep track of the uptime and verified good behavior of the network nodes.

Satoshi's proof-of-work method makes it hard for an attacker to obtain 51% of the hashing power to attack the network. I plan for the occasional voting among Texai peers to be weighted according to respective peer stakes and each such vote shall be paid for by the system in proportion to the stake. Thus an attacker would have to obtain 51% of the aggregate stake, which has been proven to be more expensive for the attacker than obtaining 51% of the hashing power in a proof-of-work coin. To my knowledge, no proof-of-stake coin has been compromised in a 51% attack, in comparison ...

List of Historical 51% Attacks on Altcoins


legendary
Activity: 1344
Merit: 1001
September 14, 2014, 08:12:51 AM
Nice selection of links in the OP! Bookmarked!
sr. member
Activity: 350
Merit: 251
Dolphie Selfie
September 14, 2014, 07:17:52 AM
Don't you need special hardware to do remote attestation? The common known remote attestation schemes use a central service to certify the hardware.

I will not be performing remote attestation at the BIOS and kernel level until such time as the project is successful enough to employ a specialist.

TrouSerS FAQ

Rather, my approach is to perform remote attestation at the application level. Peers inspect each other's tamper-evident logs verifying expected good behavior and detecting faults.

How can you detect tampering with logs on remote peers? I mean a peer not controlled by yourself could send you anything as logfile.

I currently also fail to see how remote attestation on application level could work. As far as I know, remote attestation is only reliable, if there is more or less sealed hardware envolved, that acts as a root for a chain of trust up to the application. So the user performing the remote attestation has to trust in the inability of the attestee to change the sealed hardware and employ his own root. Do you have any ressources to point me to, where remote attestation on application level is explained?


What about sybil attacks? In satoshi's Bitcoin a single node either has the economic power to lift a 51% attack or it doesn't. It doesn't matter over how many nodes this is distributed. A counter measure to sybil attacks would be to have signed each node by a CA. The other nodes verify this signature and won't allow more than one node with the same identifier. But then again the system is centralized.

Note that Bitcoin Core allows TLS and X.509 certificates already for RPC calls and for the new Payment Protocol. Texai does not need certificates for nodes to ensure third-party verification of the association of a public key with either a web domain name nor an operator's real name. The certificate is used to contain and publish the public key and to permit TLS authorization and encryption of the network traffic. Each operator, indeed each communicating role in the network has a unique UUID that is its identity. The certificate guarantees that whoever uses it has the private key in their possession. I believe that each user could hypothetically create a self-signed certificate and the Texai system would still work OK.

But if each user can create his own certificate (more ore less for free), doesn't this open the door for Sybil attacks?
legendary
Activity: 1666
Merit: 1010
he who has the gold makes the rules
September 13, 2014, 11:12:47 PM
interesting  Grin
hero member
Activity: 686
Merit: 501
Stephen Reed
September 12, 2014, 04:22:27 PM
I am working on the minimal set of Texai software agents that will operate a bitcoind instance on my Ubuntu laptop for hallway demonstration at the Hashers United Conference to be held in Las Vegas in October.

Meanwhile, I learned about the Raft distributed consensus algorithm that provides an off-the-shelf solution to how to robustly select the mint agent from among the set of candidate peers. There is an implementation in Java at GitHub that I linked in the OP. And here is an animated illustration of the algorithm as prepared by Ben Johnson ...

http://thesecretlivesofdata.com/raft/

This algorithm is robust against failing nodes and partitioned networks, but not against byzantime, e.g. malicious peers. I will handle the latter using Nick Szabo's method of remote attestation of peer behavior by inspecting their respective tamper-evident log files.
Pages:
Jump to: