18 ms·

This has some really questionable assumptions. Like the part about permanence. "An important property of a blockchain that users really value is permanence. A

by noxer 5y ago

This has some really questionable assumptions. Like the part about permanence. "An important property of a blockchain that users really value is permanence. A digital asset stored on a server will stop existing in 10 years when the company goes bankrupt or loses interest in maintaining that ecosystem. An NFT on Ethereum, on the other hand, is forever." This is wrong 2 times. First, there is no general requirement of permanent storage. Its not important at all. It solely depend on the use case. Thats why it is very much inefficient to use a DLT with that property to move value (btc/eth etc.). I dont care how my coins was moved 10 years ago. The only storage that is relevant for me, now, for value transfer is the current undisputed state (aka the balances). Sure the Tx history has use cases and people who need them should store them but making that a technical requirement is only going to degrade performance and drive up Tx cost. BTW cash does not have a recorded Tx history who thought "p2p cash" should? Its only because of the way BTC works (chain of all Tx) that this "believe" became common. Its technically not needed at all. There is absolutely no reason to recreate the whole chain to come to the current state. You either use the current state or you cant participate. If you would find an error in the chain whatcha gonna do about? Nothing. The current majority accepted state is all that matters. The "validation" is placebo it does nothing. And by running the exact same software as anyone else your validation would simply do the same error if there would be one. Second, the "forever" is a blatant lie. There is no way to know. Its will exist for however long at least someone is willing to store it. Exactly the same is true if storing is optional. But without the downside of crippling the performance and impose cost on the people running the DLT. The cost for storage should be paid by the user of the storage. If I can impose cost on all participants of a decentral system for all eternity with a one time payment then the system is deeply flawed. The possibility for abuse can be limited by simply making it expensive at any given time. But this obviously reduces the usefulness of the whole system especially for value transfer. The idea of an internet of value is to make value move like data, dirt cheap and decentral so no one takes a cut.

tromp 5y ago
> There is absolutely no reason to recreate the whole chain to come to the current state. You either use the current state or you cant participate. If you would find an error in the chain whatcha gonna do about? Nothing. The current majority accepted state is all that matters. All that matters is the valid history with the largest weight (longest chain rule in PoW). If an invalid branch somehow acquires more weight, it simply gets ignored (except by SPV clients in bitcoin, which trust others to validate). Exchanges/pools that accept an invalid branch are completely untrustworthy and should similarly be ignored.
- noxer 5y ago
  >All that matters is the valid history with the largest weight (longest chain rule in PoW). No, that exactly the believe that comes from BTCs implementation and while it may be true for BTC its completely irrelevant for other systems. Imagine there is a room full of people all have a paper with the exact same transactions in order on it. Now a new person joins and copies someones paper and then verifies all Tx. Ok, now he only has the chain for one person that's not enough he needs the chain form as much other people as possible to assure he has the longest. Its perfectly fine to ask the others to only tell him the hash of the whole thing to see if he has the same chain. So why even copy the chain first he could just start asking for the hash of the whole thing and if they all have the same there is no point to copy the chain. He just needs to copy the last state (balances) so he can add Tx as well. (BTC does not have accounts with balances so BTC does not have the concept of "only the last state" but instead of the whole chain only the ends of the tree can be used to reduce the size. but again this is ONLY relevant for BTC and BTC clones/forks its NOT a property of DLTs in general)
  - c01n 5y ago
    >So why even copy the chain first he could just start asking for the hash of the whole thing and if they all have the same there is no point to copy the chain. Well if I control enough nodes I can send you fake hashes (51% attack).
    - jimmydorry 5y ago
      51% is actually a different attack. The type of attack you are thinking of is called a Sybil Attack [1]. [1] https://en.wikipedia.org/wiki/Sybil_attack https://en.wikipedia.org/wiki/Sybil_attack
      - deleted 5y ago
        [deleted]
    - noxer 5y ago
      See other message. Listening to a nodes is voluntary and secret you dont know who or if at all anyone listens to your node. If you simply created a bunch you can be sure no one will listen to them. It doesn't matter how many % they make up.
samatman 5y ago
I agree with this, a durable record of every transaction ever performed is in fact an anti-feature for a digital ledger. Mimblewimble[0] is one interesting solution to this. Unfortunately, the requirement in current implementations (such as Grin) that both wallets be online to complete a transaction, eliminates some valuable types of transaction, such as sending coin to a cold wallet. I do think for a 'world computer' like Ethereum, being able to ignore a substantial amount of old state is going to be critical for long-term use. I also think that "blatant lie" is unnecessarily harsh. A blockchain is aspirationally forever, and it is a massively replicated data structure: it's certainly durable, and I would expect it to last a long time relative to, say, a random torrent. This is my major concern with the direction Ethereum is going, which I could caricature as "scale up massively and keep everything forever": it becomes so expensive to keep copies of all data, that only large institutional players will bother, and not many of them. This makes blockchain integrity a "take my word for it" kind of thing, and the whole system is only as durable as the increasingly-enormous data centers which hold all that information. [0]: https://scalingbitcoin.org/papers/mimblewimble.txt https://scalingbitcoin.org/papers/mimblewimble.txt
- noxer 5y ago
  The blockhcain may be "forever" but the history is definitely is not. Its a lie because the most likely outcome are that Ethereum dies because the history cripples it to an unusable system (its a lie then) or the the history dependency is removed so it can keep working (its a lie then as well because which part of the history is preserved is up to whoever does want to preserve it and no longer "guaranteed by the system") BTW history-sharding[1] isn't that complicated. If a DLT is build from the ground up with payment in mind and thus history is completely optional then you dont have to do any tech magic. But ofc this is not the case for Ethereum as it was not made for payment. [1]https://xrpl.org/history-sharding.html https://xrpl.org/history-sharding.html
  - CryptoPunk 5y ago
    State expiry/rent is being worked on in Ethereum, and would totally solve the problem of indefinite state size growth. This article, courtesy again of the hard-working Buterin, details the designs under consideration: https://hackmd.io/@vbuterin/state_expiry_paths https://hackmd.io/@vbuterin/state_expiry_paths
vvillena 5y ago
Blockchains don't have a concept of a "current undisputed state". If you managed to create a longer (and valid) Bitcoin chain on your own than the longest one there is at this very moment, and publish it, all other clients will start using it as the new longest chain. And if two equally long chains are published at about the same time, and clients get split, things will probably get resolved in the next block. So, most of the time, the current longest chain won't probably change, and if you discount, say, the 6 newest blocks (using bitcoin as an example), then it will definitely not change. So, the "undisputed state" and the "current state" are actually separate concepts in a PoW blockchain. Regarding storage, you argument that transactions shouldn't matter, since the important thing is the state. But then we're back to the fundamental problem. Why should we trust a state created from thin air that has no proof of how it was created? That's just a distributed database, which has is uses, but it's not a distributed blockchain.
- noxer 5y ago
  Don't assume blockchains are bitcoin or BTC like systems. I talk about the "current and undisputed or better indisputable (final) state". Bitcoin does not have this. Hence it can not function without history. This is a property of BTC not one of blockchains in general. Plenty other systems have a current state and a final state and there is no "better state" that can comer around and replace it. Final really means final. Its often called a closed ledger. Other systems have checkpoints and what not to reach a similar goal. BTCs "final" is just to wait some blocks its never final its just becomes incredibly unlikely to change the longer you wait. This is objectively worse than having a final state and on top of that it requires the history rather than just the last final state. >Why should we trust a state created from thin air that has no proof of how it was created? That's just a distributed database, which has is uses, but it's not a distributed blockchain. You have no choice. Either you agree with the current final state or you dont use the blockchain. Your choice is to use it or not. You choice is not to validate or not or validate and fix something if its wrong. The act of validating doesn't do anything. No matter what your validating gives you in the end you can only accept the current final state of the running network or not use it at all. Also its not created out of thin air. It was validated by the code. If there is a mistake it is there because of the code people used back when it happened. If you were there running your node it would have made the same mistake. whats the point to find it now? (beside the fact that it was already found and fixed) It doesn't change the state the state is final. Bugs happen. If you assume cheating however then well you should assume someone would have screamed back when it happens so you would already know that someone cheated somehow. Whats the point of validating it? you already know you dont want to use that chain. Zero reason to detect the cheating yourself. We know pretty well from all incidents where blockchains had to be "fixed" there is no way someone would find an unknown incident by the placebo validation act.
c01n 5y ago
Imagine a peer goes offline and stuff happens on the network while its offline, when the peer goes back online what state does it follow, remember that it is a decentralized network what peer does it trust? This is where the chain of verifiable transactions come in. Also with this setup it is kind of easy to prevent double spending. > BTW cash does not have a recorded Tx history Sorta... The central banks know every coin that has been created and notes that have been printed. When you fill in your Tax forms you are creating this Tx history manually.
- noxer 5y ago
  Not a problem if its a DLT with final state. You just need to request the hash of the final state from enough nodes to assure its the real deal. They would all need to lie the same way to trick you. If they are all compromised then the system is rendered useless anyway. Also basic properties like the total amount of tokens can be validated on the last state alone. You can assure no one added more tokens simply by summing all balances. You dont need any history data for that. >Sorta... The central banks know every coin that has been created and notes that have been printed. When you fill in your Tax forms you are creating this Tx history manually. Yeah no, you are moving and stretching the goal post to far here. Notes are unique but that's not a Tx history at all and neither is a Tax form.
  - deleted 5y ago
    [deleted]
- tsimionescu 5y ago
  So you put the series numbers of each bank note on your tax forms? That must take a pretty long time...
vbuterin 5y ago
When I talk to people in the world about what about blockchains they find exciting, the aspect of permanence really is one of the things that people find attractive. I agree it's use-case dependent, but the problem is that once you go down the use-case-dependence rabbit hole, developers and users have to really think "am I creating something permanent or not"? And once you have to think even a little bit, you lose 50%+ of the magic. Having properties that you just get by default that you don't even have to think to obtain is quite important. The good news though is that you don't need permanent storage of history to be supported by the base protocol itself. Consensus nodes don't need to know about history to verify the current chain. There are plenty of other mechanisms for storing historical data: bittorrent, centralized archives, Filecoin-style networks, etc etc. You just need the blockchain's throughput to be not _too_ high, so that it's actually possible for these protocols to store what comes out. Definitely nothing is permanent, but you can get pretty close to "permanent unless civilization collapses", and that's much better than "data could drop at any time if a few people just forget"!
- stickfigure 5y ago
  > Definitely nothing is permanent, but you can get pretty close to "permanent unless civilization collapses" Let's be honest here and acknowledge that we're talking about "permanent unless your particular fork of one particular blockchain collapses". There's a vast chasm between that and all of civilization.
  - dannyw 5y ago
    I disagree. If bitcoin or ethereum gets completely killed today, I'm confident you'll still be able to download the chain in four decades (assuming civilisation still exists) out of pure history and data hoarding.
    - meowface 5y ago
      Right. The "value" / perceived value won't be permanent (and may be very subjective and disputed from the start), but in terms of long-term data integrity and availability, blockchains can be useful. An NFT ownership transfer that occurred in 2020 on some blockchain may not be considered too valuable in a hypothetical 2040 world where almost no one is using that (or perhaps any) blockchain anymore, but you can likely at least retrieve that record and be pretty sure the data is accurate and wasn't tampered with. So a (at-one-point reasonably popular) blockchain or protocol forking or falling out of use won't actually result in that data being lost to time. You'd probably need a major worldwide catastrophe for there to be a significant risk of that.
noobly 5y ago
>I dont care how my coins was moved 10 years ago. The only storage that is relevant for me, now, for value transfer is the current undisputed state I don't have anything to add, but this has always struck me as inelegant, especially for Ethereum, which is more of a dApp platform. Can someone point me towards something that can run dApps and maintain current state with distributed consensus _without_ a blockchain (or explain why this is an ignorant question)? Also, what's wrong with truncating the chain after X blocks?
- dlubarov 5y ago
  > Also, what's wrong with truncating the chain after X blocks? I would say nothing. Truncating history isn't explicitly built into the protocol, but that's what most users do in practice. I believe Geth and Parity both prune old state by default. There are "achive" nodes that store all history, but they're in the minority. Bitcoin Core also has options for pruning old state, and for disabling some validation of old history. Though, unfortunately, it will still download blocks from the genesis even if both options are enabled.
  - dannyw 5y ago
    That's more of a philosophical decision. Even if you don't want old blocks, someone else might want. As part of your expected obligations of the network, you're asked to seed those blocks.
- antender 5y ago
  You mean something like Hyperdrive (formerly Dat) + Beaker browser?
RhodoGSA 5y ago
what you're describing is simply a litenode vs a full node. You seem to be nitpicking the 'vision' of crypto in general, which you're right, is a very human thing.

by noxer 5y ago

tromp 5y ago

> There is absolutely no reason to recreate the whole chain to come to the current state. You either use the current state or you cant participate. If you would find an error in the chain whatcha gonna do about? Nothing. The current majority accepted state is all that matters. All that matters is the valid history with the largest weight (longest chain rule in PoW). If an invalid branch somehow acquires more weight, it simply gets ignored (except by SPV clients in bitcoin, which trust others to validate). Exchanges/pools that accept an invalid branch are completely untrustworthy and should similarly be ignored.

noxer 5y ago
>All that matters is the valid history with the largest weight (longest chain rule in PoW). No, that exactly the believe that comes from BTCs implementation and while it may be true for BTC its completely irrelevant for other systems. Imagine there is a room full of people all have a paper with the exact same transactions in order on it. Now a new person joins and copies someones paper and then verifies all Tx. Ok, now he only has the chain for one person that's not enough he needs the chain form as much other people as possible to assure he has the longest. Its perfectly fine to ask the others to only tell him the hash of the whole thing to see if he has the same chain. So why even copy the chain first he could just start asking for the hash of the whole thing and if they all have the same there is no point to copy the chain. He just needs to copy the last state (balances) so he can add Tx as well. (BTC does not have accounts with balances so BTC does not have the concept of "only the last state" but instead of the whole chain only the ends of the tree can be used to reduce the size. but again this is ONLY relevant for BTC and BTC clones/forks its NOT a property of DLTs in general)
- c01n 5y ago
  >So why even copy the chain first he could just start asking for the hash of the whole thing and if they all have the same there is no point to copy the chain. Well if I control enough nodes I can send you fake hashes (51% attack).
  - jimmydorry 5y ago
    51% is actually a different attack. The type of attack you are thinking of is called a Sybil Attack [1]. [1] https://en.wikipedia.org/wiki/Sybil_attack https://en.wikipedia.org/wiki/Sybil_attack
    - deleted 5y ago
      [deleted]
  - noxer 5y ago
    See other message. Listening to a nodes is voluntary and secret you dont know who or if at all anyone listens to your node. If you simply created a bunch you can be sure no one will listen to them. It doesn't matter how many % they make up.

samatman 5y ago

I agree with this, a durable record of every transaction ever performed is in fact an anti-feature for a digital ledger. Mimblewimble[0] is one interesting solution to this. Unfortunately, the requirement in current implementations (such as Grin) that both wallets be online to complete a transaction, eliminates some valuable types of transaction, such as sending coin to a cold wallet. I do think for a 'world computer' like Ethereum, being able to ignore a substantial amount of old state is going to be critical for long-term use. I also think that "blatant lie" is unnecessarily harsh. A blockchain is aspirationally forever, and it is a massively replicated data structure: it's certainly durable, and I would expect it to last a long time relative to, say, a random torrent. This is my major concern with the direction Ethereum is going, which I could caricature as "scale up massively and keep everything forever": it becomes so expensive to keep copies of all data, that only large institutional players will bother, and not many of them. This makes blockchain integrity a "take my word for it" kind of thing, and the whole system is only as durable as the increasingly-enormous data centers which hold all that information. [0]: https://scalingbitcoin.org/papers/mimblewimble.txt https://scalingbitcoin.org/papers/mimblewimble.txt

noxer 5y ago
The blockhcain may be "forever" but the history is definitely is not. Its a lie because the most likely outcome are that Ethereum dies because the history cripples it to an unusable system (its a lie then) or the the history dependency is removed so it can keep working (its a lie then as well because which part of the history is preserved is up to whoever does want to preserve it and no longer "guaranteed by the system") BTW history-sharding[1] isn't that complicated. If a DLT is build from the ground up with payment in mind and thus history is completely optional then you dont have to do any tech magic. But ofc this is not the case for Ethereum as it was not made for payment. [1]https://xrpl.org/history-sharding.html https://xrpl.org/history-sharding.html
- CryptoPunk 5y ago
  State expiry/rent is being worked on in Ethereum, and would totally solve the problem of indefinite state size growth. This article, courtesy again of the hard-working Buterin, details the designs under consideration: https://hackmd.io/@vbuterin/state_expiry_paths https://hackmd.io/@vbuterin/state_expiry_paths

vvillena 5y ago

Blockchains don't have a concept of a "current undisputed state". If you managed to create a longer (and valid) Bitcoin chain on your own than the longest one there is at this very moment, and publish it, all other clients will start using it as the new longest chain. And if two equally long chains are published at about the same time, and clients get split, things will probably get resolved in the next block. So, most of the time, the current longest chain won't probably change, and if you discount, say, the 6 newest blocks (using bitcoin as an example), then it will definitely not change. So, the "undisputed state" and the "current state" are actually separate concepts in a PoW blockchain. Regarding storage, you argument that transactions shouldn't matter, since the important thing is the state. But then we're back to the fundamental problem. Why should we trust a state created from thin air that has no proof of how it was created? That's just a distributed database, which has is uses, but it's not a distributed blockchain.

noxer 5y ago
Don't assume blockchains are bitcoin or BTC like systems. I talk about the "current and undisputed or better indisputable (final) state". Bitcoin does not have this. Hence it can not function without history. This is a property of BTC not one of blockchains in general. Plenty other systems have a current state and a final state and there is no "better state" that can comer around and replace it. Final really means final. Its often called a closed ledger. Other systems have checkpoints and what not to reach a similar goal. BTCs "final" is just to wait some blocks its never final its just becomes incredibly unlikely to change the longer you wait. This is objectively worse than having a final state and on top of that it requires the history rather than just the last final state. >Why should we trust a state created from thin air that has no proof of how it was created? That's just a distributed database, which has is uses, but it's not a distributed blockchain. You have no choice. Either you agree with the current final state or you dont use the blockchain. Your choice is to use it or not. You choice is not to validate or not or validate and fix something if its wrong. The act of validating doesn't do anything. No matter what your validating gives you in the end you can only accept the current final state of the running network or not use it at all. Also its not created out of thin air. It was validated by the code. If there is a mistake it is there because of the code people used back when it happened. If you were there running your node it would have made the same mistake. whats the point to find it now? (beside the fact that it was already found and fixed) It doesn't change the state the state is final. Bugs happen. If you assume cheating however then well you should assume someone would have screamed back when it happens so you would already know that someone cheated somehow. Whats the point of validating it? you already know you dont want to use that chain. Zero reason to detect the cheating yourself. We know pretty well from all incidents where blockchains had to be "fixed" there is no way someone would find an unknown incident by the placebo validation act.

c01n 5y ago

Imagine a peer goes offline and stuff happens on the network while its offline, when the peer goes back online what state does it follow, remember that it is a decentralized network what peer does it trust? This is where the chain of verifiable transactions come in. Also with this setup it is kind of easy to prevent double spending. > BTW cash does not have a recorded Tx history Sorta... The central banks know every coin that has been created and notes that have been printed. When you fill in your Tax forms you are creating this Tx history manually.

noxer 5y ago
Not a problem if its a DLT with final state. You just need to request the hash of the final state from enough nodes to assure its the real deal. They would all need to lie the same way to trick you. If they are all compromised then the system is rendered useless anyway. Also basic properties like the total amount of tokens can be validated on the last state alone. You can assure no one added more tokens simply by summing all balances. You dont need any history data for that. >Sorta... The central banks know every coin that has been created and notes that have been printed. When you fill in your Tax forms you are creating this Tx history manually. Yeah no, you are moving and stretching the goal post to far here. Notes are unique but that's not a Tx history at all and neither is a Tax form.
- deleted 5y ago
  [deleted]
tsimionescu 5y ago
So you put the series numbers of each bank note on your tax forms? That must take a pretty long time...

vbuterin 5y ago

When I talk to people in the world about what about blockchains they find exciting, the aspect of permanence really is one of the things that people find attractive. I agree it's use-case dependent, but the problem is that once you go down the use-case-dependence rabbit hole, developers and users have to really think "am I creating something permanent or not"? And once you have to think even a little bit, you lose 50%+ of the magic. Having properties that you just get by default that you don't even have to think to obtain is quite important. The good news though is that you don't need permanent storage of history to be supported by the base protocol itself. Consensus nodes don't need to know about history to verify the current chain. There are plenty of other mechanisms for storing historical data: bittorrent, centralized archives, Filecoin-style networks, etc etc. You just need the blockchain's throughput to be not _too_ high, so that it's actually possible for these protocols to store what comes out. Definitely nothing is permanent, but you can get pretty close to "permanent unless civilization collapses", and that's much better than "data could drop at any time if a few people just forget"!

stickfigure 5y ago
> Definitely nothing is permanent, but you can get pretty close to "permanent unless civilization collapses" Let's be honest here and acknowledge that we're talking about "permanent unless your particular fork of one particular blockchain collapses". There's a vast chasm between that and all of civilization.
- dannyw 5y ago
  I disagree. If bitcoin or ethereum gets completely killed today, I'm confident you'll still be able to download the chain in four decades (assuming civilisation still exists) out of pure history and data hoarding.
  - meowface 5y ago
    Right. The "value" / perceived value won't be permanent (and may be very subjective and disputed from the start), but in terms of long-term data integrity and availability, blockchains can be useful. An NFT ownership transfer that occurred in 2020 on some blockchain may not be considered too valuable in a hypothetical 2040 world where almost no one is using that (or perhaps any) blockchain anymore, but you can likely at least retrieve that record and be pretty sure the data is accurate and wasn't tampered with. So a (at-one-point reasonably popular) blockchain or protocol forking or falling out of use won't actually result in that data being lost to time. You'd probably need a major worldwide catastrophe for there to be a significant risk of that.

noobly 5y ago

>I dont care how my coins was moved 10 years ago. The only storage that is relevant for me, now, for value transfer is the current undisputed state I don't have anything to add, but this has always struck me as inelegant, especially for Ethereum, which is more of a dApp platform. Can someone point me towards something that can run dApps and maintain current state with distributed consensus _without_ a blockchain (or explain why this is an ignorant question)? Also, what's wrong with truncating the chain after X blocks?

dlubarov 5y ago
> Also, what's wrong with truncating the chain after X blocks? I would say nothing. Truncating history isn't explicitly built into the protocol, but that's what most users do in practice. I believe Geth and Parity both prune old state by default. There are "achive" nodes that store all history, but they're in the minority. Bitcoin Core also has options for pruning old state, and for disabling some validation of old history. Though, unfortunately, it will still download blocks from the genesis even if both options are enabled.
- dannyw 5y ago
  That's more of a philosophical decision. Even if you don't want old blocks, someone else might want. As part of your expected obligations of the network, you're asked to seed those blocks.
antender 5y ago
You mean something like Hyperdrive (formerly Dat) + Beaker browser?

RhodoGSA 5y ago

what you're describing is simply a litenode vs a full node. You seem to be nitpicking the 'vision' of crypto in general, which you're right, is a very human thing.