Some great content on this channel:

What is your favorite mobile #nostr client? #asknostr

@miljan have you considered publishing @primal to the Accrescent app store?

@Vitor Pamplona have you considered publishing @Amethyst to the Accrescent app store?

@jb55 Have you considered publishing @Damus to the Accrescent app store?

ssh sucks

Help me understand. 1. Some have said that keeping OP_RETURN size small is important for node operator liability, because large OP_RETURN size could lead to relaying/storing full files of any kind (including the most awful stuff). 2. Yet, the OP_RETURN size limit is not a consensus rule, i.e. nothing prevents a miner from including a transaction with a huge OP_RETURN in a block, already now. 3. What Core is doing, and Knots is against, is changing the relay policy, that decides which unconfirmed transactions the node shares with other nodes (~broadcasting), before they are included in a block. Right now the default policy is to not relay a transaction with an OP_RETURN exceeding 80 bytes. 4. I tend to agree that largeish arbitrary files pose a risk to Bitcoin. I understand that it's already possible to store it in small chunks over multiple transactions or otherwise, but that would require special software to interpret. 5. Therefore, I believe the fundamental problem is not really being addressed. The fundamental problem is that there is not a true OP_RETURN size limit to begin with. 6. If we accept the premise that large OP_RETURN size is a risk to Bitcoin, we should make the OP_RETURN size limit a *consensus rule* going forward. That is, a transaction with a large OP_RETURN would be invalid, and no miner could include it in a new block (unlike now). 7. I believe this is called a SOFT FORK. Not a comfortable word, but I think that would be the consistent position here. Change my mind #asknostr @ODELL @Jeff Booth @HODL @calle @Luke Dashjr @Peter Todd @Adam Back

If bitcoin succeeds in the separation of money and state, what will be the next separation? #asknostr