Best break down of BIP110

[PepeLapiu]

You can't accept BIP110 as a solution to any problem because you don't see any problem.

I can see the problem,

My solution is to basically process the subset of the mainnet traffic. In this way, you handle only payments, and you ignore non-payments completely. Then, you still land on the same chain, with the same coins, but only optimize your own client. However, obviously, Knots is not interested in any of that, because they prefer forking to a minority chain, more than making actual optimizations, that could be beneficial for users.

I guess people are falling into this trap, because they think, that each present and future node implementation is forced to process everything that happens on-chain, forever. And that users from 2109 will still have to process and download blocks and transactions from 2009, only to find their own coins, which were created in the 22nd century, and didn't exist earlier at all. Processing 100 years of history, to handle coins, which existed only in some recent blocks, is highly inefficient method, which doesn't scale. Are you afraid, that 210,000 or more blocks will be reorged? Do you think, that someone from 2109 will still assume, that there could be a chain reorganization, which would change some block, mined in 2009? There is a reason, why Satoshi counted only block headers in the whitepaper.

One day you all decide you can't define spam.

And you know, why it is the case? Because blocking existing ways of spamming will encourage spammers to adapt, and adjust their methods. And then, instead of handling a spam, which is very simple to handle, like OP_RETURN is, you push them to use worse methods, which are harder to detect, harder to process, and harder to fight with.

If you don't understand it, then try to learn, why OP_RETURN was introduced in the first place. What problem it solved, and what people used, where there was no OP_RETURN. Then, maybe you will get it, how people, who switched to OP_RETURN, made it easier to handle the UTXO set, to increase transaction processing speed, and even allowed you to split things between "monetary" and "non-monetary" transactions, where otherwise, it would be much harder to even count it properly, and measure the scale of the problem.

The next day you claim we can't stop spam, when you just said you can't define what spam is.

If you will block for example OP_RETURN, then spammers will switch to worse methods. When someone pushes some data on-chain, and it is all behind OP_RETURN, then it is easy to define it as a spam, easy to filter, easy to block, and easy to handle it in whatever way you want. But if it is blocked, then people simply adjust. And then, you can no longer filter things by OP_RETURN, because they are encoded with OP_CHECKSIG, and with a lot of other methods. And then, you no longer know, what is spammy, and what is not, if all of that traffic is heavily mixed with regular payments.

Imagine for a while, that all spammers would always use OP_RETURN, and nothing else, to push their data. Then, it would be easy to detect, easy to handle, and when you use some optimized client, you can easily filter it, ignore it, remove it from your UTXO set, without worrying about the correctness of the future blocks, and so on. But no, let's make it worse. Let's break these assumptions, optimizations, and all of that effort, which was done to speed up the Initial Blockchain Download, by not processing things, where transaction creators want to send coins to unspendable or hard-to-spend locations.

And then, instead of handling all existing spam in one shot, you have to guess, where it is, and which form it took. You have to scan every OP_CHECKSIG, try to find ASCII strings there, try to check vanity addresses, try to check signatures, and handle thousands of ways, in which spam could be pushed. Which means, that you simply screwed all optimized clients, who previously could look at some transaction, see OP_RETURN, and ignore it instantly. Now, they need much more effort, to reach the same goal, just because you want to play Tom and Jerry's on-chain, for absolutely no reason.

So, to sum up: a spam could be stopped in a simple way, if everyone would just use OP_RETURN. By using BIP-110, you make the situation worse, because it is no longer that simple. And I am not against the idea of stopping the spam: I am against forking into a minority chain, screwing all optimized clients, and implementing a cure, which is worse than the disease. BIP-110 just distracts people from making actual optimizations and improvements, which could filter the spam properly, without any fork wars, without splitting the community, and without all of that drama.

Also, guess what: all people, who will want to split their coins between BIP-110 chain, and non-BIP-110 chain, will push real transactions on-chain, for completely no reason. They would have no reason to do that, if BIP-110 wouldn't split. The only reason why they will, is because you decided to run Tom and Jerry show on-chain, and giving all spammers a free press, which they otherwise wouldn't get at all, and their data pushes would be completely ignored, so people would stop using them.

You can't accept BIP110 as a solution to any problem because you don't see any problem.

I can see the problem

I'd have to dig them up, but previous statements from you clearly show you are the problem.

My solution is to basically process the subset of the mainnet traffic. In this way, you handle only payments, and you ignore non-payments completely. Then, you still land on the same chain, with the same coins, but only optimize your own client. However, obviously, Knots is not interested in any of that, because they prefer forking to a minority chain, more than making actual optimizations, that could be beneficial for users.

You don't need Knots's seal of approval.  I don't understand your idea. But if you believe it, nothing stops you from submitting your own proposal. I think you will likely fail if you try to post it on the Bitcoin mailing list as they don't really allow anything regarding the problem of malware.

You reject Knots filters, you reject BIP110, you endorse core 30 and the removal of op_return malware filter. It's clear to me you are on the wrong side of the isle here. I have not heard you say anything about the problem of malware on Bitcoin.

Processing 100 years of history, to handle coins, which existed only in some recent blocks, is highly inefficient method, which doesn't scale.

I agree. Which is why malware is such a horrible problem. Malware tolerance is the reverse of scaling.  

If you don't understand it, then try to learn, why OP_RETURN was introduced in the first place. What problem it solved, and what people used, where there was no OP_RETURN. Then, maybe you will get it, how people, who switched to OP_RETURN, made it easier to handle the UTXO set, to increase transaction processing speed, and even allowed you to split things between "monetary" and "non-monetary" transactions, where otherwise, it would be much harder to even count it properly, and measure the scale of the problem.

Op_return was created in the hope that malware assholes would use it instead of fake pubkeys. But that was before Segwit and Taproot which were exploited for malware to be much cheaper than op_return for malware assholes.

They are not moving to op_return and they never will because op_return is far more expensive than most other malware methods.

What core 30 did is send an invitation for new malware use cases to be created while doing absolutely nothing about existing ones.

If you will block for example OP_RETURN, then spammers will switch to worse methods.

Is this where we all pretend any malware assholes are using large op_return for 4-5x more fees than other malware methods?
Is this where we pretend doing nothing about existing malware methods and creating new ones is a proper solution to anything?

[ertil]

You don't need Knots's seal of approval.

Every project has some maintainers. If a given maintainer doesn't want to accept your changes, then all you can do, is to fork the code, and maintain your own client, just like Knots is a fork of Core. And then, the more splits are there, the less user base you have. Usually, developers use their own clients, because the first step is always to clone the repo, make some changes, and use it locally.

I don't understand your idea.

Read the chapter 7th of the whitepaper, called "Reclaiming Disk Space".

It is quite simple. If you don't like any given transaction, then you can remove it from your node. If you keep only the hash of it, then you can still verify, that the merkle tree is correct, the block hash is correct, and it is a part of the heaviest chain. Which means you can still filter the spam, while being on the same chain.

But Knots users just don't want to optimize their own clients. They want to spread their ideas into everyone, and force every other node, to follow the same rules. Which means, that they prefer to use a minority chain, than to use everyone's chain, and handle only payments from there, without handling everything else.

But if you believe it, nothing stops you from submitting your own proposal.

Why should I make something, that already exists? https://www.dci.mit.edu/projects/utreexo

I think you will likely fail if you try to post it on the Bitcoin mailing list as they don't really allow anything regarding the problem of malware.

And why should I put on a mailing list, if it is fully optional, and requires no consensus changes? In the past, some people asked, why hard-forks are needed, when we can do soft-forks. Now, the question is why soft-forks are needed, if you can have a working no-fork, by just running a more optimized code?

I agree. Which is why malware is such a horrible problem. Malware tolerance is the reverse of scaling.

Making Initial Blockchain Download slower, than it should be, is also the reverse of scaling, but BIP-110 has no problem with doing that.

They are not moving to op_return and they never will because op_return is far more expensive than most other malware methods.

Yeah, so it is better to kill OP_RETURN completely, so that all of them will move to a worse methods of spamming. Great idea. And don't forget about pushing them harder and harder, so they will switch to worse and worse ways, while regular users will suffer, when spammers won't even run any full node at all, to deploy all of that. Great idea, thankfully BIP-110 will make sure, that even if someone would want to use OP_RETURN, then that person wouldn't be able to do that, and achieve the same goals in worse ways.

Don't you think it would be much easier to deal with the spam, if every spammer would use OP_RETURN?

What core 30 did is send an invitation for new malware use cases to be created while doing absolutely nothing about existing ones.

It simply encourages moving from other, worse methods to the OP_RETURN. But BIP-110 is just making it harder, so instead of filtering every spammer in one shot, everyone will have to deal with these worse ways, based on other methods. Which only makes writing optimizations harder, and gives free press to all of the spammers, because they are now important, and can laugh at BIP-110, because they don't run any full node, so they are completely unaffected, and they can instantly switch to methods, which won't be blocked by it.

Is this where we pretend doing nothing about existing malware methods and creating new ones is a proper solution to anything?

There are other things, which could improve the situation, like processing a subset of things. But because of BIP-110, nobody will do that now, at least not in this year, when we will have at least two, if not more controversial summer forks, and every developer will patiently wait for the dust to settle, because there is no point in fixing the problem, when you have to wait for the majority, to pick the winning chain, and to not suddenly become an altcoin developer.

[PepeLapiu]

And don't forget about pushing them harder and harder, so they will switch to worse and worse ways

This is exactly what we are rejecting: the idea that we have to make room for malware assholes and be nice to them by fear they might do worst than they are already doing.
This is a coward bullied child's approach: give them what they want so they don't hurt us more.

And the same people who say this bullshit also reject all proposed filters, frame anti-malware measures as "censorship" and refer to malware as "use cases we have today" while they blow up existing malware filters. And they refer to malware as "transactions I don't like"

[internetional]

This will only be another spam thread of Bitcoin Knot.

Even if this is a spam thread, it may still be useful, because the problem is real. If I want to verify everything in Bitcoin myself, without relying on third-party nodes, I have to store other people's data. Nobody rewards me for that. Worse, I could even be punished if storing that data is illegal in the jurisdiction where my device is located.

Maybe discussions like this are where a decent solution, which still does not exist, will eventually emerge.

[Satofan44]

This will only be another spam thread of Bitcoin Knot.

Even if this is a spam thread, it may still be useful, because the problem is real. If I want to verify everything in Bitcoin myself, without relying on third-party nodes, I have to store other people's data. Nobody rewards me for that. Worse, I could even be punished if storing that data is illegal in the jurisdiction where my device is located.

No, that comes as a misunderstanding and clearly you have read too many shitposts in threads like this instead of finding a path towards the truth. There are only 2 facts, long established already:

• There is already all sorts of illegal data in the Bitcoin chain and in any shitcoin chains.
• There is no way to completely prevent the embedding of illegal data in the blockchain.

You can run a cat and mouse game of endless filtering whereby you continue the path towards placing more and more restrictions on Bitcoin but to what end? The spammer can, even in the absence of all other possibilities (unlikely), embedd data with fake public keys effectively bypassing every filter that you have introduced. So what would you have accomplished:

• Illegal data would still be embedded by those that want to do it.
• Illegal data would still be in Bitcoin.
• Bitcoin's functionality would be severely restricted and compromised compared to what it is today.

Only negatives and not a single benefit, genius strategy isn't it?   Instead we have a simple method that works fabulously for storing illegal and legal data, that comes at the least cost and risk to the chain. Honest people will use those options, dishonest people or malicious people may use other options. There is no security gain from trying to obscure this.

Maybe discussions like this are where a decent solution, which still does not exist, will eventually emerge.

If we all come nicely together we can change the nature of the universe, the math and physics behind it. Are you fucking serious? The possibilities to embed data come from the way that information theory functions, it is not something that you can "solve". The equivalent would be to try to find a way to stop 2 + 2 from adding to 4.  

[internetional]

I agree with everything except the last point.

If we all come nicely together we can change the nature of the universe, the math and physics behind it.

This statement is yours, not mine. I don't know what we can or cannot do. However, I believe that in a free discussion, one of us will be able to come up with interesting proposals regarding the solution to the problem I outlined above. I understand that BIP-110 is not a solution, but that doesn't change the fact that the problem exists. And even if you believe that the problem is theoretically unsolvable, that could be a mistake.

[PepeLapiu]

• There is already all sorts of illegal data in the Bitcoin chain and in any shitcoin chains.
• There is no way to completely prevent the embedding of illegal data in the blockchain.

There are several problems with those two statements. First, the same people who proclaim we can't stop malware completely, are the same people who get busy rejecting malware filters, blowing up existing malware filters, and referring to malware as "use cases we have today".

Secondly, nobody, and I mean nobody has the goal of completely removing all malware. Everyone understands that it can't be completely stopped. But core is not even trying to reduce malware, they are actually enabling malware.

You can run a cat and mouse game of endless filtering whereby you continue the path towards placing more and more restrictions on Bitcoin but to what end?

The cat and mouse game example again!
You fail to recognize that a barn with cats and mouse traps will have fewer mice than a barn without. Everyone understands that you can't kill all the mice and kill all the malware. But anti-mouse and anti-malware measures will result in less of it. All the while core is facilitating malware.

The spammer can, even in the absence of all other possibilities (unlikely), embedd data with fake public keys effectively bypassing every filter that you have introduced. So what would you have accomplished:

• Illegal data would still be embedded by those that want to do it.
• Illegal data would still be in Bitcoin.
• Bitcoin's functionality would be severely restricted and compromised compared to what it is today.

It's tiring to have to argue against the same cliquer every time. You talk like a coward fearful child who is being bullied by the big boy in class. You think you can't fight him and the best you can do is bend over and take it by fear he might do worst things to you if you don't obey. Grow a pair, will you?

Only negatives and not a single benefit, genius strategy isn't it?  

This is false. For example there is no negatives to BIP110 from a monetary user perspective.
Which is why all of you refuse to discuss what BIP110 actually does.

When faced with the idea of malware on Bitcoin, Satoshi had this to say:

"That's one of the reasons for transaction fees.  There are other things we can do if necessary."

In contrast, coretards are saying:

"Noooooo! We can't stop malware! So we might as well reject malware filters and remove the ones we already have"

[stwenhao]

You fail to recognize that a barn with cats and mouse traps will have fewer mice than a barn without.

If your way of getting rid of mice is to increase radioactivity in the whole house, then the owner of that space won't be happy about it. Killing all life around, only to kill some mice, is simply not worth it. There are limits to what you should do, and after passing some of them, you will start affecting real users more, than the spammers.

Which means, that doing nothing is better than harming real users. And BIP-110 supporters constantly tell us, that it won't affect any users, without testing it properly, checking edge cases, or supporting it by anything else than "I feel like it, because I am not affected, so others also won't be".

But anti-mouse and anti-malware measures will result in less of it.

Only for a short period of time, after which spammers will adjust, and you will end up in a worse situation, where you would face a choice of killing all living beings, to get rid of mice. Which means for example trying to block unstoppable spam, present in private keys.

For example there is no negatives to BIP110 from a monetary user perspective.

BIP-110 supporters consider blocking some multisigs as "no negatives", and "not a confiscation".

Even P2PK is blocked by BIP-110. Again, Satoshi using P2PK was not making payments? Was he a spammer?

[PepeLapiu]

You fail to recognize that a barn with cats and mouse traps will have fewer mice than a barn without.

If your way of getting rid of mice is to increase radioactivity in the whole house, then the owner of that space won't be happy about it.

You are taking the analogy way too far.

Killing all life around, only to kill some mice, is simply not worth it. There are limits to what you should do, and after passing some of them, you will start affecting real users more, than the spammers.

Monetary users won't be affected by BIP110. But in case they are affected in ways we could not predict, they will see their funds "frozen" for a year as the worst case scenario.

But I don't think we are going to see suck case happen. In fact, one if the talking heads of the coretards - Maxwell - admits you would have to delete your keys to lose your coin. But that's been true since the very first day of Bitcoin.

Which means, that doing nothing is better than harming real users. And BIP-110 supporters constantly tell us, that it won't affect any users, without testing it properly, checking edge cases, or supporting it by anything else than "I feel like it, because I am not affected, so others also won't be".

Here is the only edge case where you could get your coin frozen for a year, and ALL OF THE FOLLOWING ITEMS need to apply to you. If one of them doesn't aply to you, you are safe:

- You are an advanced enough user to make use of advanced features walkers like Nunchuk.

- Advanced enough of a user yet you have been living in a cave for the last year and unaware of the new rules.

- You lock your funds in a convoluted multisig that makes use of op_if in Taproot with a depth of 7 leaves or more, during the one year period.

- You do the redeem side before BIP110 expires.

- You use an out of date wallet or you use a wallet that refuses to update to the new rules.

And even than, even if all the above apply to you, your funds will be unspendable until the fork expires in September 2027.

In order for you to permanently lose your funds, you would have to do all of the above, and also delete your keys.

The problem with this is that losing your keys will always cause you to lose your coin in all the other cases where you send bitcoin.

But anti-mouse and anti-malware measures will result in less of it.

Only for a short period of time, after which spammers will adjust, and you will end up in a worse situation

First of all, it's malware, not spam. Spam is nothing more than an annoyance. Malware could severely incapacitate and compromise bitcoin.

Secondly, the first layer of protection against malware is at the social signal level. If we show them that we are willing to soft fork to rug the malware attackers, they are less likely to continue on Bitcoin. Because we have shown we are hostile to them and willing to rug them.

For example there is no negatives to BIP110 from a monetary user perspective.

BIP-110 supporters consider blocking some multisigs as "no negatives", and "not a confiscation".

Those are all malware users. No monetary user makes use of op_if in Taproot with a depth of 7 leaves or more. It's a horrible way of doing things because you are dumping a bunch of Sara on chain, which is bad for privacy. But dumping data on chain is exactly what malware attackers love to do.

Even P2PK is blocked by BIP-110.

That is a lie.

Again, Satoshi using P2PK was not making payments? Was he a spammer?

Any address script used with op_if in Taproot with a depth of 7 leaves or more will be unspendable. All other forms of multisig will be preserved. No monetary user is making use of that.

[ABCbits]

• There is already all sorts of illegal data in the Bitcoin chain and in any shitcoin chains.

Not only that, it's exist since a long time ago.

--snip--
It's just an example that i remember right away, there are all kinds of data stored on Bitcoin even since a decade ago[1]. Should i mention that research from few years ago discover some kind of content including hundreds link to child porn[2]? Should i also mention shortly after Ordinal launch, someone use it to add porn/explicit image[3]?

If you run non-pruned Bitcoin full node, your device already store such data.

[1] https://www.righto.com/2014/02/ascii-bernanke-wikileaks-photographs.html#ref14
[2] https://fc18.ifca.ai/preproceedings/6.pdf, section 4.3 Investigating Blockchain Files.
[3] https://crypto.news/bitcoin-ordinals-encounters-explicit-images-days-after-launch/

You can run a cat and mouse game of endless filtering whereby you continue the path towards placing more and more restrictions on Bitcoin but to what end? The spammer can, even in the absence of all other possibilities (unlikely), embedd data with fake public keys effectively bypassing every filter that you have introduced.

And even if fake pubkey somehow completely filtered (even at cost of filtering less common usage of monetary TX or increase size of all TX), determined spammer would resort adding the data to signature itself.

For example there is no negatives to BIP110 from a monetary user perspective.

BIP-110 supporters consider blocking some multisigs as "no negatives", and "not a confiscation".

FWIW, whether you can't access or use it for a year or even on same day, it still can be called confiscation. Even government use that term on short duration.

Return: Confiscated drinks will only be returned at the end of the same school day from the Front Office.

Even P2PK is blocked by BIP-110.

That is a lie.

Someone doesn't read BIP 110.

New output scriptPubKeys exceeding 34 bytes are invalid, unless the first opcode is OP_RETURN, in which case up to 83 bytes are valid.

New P2PK output would be blocked because it's size more than 34 bytes. Here's example of real TX with P2PK output, that shows size of P2PK output.

P2PK 04678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef3 8c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f 50.00000000 BTC

[ertil]

Even P2PK is blocked by BIP-110.

That is a lie.

Let's read BIP-110 then: https://github.com/bitcoin/bips/blob/master/bip-0110.mediawiki

New output scriptPubKeys exceeding 34 bytes are invalid, unless the first opcode is OP_RETURN, in which case up to 83 bytes are valid.

And then, P2PK outputs have, guess what: 35 bytes for compressed keys, and 67 bytes for uncompressed keys. Which means they are rejected, under new rules, and cannot be used anymore, if BIP-110 is activated.

Again, BIP-110 supporters would know about it, if they would have a proper testnet, or check edge cases more carefully. But of course they didn't, and they have no plans for doing so, they want to run it live, on a main network, and if some coins will be affected, then they simply wouldn't care, to compensate any losses.

So, what would you say now? That no new wallet will use them, and they are obsolete? And that you don't care about users from 2009, and old wallets, which may try to do so? What if Satoshi would want to move his old coins? Or maybe that P2PK is not a payment?

[ABCbits]

Again, BIP-110 supporters would know about it, if they would have a proper testnet, or check edge cases more carefully. But of course they didn't, and they have no plans for doing so, they want to run it live, on a main network, and if some coins will be affected, then they simply wouldn't care, to compensate any losses.

Proper testnet? In first place, is there any kind of publicly accessible testnet specifically to test BIP 110? BIP 110 itself doesn't mention anything about it (unless i missed it), it's almost as if the author support idea of "test in production".

[PepeLapiu]

Look, it's not rocket science.

When core rejected an ordinal filter by claiming it's censorship and claiming it's too controversial, that was a signal to malware attackers:

"Come to Bitcoin. We will defend your right to post malware on Bitcoin"

When the head core dev insults monetary bitcoiners by implying we are retarded meat eaters, that was a signal to malware attackers:

"Come to Bitcoin. We have room for you and we will insult those who don't want you here"

When the head dev of core calls malware the "use cases we have today" that us yet an other signal to malware attackers:

"Come to Bitcoin. You are not attackers, you are "new use cases" and Bitcoin is not just boring money anymore. We have room for your dickbutt.jpeg too."

When core devs decided to nuke a long time running malware filter, and they framed the filter as censorship, that was yet an other signal to malware attackers:

"Stay on Bitcoin. We are removing a malware filter for you today and redefining bitcoin as yet an other shitcoin"

Than core started to lose 25% of their nodes to Knots. And core stuck to their guns and did not reverse their retardation, that a signal to malware attackers:

"We care about you more than we care about nodes who enforce the rules of Bitcoin"

We have had enough of coretardation.

[ertil]

Proper testnet?

Exactly, like other BIPs often did, for example Segwit (block 834624 mined on 2016-05-13) or Taproot (block 2013984 mined on 2021-07-08). People tested these BIPs, before enforcing them on mainnet, because they were serious. BIP-110 is not serious, so nobody cares about testing it on any chain, before activation, people want to just fork, and test things in production.

is there any kind of publicly accessible testnet specifically to test BIP 110?

No. If it would be, then BIP-110 enthusiasts would refer to it, and encourage people to use it, to check if their coins are affected, to find any bugs or weaknesses, and so on. But obviously, if you want to reduce the on-chain data, then you don't want to spend your time and resources on a test network, which could be easily invaded by a lot of spammers, who would prove, that BIP-110 cannot stop their spam, and then, Knots testers would need to maintain it. So, obviously they don't want to test things, and reveal, what BIP-110 is really about, and how it could behave in the real network. They want to activate it unconditionally, without letting users to prepare for any of its consequences.

But instead, they would just pretend, that it doesn't block any P2PK outputs, even if it can be easily falsified by reading BIP-110 content, by testing it in any local regtest, and by simply checking the relevant lines of code, where anything bigger than 34 bytes is rejected, which includes 35-byte P2PK compressed keys.

[PepeLapiu]

Proper testnet?

Exactly, like other BIPs often did, for example Segwit (block 834624 mined on 2016-05-13) or Taproot (block 2013984 mined on 2021-07-08). People tested these BIPs, before enforcing them on mainnet, because they were serious. BIP-110 is not serious, so nobody cares about testing it on any chain, before activation, people want to just fork, and test things in production.

Give me a break! Segwit and Taproot were major changes to how Bitcoin operates. On the other hand, BIP110 is relatively small in comparison as all it does is remove some features tgatvare used by malware attackers. And it only does so for a year. Which could be considered as an adequate real life test.

On the other hand, did Segwit and Taproot testnets flush out all the problems, bugs and exploits that turned up?
Yeah, I didn't think so.

I think BIP110 sets a standard for future BIPs. They should all be temporary at first so we can make sure they don't break Bitcoin. But we were too arrogant with Segwit and Taproot and we told ourselves that their won't be any bugs or exploits. Or we told ourselves that core would be enough of a good stewart of Bitcoin and address those bugs and exploits - they didn't. So we will.

is there any kind of publicly accessible testnet specifically to test BIP 110?

No. If it would be, then BIP-110 enthusiasts would refer to it, and encourage people to use it, to check if their coins are affected

If coretards were serious about opposing BIP110, you would put out a reactive fork client and you would offer up a testnet for people to find out how much their coin would get confiscated. But you know full well there is no traction for a reactive fork client and nobody would run it. And you know that a testnet would show people that their coin is not getting confiscated, unless they are malware attackers.

to find any bugs or weaknesses, and so on.

There are no bugs in BIP110. All it's doing is removing attack vectors that nobody who does monetary transactions ever uses. The best testing ground is the 1 year expiration of BIP110.

But obviously, if you want to reduce the on-chain data, then you don't want to spend your time and resources on a test network, which could be easily invaded by a lot of spammers, who would prove, that BIP-110 cannot stop their spam

For the last 5 years all core did is signal to attackers to come set up shop on Bitcoin. BIP110 is the reversal of that malware signalling bullshit core has been doing.

and then, Knots testers would need to maintain it. So, obviously they don't want to test things, and reveal, what BIP-110 is really about, and how it could behave in the real network. They want to activate it unconditionally, without letting users to prepare for any of its consequences.

Question: Did Taproot testnet reveal that attackers could exploit Tapscript to shove jpegs in Segwit?

[ertil]

On the other hand, BIP110 is relatively small in comparison as all it does is remove some features tgatvare used by malware attackers.

Each and every soft-fork removes some features, and has some confiscatory surface. The difference is that Segwit and Taproot invalidated some non-standard transactions, while BIP-110 invalidates P2PK, which is standard since 2009.

And it only does so for a year.

Which doesn't help multisig users at all, if another party would sweep their coins, when their transaction would be blocked by BIP-110.

did Segwit and Taproot testnets flush out all the problems, bugs and exploits that turned up?

You never find all bugs, but if you don't try, then you find even less.

I think BIP110 sets a standard for future BIPs.

It should be standard, to not test things, and check everything in production? It should be standard, to lie about P2PKs not being affected, because BIP-110 supporters never tested it?

If coretards were serious about opposing BIP110, you would put out a reactive fork client and you would offer up a testnet for people to find out how much their coin would get confiscated.

Ignoring BIP-110 rules is enough. Otherwise, it would be active on all testnets we have. But you know you don't have enough hashrate, to launch it even on testnet, not to mention mainnet. And you know, that if you would do that on existing testnets, then a single non-BIP-110 block would fork you to a different chain.

There are no bugs in BIP110.

Blocking P2PK is considered as "not a bug".

The best testing ground is the 1 year expiration of BIP110.

It would be funny, if future BIPs will cause BIP-110 rules to never expire, because all people, who will lose coins because of it, would simply land on a non-BIP-110 chain.

Did Taproot testnet reveal that attackers could exploit Tapscript to shove jpegs in Segwit?

Since Segwit, the maximum size of the witness data is set to 4 MB. By sending coins to future Segwit versions, people can push almost 4 MB of contiguous data since 2017. Taproot didn't change that fact in any way. And before Segwit, people tested 1 MB blocks, full of data, so it was known since then. For example: https://mempool.space/tx/bb41a757f405890fb0f5856228e23b715702d714d59bf2b1feb70d8b2b4e3e08

By the way: this transaction is compliant with BIP-110, so it won't be blocked. If you block it, then you take real funds, from real users. If you don't, then it could be used to push more spam.

Also note, that Segwit discount doesn't matter in case of this example transaction, because the fee is set to zero.

[PepeLapiu]

I think BIP110 sets a standard for future BIPs.

It should be standard, to not test things, and check everything in production? It should be standard, to lie about P2PKs not being affected, because BIP-110 supporters never tested it?

Nobody lied to nobody about P2PK outputs affected by BIP110, it's in the documentation if you bothered to read it.
I was curious, I looked it up. As it turns out txs with P2PK outputs are very rare. According to Grok there were 3 in the last week and 13 in the last month. I was not able to pinpoint which ones. I'm working on getting a list of them. Why do I have the feeling the only people using P2PK obsolete outputs would be malware attackers with fake pubkeys?

In any way, P2PKH outputs are unaffected BIP110.

then a single non-BIP-110 block would fork you to a different chain.

It's called a soft fork, meaning that it will fork to a separate chain on it's own. That's the whole purpose of BIP11O. What do you think the S in RDTS stand for? Sexy? Or Soft fork?

There are no bugs in BIP110.

Blocking P2PK is considered as "not a bug".

P2PK outputs are obsolete. But I'll sit on this until I ha e conducted a scan of the last month's blocks forvP2PK outputs. Wanna bet they all will be at 540 sats or 330 sats?

By the way: this transaction is compliant with BIP-110, so it won't be blocked. If you block it, then you take real funds, from real users. If you don't, then it could be used to push more spam.

Nobody on the anti-malware side claims that BIP110 will kill all malware. That's a strawman argument.

Also note, that Segwit discount doesn't matter in case of this example transaction, because the fee is set to zero.

Bullshit. The Segwit discount doesn't apply because it's 11 years old before Segwit even existed.

[Satofan44]

I agree with everything except the last point.

If we all come nicely together we can change the nature of the universe, the math and physics behind it.

This statement is yours, not mine. I don't know what we can or cannot do. However, I believe that in a free discussion, one of us will be able to come up with interesting proposals regarding the solution to the problem I outlined above. I understand that BIP-110 is not a solution, but that doesn't change the fact that the problem exists. And even if you believe that the problem is theoretically unsolvable, that could be a mistake.

The thing is, it is already established as a side-effect of how information theory works. You simply can not do anything about it, you can put a 100 restrictions of all sorts, invent new restrictions all the time but ultimately there will always be a way to embed illegal data. It is a fundamental way of how information works, you can't just "solve" it to make it not work anymore. If you read enough misinformation shitposts they can mislead you to believe that this is not an issue that comes from math and physics and that it can be fully stopped, but that is a lie. It simply can not. Perhaps in some system that is nothing like Bitcoin maybe, but we can't completely change Bitcoin into something else entirely -- neither from the range of possibilities (even hard forks are limited in their capabilities) now in the risks (nobody sane would vote for this).

Secondly, nobody, and I mean nobody has the goal of completely removing all malware. Everyone understands that it can't be completely stopped. But core is not even trying to reduce malware, they are actually enabling malware.

Getting people to embed data in ways that cause more harm to the blockchain is not a win, stop lying that it is. OP_RETURN is the best solution that we have until someone comes up with something else. You should be thankful that it exists, otherwise we would have fake public keys everywhere.

You fail to recognize that a barn with cats and mouse traps will have fewer mice than a barn without.

If your way of getting rid of mice is to increase radioactivity in the whole house, then the owner of that space won't be happy about it. Killing all life around, only to kill some mice, is simply not worth it. There are limits to what you should do, and after passing some of them, you will start affecting real users more, than the spammers.

Which means, that doing nothing is better than harming real users. And BIP-110 supporters constantly tell us, that it won't affect any users, without testing it properly, checking edge cases, or supporting it by anything else than "I feel like it, because I am not affected, so others also won't be".

Exactly.

• There is already all sorts of illegal data in the Bitcoin chain and in any shitcoin chains.

Not only that, it's exist since a long time ago.

--snip--
It's just an example that i remember right away, there are all kinds of data stored on Bitcoin even since a decade ago[1]. Should i mention that research from few years ago discover some kind of content including hundreds link to child porn[2]? Should i also mention shortly after Ordinal launch, someone use it to add porn/explicit image[3]?

If you run non-pruned Bitcoin full node, your device already store such data.

[1] https://www.righto.com/2014/02/ascii-bernanke-wikileaks-photographs.html#ref14
[2] https://fc18.ifca.ai/preproceedings/6.pdf, section 4.3 Investigating Blockchain Files.
[3] https://crypto.news/bitcoin-ordinals-encounters-explicit-images-days-after-launch/

Good quote and find from the past. Since we can't reasonably ever prove that no illegal data is stored somewhere, the correct assumption is that there is already illegal data. The user can obfuscate it in various ways so that it can only be read/recognized by the intended parties (unless the obfuscation process has been compromised). Even normal transactions could be used for nefarious purposes, for example a system can be set up that checks whether an address received funds in a specific number of sats the system should launch a specific type of attack (e.g. DDoS) as a command central. Should we ban normal transactions too? 

And even if fake pubkey somehow completely filtered (even at cost of filtering less common usage of monetary TX or increase size of all TX), determined spammer would resort adding the data to signature itself.

It is an endless and pointless game with continuing downsides and no real benefits. Instead of working on important matters of Bitcoin, the resources and time of good people would be wasted fighting a war that can not be won because of how the universe works.

[BlackHatCoiner]

What I don't understand is why wasn't BIP110 written to not result in a chain split, in case of minority of hashrate voted for it? Had Luke ever entertained the idea of splitting to a Bitcoin fork, and I missed it? I don't think he ever pushed a Bitcoin fork in the early years.

Honestly, has anyone also had the thought that Luke is a fed puppet?

[PrivacyG]

Honestly, has anyone also had the thought that Luke is a fed puppet?

The most vocal BIP110 supporters are definitely not here to make things better but to rather break Bitcoin.  That is clear.