5 ms·

> The sole purpose of blockchain is to prevent double spending without a trusted party. Yes, and avoiding the trusted party makes it more inefficient by a fact

by FabHK 5y ago

> The sole purpose of blockchain is to prevent double spending without a trusted party. Yes, and avoiding the trusted party makes it more inefficient by a factor of around 100,000,000 (-ish), if you consider that BTC uses around 23 GW and can do no more (5 transactions a second) than a single trusted PC could do. What are use cases were you actually need this and the high cost is worth it?

paulsutter 5y ago
The power is used to secure the system, not to perform transactions. The transaction rate has always been the same, the power use has gone up with the value of the contents (to resist a 51% attack) Some people feel strongly this security is worth it. Some feel strongly that it isn’t (but one suspects their objection is really to the lack of central control)
- 2muchcoffeeman 5y ago
  Climate change may be the problem that defines our generation. In that light, and given the ludicrous power estimates that blockchains use, are we not morally obligated to kill all the blockchain projects if these estimates are in the right ballpark?
  - lostmsu 5y ago
    Only if you believe climate change defines this generation.
  - Tenoke 5y ago
    At most we might be obliged to kill the worst (and a lot of other non-crypto things) but killing all makes no sense when there's many with fairly neglible impact.
    - woodruffw 5y ago
      Nature abhors a vacuum: if you kill the most popular PoW scheme, the little ones will dutifully step up and use just as much power. I don’t think there’s any world we can live in where PoW schemes will have “negligible impact,” which only heartens the justification for banning all of them, now.
- FabHK 5y ago
  To the extent that blocks are assembled and validated not by one node (which is all that would be necessary), but by (tens? hundreds? of) thousands, there is massive duplication of the actual work by a factor of 1e4 or 1e5 or more. But, you are right, even that enormous inefficiency is peanuts compared to the Proof of Waste, which ramps it up to unimaginable proportions. (A single BTC transaction uses up as much electricity as a 2 person household in Germany in a year, and produces 2 iPhones worth of electronic waste.)
  - paulsutter 5y ago
    The transactions don’t use the power, the power is used to protect the contents of the chain (sorry i intended this as a reply to a different comment, not yours, not sure how i did that!)
    - FabHK 5y ago
      We agree. Around 0.000001% of the power is used for transactions, which is way more than necessary due to duplication, and 99.999999% for "protection".
      - FabHK 5y ago
        I might have been a bit too eager with the 0's and 9's, might be able to cut half of them.
- tromp 5y ago
  > The power is used to secure the system, not to perform transactions. This looks to be the case now, with block reward being dominated by the block subsidy. But by design, the latter reduces exponentially over time, so that within a few decades, the security will have to come predominantly from transaction fees.
reeeeeeee 5y ago
Cardano is a cryptocurrency that offers ~250 transactions per second but should soon scale without a layer 2 solution. I mention this as I run a validator on a 8gb raspberry pi with ZRAM swap enabled with no issues consuming ~5W the whole network could run this way if needed. This is lower power due to a mechanism called proof of stake. BTC uses proof of work. Ethereum has been 'trying' to migrate to POS for some time. As for layer 2's this could partly be the solution to some high costs. But risks sacrificing decentralization.
- tigershark 5y ago
  Proof of stake is useless. It just give all the powers to the current stakeholders. So it’s not trustless by definition since you need to trust the stakeholders.
  - tromp 5y ago
    Well, PoW needs to assume that 51% of miners is honest, while PoS needs to assume that 51% of stakers is honest. The bigger downsides of PoS to me are that 1) a pure PoS system starts with the creators holding all supply and can keep an arbitrary portion for themselves while selling the rest as they please 2) the truth in PoS is subjective (nodes need to rely on other nodes to determine what is the current state of the system).
    - akrymski 5y ago
      In PoS systems validators can vote for both chains in case of a fork, as there is nothing at stake. It's not about honesty. It's about resources being committed.
      - FabHK 5y ago
        Exactly. The ETH PoS FAQ is a good introduction to the problem. In a nutshell, when there are two competing chains, A) in PoW you A1) either put all your resources (hash power) behind one chain, and get the block, thus the mining reward, with probability equal to your proportion of the total hash power (as before) assuming that chain ends up the longest chain (so you have a strong incentive to pick the "correct" one), or A2) distribute your hash power between the two competing chains, but then each of them only gets half the hash power, and you reduce your probability of getting the mining reward to half, thus halving your expected reward. At any rate, as soon as one of the chains is ahead, there is a very strong incentive to fall in line with the LCR (longest chain rule) and place all your bets on the putative winner, rather than diluting your expensive hash power. B) In PoS, you can just continue staking on both competing chains, and whichever wins, you got get your mining reward (as usual, with probability equal to your proportion of the total stake). No incentive to settle on a winner early ("nothing at stake"), so just keep your options open by supporting both chains, and thus no incentive to congeal on a winner quickly. https://eth.wiki/en/concepts/proof-of-stake-faqs https://eth.wiki/en/concepts/proof-of-stake-faqs
baby 5y ago
Why use bitcoin, the slowest blockchain and most inefficient blockchain, as an example? Blockchains like Sui offer basically unlimited transactions/s
- laverya 5y ago
  Fundamentally the transaction rate is limited by how much data you're willing to store. Bitcoin's 5tx/sec translates to ~5gb/month added to the blockchain - improving upon this requires either making the data stored per transaction smaller, increasing the blockchain growth rate, or moving transactions off-chain.
  - baby 5y ago
    That’s true only if you care about storing historical data
    - laverya 5y ago
      When the balance of every address can only be calculated by executing the total transaction graph, as in Bitcoin, then you need to store the history. If you have a solution for this that does not require trusting anyone, I'm sure that people would love to hear it.
      - noxer 5y ago
        Longs long solved problem. You only need to store the last state of the ledger and the chain of hashes that lead there to validate that any give block actually did happen. If you dont care about validating past block you dont even need the chain of hashes but just the last state. Instead of huge transaction chains to get to the balance people use snapshots where they basically sum up everything in the past to a give point in time and add new transaction from there on. More "modern" systems like the XRPL or ETH directly use accounts with balances. If you have the last state so all accounts and all balances you can move (subtract from one and add to the other) you dont have to sum past transaction to know if someone actually has a balance to move. You can also easily sum all balances which must give the total (if the supply is fixed). >"If you have a solution for this that does not require trusting anyone...." You do not need to trust anyone you need to trust EVERYONE at one point in time exactly when you want to join and use the system. If you decide to use for example the XRPL today maybe even run a node and validate transaction yourself, then at the time "now()" the last state that everyone else agrees on that is what you need to "trust" or rather accept. You need to accept that to this date the people who ran it before you didn't never collude to "fix" or manipulate the ledger state of the past. If you think they colluded in the past and the current state is not how it should be then the system is useless to you. It doesn't matter if you can point to the exact event in some historical data. And you dont need the historical data to know such an event happen because it obviously would be hugely controversial and well documented outside of the transaction history (probably would result in a fork etc. so you could pick the chain you agree on). If you are worried about a mistake in the past that no one even noticed then that is not a problem since by definition the code everyone runs is the rules. A bug is a bug in the rules and if everyone agrees on the current state it doesn't matter that something went wrong somewhere in the past, its only important that the current state is agreed on. If you assume the past is immutable then a past bug has no effect on the future function of the system (Exception ofc is when the past was changed then you need to assume that people collude again to do it again). People think the past is immutable if we have it recorded but actual it is immutable if there is agreement on the current states finality. Think of the whole system like a closed room with people who together hold a fix number of coins. Once everyone knows the balance of everyone and there is no dispute on the balances everyone can transact with everyone. There is zero need to know the past transactions that took place. If someone has 5 coins he can give you 3 and everyone sees that he now has 2 and you 3 more. If a new person enters the room he must have zero coins else the total increased. He can then instantly accept coins from anyone once he know the current undisputed balances of everyone. Again he does not need to know from whom you got your coins just that everyone agrees that you own them.

by FabHK 5y ago

paulsutter 5y ago

The power is used to secure the system, not to perform transactions. The transaction rate has always been the same, the power use has gone up with the value of the contents (to resist a 51% attack) Some people feel strongly this security is worth it. Some feel strongly that it isn’t (but one suspects their objection is really to the lack of central control)

2muchcoffeeman 5y ago
Climate change may be the problem that defines our generation. In that light, and given the ludicrous power estimates that blockchains use, are we not morally obligated to kill all the blockchain projects if these estimates are in the right ballpark?
- lostmsu 5y ago
  Only if you believe climate change defines this generation.
- Tenoke 5y ago
  At most we might be obliged to kill the worst (and a lot of other non-crypto things) but killing all makes no sense when there's many with fairly neglible impact.
  - woodruffw 5y ago
    Nature abhors a vacuum: if you kill the most popular PoW scheme, the little ones will dutifully step up and use just as much power. I don’t think there’s any world we can live in where PoW schemes will have “negligible impact,” which only heartens the justification for banning all of them, now.
FabHK 5y ago
To the extent that blocks are assembled and validated not by one node (which is all that would be necessary), but by (tens? hundreds? of) thousands, there is massive duplication of the actual work by a factor of 1e4 or 1e5 or more. But, you are right, even that enormous inefficiency is peanuts compared to the Proof of Waste, which ramps it up to unimaginable proportions. (A single BTC transaction uses up as much electricity as a 2 person household in Germany in a year, and produces 2 iPhones worth of electronic waste.)
- paulsutter 5y ago
  The transactions don’t use the power, the power is used to protect the contents of the chain (sorry i intended this as a reply to a different comment, not yours, not sure how i did that!)
  - FabHK 5y ago
    We agree. Around 0.000001% of the power is used for transactions, which is way more than necessary due to duplication, and 99.999999% for "protection".
    - FabHK 5y ago
      I might have been a bit too eager with the 0's and 9's, might be able to cut half of them.
tromp 5y ago
> The power is used to secure the system, not to perform transactions. This looks to be the case now, with block reward being dominated by the block subsidy. But by design, the latter reduces exponentially over time, so that within a few decades, the security will have to come predominantly from transaction fees.

reeeeeeee 5y ago

Cardano is a cryptocurrency that offers ~250 transactions per second but should soon scale without a layer 2 solution. I mention this as I run a validator on a 8gb raspberry pi with ZRAM swap enabled with no issues consuming ~5W the whole network could run this way if needed. This is lower power due to a mechanism called proof of stake. BTC uses proof of work. Ethereum has been 'trying' to migrate to POS for some time. As for layer 2's this could partly be the solution to some high costs. But risks sacrificing decentralization.

tigershark 5y ago
Proof of stake is useless. It just give all the powers to the current stakeholders. So it’s not trustless by definition since you need to trust the stakeholders.
- tromp 5y ago
  Well, PoW needs to assume that 51% of miners is honest, while PoS needs to assume that 51% of stakers is honest. The bigger downsides of PoS to me are that 1) a pure PoS system starts with the creators holding all supply and can keep an arbitrary portion for themselves while selling the rest as they please 2) the truth in PoS is subjective (nodes need to rely on other nodes to determine what is the current state of the system).
  - akrymski 5y ago
    In PoS systems validators can vote for both chains in case of a fork, as there is nothing at stake. It's not about honesty. It's about resources being committed.
    - FabHK 5y ago
      Exactly. The ETH PoS FAQ is a good introduction to the problem. In a nutshell, when there are two competing chains, A) in PoW you A1) either put all your resources (hash power) behind one chain, and get the block, thus the mining reward, with probability equal to your proportion of the total hash power (as before) assuming that chain ends up the longest chain (so you have a strong incentive to pick the "correct" one), or A2) distribute your hash power between the two competing chains, but then each of them only gets half the hash power, and you reduce your probability of getting the mining reward to half, thus halving your expected reward. At any rate, as soon as one of the chains is ahead, there is a very strong incentive to fall in line with the LCR (longest chain rule) and place all your bets on the putative winner, rather than diluting your expensive hash power. B) In PoS, you can just continue staking on both competing chains, and whichever wins, you got get your mining reward (as usual, with probability equal to your proportion of the total stake). No incentive to settle on a winner early ("nothing at stake"), so just keep your options open by supporting both chains, and thus no incentive to congeal on a winner quickly. https://eth.wiki/en/concepts/proof-of-stake-faqs https://eth.wiki/en/concepts/proof-of-stake-faqs

baby 5y ago

Why use bitcoin, the slowest blockchain and most inefficient blockchain, as an example? Blockchains like Sui offer basically unlimited transactions/s

laverya 5y ago
Fundamentally the transaction rate is limited by how much data you're willing to store. Bitcoin's 5tx/sec translates to ~5gb/month added to the blockchain - improving upon this requires either making the data stored per transaction smaller, increasing the blockchain growth rate, or moving transactions off-chain.
- baby 5y ago
  That’s true only if you care about storing historical data
  - laverya 5y ago
    When the balance of every address can only be calculated by executing the total transaction graph, as in Bitcoin, then you need to store the history. If you have a solution for this that does not require trusting anyone, I'm sure that people would love to hear it.
    - noxer 5y ago
      Longs long solved problem. You only need to store the last state of the ledger and the chain of hashes that lead there to validate that any give block actually did happen. If you dont care about validating past block you dont even need the chain of hashes but just the last state. Instead of huge transaction chains to get to the balance people use snapshots where they basically sum up everything in the past to a give point in time and add new transaction from there on. More "modern" systems like the XRPL or ETH directly use accounts with balances. If you have the last state so all accounts and all balances you can move (subtract from one and add to the other) you dont have to sum past transaction to know if someone actually has a balance to move. You can also easily sum all balances which must give the total (if the supply is fixed). >"If you have a solution for this that does not require trusting anyone...." You do not need to trust anyone you need to trust EVERYONE at one point in time exactly when you want to join and use the system. If you decide to use for example the XRPL today maybe even run a node and validate transaction yourself, then at the time "now()" the last state that everyone else agrees on that is what you need to "trust" or rather accept. You need to accept that to this date the people who ran it before you didn't never collude to "fix" or manipulate the ledger state of the past. If you think they colluded in the past and the current state is not how it should be then the system is useless to you. It doesn't matter if you can point to the exact event in some historical data. And you dont need the historical data to know such an event happen because it obviously would be hugely controversial and well documented outside of the transaction history (probably would result in a fork etc. so you could pick the chain you agree on). If you are worried about a mistake in the past that no one even noticed then that is not a problem since by definition the code everyone runs is the rules. A bug is a bug in the rules and if everyone agrees on the current state it doesn't matter that something went wrong somewhere in the past, its only important that the current state is agreed on. If you assume the past is immutable then a past bug has no effect on the future function of the system (Exception ofc is when the past was changed then you need to assume that people collude again to do it again). People think the past is immutable if we have it recorded but actual it is immutable if there is agreement on the current states finality. Think of the whole system like a closed room with people who together hold a fix number of coins. Once everyone knows the balance of everyone and there is no dispute on the balances everyone can transact with everyone. There is zero need to know the past transactions that took place. If someone has 5 coins he can give you 3 and everyone sees that he now has 2 and you 3 more. If a new person enters the room he must have zero coins else the total increased. He can then instantly accept coins from anyone once he know the current undisputed balances of everyone. Again he does not need to know from whom you got your coins just that everyone agrees that you own them.