Maintainers of Bitcoin Core software are lagging behind!

[ertil]

I believe any BIP that leads to spending paths getting disabled ultimately should be rejected.

Well, all soft-forks have some "confiscatory surface". However, there is a difference between invalidating something, which is standard, and used for years, and rejecting things, which were non-standard, and spendable by anyone, before a given BIP.

For example: Taproot blocked all users, who used "OP_1 <32-byte value>", and moved it without any signatures. But in that case, it was non-standard, and there were other ways to push 32 bytes, if anyone needed it. In case of BIP-110, it blocks things, which were standard for decades, and even used by Satoshi, like P2PK, so the chance of blocking some funds is much higher.

I feel like spam will continue to stay a non-issue unless somehow another inscribing project gains critical mass.

Even in that case, the main problem is still related to the Initial Blockchain Download, and then, it doesn't matter, if some transaction is "financial" or "non-financial". In case of actual payments, the cost of handling it is bigger, because of the cost of OP_CHECKSIG, the cost of hashing data, and similar costs. While OP_RETURN can be checked very fast, because it can be simplified to just "ignore these bytes, whatever is there".

Which also means, that by fighting with the spam, which is easy to validate, it will be replaced by a different spam, where data pushes will be placed in private keys, public keys, signatures, and other places, used by real payments. And then, it is much harder to handle that, to filter it, or to do anything with it. Supporting things like BIP-110 will push spammers to these methods, where they wouldn't care that much, if they use "OP_RETURN <data>" or "<data> OP_CHECKSIG OP_NOT". It will work fine for them in both cases, and they can invent many more. While for the rest of the network, it will just slow down validation, just because some purists prefer to see random data, hidden as payments, than random data, pushed in a simple way, that can be easily filtered/ignored/whatever.

[Greg Tonoski]

There are other things we can do if necessary - Satoshi Nakamoto

Yes, there have been several things that have been done after Satoshi said that. Examples are (...).

Satoshi wrote "There are other things we can do if necessary" specifically for things we can do (e.g. BIP-110) to protect against arbitrary data like Lady Gaga video in Bitcoin.

Maintainers of Bitcoin Core are lagging behind and may merge the changes in rush in the last moment, thus giving users very little time for evaluation.

It's not lagging behind, when there's no plan to merge PR BIP 110 code. See https://github.com/bitcoin/bitcoin/pull/34930.

There isn't written that there's no plan to merge the PR BIP 110 code at the URL. The task is closed without a comment or any reason. I suppose that a bot or Ava Chow closed it automatically (within <2 hours after it had been opened, BTW).

What else do the five maintainers work on at b'Core (Ava Chow, Marco Falke, Hennadii Stepanov, Ryan Ofsky, Sebastian Kung)?

Can't wait to read that putting 5MB spam in a block is unstoppable. /s

Because it is.

Nonsense. Either you have lost your mind or trolled asserting that 5MB spam in a block is unstoppable in Bitcoin where the size limit of a block is less than that, i.e. 4MB. I will ignore your delusions posted here and not reply to your posts.

I believe any BIP that leads to spending paths getting disabled ultimately should be rejected.

The BIP-110 disables (for a timespan of a year) the spending path to 100KB OP_RETURN. Why do you believe the improvement should be rejected?

[NotATether]

The BIP-110 disables (for a timespan of a year) the spending path to 100KB OP_RETURN. Why do you believe the improvement should be rejected?

Has anyone verified that no spending paths for non-dust bitcoins are disabled by this BIP?

[ertil]

asserting that 5MB spam in a block is unstoppable in Bitcoin where the size limit of a block is less than that, i.e. 4MB.

Nodes store more than one block in *.blk files. Which means, that it is possible to put 5 MB of "contiguous" data there. You can have 4 MB in one block, and 1 MB in another block. If they are sequentially mined one after another, then you have your "5MB spam" in a single chunk.

By the way: note that the old limit was 1 MB, and since Segwit, it was increased to 4 MB. Which means, that changing it is technically possible.

Why do you believe the improvement should be rejected?

Because it is not an improvement. What do you want to validate: "<data> OP_CHECKSIG OP_NOT", or "OP_RETURN <data>"? Checking OP_RETURN is faster, and can be discarded immediately. Encouraging spammers to switch from OP_RETURN to worse ways of spamming will not "improve" the situation in any way. It will make their transactions harder to filter, it will slow down nodes for no reason, and force them to process OP_CHECKSIG, or OP_SHA256, or other similar opcodes, which wouldn't be used at all in OP_RETURN, and it will encourage people to push more on-chain data, than they otherwise would.

What else do the five maintainers work on

Even if you assume, that they do nothing, then still: it is better, than actively supporting BIPs, which will be used to block more and more transactions in the future. Maybe you will understand it, if new Knots users will look at your own transactions, mark it as a spam, and try to block it.

Because the cat and mouse game of blocking spammy transactions has no end. The final stage is where blocks are empty, and every transaction is blocked properly, just like when Luke blocked CoiledCoin. Do you want to use a chain, where you would need to ask developers for permission, to know, what will be blocked, and what will be allowed in the future? In Knots, you can never be sure, what else will be blocked later, you can only guess, or ask Luke, and assume, that he won't change his mind, like he did in the past (earlier, his Eligius mining pool confirmed a lot of non-standard transactions; it was not a spam then, and suddenly is a spam now?).

Has anyone verified that no spending paths for non-dust bitcoins are disabled by this BIP?

They don't worry about that. This BIP disabled P2PK, and a lot of other things, which were used for decades.

[Greg Tonoski]

The BIP-110 disables (for a timespan of a year) the spending path to 100KB OP_RETURN. Why do you believe the improvement should be rejected?

Has anyone verified that no spending paths for non-dust bitcoins are disabled by this BIP?

Yes, I have verified that there isn't any coin (UTXO) spending disabled by the BIP-110. It wouldn't make sense to disable spending coins as it would be against the monetary nature of Bitcoin, of course. Additionally, the BIP-110 expiration after a year is the extra safety measure (just in case).

[gmaxwell]

Which also means, that by fighting with the spam, which is easy to validate, it will be replaced by a different spam, where data pushes will be placed in private keys, public keys, signatures, and other places, used by real payments. And then, it is much harder to handle that, to filter it, or to do anything with it. Supporting things like BIP-110 will push spammers to these methods, where they wouldn't care that much, if they use "OP_RETURN <data>" or "<data> OP_CHECKSIG OP_NOT". It will work fine for them in both cases, and they can invent many more. While for the rest of the network, it will just slow down validation, just because some purists prefer to see random data, hidden as payments, than random data, pushed in a simple way, that can be easily filtered/ignored/whatever.

Exactly. It's really just a full employment program for "spammers" (get free publicity, which entirely what their income is based on) and the censors -- whom have no reason to exist in Bitcoin but can retain their relevance, funding, and narcissistic supply by maintain an unwinnable forever war against the actions of mutually consenting third parties.

Yes, I have verified that there isn't any coin (UTXO) spending disabled by the BIP-110.

That is an outright lie and an *outrageous* one, given that it's already been refuted in this very thread.  BIP-110 directly blocks most of the functionality in script by completely removing conditionals IF/THEN and by preventing you from replacing conditionals with expanded leaves by limiting the tree depth to 7.  Existing timelocked coins which pay to scripts (e.g. non-trivial multisigs) are effectively destroyed by 110.  I would point out that you literally cannot know what exists because scripts are hashed and classical timelocks are off chain until they're used but many people have pointed out existing usage on the network it will block and I've directly pointed out that I know of timelocks whose coins it will destroyed.

It wouldn't make sense to disable spending coins as it would be against the monetary nature of Bitcoin, of course.

Indeed, BIP110 does not make sense.

Additionally, the BIP-110 expiration after a year is the extra safety measure (just in case).

Which is not really true: The authors have expressly said they intend it to last forever on the installment plan and expand to cover more cases. The reason for the expiration is to maximize their ability to censor additional forms of transaction in the future by creating a forcing function.  But even if it were true: that would just highly how extremely *pointless* the exercise is, and it still wouldn't remove the confiscatory nature: a coin delayed is a coin denied, especially since one may need to immediate use a timelock when it matures to prevent a later case from being used (e.g. exactly as lightning channel works).   As one of the two dozen other discussions point out here: a recommended config for high wealth individuals with complicated multisigs is to keep a long delayed timelock that pays to a simple private key to assure that the coins can be recovered even if the other conditions become unavailable.  But if you can't use the intended secure recovery before the insecure keys become active your funds may be lost.

Perhaps there could be proposals that were worth exposing users to these risks-- I think BIP110 is clearly an awful hobbling and actively destructive change to Bitcoin even absent these issues, but one could imagine problems with solutions that have some confiscatory risk that were worth it.  But for that to happen the authors and proponents would have to admit outright the harm and potential harm and weigh it against the benefits.  In this case the authors and proponents have actively mislead the public, lying about the harms specifically because they *know* their proposal is not worth it.

we acknowledge [...] your discontent is from having been not invited to participate in OCEAN's fund raise

By all outside appearances ocean is a failing business and a mild catastrophe for the ecosystem.  Anyone who wasn't invited to 'invest' in that clusterfuck probably feels grateful for the fact: But I wouldn't know because I'm not one of them.

As anyone at ocean should know, I was asked multiple times to invest and I flatly turned it down.  Which is also why I was immediately able to spot the misconduct of undisclosed ocean investors signing on this "anti-spam" marketing campaign when ocean pivoted to transaction censorship being their reason for existence after largely failing to attract participation otherwise.  I can only speculate on how others might feel, but I certainly feel that I wisely dodged a huge bullet.
 
I waited overnight to reply to you after privately asking you to remove this falsehood.  I also asked luke-jr to ask you to remove this absurd allegation-- so I guess we'll see your level of misinformation is official policy that goes right to the top of ocean or not.

But in any case, I'm always happy to see more acknowledgement that this whole drama is substantially about failing a mining pool desperately trying to generate attention and relevance for themselves and their no-coiner leadership.  I had nothing but positive hopes for Ocean until they made transaction censorship a selling point, but even if I had hated them that wouldn't be a reason for anyone to see their ridiculous proposed restrictions on Bitcoin as any more desirable.

[spooderman]

>Existing timelocked coins which pay to scripts (e.g. non-trivial multisigs) are effectively destroyed by 110

Lol Greg, no they aren't. This stupid scenario you keep bringing up results in delay, not destruction.

[gmaxwell]

>Existing timelocked coins which pay to scripts (e.g. non-trivial multisigs) are effectively destroyed by 110
Lol Greg, no they aren't. This stupid scenario you keep bringing up results in delay, not destruction.

I seem to have missed your withdraw of your false allegations about my motivations.  Can you point me to it?

It would only be a delay and not outright destruction if and only if BIP110 goes away-- yet there is absolutely no reason for it to go away under the arguments advanced by its authors and proponents.  If they viewed it as okay to go away then there is just no reason to ever do it in the first place.

Its authors have expressly said that the expiration is so that it will be *expanded* to cover more cases later rather than allowing the status quo to dominate, similar to the programmed expiration in knots software and varrious pseudo-decenteralized cryptocurrency node software: It shuts off so you're forced to take action.  This is their answer to pointing out that any of the NFT crap can evade bip110 with a couple lines code change at worst:  Constantly slashing off more and more of Bitcoin's functionality in a losing fight against an enemy that profits more from the attention than anything else.

But even if we did believe that it would actually be temporary: That only doesn't result in a permanent of loss if access to the time lock during a particular period wasn't necessary to prevent later conditions from activating-- but a cascade of time-locks is *commonly* used in Bitcoin, it's central to how lightning works just to give an example-- so the idea that even just delaying can lead to outright loss is not a fanciful one.  Cascaded timelocks are a thing I personally use, and they're something I've helped others setup.  And they've been pointed out on Bitcoin talk in these discussions before-- BIP110 bad actors keep resetting the discussion so they can pretend (and falsely claim) that there hasn't been opposition.  Unlike the no-coiner directors of ocean other people have taken responsibility to secure their coins in sophisticated ways.

I for one completely believe the authors that they intend to personally censor transactions and impose their own views of right and wrong uses of Bitcoin for as long as they're able.

Perhaps you think it's okay to deny people access to their coins for a year (or destroy them completely in the case that BIP110's restrictions don't deactivate in practice), even if doing so comes with a risk that it'll cause loss.  I disagree, but it's something you could believe, it's something you could try to justify.  However the consistent dishonesty about these risk from Ocean and associated proponents means we can never trust *any* proposal from them: they won't even frankly disclose the risks they're aware of, and they actively mislead the public about them while viciously slandering people like myself who are calling out the risk and pointing out that they'd be personally harmed by the proposal.  You've called me a pedophile, you've called me a spammer, you've claimed I support fraud, now you claim I was excluded from investing in your dumpster fire and I'm somehow sour about it.  Well fuck you and your lame cancel culture censorship.  I won't be silenced while you try to fuck up bitcoin in an orgy of hysterical delusion.

I for one am counting down the days until bip110 activates and forks all of you away from bitcoin, hopefully forever.

[ABCbits]

The absolute worst case scenario that you're invoking here still only results in delay, not confiscation as asserted.

Even if it's not permanent or forever, word "confiscation" still generally used if someone can't access, use or move their goods for certain duration. For example, school use term confiscate even if it's less than a day.

Maintainers of Bitcoin Core are lagging behind and may merge the changes in rush in the last moment, thus giving users very little time for evaluation.

It's not lagging behind, when there's no plan to merge PR BIP 110 code. See https://github.com/bitcoin/bitcoin/pull/34930.

There isn't written that there's no plan to merge the PR BIP 110 code at the URL. The task is closed without a comment or any reason.
--snip--

But if there's plan to add BIP 110 to Bitcoin Core, i expect that PR would be re-opened or someone would comment there's already another PR or someone else currently work on it.

[DaveF]

What I find the most amusing / sad about the entire 110 thing is that there is no case for it and people keep talking about it like it's needed.

At the end of the day, big whoop more data in the chain. And???

The only argument I have seen that kind of / sort of holds any validity is poor people in really impoverished areas can't afford to run a full node. Which, is disingenuous at best.

If you (1) can't afford the hardware and (2) don't have the means / resources to get what is needed there is NO reason to be running your own node. An SPV wallet is what they should be using. Because, even the latest and greatest newest hardware can still die an early death. And now said person is trying to figure out where they can load their wallet.dat file to get get their BTC. But if they had been running electrum (or any other SPV wallet) then it's oh, load my seed phrase here and go. Poor power, do you really want to be running a node or would you rather be able to send TXs from your phone. Bad internet? No big deal all you need is a 3g connection and you can still send / receive no need to sync a block at all.

The "we don't want to store other peoples data" well, tough. Even the most ardent 110 supporters admit it's not going to stop transactions they don't like from being put into the chain. So you are still going to have them. All you are doing is limiting what other people can do with BTC and their transactions.

Either way 72 days +/- a few hours from this post 110 supporters will have their own chain and can do with it what they want. Hopefully some miner deliberately mines a couple of blocks that are 110 incompatible so they split off sooner. Since there have been a couple of spikes in what people were paying to rent hash around the same time Ocean and it's supporters found more block a few days ago then they usually do. At a 10000% guess it was them renting hash to prepare and making sure everything works. Could also be coincidence but I like my tinfoil hat very much and I am going to wear it.

Would be nice if it happened sooner since these arguments are getting repetitive.

-Dave
 

[philipma1957]

What I find the most amusing / sad about the entire 110 thing is that there is no case for it and people keep talking about it like it's needed.

At the end of the day, big whoop more data in the chain. And???

The only argument I have seen that kind of / sort of holds any validity is poor people in really impoverished areas can't afford to run a full node. Which, is disingenuous at best.

If you (1) can't afford the hardware and (2) don't have the means / resources to get what is needed there is NO reason to be running your own node. An SPV wallet is what they should be using. Because, even the latest and greatest newest hardware can still die an early death. And now said person is trying to figure out where they can load their wallet.dat file to get get their BTC. But if they had been running electrum (or any other SPV wallet) then it's oh, load my seed phrase here and go. Poor power, do you really want to be running a node or would you rather be able to send TXs from your phone. Bad internet? No big deal all you need is a 3g connection and you can still send / receive no need to sync a block at all.

The "we don't want to store other peoples data" well, tough. Even the most ardent 110 supporters admit it's not going to stop transactions they don't like from being put into the chain. So you are still going to have them. All you are doing is limiting what other people can do with BTC and their transactions.

Either way 72 days +/- a few hours from this post 110 supporters will have their own chain and can do with it what they want. Hopefully some miner deliberately mines a couple of blocks that are 110 incompatible so they split off sooner. Since there have been a couple of spikes in what people were paying to rent hash around the same time Ocean and it's supporters found more block a few days ago then they usually do. At a 10000% guess it was them renting hash to prepare and making sure everything works. Could also be coincidence but I like my tinfoil hat very much and I am going to wear it.

Would be nice if it happened sooner since these arguments are getting repetitive.

-Dave
 

criminals always want to restrict in the name of safety.

too bad they don’t see it that way and actually want to believe they are the good guys.

[ertil]

The only argument I have seen that kind of / sort of holds any validity is poor people in really impoverished areas can't afford to run a full node.

If they have a problem to run a node now, then all their issues will remain, no matter if BIP-110 will be activated, or not. It doesn't matter from the Initial Block Download perspective, if you have 4 MB with only payments, or 4 MB with only data pushes. Actually, if you have OP_RETURNs, then they make blocks smaller, because instead of having 4 MB witness data, you have 1 MB legacy data. And also, validating OP_RETURN is faster, than OP_CHECKSIG, and a lot of other opcodes, so it can only accelerate Initial Blockchain Download, instead of slowing it down.

The "we don't want to store other peoples data"

Bitcoin was always about processing transactions, which were made by other people. Think about it: if you have a chain, where you have only your transactions, and nothing else, then the whole history is crystal clear, easy to track, and it is obvious, who owns what, which means low privacy. The whole point of accepting other payments, is to "hide in the crowd". Blocking any transactions would just reveal identities faster, than they would be in normal circumstances, because the less transactions there are, the easier is to track a given user.

Which is why even SPV users would be a bit safer, if they would handle more data, than just related to their own payments. For example: if you have some SPV node, and it asks about your address, and absolutely nothing else, then SPV server can easily track that user. However, if you request the whole block, then you can scan it, and find your payment, without informing anyone, which address is yours.

Hopefully some miner deliberately mines a couple of blocks that are 110 incompatible so they split off sooner.

They won't split sooner, than during "mandatory signalling". Because otherwise, they would split here and now. And they still follow non-BIP-110 chain, so we have to patiently wait for the block 961632, and then, a single non-BIP-110 block will move them to a different chain. Then, they will always split, if they will be in any minority. And the speed of their chain will be proportional to the split of the hashrate. If we assume they will get 1% or 2%, then they will produce something like one or two blocks per day.

In general, if someone wants to get an idea, how fast BIP-110 chain will be, then all that is needed, is to trace their signalling blocks. Let's assume, that the blocks they mined are the only blocks they have in their chain. And then, it is a question: do you want to use a chain, which can produce one or two blocks per day, instead of one block per 10 minutes?

At a 10000% guess it was them renting hash to prepare and making sure everything works.

Which is good, because if they would reach 1% or 2%, then they will split, and use their own, slow chain. But if they would have 0%, then BIP-110 would simply fail, and we would still have to deal with them. Having a little hashrate is needed, to get rid of them. And later, when their difficulty will adjust, they will be not that much different, than altcoins, which hard-forked instead, like BCH. Because even if they will have a soft-fork, then still: a minority soft-fork is still a fork. As more and more time will pass, it will be harder and harder for them, to revert BIP-110, and unite with the original chain, or reach enough mining power, to replace it.

Would be nice if it happened sooner since these arguments are getting repetitive.

Well, many changes could happen sooner. But they still want to stick with their original timeline, to create a perception, that there is a chance to reach bigger hashrate.

Also, they still keep things, which are not needed, for example disabling BIP-110 rules, after a given time. It won't push them back to non-BIP-110 chain. Coinbase transactions will split coins anyway, even if there will be absolutely no replay protection. And there actually is: a single output, violating BIP-110 rules, is enough to split the coins. Then, Core will process and include a transaction with simple things, for example single P2PK use, and BIP-110 chain will reject it, and mark it as "not a payment" (because obviously, Satoshi using P2PK was a spammer, and not a real user).

[gmaxwell]

What I find the most amusing / sad about the entire 110 thing is that there is no case for it and people keep talking about it like it's needed.

At the end of the day, big whoop more data in the chain. And???

The only argument I have seen that kind of / sort of holds any validity is poor people in really impoverished areas can't afford to run a full node. Which, is disingenuous at best. [...] If you (1) can't afford the hardware and (2) don't have the means / resources to get what is needed there is NO reason to be running your own node. [...]

The "we don't want to store other peoples data" well, tough.
 

I would say more generally and less judgmentally that if you can't run a node due to resource requirements then you can't run a node.  Your ability to not run it isn't made worse if the the other's people's data in the chain is Luke-Jr's holy donations to anti-contraception charities (oh sorry, one has to have coins to donate them...)  or if it's monkey jpegs.  In fact, if your limit is processing cost related or UTXO related (e.g. the minimum storage required to run a node) the monkey jpegs are strictly an improvement in your ability to run a node over other less stupid sorts of transactions-- just as Ertil says.  But in either case they are the transactions of a third party.

This is why the ability to run a node is protected by the block weight limit and market competition for access to the available weight.  It shouldn't need further protection and if it did censoring this kind or that kind of transaction won't work even if you make the wild assumption that the censorship would be effective-- because the capacity will get used up by things that aren't censored (whatever they are) and leave you just as unable to run a node.

I think it is a goal in the community to preserve node ability pretty broadly simply because even if you can *afford* to run a node, if it's costly you're much less likely to do so because the benefits from doing so are fairly indirect and distance (except for privacy and resistance to censorship by services, which any kind of light wallet is more vulnerable to).

Maybe I should have just skipped this post-- Ertil said most of it, but some things are important enough to be worth saying twice!