Antoine Poinsot

Some previous related discussions: - ["What's a good stopping point? Making the case for the capabilities enabled by CTV+CSFS"](https://gnusha.org/pi/bitcoindev/F5vsDVNGXP_hmCvp4kFnptFLBCXOoRxWk9d05kSInq_kXj0ePqVAJGADkBFJxYIGkjk8Pw1gzBonTivH6WUUb4f6mwNCmJIwdXBMrjjQ0lI=@protonmail.com/) - Bitcoin dev mailing list thread discussing the capabilities offered in...

Thanks for the feedback @Ademan. > as much as I'd like to avoid excessive bikeshedding Some amount of bikeshedding is justified for a proposal as consequential as a consensus change....

> Wouldn't the hash naturally be cached in implementation? In the Taproot signature hash (which this proposal re-uses), various parts of the transaction are pre-hashed such that the hash can...

I think a separate bundle BIP is preferable for at least two reasons: - Separation of concerns. It's cleaner to give the motivation for a bundled soft fork in its...

I didn't mean to imply you suggested that. I was just chiming in as it appeared to have been welcome above. Anyways, what would you recommend here?

> I added a rollback_wallet_tip method to the Bitcoin interface to roll back the local chain's tip in case of a reorg. This helps when syncing the wallet to detect...

One thing to check, i don't remember if we support it even with the bitcoind backend: if a user imports a PSBT which spends in part coins from another wallet...

> How about only considering transactions with 2 confirmations or more, and this way you don't need to deal with reorgs? Code would be much simpler (even if it would...

> Proper consensus forming process for choosing release names Since [v0.7.1](https://github.com/ElementsProject/lightning/releases/tag/v0.7.1) we have an unfailing consensus !