Nostr Web Client

Yes, in both cases it has no impact on Bitcoin’s consensus rules nor the “definition of Bitcoin”. In both cases, if the decision is “wrong”, the network will simply route around Bitcoin Core (either with a different wallet or by using things like Slipstream).

Yes, obviously the GUI is less likely to cause problems for other Bitcoin users than P2P changes but in both cases this is a question for the open source contributors of Bitcoin Core (which is an open process everyone should provide feedback on!), not one that gets decided by “consensus” and doesn’t change without it.

supermass 7mo ago 💬 1

I think from the outside perspective, your framing of the "definition of Bitcoin" is a bit worrisome.

Obviously Core is not Bitcoin, but it is a default!

And as we've learned from the discussion, defaults are incredibly sticky.

Fragmenting the network's mempool/miner relationship (if we made datacarrier=0 by default let's say) would still be incredibly hard and require a huge, sustainable actor in the space to push non-standard transactions.

I think we are giving too much credit to that being a reality and not enough credit to the reality that the majority view Core as Bitcoin, and having to "prove" them wrong would be much more harmful than not.

For example, do you think having thousands of people switch to Knots is a good thing right now?

It is happening because of this debate, and I find it much more harmful (given Knots current fundamentals) than just closing the PR and continuing to monitor expected vs. actual blocks for the foreseeable future.

Also would like to state for the record I am in the nostr:nprofile1qyw8wumn8ghj7mn0wd68yttjv4kxz7fwwak8vuewwdcxzcm9qythwumn8ghj7mn0wd68ytnxd46zuamf0ghxy6t6qqsqyredyxhqn0e4ln0mvh0v79rchpr0taeg4vcvt64te4kssx5pc0sk99k65 camp, the default should be maximized, but config option not removed. Yes, I understand leaving the config option would only allow nodes to 'harm themselves' by obfuscating their mempool and fee rates but I frankly don't care.

Reply to this note

Please Login to reply.

Discussion

Matt Corallo 7mo ago 💬 1

> think from the outside perspective, your framing of the "definition of Bitcoin" is a bit worrisome.

To be clear, there I was referring to the consensus rules. The consensus rules are, literally, the definition of Bitcoin. So I was drawing a distinction between the code that literally defines Bitcoin and the rest of the code in Bitcoin Core.

> And as we've learned from the discussion, defaults are incredibly sticky.

I think this is very much the wrong takeaway. Rather, if we look at actual network behavior and the transactions that get mined, our takeaway should be “if Bitcoin Core doesn’t relay it, and its consensus-valid, someone will build some shitty centralized relay alternative that will be used”. Yes, Bitcoin Core’s defaults might largely decide the P2P relay rules, but those don’t matter if transaction creators are just routing around that network!> think from the outside perspective, your framing of the "definition of Bitcoin" is a bit worrisome.

> And as we've learned from the discussion, defaults are incredibly sticky.

> I think we are giving too much credit to that being a reality and not enough credit to the reality that the majority view Core as Bitcoin, and having to "prove" them wrong would be much more harmful than not.

Where are you getting this from, though? Every day, many, many non-standard transactions get confirmed. With turning off RBF it was clear that if Bitcoin Core doesn’t provide something, someone else will, and many miners will use it! (In this case Peter Todd’s patch set). With Slipstream it’s similarly evident that any policy rules Bitcoin Core makes just don’t add up to anything but giving Mara more money at the expense of other miners.

Matt Corallo 7mo ago 💬 1

As for the “just leave it an option and change the default”, there’s no reason to do that that I’ve seen either. As you note, most nodes run with the default options, so it doesn’t delay or prevent these transactions from being mined. The only impact it has is it makes you and your peers use more bandwidth and slows down block propagation.

Having policy be configurable is actually a really bad idea generally, and including this specific case.

supermass 7mo ago 💬 1

I guess I am starting to come around, here's my understanding..

Even if long-term demand for nonstandard transactions does not meaningfully materialize (as I claim it won't), the present set of actors (whoever it is and whatever they are doing) will be contributing a centralizing influence on miners because larger ones can claim the fees of confirming these transactions without eating the slippage from excluding other, standard transactions instead. They can reasonably expect to get the transactions confirmed quickly.

Removing any OP_RETURN limitations removes the mining influence immediately. It still remains cheaper to use witness data in general, so the additional pressure for data anchoring that is introduced by OP_RETURN is minimal.

I still don't know how I feel about removing configurable policy.

I understand the argument for this specific case, but in general? Especially for something like bitcoin.conf which we've both conceded will only be altered by enthusiasts. How many options should be done away with?

Matt Corallo 7mo ago 💬 1

In general, my view is software shouldn’t have options that let you shoot your foot off, even accidentally. Even if you can live fine without a foot, you probably prefer to have it.

For relay policy, divergent rules tends to be that. There may be some exceptions (like “I have little CPU power and can’t process complicated packages of transactions” or “I have little memory and want a smaller mempool” or even “this may get used in the future but it isn’t now so have an option so people can enable some new transactions without upgrading”), but in most cases divergent policy is simply divergent policy, and only harms the user”.

supermass 7mo ago 💬 1

Thank you for taking the time to discuss

Matt Corallo 7mo ago

Thank you for asking good questions!