2 ms·

It's true in terms of historical chainsize growth rate as I use it in [1].

by tromp 3y ago

adastra22 3y ago
Are you assuming MW aggregation, and that’s how you’re amortizing CT cost?
- tromp 3y ago
  No, I'm just using the fact that in a Mimmblewimble blockchain, the initial block download doesn't include any data about spent outputs. Neither the outputs themselves nor their rangeproofs. That's the beauty of MW. You could call that historical aggregation, but normally when people talk about aggregation (as I assume you do) it refers to aggregating transactions before they're included in a block. In other CT blockchains, that data stays around forever, hurting scalability.
  - adastra22 3y ago
    Initial block download isn’t the bottleneck for scalability though. You can quite safely import a year-old utxo set, especially if there are utxo set commitments or if you already have access to a running node somewhere. In my experience when people talk about on-chain scalability, they mean transactions per second of real-time validation. Maybe I’m wrong but I don’t think anyone in this thread was talking about IBD / validation of historical data.
    - tromp 3y ago
      > Initial block download isn’t the bottleneck for scalability though. It is for full nodes (fully verifying nodes). They don't trust the UTXO set to be correct just because miners keep building on it. Huge chain size is exactly the reason why there are so few Ethereum full nodes (which takes weeks to sync), which makes it less decentralized.
      - adastra22 3y ago
        But even right now in bitcoin you can initialize a node with -assumeutxo to avoid IBD costs. You either get the UTXO set from a node you already control (and its turtles all the way down), or if bitcoin supported UTXO set commitments you simply pick a committed UTXO set from N blocks back, for some sufficiently large N. All block headers are downloaded, but full blocks back to the Nth block commitment are validated. While technically SPV, this ends up being exactly the same security model overall, since an attacker that can invent (say) a full year's worth of alternate history to fool you can already perform arbitrary double-spends on main net. In addition, although this is not required, for most of bitcoin's history the last year or two of mining represents almost all of the proof of work anyway, so someone who serve you a more-work forked off false chain with a false UTXO set commitment could have also rewritten the block chain since genesis. Bitcoin's security model already assumes this is not possible. So with UTXO set commitments (which bitcoin will eventually get in some form), you only need to IBD a few months worth of blocks, or maybe a year or so if you are truly paranoid.

It's true in terms of historical chainsize growth rate as I use it in [1].

by tromp 3y ago

It's true in terms of historical chainsize growth rate as I use it in [1].

adastra22 3y ago

Are you assuming MW aggregation, and that’s how you’re amortizing CT cost?

tromp 3y ago
No, I'm just using the fact that in a Mimmblewimble blockchain, the initial block download doesn't include any data about spent outputs. Neither the outputs themselves nor their rangeproofs. That's the beauty of MW. You could call that historical aggregation, but normally when people talk about aggregation (as I assume you do) it refers to aggregating transactions before they're included in a block. In other CT blockchains, that data stays around forever, hurting scalability.
- adastra22 3y ago
  Initial block download isn’t the bottleneck for scalability though. You can quite safely import a year-old utxo set, especially if there are utxo set commitments or if you already have access to a running node somewhere. In my experience when people talk about on-chain scalability, they mean transactions per second of real-time validation. Maybe I’m wrong but I don’t think anyone in this thread was talking about IBD / validation of historical data.
  - tromp 3y ago
    > Initial block download isn’t the bottleneck for scalability though. It is for full nodes (fully verifying nodes). They don't trust the UTXO set to be correct just because miners keep building on it. Huge chain size is exactly the reason why there are so few Ethereum full nodes (which takes weeks to sync), which makes it less decentralized.
    - adastra22 3y ago
      But even right now in bitcoin you can initialize a node with -assumeutxo to avoid IBD costs. You either get the UTXO set from a node you already control (and its turtles all the way down), or if bitcoin supported UTXO set commitments you simply pick a committed UTXO set from N blocks back, for some sufficiently large N. All block headers are downloaded, but full blocks back to the Nth block commitment are validated. While technically SPV, this ends up being exactly the same security model overall, since an attacker that can invent (say) a full year's worth of alternate history to fool you can already perform arbitrary double-spends on main net. In addition, although this is not required, for most of bitcoin's history the last year or two of mining represents almost all of the proof of work anyway, so someone who serve you a more-work forked off false chain with a false UTXO set commitment could have also rewritten the block chain since genesis. Bitcoin's security model already assumes this is not possible. So with UTXO set commitments (which bitcoin will eventually get in some form), you only need to IBD a few months worth of blocks, or maybe a year or so if you are truly paranoid.