Re:Rhetoric around the blockchain hints at problems with tec...
by quickthrower2 on Monday May 14, 2018 @04:06PM
(#17068987)
"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.
Re:Rhetoric around the blockchain hints at problems with tec...
by icebraining on Monday May 14, 2018 @04:20PM
(#17069105)
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.
Re:Rhetoric around the blockchain hints at problems with tec...
by thespirit on Monday May 14, 2018 @07:00AM
(#17064376)
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)
Re:Rhetoric around the blockchain hints at problems with tec...
by icebraining on Monday May 14, 2018 @07:28AM
(#17064522)
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.
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.)