Mention more BIP 448 benefits, compare it with APO

[OrfeasLitos]

• Mention delegation and DLC optimisation
• Mention that it provides building blocks for future updates
• Compare with APO that doesn't offer the above

Thanks cmp_ancp for the pointers.

[jonatack]

Unsure whether these changes are worth pinging the BIP authors to look at, cc @darosior.

[murchandamus]

cc: @instagibbs, @stevenroose

[darosior]

Thanks for the improvement suggestions.

We are aware of the optimizations BIP 446 brings to DLCs, as mentioned there. But i personally do not consider it a strong enough motivation for the bundle to be worth mentioning, since performance does not appear to be the reason behind the lack of traction for non-custodial trading.

A comparison to APO in the rationale section would probably be good to have, but it's more complicated than it being strictly less modular. For instance, the sighash flags that can be used in combination with APO enable more modularity for the next transaction commitment use case.

[OrfeasLitos]

@darosior let's try to clarify the comparison with APO while keeping it high level.

The main benefit of APO is that it enables more customizable covenants than BIP 448. Its main drawback vis-a-vis 448 is that it extends transaction validity semantics in a rather pervasive way, making it even harder to hold it all in my head. OTOH 448 achieves most of the things that APO does while introducing minimal new powers to the Script - it's much easier for me to reason about what's happening inside a script because I can forget almost all other Bitcoin semantics. What's more, it does it by adding 3 simple-to-reason-about opcodes, so it makes future updates easier to reason about than APO would.

I've pushed a candidate rephrasing, let me know what you think.