What would Satoshi say about BIP110?

[d5000]

@PepeLapiu:

I will not accept any proposal which doesn't have an exception for at least one change output. Fearing a single fake pubkey output of a transaction is simply paranoia. And putting more restrictions on that output, like adding some kind of signature, doesn't make sense because we'd then create additional blockchain bloat. We've already discussed that and there is no way I'll change my mind. I'm already WAY too understanding with the poor Knots camp.

I only would support any additional restriction for the change output if and only if:

- that "BIP" is first implemented with the unrestricted change exception for 1 output
- and then REALLY there is a spam wave using that for spam, with over ~20% of blocks filled with data.

Then the additional restriction can be implemented in a second step. But probability for that is close to 0%.

By the way that wasn't your idea but @franky1's idea (yeah, somewhen he has some interesting thoughts). I brought it up in one of our discussions and now you are trying to sell it as yours.

[PepeLapiu]

Imho your claims are short sighted and they are the actually ridiculous ones.

You did not quote or address any of my so-called claims.

For the last 5 years the nodes have been asking for filters, and core was too busy making room for the spam corporations they were financed by.

After 5 years of this shit, spammers and shitcoiners have started to make bitcoin their home. And now you actually think bitcoin is a genuine file sharing network. It's not, it never was, and we are going to make sure it won't be in the future. Don't let the door hit you in the ass on your way out, shitcoiner.

I will not accept any proposal which doesn't have an exception for at least one change output.

There would be an exception for the change output by re-using one of the inputs.

I know, I know, you think it's a privacy leak. It's less than 5,000 sats, stop making a big deal out of it.

Think about it, the vast majority of wallets and users don't care all that much about privacy for <5,000 sats UTXOs when that's all they have left. Those wallets and users will have no problems re-using an input as a change address whenever required. Hell, many wallets still re-use addresses.

The more privacy minded wallets like Samurai, Wasabi, and Sparrow could easily show a warning and offer the user to tack on an other input if available, or re-use an input for change, or give up the change as miner fee (in cases where the change is only a few sats), or even offer to cancel the send.

You are making it a bigger deal than it really is. To me, the biggest inconvenience to users is having a temporarity unspendable sub-dust balance.

I personally care about my privacy. So I would expect my Sparrow wallet to get around the 5000 dust limit by adding more inputs to increase the change address to above 5000 sats. And in the rare case when I have 9000 sats in my wallet, and I end up with a 4000 sats change address, I don't think I would mind at all re-using an input for change. I'm not scared of the NSA breaking down my door and charging me with money laundering over a 4000 sats re-used change UTXO.

Fearing a single fake pubkey output of a transaction is simply paranoia.

I actually don't think fake pubkeys are that much of a problem. To me, the problem is core that conveniently uses the fake pubkeys as a perpetual excuse to make more room for spam. And they keep claiming fake pubkeys can't be mitigated or prevented, that is a lie. My BIP would shut them up and take away one of their excuses for pushing more spam.

And putting more restrictions on that output, like adding some kind of signature, doesn't make sense because we'd then create additional blockchain bloat.

Not really, that signed message could easily be made to expire after a week or so. And it would only be used very seldomly when all you have left in your wallet after a spend, is less than 5,000 sats.

The vast majority of users don't care all that much about privacy. And those who do can easily absorb the minor inconvenience of not being able to spend, or lose the last >5,000 sats balance.

We've already discussed that and there is no way I'll change my mind. I'm already WAY too understanding with the poor Knots camp.

You are wrong to frame it as a "Knots camp" thing. This could be easily sold as a core 30 companion. They keep claiming that op_return is less damaging, and that is their excuse for blowing up the spam filter. Yet everyone understands no existing spammer is going to move to much more expensive op_return. All because "muh fake pubkeys"

I only would support any additional restriction for the change output if and only if:

- that "BIP" is first implemented with the unrestricted change exception for 1 output

I'll think about it. It might be an acceptable compromise.

- and then REALLY there is a spam wave using that for spam, with over ~20% of blocks filled with data.

Stop it. The moment we start talking about fighting spam, it seems to have the effect of reducing spam, albeit likely temporarily. Don't be so short sighted and just wait until it starts getting worst again. And I also thing 20% of spam per block is way too much and unacceptable.

I guaranty it, if you could somehow gun down and silence every monetary maximalist bitcoiner, the spammers would come back in force. Do I need to remind you that less than a couple of months ago, over 50% of blocks were spam?

I brought it up in one of our discussions and now you are trying to sell it as yours.

I came up with the two ideas on my own. But I'm an anon, and I don't care about getting famous or getting credit. I would gladly have someone else read my ideas and implement them himself in his own BIP. I'm not an attention whore.

If I have to take it up on my own, it will be only after BIP110 is over and done. I don't want to compete with BIP110 as I support it.

I think BIP110 will susceed. All it takes is an intolerant minority to be aggresive about it. BIP110 nodes have nothing to lose. They (we) are going to take it to the bitter end. They (we) know that this attack needs to be curtailed if bitcoin is to survive in the long run.

I expect the spam to gradually die down until August when BIP110 is activated. There is still a non-zero chance that BIP110 fails. If so, unless we keep fighting, the spam will gradually come back.

Not gonna happen on my watch.

[ABCbits]

Personally i would also add change that make script that contain parts that impossible to be executed as non-standard or invalid.

How do you know, if something is "impossible to be executed"?

In some cases, like OP_RETURN, or "OP_FALSE OP_VERIFY", you can be sure about it.

I totally forget Bitcoin scripting can be really weird or unusual. Only using known cases (such as one you mentioned) could work, but it would lead to "cat and mouse".

But in that case, it should limited to 1 new UTXO rather than last UTXO since it would reduce privacy.

I think this would be no big difference, but how is it more privacy friendly? I think that if only one of the outputs isn't "dust limited", the ordering doesn't really matter. Or am I wrong?

I was assuming more wallet developer would simply use last output as change, no matter it above or below limit. If that happens, blockchain analyzer can have higher certainty with their analysis.

[PepeLapiu]

But in that case, it should limited to 1 new UTXO rather than last UTXO since it would reduce privacy.

I think this would be no big difference, but how is it more privacy friendly? I think that if only one of the outputs isn't "dust limited", the ordering doesn't really matter. Or am I wrong?

What I propose is that the only output that would be allowed exception to the dust limit would be if you re-use an input as change address.

Wallets and users that don't care about the privacy for a <5000 UTXO would do this automatically whenever the change output is below the dust limit

Wallets that do care about privacy would have several options:

- Warning window telling the sender one of his input will be re-used and this could cause a minor privacy leak.

- Warning window telling the sender his change will be forfeited to the miner. In this case the miner fee could be set to 0sat/vB plus the <5000 sats change.

- Warning window (or automatically done) to add an other input as to increase the change output to >5000 sats.

- Warning window with a combination of any of the above.

In any case, I think you are wrong to frame it as confiscation without addressing the fact that this is already happening. If have 2000 sats and I attempt to send you 1600 sats plus 100 sats miner fee, my Electrum Android wallet donates(or confiscates?) the remaining 300 sats to the miner.

This would still happen with my suggested BIP. But due to the larger amount a good wallet would give you options and warnings.

The two bigger inconveniences of my proposal is that a balance of <5,000 sats would become temporarily unspendable. And you would not be able to send anyone less than 5000 sats.

The change output limit is really a much smaller inconvenience in my views. If the wallet is designed properly.

An other more complicated option if you really want to send me 4000 sats, would be to do a multisig. We both commit 1000 sats to the multisig. You get 6000 sats change output (minus fee). And I get the 1400 sats spend.

@PepeLapiu:

I will not accept any proposal which doesn't have an exception for at least one change output. Fearing a single fake pubkey output of a transaction is simply paranoia.

I don't really fear fake pubkeys. In fact if fake pubkeys were the only spam option, it's likely the spammers would be far fewer as fake pubkeys are more expensive than the Segwit and Taproot exploits.

What I fear is core using the fake pubkeys FUD as an excuse to give up more space to the spammers.  

Core claims that fake pubkeys can't be stopped. They are wrong, they are lying. My proposal would greatly reduce unspendable fake pubkeys (but not spendable fake pubkeys). And other ideas could completely prevent fake pubkeys.

For example, it could be required that every output be either a re-used input, or with a signed message. The signed message could be made to expire after a week or so to prevent chain bloat. Or the message could be made to automatically expire once the tx is confirmed. But this would require a major overhaul of all wallets. I don't think we need to go that far as fake pubkeys is not a big problem in my book. It's the core fake pubkeys FUD I dislike the most.

If I tell you that I don't like the spam, that's a huge understatement.
I'll add that it saddens me greatly that Core did this move - and they did it in this way.

You can claim all you want you don't like spam and you don't like what core is doing. But if you allow it and don't do anything as a reaction, that is a de facto support of spam and support of core wrecklesness.

However, adding censorship - for any good reason now - is the road to perdition, so a big no.

It's ridiculous to frame anti-spam as censorship. Nobody is attempting to stop anyone from buying and selling dickbutt jpegs. You can use bitcoin to buy and sell pancakes and dickbutts. But neither your pancakes nor your dickbutts belong on the bitcoin chain.

What you are basically arguing is that a Muslim should be able to praise Allah in a Jewish temple or church, and anyone resisting it is depriving him of his freedom of religion.

Today you filter spam, next you filter "dirty" coins, soon afterwards you filter this or that country, ... sounds like a bright future, isn't it?

Can we please stop pretending that the 90,000 nodes are so stupid and don't know the difference between a dickbutt jpeg and banning Iranian UTXOs?

Given this, depicting everything in black and white, in "this side holding the truth" and "the other side liars and c***d p**n lovers" is also just as bad and wrong.

Citation needed. You are the first one in this thread to bring up child p**n and that one side or the other holds the truth.

Adding Satoshi name into the equation is just a cheap attempt to manipulate the mobs, hence I will not guess for you.

Just because you don't like what he said doesn't make it cheap manipulation.
If you disagree with Satoshi, and if you think Bitcoin should open the doors to "use cases we gave today" (aka spam) please say so.

[DaveF]

Just going to put this out there:
https://www.theblock.co/post/391667/developer-embeds-image-on-bitcoin-as-a-single-transaction-challenging-bip-110s-core-claims

So yeah, OP_return limits are totally going to work. Insert eye-roll here.

-Dave

[l8orre]

ECDSA can't encrypt messages, only sign signatures.

It would be unwise to have permanently recorded plaintext messages for everyone to see.  It would be an accident waiting to happen.

If there's going to be a message system, it should be a separate system parallel to the bitcoin network.  Messages should not be recorded in the block chain.  The messages could be signed with the bitcoin address keypairs to prove who they're from.

I hope this answers that question.

[NeuroticFish]

1. I will try to avoid doing you the favor of quoting you.
2. I don't expect you would understand or care about my arguments, your main focus is to find - no matter how weak that is - proof in your favor.
3. Your latest long post only shows how oblivious you are on what is actually happening. Quite shame, but I guess that's nothing I can do.

Just going to put this out there:
https://www.theblock.co/post/391667/developer-embeds-image-on-bitcoin-as-a-single-transaction-challenging-bip-110s-core-claims

So yeah, OP_return limits are totally going to work. Insert eye-roll here.

-Dave

Nice one, but they will probably do their best to find an explanation for it and wrap it as good as possible so the "knots team" would believe it.

[BlackHatCoiner]

What I fear is core using the fake pubkeys FUD as an excuse to give up more space to the spammers.

Somehow you have to explain how Core allowing the default value of the OP_RETURN size allows more space to the spammers, when using OP_RETURN is a lot more expensive than just sticking with the Segwit discount.

You are either unaware that OP_RETURN is more expensive, or you think that the spammers act irrationally and prefer to throw money into the trash. In either case, Core is not giving more space to the spammers, as they already have the ability to spam at a certain price.

[PepeLapiu]

Just going to put this out there:
https://www.theblock.co/post/391667/developer-embeds-image-on-bitcoin-as-a-single-transaction-challenging-bip-110s-core-claims

So yeah, OP_return limits are totally going to work. Insert eye-roll here.

-Dave

Here is the important part to consider:
OP_RETURN limit doesn't prevent all spam just like getting a cat doesn't kill all mice.
But a barn with cats will have fewer mice than a barn without cats. A barn without cats eventually gets completely infested with mice.

And the example stated in your link was a direct submission to Mara's SlipStream. This us important to understand. Because jpeg hosting service is not a bitcoin sanctioned used case, these attackers have to obfuscate their jpeg to look like a generic bitcoin monetary transaction. And in this case, he had to bribe a miner to accept it because the network itself would have rejected the tx as an out of band transaction.

BTW, whenever you hear "out of band transaction" just know that it's a politically correct way of saying spam.

Now, this in important. The fact that he had to bribe a miner to confirm his spam shows you that before core 30, putting contiguous illicit files on chain was basically next to impossible. Unless you think Mara is retarded enough to fill their blocks with child porn for a $5 fee.

But since core 30, putting illicit material on chain is now a supported use case. It is now effectively possible to post something illegal or immoral on chain and force the 90,000 nodes into downloading it, hosting it, and sharing it until the end of time. And we have core to thank for that.

Furthermore, nobody claims we can stop all spam. Nobody claims that BIP110 will prevent all spam. So the example in your link is the equivalent of saying an intruder broke your window to get in, therefore your front door lock failed at preventing intruders. It's a stupid arguement.

Somehow you have to explain how Core allowing the default value of the OP_RETURN size allows more space to the spammers, when using OP_RETURN is a lot more expensive than just sticking with the Segwit discount.

Core removing a spam filter will result in more spam. That is a fact. I'm sorry I have to state the obvious to you. Yes, I agree, op_return is generally more expensive than other means of spamming bitcoin. So the existing spammers are not likely to move from other methods to op_return. What core did is create a new way to spam bitcoin and it's now waiting for spammers to figure out a new way of spamming bitcoin with op_return.

But most importantly, before core 30, file sharing was never an actual sanctioned and supported use case of bitcoin. The only use case of bitcoin was always only money. Sure, you could post a jpeg, but you would have to use fake pubkeys, fake scripthash, or use the Segwit exploit, or the Taproot exploit, or bribe miners with spamware like SlipStream and LibreRelay.

But core 30 effectively made bitcoin a monetary network AND an illicit file sharing network. You no longer need to trick the system into thinking your spam is a monetary transaction. Now uploading illicit files is a use case sanctioned by core 30.

First, they claimed that the filter doesn't work.
Than they claimed they had to remove the filter in order for some people to use large op_return. Which basically contradicts the idea that the filter didn't work.
And now the claim is that nobody is going to use op_return because it's too expensive. So why blow up the filter in the first place, if nobody's going to use it?

You are either unaware that OP_RETURN is more expensive, or you think that the spammers act irrationally and prefer to throw money into the trash. In either case, Core is not giving more space to the spammers, as they already have the ability to spam at a certain price.

You are correct, op_return is more expensive than most other methods of spamming bitcoin. Everyone understands that. Which tells you that core removing the filter under the premise that it's less damaging than other spamming methods, that is very suspicious.

There are ways to stop or mitigate fake pubkeys. But core is not intetested in doing any of them. Because they want to keep using fake pubkeys as perpetual FUD to cater to spammers.

1. I will try to avoid doing you the favor of quoting you.

Yes, of course. Personal attacks on complete strangers and ad hominem are so much easier than addressing what I actually say.
 

[DaveF]

Oh, and you can also mine the image into a block using knots

https://knotslies.com/#update---the-bip-110-compliant-variant

So there is that too.

-Dave

[Easteregg69]

What I fear is core using the fake pubkeys FUD as an excuse to give up more space to the spammers.

Somehow you have to explain how Core allowing the default value of the OP_RETURN size allows more space to the spammers, when using OP_RETURN is a lot more expensive than just sticking with the Segwit discount.

You are either unaware that OP_RETURN is more expensive, or you think that the spammers act irrationally and prefer to throw money into the trash. In either case, Core is not giving more space to the spammers, as they already have the ability to spam at a certain price.

BRC20. It has a name. Not spamming.

Some did not buy eth.. And here we go. Their shit is better.

[d5000]

@PepeLapiu: You still don't understand. Your "BIP" has zero chances to get any support in this state. A BIP is a collaborative effort, not a "brilliant idea" of someone who thinks that their thoughts are so genius everybody must accept them as they are without discussion. (Even Satoshi, who was a genius, or a group of geniuses, accepted suggestions.)

You drastically overestimate how big the tiny Knots bubble is (perhaps due to the 5800 VPS nodes, which may mislead people who don't do the research properly). I just did a search of "BIP-110" in the Bitcoin Reddit and there were literally zero results. Nobody outside a very small X bubble considers this BIP serious, and I guess the vast majority are sockpuppets of Luke and his Ocean buddies. Well, some at r/btc (the other tiny bubble, butthurt BCash folks who now have turned full-on anti-Bitcoiners) have talked recently about "BIP"-110. And they have of course their own tiny subreddit.

The same fate will happen to your authoritarian dust BIP which would cripple Bitcoin as a payment means if you don't craft it in a way ... it doesn't cripple the payment functionality, which includes the possibility to retain change coins. . Requiring to re-use an address to be able to retain change doesn't make any sense, and much less in an era of quantum computers.

[PepeLapiu]

@PepeLapiu: You still don't understand. Your "BIP" has zero chances to get any support in this state.

There is a non-zero chance that BIP110 will fail, sure. But do.you want to be on the good side of things, or on the popular side of things?

And there is no fail. If we fail the first time, spam will get worst, and illicit material will get on chain at some point. That's when we pull out the "Told you so" giant foam finger and bring in BIP110 2.0.

The same fate will happen to your authoritarian dust BIP which would cripple Bitcoin as a payment means if you don't craft it in a way ... it doesn't cripple the payment functionality, which includes the possibility to retain change coins. .

Nobody will be required to re-use an input for change. That is ridiculous. I enumerated several options that could be implemented. Re-using an input address is just one of those options.

I know of at least two wallets that still re-use addresses for change. While I disagree with that practice, I can't deny it's something some wallets are already doing and will keep on doing, regardless of my BIP occurring or not.

The only two inconveniences to the users is that a small <6000 sats balance would be temporarily unspendable and <5000 sats spends would require the use of multisig.

Requiring to re-use an address to be able to retain change doesn't make any sense, and much less in an era of quantum computers.

STFU with the quantum FUD already. Even if that was a real danger, we are talking about a change UTXO of <5000 sats or <$3.35 USD at current price. And input re-use is only one of the many options available to wallets and users.

Before core 30, it may have been technically possible to post contiguous illicit material on chain. But it was for all practical purposes virtually impossible, unless you could bribe a miner to put it in his block. And what are the chances that spam miners like Mara or F2Pool would be willing to fill their blocks with child porn for a few $5 fees?

With core 30 spamware, that is now possible without going through a miner. And it will absolutely happen at some point. Here are the different actors most likely to do this:

- A state agency or a central bank wanting to discredit or slow down bitcoin

- A degenerate who doesn't want the legal risk of keeping that stuff on his drive and chooses to dump the legal risk onto the 90,000 nodes who will be forced to download it, host it, and share it.

- A shitcoiner who thinks this might promote his own shitcoin

- A trader with a large BTC put position who would benefit from the resulting drop in price.

- Even someone on my side who might want to do it to push for Knots and BIP110 adoption.

The fact is, it will happen. Someone will post illicit immoral and disgusting material in op_return. It's not an "if" but a "when".

Oh, and you can also mine the image into a block using knots
https://knotslies.com/#update---the-bip-110-compliant-variant
So there is that too.
-Dave

You are ignoring the fundamental difference between Knots and Core.

Core node runners don't have a mempool policy, they adopt whatever the enforced centralised mempool policy if core is. If core decides to blow up the op_return filter, than you must do as they say, unless you can play around with code and edit .config files, which the vast majority of us don't know how to do.

With Knots, there is no such thing as a centralised mempool policy imposed on the users by Luke. You get an easy tab with clickable sliders where you can configure all your filters yourself. So you could configure your Knots node to operate the same way a LibreRelay or core node operates.

Core is the dictator of your node's mempool policy, but you control your own node with Knots

[ABCbits]

Requiring to re-use an address to be able to retain change doesn't make any sense, and much less in an era of quantum computers.

While also give headache to both wallet developer and user (who manually specify all outputs).

And there is no fail. If we fail the first time, spam will get worst, and illicit material will get on chain at some point. That's when we pull out the "Told you so" giant foam finger and bring in BIP110 2.0.

Before core 30, it may have been technically possible to post contiguous illicit material on chain. But it was for all practical purposes virtually impossible, unless you could bribe a miner to put it in his block. And what are the chances that spam miners like Mara or F2Pool would be willing to fill their blocks with child porn for a few $5 fees?

Unfortunately, it already happened since more than a decade ago. Some of those method doesn't require miner to manually add the TX either.

--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/

[PepeLapiu]

Unfortunately, it already happened since more than a decade ago. Some of those method doesn't require miner to manually add the TX either.

Someone is not paying attention here. BIP110 doesn't aim at stopping all spam of all kinds. It aims at stopping contiguous data. Your examples are not contiguous data. A mere link to something is not a file stored on chain.

After BIP110, other things will be done to prevent more spam. Like The Cat for example and maybe my own idea.

Let me make an analogy here. Let's say I send you an email and in the body of the email, not in attachment, I embed a few pixels of a picture. You won't even detect that I have sent that to you, you will just read the email as if it were a normal email.

Than I send you 50 other emails all with embedded pixels. And if you were to decode them and put them together, you would get the picture of a kitten.

Nobody is going to detect you have a kitten jpeg on your drive. There is not a scan that can find out you are hosting kitten jpegs. Because I embedded it in the body, not as an attachment.

Op_return is like sending you a whole picture of a kitten as an attachment.

Sure, you can go back and find out in one email, I sent you a link to a kitten jpeg. But you are still not having a kitten jpeg on your drive.

Op_return is an attachment of the entire file in one piece. The purpose of op_return since core 30 is to send entire contiguous files on chain. Any file you desire.

While also give headache to both wallet developer and user (who manually specify all outputs).

It"s only a mild nuisance if you have a low balance near the dust limit. And if you want to construct yoyd own txs manually, that is your own choice to make things more complicated for yourself.

[PepeLapiu]

Just going to put this out there:
https://www.theblock.co/post/391667/developer-embeds-image-on-bitcoin-as-a-single-transaction-challenging-bip-110s-core-claims

So yeah, OP_return limits are totally going to work. Insert eye-roll here.

-Dave

Have you noticed that every single instance of this hit piece fails to give a link to the tx in mempool.space?
Doesn't that strike you as a bit strange?

If you look it up, you will find this is the link to the tx:
https://mempool.space/tx/b8cc570ef453508b6c6a1758bc591c276abdbe2b88881ae487ba4e858bd8d4be

Most importantly, you should notice that it's a nonstandard tx and that it was not seen in mempool.

What that means is that he had to bypass the network and submit it directly to Mara with a bribe.

Now, it deeply disturbs me that Mara is ignoring the policy of the network and attacking the network this way. I think Mara is acting in a malicious way here.

But you have to undsrrstand there are already hurdles put in place to prevent this spam and Mara just decided to ignore them all and cater to the spammer.

But I ask you, what do you think Mara would say if you asked them to put illegal child porn in their block for a $5 fee?

Yeah, with BIP110, it will still be possible to post data in Segwit in a continuous manner. But it will be exceedingly difficult to post illicit and objectionable material on chain, unless you can find a miner willing to go against the will of the nodes and stuff his own blocks with illicit material.

And I think we should deal with this problem of miners accepting direct submission for spam.

[DaveF]

......

Most importantly, you should notice that it's a nonstandard tx and that it was not seen in mempool.

What that means is that he had to bypass the network and submit it directly to Mara with a bribe.

.....

Yeah, whatever. It can be done quite as a BIP110 transaction.

https://knotslies.com/#update---the-bip-110-compliant-variant

Look at it this way, you can keep trying to censor things. It's looks like real programmers can have some fun showing how it does not work.

-Dave