rich1.0epsql (npub1zh…vs67x)https://nostr.now/npub1zhmsa0fs76dctwag0slvg4j9xqxu9q66dkkzxh7ls9pu4d0f9qkqgvs67xnjumphttps://nostr.nowCore uncapping the OP_RETURN size was certainly something I did not like, but that is not a *consensus* change, only a relay policy one though. This has to be specifically stated otherwise our conversation does not make much sense. > So if the changes in consensus are dependent on centralised miners permission then Bitcoin is not really permissionless or decentralised. I am not sure I agree with this since we're dealing with a proof-of-work network. > the hashsers are happy to have high op_return which is causing problems for nodes What problems is uncapping OP_RETURN causing? Don't get me wrong, I'd prefer to see only financial transactions on my node since this is why Bitcoin exists, but I would not say that large OP_RETURNs are causing issues per se, since the block size is capped anyway (I'd like not to have the segwit discount though) > nodes have the right to find new hashers which align with the wishes of these nodes. And that's what is happening This is surely something that nodes can do, although it remains to be seen whether the Blake hard fork will gain any value. I honestly prefer the ecash fork since it also reduces the block size and implements drivechains via BIP300/BIP301, which is much more compelling IMO when compared to simply having less spam