Hello Everyone,

The below comment by Matt about different implementations and their opinion on 
`lockinontimeout` is from 18 Feb 2021 communication: 

> If the eventual outcome is that different implementations (that have material 
>*transaction processing* userbases, and I’m not sure to what extent that’s 
>true with Knots) ship different consensus rules, we should stop here and not 
>activate Taproot. Seriously. Bitcoin is a consensus system. The absolute worst 
>outcome at all possible is to have it fall out of consensus.

I don't agree to the part that 'we should stop and not activate taproot'. 
Instead it will be helpful if we can educate most of the people about 
trade-offs involved in both options with some tables, charts etc.

I think its time to use Bitcoin Knots for more projects and also maintain 
multiple forks of Bitcoin Core. This is not just limited to `LOT=True or False` 
but few other things and in general its good for decentralization of Bitcoin. 
Bitcoin Core is used by most of the nodes according to this pie chart: 
https://luke.dashjr.org/programs/bitcoin/files/charts/software.html however 
having multiple forks of Bitcoin Core with real usage, more maintainers in 
different parts of the world (some even anon), few different features, more 
reviewers, better communication channels etc. will help everyone involved in 

I am working on a project right now which involves multisig, discreet log 
contracts, liquid etc. Using bitcoin-s for it because I need DLC but still 
depending on Bitcoin Core in it. Would try Bitcoin Knots and other 
implementations soon and also have been looking for developers good with C++ 
and Python, living in India who are interested to maintain a fork of Bitcoin 
Core with few changes. I had shared about in replies to Amir Taaki's tweet few 
days back.


bitcoin-dev mailing list

Reply via email to