191–200 of 204 posts
DLT strips away almost everything that makes blockchain compelling. Why would a distributed systems engineer work on what amounts to a really shitty database?
Earlier quoted context omitted.
It isn't intrinsically theft prone, the UI around using it is just not up to snuff yet. Credit cards, on the other hand, are intrinsically theft prone. They are a pull architecture. Every time you use your credit card, the store takes money from you. This is patently absurd, and the only reasonable definition of 'theft prone'. Bitcoin is a push architecture. You can never take my bitcoin, I can only send you bitcoin.…
> Every time you use your credit card, the store takes money from you. No, precisely no credit cards work that way. That's why they're called credit cards.
Earlier quoted context omitted.
That's why I've never understood all this talk about "private blockchains." Why? What's the point? We already have distributed database systems that are light years faster than blockchains. The ONLY benefits of a blockchain-based approach are censorship resistance and not having to trust the actors in the system. If you don't need either of those two benefits, then there are far better existing solutions for record k…
Private blockchains have a use case where you have a central authority coordinating many participants that don't trust each other - if the central authority periodically publishes the signed blockchain ledger/update, it enables "shared truth" that every participant can use, and each of them can verify that noone has "altered history", that particular constraints have been met, etc. In essence, it can be used as a ver…
In other words, something like http://ledger-cli.org/ stored in a git repository with some input validation and signed commits would suffice.
Proponents call this "blockchain technology" because it sounds advanced. They can because nobody has a definition of what "blockchain technology" is. In my mind, if it could have been designed by any competent engineer prior to Bitcoin, then it isn't "blockchain technology". But that's just me.
Earlier quoted context omitted.
> Someone needs to pay me to implement something that requires blockchain It's difficult to find something that requires a blockchain, because the unique distinguishing feature of blockchains is the lack of any trusted central authority. If you have a trusted authority, then you can do anonymous currency, money transfers, smart contracts, or anything similar 1000x more efficiently with a single server, an API, and so…
Which makes it look like blockchain is a solution looking for a problem. I still believe that problem will come up, and/or we'll see technologies that borrow concepts from blockchain without being true "blockchain."
The blockchain comes as the refactoring of this legacy system.
Earlier quoted context omitted.
Some would say that the "wisdom of the crowd" and startups are things that so many people ascribed special superpowers to, it brought in a lot of people that normally wouldn't push deeply into a high-complexity tech field.
That's cool, but how is it relevant?
Earlier quoted context omitted.
There are solutions to that though, like Proof of Stake. If distributed systems really cared about that, then that's exactly why they ought to be working on blockchains, to make them more efficient.
In part because this is trodden ground for distributed systems engineers and we know that, on balance, the correct solutions all involve massive centralization. You don't want that. So we're at a bit of an impasse. Distributed systems these days mostly argue that you do your trusting up front, outside of the protocol itself. You then validate that the actors share the secrets you all agreed upon, and then optimize th…
Earlier quoted context omitted.
In part because this is trodden ground for distributed systems engineers and we know that, on balance, the correct solutions all involve massive centralization. You don't want that. So we're at a bit of an impasse. Distributed systems these days mostly argue that you do your trusting up front, outside of the protocol itself. You then validate that the actors share the secrets you all agreed upon, and then optimize th…
In some cases you can forget bad input, though, can't you? It's a rather wasteful example, but if (like you say, having established trust beforehand) every element of a grow-only set is a signed message, you can reject any messages that don't validate against their signature when merging. On one hand, this breaks idempotence. On the other, if we regard that set as a subset of the set of validly signed messages, it co…
That's not really what I meant by "bad". I meant bad as in intent, not structural and immediately verifiable message integrity.
If all entities in the coalescing set can independently verify that a message does not meet its signature requirements, it will be rejected and idempotence is maintained.
If ONE member is somehow deceived about key validity it'll propagate the message into every other member's state, eventually.
Earlier quoted context omitted.
Ethereum has not shown a particularly strong track record when it comes to security, so I think the comment stands until they address that or get replaced by the next hotness.
Ethereum actually has a better security track record than Bitcoin does [1]. It's the contracts on top of Ethereum that are the problem. Calling those incidents Ethereum security problems is like calling a Windows 0day an Intel security problem. 1. https://en.bitcoin.it/wiki/Value_overflow_incident
Earlier quoted context omitted.
> Every time you use your credit card, the store takes money from you. No, precisely no credit cards work that way. That's why they're called credit cards.
The money is taken from the credit card company, then. The architecture is still pull. You're splitting hairs.
If I buy something with a credit card for $2k and have $2k in my bank account, the $2k is still there until I pay the credit card company. It could take years or be paid off immediately.
It's not a "pull" at all.
Earlier quoted context omitted.
The money is taken from the credit card company, then. The architecture is still pull. You're splitting hairs.
That's not splitting hairs; that's literally the point of credit cards. It is entirely "push" from my perspective, modulo the minimum monthly payment and tolerance for paying interest and bad credit. If I buy something with a credit card for $2k and have $2k in my bank account, the $2k is still there until I pay the credit card company. It could take years or be paid off immediately. It's not a "pull" at all.