UTXOS.org is the hangout of BIP119 and the home page title should send alarm bells ringing across the Bitcoin community.
‘Next-Gen Smart Contracts for Bitcoin’ – as far as I am concerned if you want smart contracts use Ethereum or some other Alt coin. Bitcoin has no need for additional smart contracts, it is already highly programmable especially with the continued development of the lightning second layer. For an overview of why BIP119 is such a BAD idea start with the broadcast by Andreas M. Antonopoulos below.
The main argument against BIP119 is that it introduces more complexity into the Bitcoin programming environment, more complexity means more risk to the security of Bitcoin. Other blockchains illustrate what can go wrong with flexible programming environments. Ethereums DAO roll back. More recently the Solana blockchain was offline for more than 7 hours.
For a more detailed look at BIP 119 take a look at the following
36.00 Jimmy Song overview of BIP119
40.00 Tone Vays nails it – 2 main issues
41.09 nvk – Speedy trial is a terrible idea for Bitcoin. Hard forks only! Not UASF
45.00 Stop f**king with my money
47.00 Adam Back. Risk is counter intuitive…Innovation is NOT a metric of success.
54.20 Don’t f**k with my money
59:00 Bitcoin mechanic
1:00:00 Malicious softfork
1:06:00 ‘How do I get my upgrade into Bitcoin’ – You can’t – that is the defualt
1:09:00 Jedi mind f**k. ‘Wash my car’
1:11:00 Bitcoin default should be ‘no change’
1:14:00 The systemic risk of Covenants
1:14:00 Jimmy Song : Covenants are ALREADY in Bitcoin
Fuzzy property boundaries are NOT good in economics or socially
1:25:00 First do no harm
1:26:00 nvk ‘when in doubt nothing happens’
Need I go on – BIP119 is a very BAD idea for Bitcoin
Further reading as too why complexity in programming is a bad idea read the following
The Mythical Man-Month : Fred Brooks
–>especially–>
The second-system effect
Main article: Second-system effect
The second-system effect proposes that, when an architect designs a second system, it is the most dangerous system they will ever design, because they will tend to incorporate all of the additions they originally did not add to the first system due to inherent time constraints. Thus, when embarking on a second system, an engineer should be mindful that they are susceptible to over-engineering it.
The tendency towards irreducible number of errors
See also: Heisenbug
99 little bugs in the code.
99 little bugs.
Take one down, patch it around.
127 little bugs in the code…[2]
The author makes the observation that in a suitably complex system there is a certain irreducible number of errors. Any attempt to fix observed errors tends to result in the introduction of other errors.
Or perhaps
The Art of Computer Programming : Donald Knuth
BIP119 is a very BAD idea : Don’t f**k with my money