Hi SlipperySlope,
I see you've updated your whitepaper today (May 20), and I think also every day before that. I have a few comments, though I've got a lot of reading to do so I can't promise I'll follow up on them in a timely fashion.
1. You spend a bunch of the first part of your paper claiming that Bitcoin's proof-of-work system is wasteful and that hashing is "single-purpose". (This is a common meme on here and Reddit, I understand — in general, I'd advise you when learning about Bitcoin to not pick up ideas from this website unless they originate with somebody who is a known expert on Bitcoin.) I recently had a discussion with fenn on ##hplusroadmap about the "single-purpose" claim as well as the "zero-sum" game. Notice that there is no known way to achieve distributed consensus without proof-of-work, so these claims that the entropy production is unnecessary are extraordinary and require significant evidence.
2014-05-11 12:20:10 fenn it's a zero sum game
2014-05-11 12:20:32 fenn except for the value of the network of course
2014-05-11 12:20:55 fenn network value is independent of number of hashes being performed
2014-05-11 12:21:36 kanzure do you know what the hashes are for?
2014-05-11 12:27:58 fenn "Any block that is created by a malicious user that does not follow this rule (or any other rules) will be rejected by everyone else."
2014-05-11 12:29:18 fenn "Each block memorializes what took place immediately before it was created."
2014-05-11 12:29:49 fenn New blocks can't be submitted to the network without the correct answer - the process of "Mining" is essentially the process of competing to be the next to find the answer that "solves" the current block.
2014-05-11 12:30:24 fenn each hash is a "guess" at the answer
2014-05-11 12:30:59 andytoshi fenn: you are totally missing the forest for the trees
2014-05-11 12:31:11 andytoshi like if you said aerobic respiration was a process for binding carbon to oxygen
2014-05-11 12:31:33 fenn he said "do you know what the hashes are for" and i answered, what do you want
2014-05-11 12:31:40 andytoshi and when asked what it's for, you started talking about valence electrons and how respiration gets you the right reconfiguration
2014-05-11 12:32:13 andytoshi fenn: the hashes give a way to translate computational resources into something cryptographically verifiable
2014-05-11 12:32:21 andytoshi that's what "proof of work" refers to
2014-05-11 12:32:35 fenn it has nothing to do with computational resources
2014-05-11 12:32:48 andytoshi it lets you /define/ the system mathematically so that it is hard to rewrite history
2014-05-11 12:33:08 andytoshi fenn: the correct answer to kanzure's question was "no"
2014-05-11 12:33:24 fenn it's just the ability to do this particular cryptographic algorithm, which happens to be implemented on something resembling a computer
2014-05-11 12:33:52 --> drewbug1 ([email protected]) has joined ##hplusroadmap
2014-05-11 12:35:21 fenn you can take all the bitcoin asics in the world and the won't be able to add 2+2
2014-05-11 12:35:52 chris_99 heh
2014-05-11 12:36:14 <-- drewbug (~Adium@fsf/member/drewbug) has quit (Ping timeout: 240 seconds)
2014-05-11 12:36:30 andytoshi yeah, and you can take all the aerobic biomass in the world and they won't be able to either
2014-05-11 12:36:54 andytoshi and yet here we are huffing and puffing as we type frantically
2014-05-11 12:37:01 fenn the difference is you say one is "computational resources" and the other isn't?
2014-05-11 12:38:09 andytoshi ?? the difference is that respiration is used to provide useful energy to the organism while bitcoin hashing is used to translate a fact of physics to a fact of mathematics
2014-05-11 12:38:22 andytoshi they are more alike than they are different at the level we are talking
2014-05-11 12:38:42 andytoshi in both cases they are a mechanism for taking resources from the environment and translating them into a form that the system can use
2014-05-11 12:38:44 fenn but cells are more general purpose than bitcoin asics
2014-05-11 12:39:06 fenn even "specialized" cells can do a large number of things
2014-05-11 12:39:16 andytoshi i'd like a citation that DNA is more expressive than bitcoin script..
You later suggest that checkpoints are an improvement on consensus. This is not true.
Checkpoints have nothing to do with consensus. Nada. This has been beaten to death by myself and several others, and is another example of a bitcointroll meme infecting your thought. Above you say that proof-of-stake is the reason that Peercoin is so popular. But Peercoin has been centralized from the start, and has no plan for ever being decentralized. Of course a centralized consensus system is able to be more efficient than a trustless one.
You compare Bitcoin confirmation times to CC transaction approval times. This is nonsense. There is no amount of time after which CC transactions are really irreversible in the sense of Bitcoin, but even the amount of time to eliminate the trivial "call the CC company and dispute the charge" method of reversal is several months. So you should be comparing hours (for Bitcoin) to months (for CC companies). If all you care about is transaction "approval" this is limited only by the speed of the network, just like with CC's, except that the Bitcoin network is more distributed and anyone can verify transactions, so the uptime is better. Again, this has been beaten to death here.
You say that Primecoin is an example of a "useful PoW". But there is no known use for Cunningham chains, and Primecoin has an awful awful "proof" of work which fails pretty-much every point laid out in my ASIC FAQ.
You repeatedly describe the adversarial nature of the Bitcoin network as something Satoshi made up. But adversariality is a fact about the world and not something you can model away when designing a decentralized cryptosystem.
2. I haven't look into your tamper-resistant logs but I worry about how efficient these can be regarding both CPU time and bandwidth, since you have every transaction producing a bunch of these, in some cases from cell-phones or other transaction-producing devices. It looks like at every time you have a single mint who gets to decide what order transactions occur in and which ones are valid or invalid. It's not clear what happens if the node approves conflicting transactions (I guess he gets banned when the next block is produced, but then how do you decide which one was the "correct" one? This does not seem to achieve the "instantly confirmed transaction" scenario I think you are going for.)
Also, don't use Bitcoin addresses for authentication. They can be used to authenticate against "the owner of coins sent to this address" but pretty-much nothing else. Addresses are payment identifiers and confusing this purpose with that of signing keys is only going to cause user error.
3. As we discussed in Austin, this nomadic business makes historic consensus tricky. Suppose the superpeers wind up in being in Vancouver for the summer. After some time they move on to London, so I have an opportunity to buy all the old superpeers' hardware from them for cheap prices. I use them to rewrite some history sufficient that they now pass off to a system in Austin which I control. From there on I'm able to do the usual stake-grinding or whatever tricks to maintain possession of the entire superpeer network forever, just sending it to my hubs around the world. If I were andyfastow rather than andytoshi I'd even set up a bunch of shell corps to disguise that I was doing this.
The point is that if you want to prevent rewriting history, you need to trust everyone with an ability to manipulate history, forever, even long after their incentives to help the network have gone. You need to prevent old hardware from winding up in unsecured dumps, from being stolen, from being hacked, etc., etc. I'd wager most TPM chips out there will expose their keys to (at least one of) the Chinese or Americans.
4. When you talk about trusted computing, what is the actual trust model behind this? I assume you need an authenticated channel to the TPM to verify the machines' software, but when you are only talking to a node through a network it is unclear to me how you can trust that you're talking to a real TPM which is really installed in the system that you're communicating with.
Andrew