5 ms·

I like the tech. I even paid for my coffee with the Lightning network in El Salvador and went to BTC Miami. The things I'm still not sure about are: 1. When wi

I like the tech. I even paid for my coffee with the Lightning network in El Salvador and went to BTC Miami. The things I'm still not sure about are: 1. When will the value become relatively stable? This flies in the face of the store of value argument. 2. How is Monero-like fungibility going to be added? Good cash needs to be fungible.

jacquesm 3y ago
As to '2' I don't think that can be done without losing some other desirable properties.
- tromp 3y ago
  You can significantly improve privacy without harming scalability (in fact improving scalability at the same time) [1]. Admittedly you still lose full supply auditability [2]. [1] https://forum.grin.mw/t/scalability-vs-privacy-chart https://forum.grin.mw/t/scalability-vs-privacy-chart [2] https://phyro.github.io/grinvestigation/why_grin.html https://phyro.github.io/grinvestigation/why_grin.html
  - adastra22 3y ago
    You know that’s not true, tromp. All CT approaches incur an intrinsic 10-30x validation cost and similar (though decreasing) witness cost.
    - 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.
adastra22 3y ago
Monero-like fungibility will never be added to bitcoin. The core devs are specifically against it.

jacquesm 3y ago

As to '2' I don't think that can be done without losing some other desirable properties.

tromp 3y ago
You can significantly improve privacy without harming scalability (in fact improving scalability at the same time) [1]. Admittedly you still lose full supply auditability [2]. [1] https://forum.grin.mw/t/scalability-vs-privacy-chart https://forum.grin.mw/t/scalability-vs-privacy-chart [2] https://phyro.github.io/grinvestigation/why_grin.html https://phyro.github.io/grinvestigation/why_grin.html
- adastra22 3y ago
  You know that’s not true, tromp. All CT approaches incur an intrinsic 10-30x validation cost and similar (though decreasing) witness cost.
  - 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.

adastra22 3y ago

Monero-like fungibility will never be added to bitcoin. The core devs are specifically against it.