Thinking back to Taproot, that was a big deal for privacy and scripting, but what’s on the horizon? Are you guys thinking that soft forks like Ark or Layer 2 solutions such as Fedimint and improvements to Lightning could be the way forward, or should we just keep Bitcoin's upgrades on the conservative side?
IMO privacy offered by Taproot isn't that big, since the actual privacy improvement mostly are about,
1. Not reveal part of script path that isn't used to spend the UTXO.
2. It's Schnorr Signature (usually for multi-sig) aggregate multiple signature, where individual key isn't revealed.
Ark generally categorized as Layer 2 rather than part of Bitcoin protocol that require soft-fork to be activated. And in strict definition, both Fedimint and LN aren't part of Bitcoin protocol/network.
Open up new doors? No they should stay and remain on layer two.
There's a reason they are been run at layer two and that's because there's always a sacrifice.
I believe it should be Simple and Money like
Organic upgrades not half assed rushed for the sake of upgrading.
I'm "shipping" for two major upgrades:
1) Covenants. Basically that means that you can set up conditions for payments. While that is already possible to some extent, once the person you paid the coins to has "unlocked" them with their private key, they can do what they want with them. In some cases however you would like to put a condition one step further, i.e. that the person you paid has also to follow some rules to spend the coins. An example: They must spend them to a certain group of addresses.
Some sidechains, Lightning and also Ark would enormously benefit from this feature. Some people will now yell "Bitcoin isn't Ethereum!!!". But covenants would still not enable infinite loops like Ethereum does, and if we had better L2s, then the scalability problem would have been practically solved and Bitcoin is finally really ready for global mass adoption.
An explanation from Bitcoin Magazine:
There are several proposed mechanisms which can be seen here in this wiki page with support from developers.
2) Utreexo. Storing the UTXO set in a different way, instead of all UTXOs being stored fully, only an "accumulator" composed of hashes is stored. This would lower the burden on full nodes, above all if we consider the bloat of the UTXO set due to protocols like Ordinals and Stampchain which create a lot of unspendable or dust outputs which would clutter the UTXO set forever.
I think this is a part of the final solution to the spam problem too.
There are draft BIPs with proposed numbers 181 to 183. I've also started a thread about that feature.