5 ms·

I've spoken to a number of vendors and come across similar findings as well. Though of course, this is just observational on my part and not a detailed investig

I've spoken to a number of vendors and come across similar findings as well. Though of course, this is just observational on my part and not a detailed investigation or study, but I have been getting much the same impression. There's a lot of unnecessary hype and people jumping on the bandwagon just because it's currently a buzzword. That said, I still have a lot of faith in what Blockchain will eventually be able to achieve. It might just take longer to get there than we thought. I remember when I was studying computer science in 1999, even though the internet had been out a while and there had been lots of talk about e-commerce no one had really solved the problem particularly well in terms of providing a platform to the average Joe, but by 2005 things were very different and then by 2015 there was no looking back. I think it's going to be the same for Blockchain.

bognition 8y ago
> I still have a lot of faith in what Blockchain will eventually be able to achieve. What does this even mean? Its a really beautiful solution its just lacking a good problem.
- snaky 8y ago
  https://hackernoon.com/how-blockchain-technology-could-fix-the-node-js-ecosystem-bccc60832900 https://hackernoon.com/how-blockchain-technology-could-fix-t...
  - fwip 8y ago
    The solution offered is: "But instead of giving full maintenance or full publishing rights to new collaborators, the original developer would give new maintainers or a CI system only signing rights. So they would sign their releases and after a careful review the original author would countersign stating that he checked and approves these changes." This is 100% equivalent to the maintainer merging a pull request. The other half of the solution is "we need to pay open source maintainers," which doesn't need a blockchain either. Blockchain doesn't help this scenario at all.
  - XMPPwocky 8y ago
    > We need an easier way to automatically distribute payments based on certain rules to open source developers. Has almost nothing to do with Blockchain. This is just called "micropayments"- and blockchains suck for them. At best, you end up doing little payments outside the blockchain, and then settling them occasionally on the blockchain. You may notice this same approach works quite well for "do little payments outside the existing financial system, and settle them periodically." > Code and modules need to be multi-signed and certificates should be inexpensive to get and easy to validate. Code signing is unrelated to blockchain. Certificates are already easy to get. GPG is free. Certificates signed by a CA sometimes cost money- code signing certs, at least in theory (in practice? hah, not really), cost because they need to be able to verify your actual identity. Certificates being easy to validate... this is a PKI problem. Blockchain provides nothing of value here. You might be able to do something like what Keybase does- having some centralized "identity" and making changes to same auditable- with a degenerate Merkle tree. You know what else does this? A HSM from like 2006, which, in each audit log entry, includes the hash of the previous one, to establish exactly this property- changes and edits can be detected. > One of our dependencies could become a malicious package in the same way we saw it with event-stream. But instead of giving full maintenance or full publishing rights to new collaborators, the original developer would give new maintainers or a CI system only signing rights. So they would sign their releases and after a careful review the original author would countersign stating that he checked and approves these changes. Not only has this got nothing to do with Blockchain, the proposal here is just "a new maintainer needs to ask the old maintainer for permission to publish for a while", which is quite silly- if the old maintainer is tired of bothering with the maintenance bit, the LAST thing they want to do is careful code audits. > Later, if our fictional project received an in-app payment there could be some logic within the runtime environment that based on the impact or contribution of this open source module to our project would automatically distribute a couple of cents of each payment to the author who can be determined based on the certificate. Well, no, the author can't be determined based on the certificate on your binary. The person (or persons) who signed it can be. Asking every contributor to sign every release in perpetuity is silly, of course. Incentivize them to do it with a cut of the profits? Great, now they just rubber stamp everything. Now, if you mean the maintainer of the module, sure. You know what else works quite nicely for this? Just having a payment address in your Git repo in some file with a well-known name. There's no point in the certificate, here! "Aha- a payment address! PayPal won't work, not much else that exists will, either. For those smaller payments, only a Blockchain-based approach would work." Well, that's true- for now. Similarly, "free, rapid person-to-person transfers" was largely just Venmo for a while. Then the sleeping giants that are the financial industry woke up, threw some pocket change at the problem, and created Zelle / Early Warning, which does the exact same thing. There isn't a good way to do microtransactions today because there isn't that much demand for microtransactions. If there is, it'll pop up quite quickly. This entire article is just... clown shoes. The parts that might work aren't novel and don't require anything besides a degenerate Merkle tree, and the parts that are novel or require a Real Blockchain(TM) are useless. Why is this? Because the article itself was written backwards! The author started out with "I like and know Blockchain. (more cynically, 'I benefit when $ETH goes up'.) Here is a problem. How can we apply Blockchain to it, and make the world more secure (and more cynically, 'make me richer and my skills more in demand')?" In so far as this article attempts to solve any problem, the problem is "Blockchain isn't used as much as I'd like it to be."
- asynchrony 8y ago
  Faith is required to sustain belief in promises that are never delivered.
dragontamer 8y ago
> That said, I still have a lot of faith in what Blockchain will eventually be able to achieve. It might just take longer to get there than we thought. Why should anyone care more than say... the adoption rate of SkipLists or Bloom Filters? Blockchain IS a usable datastructure with some interesting properties. But so are Cuckoo Hashes. But no one is going around talking about how Cuckoo Hashes will take over the world. Its like XML or SOAP, or any other buzzword technology. There's certainly a benefit to the technology, but ultimately the engineering of stuff that uses it is relatively boring.
- deleted 8y ago
  [deleted]
hudon 8y ago
> in 1999, even though the internet had been out a while and there had been lots of talk about e-commerce no one had really solved the problem particularly well in terms of providing a platform to the average Joe I'm not sure why you focused on e-commerce as a use case, as well as the average Joe as the user. The article in question talks about them trying to find ANY industry use case. The Internet was useful pretty much from day 1. In the early 70s it already enabled digital file transfers and email communication. The use cases were easy to find...
- anongraddebt 8y ago
  The percentage of people saying blockchain doesn't have a substantial use case, is about the same percentage as there were in the late 70's or early 80's saying the internet didn't have a substantial use case. Initially, few people thought file transfer over the internet was a substantive use case because the transmission speed was too slow. Then throughput capacity picked up, but people then shifted the argument to something like, "It's good for medium size file transfer, and I guess I can sometimes send this clunky email thing instead of picking up the phone or sending a fax." This process repeats itself, with goalposts ever shifting, until someone talks about the possibility of selling everything over the internet, starting with books, and most think it's nutty, but believe hearing "you've got mail" every morning might get mass adoption. I'm not sure whether 'blockchain' is a database or a universal computer or a new software primitive. Or whether we can even tell. What I know is that it is at the very least some sort of network infrastructure (in the most abstract sense of the term). Just like with the internet (another network infrastructure), the space of substantial use cases increases as more people and technologies are connected to it. Could it end up being a dud apart from some random use cases? Emphatically yes. Could it end up being pretty important? Possibly (we don't know). Ironically, the best evidence I have for being agnostic about the potential of 'blockchain' is the number of educated and non-educated people making wild claims about the benefits of decentralization, etc. When the telegraph arrived, a substantial mass of people said it would usher in world peace. When the internet arrived, a substantial mass of people made wild claims about breaking us free from corporate power, educating the masses, etc.
  - deleted 8y ago

bognition 8y ago

> I still have a lot of faith in what Blockchain will eventually be able to achieve. What does this even mean? Its a really beautiful solution its just lacking a good problem.

snaky 8y ago
https://hackernoon.com/how-blockchain-technology-could-fix-the-node-js-ecosystem-bccc60832900 https://hackernoon.com/how-blockchain-technology-could-fix-t...
- fwip 8y ago
  The solution offered is: "But instead of giving full maintenance or full publishing rights to new collaborators, the original developer would give new maintainers or a CI system only signing rights. So they would sign their releases and after a careful review the original author would countersign stating that he checked and approves these changes." This is 100% equivalent to the maintainer merging a pull request. The other half of the solution is "we need to pay open source maintainers," which doesn't need a blockchain either. Blockchain doesn't help this scenario at all.
- XMPPwocky 8y ago
  > We need an easier way to automatically distribute payments based on certain rules to open source developers. Has almost nothing to do with Blockchain. This is just called "micropayments"- and blockchains suck for them. At best, you end up doing little payments outside the blockchain, and then settling them occasionally on the blockchain. You may notice this same approach works quite well for "do little payments outside the existing financial system, and settle them periodically." > Code and modules need to be multi-signed and certificates should be inexpensive to get and easy to validate. Code signing is unrelated to blockchain. Certificates are already easy to get. GPG is free. Certificates signed by a CA sometimes cost money- code signing certs, at least in theory (in practice? hah, not really), cost because they need to be able to verify your actual identity. Certificates being easy to validate... this is a PKI problem. Blockchain provides nothing of value here. You might be able to do something like what Keybase does- having some centralized "identity" and making changes to same auditable- with a degenerate Merkle tree. You know what else does this? A HSM from like 2006, which, in each audit log entry, includes the hash of the previous one, to establish exactly this property- changes and edits can be detected. > One of our dependencies could become a malicious package in the same way we saw it with event-stream. But instead of giving full maintenance or full publishing rights to new collaborators, the original developer would give new maintainers or a CI system only signing rights. So they would sign their releases and after a careful review the original author would countersign stating that he checked and approves these changes. Not only has this got nothing to do with Blockchain, the proposal here is just "a new maintainer needs to ask the old maintainer for permission to publish for a while", which is quite silly- if the old maintainer is tired of bothering with the maintenance bit, the LAST thing they want to do is careful code audits. > Later, if our fictional project received an in-app payment there could be some logic within the runtime environment that based on the impact or contribution of this open source module to our project would automatically distribute a couple of cents of each payment to the author who can be determined based on the certificate. Well, no, the author can't be determined based on the certificate on your binary. The person (or persons) who signed it can be. Asking every contributor to sign every release in perpetuity is silly, of course. Incentivize them to do it with a cut of the profits? Great, now they just rubber stamp everything. Now, if you mean the maintainer of the module, sure. You know what else works quite nicely for this? Just having a payment address in your Git repo in some file with a well-known name. There's no point in the certificate, here! "Aha- a payment address! PayPal won't work, not much else that exists will, either. For those smaller payments, only a Blockchain-based approach would work." Well, that's true- for now. Similarly, "free, rapid person-to-person transfers" was largely just Venmo for a while. Then the sleeping giants that are the financial industry woke up, threw some pocket change at the problem, and created Zelle / Early Warning, which does the exact same thing. There isn't a good way to do microtransactions today because there isn't that much demand for microtransactions. If there is, it'll pop up quite quickly. This entire article is just... clown shoes. The parts that might work aren't novel and don't require anything besides a degenerate Merkle tree, and the parts that are novel or require a Real Blockchain(TM) are useless. Why is this? Because the article itself was written backwards! The author started out with "I like and know Blockchain. (more cynically, 'I benefit when $ETH goes up'.) Here is a problem. How can we apply Blockchain to it, and make the world more secure (and more cynically, 'make me richer and my skills more in demand')?" In so far as this article attempts to solve any problem, the problem is "Blockchain isn't used as much as I'd like it to be."
asynchrony 8y ago
Faith is required to sustain belief in promises that are never delivered.

dragontamer 8y ago

> That said, I still have a lot of faith in what Blockchain will eventually be able to achieve. It might just take longer to get there than we thought. Why should anyone care more than say... the adoption rate of SkipLists or Bloom Filters? Blockchain IS a usable datastructure with some interesting properties. But so are Cuckoo Hashes. But no one is going around talking about how Cuckoo Hashes will take over the world. Its like XML or SOAP, or any other buzzword technology. There's certainly a benefit to the technology, but ultimately the engineering of stuff that uses it is relatively boring.

deleted 8y ago
[deleted]

hudon 8y ago

> in 1999, even though the internet had been out a while and there had been lots of talk about e-commerce no one had really solved the problem particularly well in terms of providing a platform to the average Joe I'm not sure why you focused on e-commerce as a use case, as well as the average Joe as the user. The article in question talks about them trying to find ANY industry use case. The Internet was useful pretty much from day 1. In the early 70s it already enabled digital file transfers and email communication. The use cases were easy to find...

anongraddebt 8y ago
The percentage of people saying blockchain doesn't have a substantial use case, is about the same percentage as there were in the late 70's or early 80's saying the internet didn't have a substantial use case. Initially, few people thought file transfer over the internet was a substantive use case because the transmission speed was too slow. Then throughput capacity picked up, but people then shifted the argument to something like, "It's good for medium size file transfer, and I guess I can sometimes send this clunky email thing instead of picking up the phone or sending a fax." This process repeats itself, with goalposts ever shifting, until someone talks about the possibility of selling everything over the internet, starting with books, and most think it's nutty, but believe hearing "you've got mail" every morning might get mass adoption. I'm not sure whether 'blockchain' is a database or a universal computer or a new software primitive. Or whether we can even tell. What I know is that it is at the very least some sort of network infrastructure (in the most abstract sense of the term). Just like with the internet (another network infrastructure), the space of substantial use cases increases as more people and technologies are connected to it. Could it end up being a dud apart from some random use cases? Emphatically yes. Could it end up being pretty important? Possibly (we don't know). Ironically, the best evidence I have for being agnostic about the potential of 'blockchain' is the number of educated and non-educated people making wild claims about the benefits of decentralization, etc. When the telegraph arrived, a substantial mass of people said it would usher in world peace. When the internet arrived, a substantial mass of people made wild claims about breaking us free from corporate power, educating the masses, etc.
- deleted 8y ago