5 ms·

My issue with Blockchain and "information laws" (not just GDPR, but any law which prohibits or controls information) is that you ("you" being the creator/mainta

My issue with Blockchain and "information laws" (not just GDPR, but any law which prohibits or controls information) is that you ("you" being the creator/maintainer of the blockchain) can never mess up. If someone puts "illegal information" directly in your blockchain, you either need a way to roll-back the change (which removes most/all of the benefits of an append-only structure like a blockchain), or you need to be okay with breaking the law. That someone could be a blackhat that wanted to publish a bunch of personal info, a disgruntled employee, or just regular users if you allow arbitrary input. I don't know of any kind of real solution, and at some point someone is going to push the limits and make it obvious that "illegal information" is on a blockchain, and we (as society) will have to come up with a way to deal with it.

knorker 8y ago
Would be better if someone could come up with a problem that blockchains solve.
- petertodd 8y ago
  There's a good chance you're using a blockchain(1) to visit this website: the SSL certificate that protects your connection is published in a Certificate Transparency blockchain. If you're using Chrome, your browser verified a proof that the certificate was in fact in one of the CT blockchains. Being a blockchain, auditors (like the sysadmins at hacker news) can be sure they have the complete set of all certificates, and thus be sure they can detect any forgeries. 1) A blockchain is simply a chain of blocks. The key thing they do is allow auditing mechanisms to be sure they have the complete set of data contained in them. They're really a very simple and useful idea, which unfortunately has been hyped up by a bunch of scammers and semi-scammers. The consensus mechanisms used to secure blockchains are the interesting part, not the blockchains themselves. Although for many applications - Certificate Transparency being one of them - boring old trusted third parties seem to be good enough. That said, if you have a stronger decentralized chain available too, you can always publish commitments to the state of your centralized chain in the decentralized chain, improving security at relatively little cost. I wrote up a particularly scalable version of that idea here: https://petertodd.org/2017/scalable-single-use-seal-asset-transfer https://petertodd.org/2017/scalable-single-use-seal-asset-tr...
  - knorker 8y ago
    > Certificate Transparency Only in the sense that "git" also is a blockchain. In other words: nothing relevant to cryptocurrencies, really.
    - petertodd 8y ago
      But that's the thing: git is very close to a blockchain! The only thing that's missing from git that makes it not quite a blockchain is that the way we use git doesn't expect there to be a linear series of commits. But with relatively little effort you can add that to git, making a blockchain out of it. What blockchains do in cryptocurrencies is not magic: they're just the basic auditing mechanism that allows everyone with a full node to verify that all the rules are being followed by parsing all the transactions. The simplest way to do that is with a linear chain of blocks that you validate, starting at block zero. All the "magic" is in the consensus mechanisms that decide which chain of blocks is in fact the real chain, not the blockchains themselves.
      - tscs37 8y ago
        Git is a blockchains. I don't see any rules that a consensus algorithm needs to be non-human or that only a single chain can be authorative. Git is a blockchain that has none of the usual problems of blockchains since the arbiter is a human and they can do as they please. Argreement between humans is a social procedure.
        petertodd 8y ago
        My only real disagreement with you is I'd call Git a blockdag, because it's a more general directed acyclic graph rather than a linear chain. But that's just a disagreement about what's more helpful terminology.
      - admax88q 8y ago
        I think the term "blockchain" implies more than just a merkle-tree but some level of distributed concensus. A plain merkle-tree or merkle-list. Such technology has been around for a while before "blockchain" was such a hyped technology.
- tomjen3 8y ago
  Here is one: without a block chain to prove you developed something first you have to write it in an engineering log, in your handwriting and pay a fortune to store that some place safe, probably environmentally secured, etc. With a block chain you can pay 1 sat (ie less than 1/100 penny) to have your git hash stamped forever into the blockchain. You can then pay nearly nothing to have it safely stored until you need to prove it, at which point you have very, very good evidence to prove you had what you claimed, when you did. You can also stamp the git hash into your twitter, (you can, as of this writing, delete but not edit tweets), but that assumes you are counting on Twitter to be around 30+ years.
  - theamk 8y ago
    ... or sign it using cryptographic timestamp service, and keep certificate? Use multiple timestamp services if you want more assurance. see also: https://www.globalsign.com/en/blog/what-is-timestamping-how-does-it-work/ https://www.globalsign.com/en/blog/what-is-timestamping-how-... see also free services: https://stackoverflow.com/questions/25052925/does-anyone-know-a-freetrial-timestamp-server-service https://stackoverflow.com/questions/25052925/does-anyone-kno...
    - tomjen3 8y ago
      There are more than one way to do it, of course, but you are relying on them never to lose control of their private keys.
  - knorker 8y ago
    I'll agree that this makes it easier. But why? Have you ever, in your life, needed to do this? Do you know anyone who has? Have you heard of anyone who has? This problem sometimes comes up in thought experiments, and sometimes involves convoluted solutions such as bouncing signals off of celestial bodies to produce a time delay. I have never needed to do this. And either way the actual cost for society to do this with blockchains is huge, in energy. You're not paying it, but the cost is there. Or you could just do it the traditional way: Put it on pastebin. Hell, put it on a couple of cloud services, who will likely have logs about upload times. Maybe there are cases, where you want to guard yourself against someone reinventing your industry secret and claiming IP theft saying you copied them. It won't help against a patent lawsuit, I'm pretty sure, since you didn't publish. And publishing is the trade you make with society in order to get monopoly for 18-20 years via a patent. But more importantly: This NEVER needs to be a blockchain. This is not a use for a blockchain. There is nothing chain about it. You just want your blob signed. You could build a service in a weekend that does nothing but sign "I saw the following hash on 2018-05-24: 82390182903120", and run it for no cost (not 0.5% of world electricity). Send your hash to 100 places and boom, done.
petertodd 8y ago
> you either need a way to roll-back the change (which removes most/all of the benefits of an append-only structure like a blockchain) Blockchains are not inherently immutable or even append-only. What they guarantee (assuming the consensus scheme is working) is that you'll be aware of all the data in the chain or the fact that some of it is missing; the idea that blockchains are inherently immutable is a big misconception that treats blockchains like they're magic. In a database, if you are forced to delete data, you'll go ahead and delete that data. You's probably also record the fact that you deleted that data in some kind of auditing log to be able to audit compliance with those deletion requests, as well as detect illegitimate deletions. In a blockchain, you can do the exact same thing, but with better controls: add a block to the blockchain that contains machine-readable instructions telling all nodes processing the blocks to delete the data if they have a copy. Once every node has done that, even though the blockchain still commits to that data, the data itself is unavailable, thus complying with the requirement to delete it. Essentially we now have a dangling pointer: there will be a digest in the chain, but the data that was hashed to produce the digest is no longer available. The blockchain is of course no longer able to be validated in the same way as before, but what you can validate is the fact that the deletion process was followed properly. E.g. you might have rules that state 2-of-3 senior admins have to use their signing keys to sign off on a deletion request. A similar example of this principle exists in Git: you can do a shallow checkout that doesn't contain all prior history. Recentish versions of Git handle this quite well: every operation will succeed if it doesn't happen to process the missing history. Similarly, if every git repo is in fact a shallow repo, with some history deleted, that data will gone. At the low level, this works because practically all blockchains make use of merkle trees. Rather than the hash of a block b_n being calculated as Hash(b_n), you instead have a header that commits to a merkle tree of data items. Thus you can still validate that the headers are connected without actually having all the data (extra credit problem: is this always a good thing?). 1) By "commit", we mean that the blockchain headers contains a hash digest of some other data; the headers are committed to the data they hashed, because if that data was changed the hash digest would change, rendering the headers invalid.
- Klathmon 8y ago
  I'd argue at that point it's not a "blockchain", since you are removing one of the major points for using the data structure (the ability to verify the chain without trust). If you are just going to rely on a central authority to say which blocks should be "ignored" (in other words, which hashes should just be trusted), then why use a blockchain at all? It's just a very slow, complicated, expensive append-only log file. The only benefit a blockchain provides (for the sake of this discussion) is it's ability for someone to verify it without trust from the genesis block all the way to the most current. You take that away, it's not a blockchain anymore.
s73v3r_ 8y ago
That makes this law a very, very, very good thing! Before this, you would have put out that blockchain without a second thought. Now, you're thinking about the consequences and ramifications of what might happen. And when you start thinking about those, and get others thinking about them, then you start thinking about solutions for them.

knorker 8y ago

Would be better if someone could come up with a problem that blockchains solve.

petertodd 8y ago
There's a good chance you're using a blockchain(1) to visit this website: the SSL certificate that protects your connection is published in a Certificate Transparency blockchain. If you're using Chrome, your browser verified a proof that the certificate was in fact in one of the CT blockchains. Being a blockchain, auditors (like the sysadmins at hacker news) can be sure they have the complete set of all certificates, and thus be sure they can detect any forgeries. 1) A blockchain is simply a chain of blocks. The key thing they do is allow auditing mechanisms to be sure they have the complete set of data contained in them. They're really a very simple and useful idea, which unfortunately has been hyped up by a bunch of scammers and semi-scammers. The consensus mechanisms used to secure blockchains are the interesting part, not the blockchains themselves. Although for many applications - Certificate Transparency being one of them - boring old trusted third parties seem to be good enough. That said, if you have a stronger decentralized chain available too, you can always publish commitments to the state of your centralized chain in the decentralized chain, improving security at relatively little cost. I wrote up a particularly scalable version of that idea here: https://petertodd.org/2017/scalable-single-use-seal-asset-transfer https://petertodd.org/2017/scalable-single-use-seal-asset-tr...
- knorker 8y ago
  > Certificate Transparency Only in the sense that "git" also is a blockchain. In other words: nothing relevant to cryptocurrencies, really.
  - petertodd 8y ago
    But that's the thing: git is very close to a blockchain! The only thing that's missing from git that makes it not quite a blockchain is that the way we use git doesn't expect there to be a linear series of commits. But with relatively little effort you can add that to git, making a blockchain out of it. What blockchains do in cryptocurrencies is not magic: they're just the basic auditing mechanism that allows everyone with a full node to verify that all the rules are being followed by parsing all the transactions. The simplest way to do that is with a linear chain of blocks that you validate, starting at block zero. All the "magic" is in the consensus mechanisms that decide which chain of blocks is in fact the real chain, not the blockchains themselves.
    - tscs37 8y ago
      Git is a blockchains. I don't see any rules that a consensus algorithm needs to be non-human or that only a single chain can be authorative. Git is a blockchain that has none of the usual problems of blockchains since the arbiter is a human and they can do as they please. Argreement between humans is a social procedure.
      - petertodd 8y ago
        My only real disagreement with you is I'd call Git a blockdag, because it's a more general directed acyclic graph rather than a linear chain. But that's just a disagreement about what's more helpful terminology.
    - admax88q 8y ago
      I think the term "blockchain" implies more than just a merkle-tree but some level of distributed concensus. A plain merkle-tree or merkle-list. Such technology has been around for a while before "blockchain" was such a hyped technology.
tomjen3 8y ago
Here is one: without a block chain to prove you developed something first you have to write it in an engineering log, in your handwriting and pay a fortune to store that some place safe, probably environmentally secured, etc. With a block chain you can pay 1 sat (ie less than 1/100 penny) to have your git hash stamped forever into the blockchain. You can then pay nearly nothing to have it safely stored until you need to prove it, at which point you have very, very good evidence to prove you had what you claimed, when you did. You can also stamp the git hash into your twitter, (you can, as of this writing, delete but not edit tweets), but that assumes you are counting on Twitter to be around 30+ years.
- theamk 8y ago
  ... or sign it using cryptographic timestamp service, and keep certificate? Use multiple timestamp services if you want more assurance. see also: https://www.globalsign.com/en/blog/what-is-timestamping-how-does-it-work/ https://www.globalsign.com/en/blog/what-is-timestamping-how-... see also free services: https://stackoverflow.com/questions/25052925/does-anyone-know-a-freetrial-timestamp-server-service https://stackoverflow.com/questions/25052925/does-anyone-kno...
  - tomjen3 8y ago
    There are more than one way to do it, of course, but you are relying on them never to lose control of their private keys.
- knorker 8y ago
  I'll agree that this makes it easier. But why? Have you ever, in your life, needed to do this? Do you know anyone who has? Have you heard of anyone who has? This problem sometimes comes up in thought experiments, and sometimes involves convoluted solutions such as bouncing signals off of celestial bodies to produce a time delay. I have never needed to do this. And either way the actual cost for society to do this with blockchains is huge, in energy. You're not paying it, but the cost is there. Or you could just do it the traditional way: Put it on pastebin. Hell, put it on a couple of cloud services, who will likely have logs about upload times. Maybe there are cases, where you want to guard yourself against someone reinventing your industry secret and claiming IP theft saying you copied them. It won't help against a patent lawsuit, I'm pretty sure, since you didn't publish. And publishing is the trade you make with society in order to get monopoly for 18-20 years via a patent. But more importantly: This NEVER needs to be a blockchain. This is not a use for a blockchain. There is nothing chain about it. You just want your blob signed. You could build a service in a weekend that does nothing but sign "I saw the following hash on 2018-05-24: 82390182903120", and run it for no cost (not 0.5% of world electricity). Send your hash to 100 places and boom, done.

petertodd 8y ago

> you either need a way to roll-back the change (which removes most/all of the benefits of an append-only structure like a blockchain) Blockchains are not inherently immutable or even append-only. What they guarantee (assuming the consensus scheme is working) is that you'll be aware of all the data in the chain or the fact that some of it is missing; the idea that blockchains are inherently immutable is a big misconception that treats blockchains like they're magic. In a database, if you are forced to delete data, you'll go ahead and delete that data. You's probably also record the fact that you deleted that data in some kind of auditing log to be able to audit compliance with those deletion requests, as well as detect illegitimate deletions. In a blockchain, you can do the exact same thing, but with better controls: add a block to the blockchain that contains machine-readable instructions telling all nodes processing the blocks to delete the data if they have a copy. Once every node has done that, even though the blockchain still commits to that data, the data itself is unavailable, thus complying with the requirement to delete it. Essentially we now have a dangling pointer: there will be a digest in the chain, but the data that was hashed to produce the digest is no longer available. The blockchain is of course no longer able to be validated in the same way as before, but what you can validate is the fact that the deletion process was followed properly. E.g. you might have rules that state 2-of-3 senior admins have to use their signing keys to sign off on a deletion request. A similar example of this principle exists in Git: you can do a shallow checkout that doesn't contain all prior history. Recentish versions of Git handle this quite well: every operation will succeed if it doesn't happen to process the missing history. Similarly, if every git repo is in fact a shallow repo, with some history deleted, that data will gone. At the low level, this works because practically all blockchains make use of merkle trees. Rather than the hash of a block b_n being calculated as Hash(b_n), you instead have a header that commits to a merkle tree of data items. Thus you can still validate that the headers are connected without actually having all the data (extra credit problem: is this always a good thing?). 1) By "commit", we mean that the blockchain headers contains a hash digest of some other data; the headers are committed to the data they hashed, because if that data was changed the hash digest would change, rendering the headers invalid.

Klathmon 8y ago
I'd argue at that point it's not a "blockchain", since you are removing one of the major points for using the data structure (the ability to verify the chain without trust). If you are just going to rely on a central authority to say which blocks should be "ignored" (in other words, which hashes should just be trusted), then why use a blockchain at all? It's just a very slow, complicated, expensive append-only log file. The only benefit a blockchain provides (for the sake of this discussion) is it's ability for someone to verify it without trust from the genesis block all the way to the most current. You take that away, it's not a blockchain anymore.

s73v3r_ 8y ago

That makes this law a very, very, very good thing! Before this, you would have put out that blockchain without a second thought. Now, you're thinking about the consequences and ramifications of what might happen. And when you start thinking about those, and get others thinking about them, then you start thinking about solutions for them.