Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

A great example of something that does not need a blockchain. You're just asking for the relevant government departments to publish their books.


Don't you want some verifiable continuity in those books?

How do you guarantee that continuity breaches are easy to spot when they're "books" and you can publish as many of them as you want, or skip one if it turns out we don't want transparency somewhere because of "national security"?

This argument always seems to start with "there is no application for blockchain" and then moves the goal post to "that application doesn't NEED a blockchain" when we didn't even want ONLY that one application, we came for the whole package.

Do you really trust the government to publish accurate data if there is no transparent mechanism to keep them accountable for their accuracy? What is your alternative proposed mechanism for ensuring that the books are not cooked? (Is it another law, this time that says "books SHALL be balanced" and links to the RFC that provides specific definitions for modal verbs like MUST, SHALL, MAY, COULD?)

We certainly COULD invent another system that all tax money passes through, which ties out and all tax revenue is required to pass through, but how far will you stretch the spec in the opposite direction just to make sure that we didn't use "blockchain" which I'm assuming you consider as "scam tech" and you are apparently convinced that we don't need?


What's realistic is a policy of "no backsies". You can't prevent a party from lying (without remaking the world so that everything happens on your favorite blockchain, which ain't gonna happen), so what you do is you catch them in their lies.

This problem is already solved for TLS, with no bitcoin-style blockchain and no climate destruction: https://certificate.transparency.dev/


Just so you understand me, I have basically zero expectation that anyone is going to choose "my favorite blockchain" for their next big project and send the price soaring. It's just not going to happen.

With that out of the way, what stops the government from implementing their own CBDC and saying "tax revenues SHALL be paid downstream via the US-CBDC Token" and requiring approved vendors to implement it for their US-Gov Receivables? This seems very likely to happen. I would actually bet on it.

You're telling me on one hand, the problem is solved (example TLS) and on the other hand, I need to be realistic about my expectations, since it doesn't solve the whole problem... which seems to indicate to me that your solution is actually not solving the problem you expected me to have, which is there is no effective or continuous transparency about how much money our institutions have in-flight and where it's going or gone, and there is no sponsored route for institutions to "opt in" to such transparency and actually enforce it permanently.

That's what the blockchain is for.

What's un-fixably wrong with the blockchain solution exactly? I fully expect this US-CBDC is going to look nothing like I wanted my blockchain to look (it won't be in any way decentralized at all, it will have some government-sponsored "oracles" instead of user-sponsored nodes, so that it will be a blockchain in name and in function, but you won't be able to mine it, and it won't be "ours" – it might actually go on Ethereum, but I doubt it will and I definitely won't hold my breath. It will probably be super green for the environment, whatever it is.)

So how can you simultaneously believe this is a solved problem, which can't be solved, and yet already has been solved by Blockchain (but we don't need it?)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: