discuss
Discussion
no changes
Lmao.
Who desides what is “off topic”, and who can provide commentary?
This seems antithetical to open, and permission-less project.
no.
NACK.
Why suddenly such a rush to change major Bitcoin policy, after all these years of blocking every sensible proposal (which would actually enable/facilitate all these L2 pegs!!) such as CTV? Just because Citrea would like it for its bridge - that exist on a whitepaper?
Major 🚩
The use of the word “arbitrary” is not arbitrary
I can teach you how to turn your $300 into $6200 in just 4hours without interrupting your daily activities and it's 100% legitimate and secure TEXT ME IF YOU ARE INTERESTED FOR MORE INFORMATION WITH THE DETAILS
TEXT NUMBER. +1 352778 0492
WHATSAPP NUMBER: +1 352778 0492
Email: w98701483@gmail.com
Telegram: cello771
This is a scam
Ask nvk on Wednesday
This affects me very little, doesn't appear to be a major roadblock to Bitcoin scaling and doesn't seem to be a legit code maintenance issue. It kinda seems like change for the sake of change.
Therefore I am on team no change unless I'm wrong about it being a bigger problem than I outlined above.
Just because it might end up in a block, doesnt mean it needs to be in my mempool. And defaults matter. So if retordinals are able to do a thing, then let them, but don't ask maintainers to support it or the rest of the network help propogate bullshit.
Not sure I fully understand it, but it feels like a shitcoin blockchain request resulting in larger data payloads that could unnecessarily increase the storage requirements for full nodes, possibly affecting decentralisation and the ability of individuals to run full nodes?
This won't change storage requirements. Block size remains where it is. Data in OP_RETURNs is not added to the UTXO set, so it might decrease storage requirements actually.
NACK
Ack
I don't see what the harm is leaving the code as-is. I think the argument is it can be bypassed but unless the code is actually harmful, I don't see any reason for the change
If the community's consensus is to keep Bitcoin strictly as a form of money, then there may be little to no demand for a larger OP_RETURN size. Here are some reasons why a larger OP_RETURN might not be necessary or desired in that context:
1. **Focus on Transactions:** If Bitcoin is primarily viewed as a medium of exchange, the emphasis would be on facilitating transactions rather than storing additional data. The existing 80 bytes are sufficient for basic metadata, such as transaction identifiers or short messages.
2. **Avoiding Complexity:** A larger OP_RETURN could introduce complexity that the community may not want. Keeping the protocol simple helps maintain security and reduces the risk of bugs or vulnerabilities.
3. **Preserving Blockchain Integrity:** A larger data size could lead to increased blockchain bloat, which might make it harder for individuals to run full nodes. This could undermine the decentralization and security of the network.
4. **Sufficient for Current Use Cases:** For most use cases related to Bitcoin as money, such as payment confirmations or simple transaction notes, 80 bytes is generally adequate. There may not be a compelling need for more space.
5. **Community Consensus:** If the community is aligned on the vision of Bitcoin as a currency, then there may be a collective agreement that the current OP_RETURN limit is sufficient and that expanding it could divert focus from that primary goal.
In summary, if the community is unified in wanting Bitcoin to remain a straightforward and efficient form of money, there may be little motivation to increase the OP_RETURN size, as the existing limit serves the intended purpose well.
Monero is already better money. BTC is a store of value that seeks to expand itself, as diminishing returns hurt speculators. Becoming a second ETH, now that ETH is proof of stake?
Everyone is so driven by fear and dogma. It’s very clear… there are only 2 options.
nostr:note1vynfacq3khpmm6lx00azcs3x8zuhwyjq96fjsxaawmn8ec2d7flqmw2l72
"the cat and mouse game is futile, look at all the damage the mouse did, letting the cat we-kneecapped-and locked-in-a-cage out would make it worse so lets delete the cage with the cat in it so theres more room for mice"
Core continues to display a lack of leadership on the topic of arbitrary data.
grant money used on gaslighting instead
discuss
nevent1qqsphs2sm8xmlrvqxslrpxkxvnfg8fje99afcg3485kj6m72f6gtmacpz3mhxue69uhhyetvv9ujuerpd46hxtnfduzag94r
reason, then tough love, then wood shed.
Knots
Run Knots.
Protect decentralization at all cost.
Time to start funding Knots
Peter Todd seems to enjoy being a shit disturber. I remember when he floated the idea that Bitcoin needs demurrage .. it sank like a lead weight .. I predict this will too.
I looked at OP_RETURN bot and realized I need to run bitcoin knots asap
Concept NACK
we should make it prohibitively expensive to store arbitrarily large data in the blockchain
Concept NACK
we should make it prohibitively expensive to store arbitrarily large data in the bitcoin blockchain
nevent1qqsd3nlz5xenmvxzzt4yhaer27cmxtupd47p5k4k20uszu3xz8ewy7qpzemhxw309ucnjv3wxymrst338qhrww3hxumnwwfcve4
whether you're for it or against it, it's obviously controversial and shouldn't be merged so quickly
Bitcoin is a monetary protocol not a general data storage protocol.
Bitcoin Core is the dominant (really only) client in the ecosystem. It's maintainers this have the additional duty of being good stewards of the network/project as a whole - of they want it or not.
1) With that market dominance default configs matter as much as consensus rules.
But they are not just proposing to change/disable data carrier, but to remove this option completely -stripping users of the very choice to configure their mempool if they do choose.
2) What about miners? Adam Back correctly points out that through mempool policy miners construct their block template. Core physically removing this option will have make impact. First miners realize this, and speak up like Bob Burnett. Maybe nostr:nprofile1qqsywt6ypu57lxtwj2scdwxnyrl3sry9typcstje65x7rw9a2e5nq8sprpmhxue69uhhyetvv9ujuumwdae8gtnnda3kjctvqydhwumn8ghj7un9d3shjtnzd96xxmmfdecxzunt9e3k7mgpp4mhxue69uhkummn9ekx7mq9hxafw also cares. 
3) Loop and others made it clear that user concern *does not matter* - that Core contributors *alone* can discuss on this!
Plebs are to shut up and dribble.
Before the GitHub comments were locked there was a clear 4:1 ratio of commenters REJECTING this change. But Mr nostr:nprofile1qqs0w2xeumnsfq6cuuynpaw2vjcfwacdnzwvmp59flnp3mdfez3czpspz9mhxue69uhkummnw3ezuamfdejj76l8lp0 says they don't get a say.
This is a violation of the (unwritten) rule of being good stewards.
How does Ten31 see this? Are you supporting and endorsing such behavior?
NACK