11 ms·

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 - imp

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 4y ago
That’s true only if you care about storing historical data
- laverya 4y 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 4y 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.
  - baby 4y ago
    I do. Check out Mina. It uses recursive zero knowledge proofs to give you a proof of all state transitions since genesis.
    - baby 4y ago
      For the curious: https://minaprotocol.com/ https://minaprotocol.com/
      - laverya 4y ago
        A 22kb fixed size reads like transparent bullshit to me. Fundamentally you cannot store infinite information within such a block, and "participant X has the right to send Y amount" is information. To me this implies that either there is a limit to the number of participants, that there is information stored off-chain, or that there will be data loss over time - possibly all three. And the fact that you've mentioned one cryptocurrency to fix the transaction rate issue, and another to fix the blockchain size issue, but not one to fix both issues at the same time, has not escaped me.
        baby 4y ago
        It's funny how people keep moving the goal post :) read more about it instead of spending 5min on a page and finding negative things to say about it. If you want to hate on the technology for the sake of hating it then you won't go far in life
        laverya 4y ago
        If it takes more than 5 minutes to even mention how you're sidestepping some very basic information theory concepts, then it's probably a scam. And speaking of moving the goalposts... You recommended Sui as a blockchain with "basically unlimited transactions per second", and then recommended Mina when I commented about chain sizes. It sure seems like you have a mutually-exclusive blockchain for each set of goalposts to me.

baby 4y ago

That’s true only if you care about storing historical data

laverya 4y 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 4y 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.
- baby 4y ago
  I do. Check out Mina. It uses recursive zero knowledge proofs to give you a proof of all state transitions since genesis.
  - baby 4y ago
    For the curious: https://minaprotocol.com/ https://minaprotocol.com/
    - laverya 4y ago
      A 22kb fixed size reads like transparent bullshit to me. Fundamentally you cannot store infinite information within such a block, and "participant X has the right to send Y amount" is information. To me this implies that either there is a limit to the number of participants, that there is information stored off-chain, or that there will be data loss over time - possibly all three. And the fact that you've mentioned one cryptocurrency to fix the transaction rate issue, and another to fix the blockchain size issue, but not one to fix both issues at the same time, has not escaped me.
      - baby 4y ago
        It's funny how people keep moving the goal post :) read more about it instead of spending 5min on a page and finding negative things to say about it. If you want to hate on the technology for the sake of hating it then you won't go far in life
        laverya 4y ago
        If it takes more than 5 minutes to even mention how you're sidestepping some very basic information theory concepts, then it's probably a scam. And speaking of moving the goalposts... You recommended Sui as a blockchain with "basically unlimited transactions per second", and then recommended Mina when I commented about chain sizes. It sure seems like you have a mutually-exclusive blockchain for each set of goalposts to me.