[thespirit]

As someone presented with a startup that needs an "append-only" transaction database with consensus across 2-N servers (depending on scale), and an inherent incentive to exploit any potential "double-spend" issue, an internal blockchain with a single node acting as an authoritative "miner" (aka, controller) seems pretty cheap to roll out considering I can just modify existing bitcoin/blockchain software.

Is there any software out there that I could readily adapt to provide the same properties and guarantees without incurring hundreds of hours of development and testing?

[kybernetikos]

This is the right way to look at it I think. I've been looking at a blockchain based solution recently, and there has been an awful lot of negativity, and people wondering if it would have been possible to implement the same solution with an oracle database.

Well, yes, it would have been possible. There are a couple of minor things the blockchain does better and a couple of things it does worse for this use case, but fundamentally, I believe the blockchain based solution was cheaper to build and will be cheaper to maintain.

People need to consider these solutions in the context of whether or not they solve business problems effectively, and put aside knee jerk reactions based on technological prejudices.

[icebraining]

Why was the blockchain cheaper to build and maintain compared to a traditional RDBMS? I agree that avoiding knee-jerk reactions is good, but I frankly have yet to see a case where it was actually the best solution, except for the case of Bitcoin and other public cryptocurrencies.

[kybernetikos]

Because we wanted transactions signed with the key of the transactor and a complete audit history (ideally one that couldn't be tampered with, even by an admin).

By using ethereum, we didn't need to write microservices to front the database, we didn't need to configure the database (not trivial if you want serializability https://blog.dbi-services.com/oracle-serializable-is-not-ser... ), we didn't need to write any cryptography code, we don't need to run any kind of infrastructure (let alone expensive, distributed infrastructure) to allow people to interact with and update the data. We get broadcasting of changes to clients so that the UIs can be kept up to date for free too.

We do have to carefully audit our smart contracts, but they are much smaller pieces of code than the microservices and triggers that we would otherwise have written.

Mainly, because our use case was similar to the crypto-asset tracking use case, there was a lot of code we could rely on already in ethereum that we would have had to write ourselves in the RDBMS world.

[icebraining]

Thanks. I have to admit I don't agree with most of that as stated, but I wasn't involved in the actual project, so I admit I may still be missing specifics.

By the way, did you use any historical data from the tracking? Does ethereum provide good tools to analyze that?

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

[jakeinspace]

Maybe look into datomic