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

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

[2] https://phyro.github.io/grinvestigation/why_grin.html

You know that’s not true, tromp. All CT approaches incur an intrinsic 10-30x validation cost and similar (though decreasing) witness cost.

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

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

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.

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.

> 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 makes it less decentralized.

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.

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