[icebraining]

If you have a single miner and an incentive to exploit double-spends, won't whoever controls the miner just do the double-spending themselves? They can mine a chain that spends one way, then mine another to replace that one that spends again.

If you can trust the miner, why not just use a regular RDBMS? The controller is the primary/master, you just need to disallow UPDATEs and DELETEs, and to have a constraint that prevents an account from spending more than they received. The other nodes are read-only replicas.

(To the complaint that a single master doesn't scale: it should scale as well as a single miner. They're both the only writer to the database.)

[quickthrower2]

"select * from transactions" won't tell you that this has happened.

But your blockchain client will know immediately if the single miner has rewritten the block chain. It won't be able to download any new blocks based on the one it current thinks is head.

So while you can't stop the miner from doing what you said, no one will be fooled when it happens.

[icebraining]

As I wrote in the reply to the sibling post, chain-signing the transactions is basic, just a few lines of code using a crypto library like NaCl. We did that for an invoicing API, it was one of the easiest parts, literally less than 10 lines.

[thespirit]

That makes sense, but what about auditing (in isolation) the read-only replicas?

I suppose I could implement my own hash-chain to verify the authenticity? (aka, no missing data)

[icebraining]

Sure, you hash(transaction info + hash of previous transaction) and sign that with a private key, and you store it as a text field in the database.

In my country, all invoicing software must implement that (it's part of the SAF-T format that we must deliver to the IRS), and it took us less than ten lines of Ruby to do it. It's literally concatenating a few strings, then using some crypto library to hash and sign it.

Verification is just doing the same process, then checking if the signed hashes match.