Live data from Hacker News

Show HN: My experimental take on a decentralized ledger

github.com

21–28 of 28 posts

Re: Show HN: My experimental take on a decentralized ledger

#21

Check out https://morph.is/v0.8/ if you haven't seen it, decentralized encrypted file storage and email, exciting stuff.

> Distributed Spam Proof Mail! Uncensorable, inherently spam proof and transparently encrypted and sender authenticated messaging! Secure enough for Edward Snowden! Easy and fool-proof enough for a child!

43 exclamation points on the front page. He has the hype cranked up pretty high. Still, it's nice to see all of these P2P efforts.

Re: Show HN: My experimental take on a decentralized ledger

#22
post #6

Earlier quoted context omitted.

I'm using upserts... The reason I'm using upserts is basically just lazyness because I didn't feel like refactoring the source code to work around requiring upserts. Also, I'm not very confident in C++ so I did not want to take on that task.

You can fix this with basic SQL IF record EXISTS then UPDATE else INSERT

No. Conccurrency makes it way harder than that.

Re: Show HN: My experimental take on a decentralized ledger

#24
post #9

> Transactions are FREE (the fee is always zero) How would you deal with DDoS attacks? Taking down a ledger like this could be easy...

Cloudflare doesn't have to charge a fee for every http request, although transaction fees do seem like the elegant solution.

Cloudflare is a massive, well-funded, centralized entity.

Re: Show HN: My experimental take on a decentralized ledger

#25

Earlier quoted context omitted.

You can fix this with basic SQL IF record EXISTS then UPDATE else INSERT

No. Conccurrency makes it way harder than that.

In PostgreSQL, you can set the SERIALIZABLE isolation level for the whole database, put a retry loop around all database transactions and completely stop worrying about concurrency issues.

I think all database applications should be written like this at least until performance starts being an issue.

Re: Show HN: My experimental take on a decentralized ledger

#26
post #25

Earlier quoted context omitted.

No. Conccurrency makes it way harder than that.

In PostgreSQL, you can set the SERIALIZABLE isolation level for the whole database, put a retry loop around all database transactions and completely stop worrying about concurrency issues. I think all database applications should be written like this at least until performance starts being an issue.

Entirely depends on the the type of workload / application architecture. In some cases the rollback ratios will be massive (I've seen 70%). In other cases adding such a retry loop is unattractive because the latency jitter. Or retaining all involved data for a retry is unattrictive.

Yet Another problem is that you need to enforce all sessions potentially involved in a data race need to use serializable; that can be easy or hard, depending on the scenario.

Re: Show HN: My experimental take on a decentralized ledger

#27
post #25

Earlier quoted context omitted.

No. Conccurrency makes it way harder than that.

In PostgreSQL, you can set the SERIALIZABLE isolation level for the whole database, put a retry loop around all database transactions and completely stop worrying about concurrency issues. I think all database applications should be written like this at least until performance starts being an issue.

Use UPSERT, it's correct -and- fast rather than just correct.

Increasing the transaction isolation level shouldn't be done out of laziness.

Post reply on HN