{"type":"rich","version":"1.0","author_name":"npub10lrzse62vddqwsscqcmjurmhtxh545zf6q7ez9q25ddlc7p7saeqems9ug","author_url":"https://nostr.ae/npub10lrzse62vddqwsscqcmjurmhtxh545zf6q7ez9q25ddlc7p7saeqems9ug","provider_name":"njump","provider_url":"https://nostr.ae","html":"Are you running an older version of Core or one of the newest versions with the OP_RETURN changes? \n\nAlso curious about your views on spam. \n\nI was uneasy about moving from Core to Knots initially - then I reviewed the Knots policy source code and saw how a few lines of code per spam attack vector is enough to filter it which made me seriously question why Core had refused to mitigate spam or accept Luke’s filters for years (my conclusion is that the main Core devs are passionate about Bitcoin but not monetary maximalists and fine with any use case that existing consensus rules allow). I don’t like all the unnecessary stylistic changes Knots makes to Core source code because it makes comparing differences time consuming, but I got comfortable with it. I would prefer if it was a minimal patch that I apply to Core source code.\n\nIt took me a very long time to decide to run Knots with BIP-110. I eventually decided that to stop Libre Relay and Slipstream (and similar) spam threats, we need to change consensus rules because they deliberately bypass node filters. Even if BIP-110 fails, I think we should try as a community.\n\nI’m an “almost” monetary maximalist. Open timestamps, and other minimal data payload use cases are fine with me. I would even be ok with OP_RETURN allowing a small payload of say150 bytes to support use cases like Citrea - even though I’m not a fan of Citrea.\n\nI’ve been really disappointed with all the ad-hominem attacks from both sides. It’s a distraction from the key issues in my opinion."}