Core and spam debate - easy explanation

[Dogedegen]

But hoping every wallet follow same rule unlikely to happen, when some wallet either lagging behind or never implement certain feature.

It is impossible, especially with wallets that have many shitcoins and tokens on them. We may not be favorable to those here but they have huge user bases and are often also lagging behind in changes that may not be urgent.

Nothing you can do to stop those.

Well, you can require some Proof of Work: fees are not the only way to pay for things. But then, it would negatively affect real payments.

Well, does that really stop them or does it just discourage them by making them more expensive? At the same time as you said it punishes everyone else too, but it does not completely eliminate the issue either.

Fake pubkeys can be mitigated, and even completely suppressed if the need be.

If you reject fake public keys, then the recipient would need to sign things, to receive a new payment. Which makes it harder to send things, when one side is offline.

It is not really possible to reject fake public keys in practice, but the user will not be convinced of this. It seems that he will insist in whatever he thinks is true. Posts like you have written are a good learning opportunity, but some simply will not have it. They always know better instead of being thankful for the knowledge shared.

Private keys are not stored on chain, so feel free to make as many fake private keys as you want.

If you have weak public keys, then you can easily get the private key, by breaking a weak signature. And then, it is equivalent to storing private keys directly on-chain, just it takes more space than usual. Another way is to store data just in signatures, then it is even more efficient.

Stuff like what you posted here and under a code block is very interesting, a bit above my level but thank you for sharing.

In this case, even if you replace the original data with something else, then still: it is guaranteed, that it would take at least N bytes, or would be stored in the UTXO set forever.

Also, I wonder, how many spammy transactions were created, just because of the drama. Because if nobody would point out, that there is a problem with the spam, then some of these things would never be created.

I think there was a thread by someone here it tracked OP RETURN total data and also I think since Core raised the limits. It turns out to be a very small amount of data for a whole year, so it seems that those that were the loudest about this didn't even invest resources to make their case more believable.

[ertil]

It is not really possible to reject fake public keys in practice, but the user will not be convinced of this.

Let's test some of that in practice:

Code:

message="It is hard to stop fake public keys, because of pubkey recovery."
hex=4974206973206861726420746f2073746f702066616b65207075626c6963206b6579732c2062656361757365206f66207075626b6579207265636f766572792e
r=hex1=4974206973206861726420746f2073746f702066616b65207075626c6963206b
s=hex2=6579732c2062656361757365206f66207075626b6579207265636f766572792e
R=024974206973206861726420746F2073746F702066616B65207075626C6963206B
der_signature=304402204974206973206861726420746f2073746f702066616b65207075626c6963206b02206579732c2062656361757365206f66207075626b6579207265636f766572792e01

And now, we can make an output, where it is spendable, by using public key recovery:

Code:

decodescript 47304402204974206973206861726420746f2073746f702066616b65207075626c6963206b02206579732c2062656361757365206f66207075626b6579207265636f766572792e017cac
{
  "asm": "304402204974206973206861726420746f2073746f702066616b65207075626c6963206b02206579732c2062656361757365206f66207075626b6579207265636f766572792e01 OP_SWAP OP_CHECKSIG",
  "desc": "raw(47304402204974206973206861726420746f2073746f702066616b65207075626c6963206b02206579732c2062656361757365206f66207075626b6579207265636f766572792e017cac)#fxccq8z3",
  "type": "nonstandard",
  "p2sh": "2NAzfa1UgFPWfwX1evSCLJUfHioU2J1oxYq",
  "segwit": {
    "asm": "0 e49deb0a6b5809269f4c39c2e4b263c68c9a40d34c4c765cb3c202ffaee80dc1",
    "desc": "addr(tb1qujw7kznttqyjd86v88pwfvnrc6xf5sxnf3x8vh9ncgp0lthgphqsyafmn7)#8927qgsx",
    "hex": "0020e49deb0a6b5809269f4c39c2e4b263c68c9a40d34c4c765cb3c202ffaee80dc1",
    "address": "tb1qujw7kznttqyjd86v88pwfvnrc6xf5sxnf3x8vh9ncgp0lthgphqsyafmn7",
    "type": "witness_v0_scripthash",
    "p2sh-segwit": "2N21f2d1LkHfDgbCnrEDDVWyYZ3rWmFsXVV"
  }
}

Which means, that by sending coins to tb1qujw7kznttqyjd86v88pwfvnrc6xf5sxnf3x8vh9ncgp0lthgphqsyafmn7, we can push that data on-chain, because they will be just encoded into the signature. Let's spend that in practice: https://mempool.space/signet/tx/7cf7a21e3e2b6e7381bf6438e1a76b3c239f896e48ba8500c83f187a4c42598c

As you can see, there is some fake public key 0382782bf703c61db99280b27c088da84fde58308648eb2c64a7e6488c718f9d23 where nobody knows the private key. And the signature contains the message. For R-value, we have 024974206973206861726420746f2073746f702066616b65207075626c6963206b, which means, that nobody knows the k-value behind it. Also, as you can see, s-value can store yet another payload, without breaking SHA-256, or anything like that.

So, to sum up: there are some fake public keys flying around, but all of that passes ECDSA verification. And there are more possible tricks, than just that.

[ABCbits]

--snip--
Than also a more complicated one would require every output to have a specific signed message. This could be done automatically in the background by the wallets without the user even being aware of it. And to prevent chain bloat the message could have an expiry date of 24 hours or a week or so.

If there's expiry date, i would guess the signed message isn't stored on blockchain. So if i understood the idea correctly, it means future node can't perform that verification.

But hoping every wallet follow same rule unlikely to happen, when some wallet either lagging behind or never implement certain feature.

With my idea of raised dust limit, those wallets not updating would not work properly, or cause user funds loss. In the second case, those wallets not updating to it would not work at all. So wallets would be forced to update.

This is the only con to that idea, forcing every wallet to update to the new rules.

Looking at some past technical support, i expect some users would be angry with/without knowing wallet they use isn't updated by developer yet if your idea become reality.

[PepeLapiu]

So let's look at the different ways to fight spam and fake pubkeys.

First, you got Knots filters which can only really work if there is over 80% of the nodes running them. No bitcoin wallet devs would need to adapt to the filters. And getting to over 80% of Knots nodes would be a gradual process anyways, if it happens.

Than you got The Cat which would essentially rug the spammers and remove their UTXO from the UTXO set. No bitcoin wallets need to adapt to any of this, unless they are widely used by spammers.

Than you got the BIP-110 which only goes after two of those most egregious ways of spamming bitcoin. To my knowledge only Nunchuk wallet would need to adapt. And spammer wallets too of course, but that's the point of it all. If spam wallets and spammers get upset, they can cry me a river.

Than you got my proposal of raising the dust limit to 5,000 sats and limiting Segwit data to 200 bytes per input. Wallets would still function with my proposal, but it would cause some tx's to be rejected by the network, or cause the user to lose their 5,000 sats outputs if not careful.

Than you got the idea of forcing all outputs to have a time expiring signed message. That one would be the most effective against spam, but also the one that would cause the most trouble to wallet devs. Their wallet won't work until they implement the new restriction. So that is an incentive right there. And you could always switch to a wallet that does properly update. It's not like youe coin is gone if your wallet doesn't update.

But in the end, fake pubkeys are not that big of a problem to me. The real problem is core not willing to do anything about fake pubkeys while using fake pubkeys as an excuse to cater to spammers.

Looking at some past technical support, i expect some users would be angry with/without knowing wallet they use isn't updated by developer yet if your idea become reality.

The users could always switch to a wallet that updated properly, and the aalket devs would be incintivised to update as to not lose users.

In any way, it's a bit stupid to deny ourselves a beneficial upgrade just because we fear wallet devs might not upgrade.

[ertil]

First, you got Knots filters which can only really work if there is over 80% of the nodes running them.

If a single miner will confirm all filtered transactions, then it won't work.

Than you got The Cat which would essentially rug the spammers and remove their UTXO from the UTXO set.

First, it has a misleading name, and many people think about reintroducing OP_CAT, when they read it. And also, confiscating UTXOs will harm regular users, because it may turn out, that some regular use cases will be blocked as well. For example: if using things like OP_IF is forbidden, then it may hit regular users, in simple use cases, like "if this timelock is valid, then use Alice's key, otherwise Bob's key".

Than you got the BIP-110 which only goes after two of those most egregious ways of spamming bitcoin.

Which still doesn't stop the spam, and where valid TIFF files can be used to push images, while also being BIP-110 compliant.

Than you got my proposal of raising the dust limit to 5,000 sats

Dust limits were never in consensus rules. And if they will be, then if the price per coin will increase, it will be impossible later to lift these limits. And then, there will be some centralization pressure, because then you will have to share UTXOs, to process any smaller payments.

Also, introducing any dust limit into consensus, will block all features, where coin amounts could be hidden. And of course, it will also hit anchors, used by Lightning Network, where you can have a transaction with zero fees, and where the next transaction uses CPFP to pay the proper fees (because then, you don't have to predict them in advance).

Than you got the idea of forcing all outputs to have a time expiring signed message.

If it will expire after some time, then it will be impossible to verify the history later. Also, it would force users to move coins, before these things will expire, or otherwise, they will be unspendable. Which means, that it is a hidden way to confiscate all coins in all cold storages, because if nobody will touch them, then they won't have such signatures, so they won't be spendable under new rules.

Another thing is if you force users to make signatures, or move their coins, then you will have more spam, not less. Because people will be forced to make self-payments, only to keep their coins spendable (which they don't have to do in the current consensus).

It's not like youe coin is gone if your wallet doesn't update.

So, how do you know, if some output was never signed, or if the signature simply expired? You don't. If nobody can give you that signature, then you don't know, if it was ever there in the first place.

The real problem is core not willing to do anything about fake pubkeys

If protecting your house means destroying all walls in the process, then it is not worth it. In case of fake public keys, the cure is worse than the disease, and if you block them, then your coin will be worth less, than it currently is. For example because offline payments will be more difficult to do, than they currently are.

it's a bit stupid to deny ourselves a beneficial upgrade just because we fear wallet devs might not upgrade

If you require making signatures, or moving coins, to not lose them, then it is not "a beneficial upgrade". It produces more data in the process, so there will be more spam, not less, if such idea will be implemented.

What takes more bytes: fake public keys alone, or fake public keys with fake signatures?

I already gave you an example: https://mempool.space/signet/tx/7cf7a21e3e2b6e7381bf6438e1a76b3c239f896e48ba8500c83f187a4c42598c

If such output is left as it is, then it takes only 32 bytes of P2WSH. If it is spent, then it produces around 100 bytes, where you have a fake signature, with a fake public key, and all of that is valid.

So, what do you want? Some UTXO with fake pubkey, taking 32 bytes, or some transaction, taking around 3x more on-chain space for every such input?

[ABCbits]

and limiting Segwit data to 200 bytes per input

That's crazy. It would make some some Bitcoin no more spendable, including N-of-M multisig address with high total of N + M.

Looking at some past technical support, i expect some users would be angry with/without knowing wallet they use isn't updated by developer yet if your idea become reality.

The users could always switch to a wallet that updated properly, and the aalket devs would be incintivised to update as to not lose users.

In any way, it's a bit stupid to deny ourselves a beneficial upgrade just because we fear wallet devs might not upgrade.

You overestimate technical knowledge and willingness to change wallet among average people who own Bitcoin. Besides, previous update (such as SegWit or Taproot) doesn't make people lose their coin even if wallet they use doesn't support either.

[PepeLapiu]

Looking at some past technical support, i expect some users would be angry with/without knowing wallet they use isn't updated by developer yet if your idea become reality.

That's the wallet dev problem to deal with.

and limiting Segwit data to 200 bytes per input

That's crazy. It would make some some Bitcoin no more spendable, including N-of-M multisig address with high total of N + M.

Can you show an example of this on mempool.space?

You overestimate technical knowledge and willingness to change wallet among average people who own Bitcoin. Besides, previous update (such as SegWit or Taproot) doesn't make people lose their coin even if wallet they use doesn't support either.

Nothing would cause any users to lose any coin with the signed output idea. The network would just reject your tx until you either change wallet, or wait for your wallet devs to catch up.

If the change made their wallet unusable, devs would be incentivized to catch up.

In any case, the signed output method is the most drastic method of mitigating fake pubkeys. And not my favorite one.

I would prefer to raise the dust limit to 5000 sats with an exception to reusing an input as change output. Maybe the Cat, maybe the Lynx.

Point being, core keeps claiming fake pubkeys can't be fought against. They are lying.

Fake pubkeys can be completely eliminated with the forced signed outputs idea. And they can be mitigated with other methods.

If a single miner will confirm all filtered transactions, then it won't work.

You are completely ignoring how filters actually work and how putting out of band txs in their blocks could be costly to the miners.

Out of band txs slow down the block propagation speed of the specific block. If there is only one small out of band tx in the block, not a bog deal. But as the amount of out of band txs increase in that block, the propagation speed increases and the miner risks getting his block orphaned.

Even core acknowledges this as they say that when the nodes policy don't match with what miners put in their blocks, propagation speed is decreased. What core fails to say is that this only affects spam miners.

Than you got The Cat which would essentially rug the spammers and remove their UTXO from the UTXO set.

First, it has a misleading name, and many people think about reintroducing OP_CAT, when they read it.

Now, you are being stupid. Only very technical people would make that connection. I think that coretards keep making the stupid analogy that fighting spam is a useless cat and mouse game. They fail to recognize that a barn with cats has fewer mice than a barn without cats. The Cat was likely named that way to poke fun at the stupid analogy.

And also, confiscating UTXOs will harm regular users, because it may turn out, that some regular use cases will be blocked as well. For example: if using things like OP_IF is forbidden, then it may hit regular users, in simple use cases, like "if this timelock is valid, then use Alice's key, otherwise Bob's key".

You are making no sense at all and mixing up proposals. The Cat does not address or touch any op_if. That's BIP110, which I also support. But I digress. No bitcoin monetary users would he affected by The Cat. Do your research.

Than you got the BIP-110 which only goes after two of those most egregious ways of spamming bitcoin.

Which still doesn't stop the spam, and where valid TIFF files can be used to push images, while also being BIP-110 compliant.

BIP110 can't stop all spam. Nothing can stop all spam just as cats can't prevent a mouse from entering a barn. But a barn with cats will result in fewer mice. That is a fact.

And it's really stupid to claim that JPEGs could be switched with TIFFs. That still would be an out of band tx, and you still would have to bribe a miner to put that junk in his block. I'm sure you can find a miner to bribe and put a crying Luke TIFF in his block. But try that with illicit and disgusting material such as child p**n and see how far you get.

Than you got my proposal of raising the dust limit to 5,000 sats

Dust limits were never in consensus rules. And if they will be, then if the price per coin will increase, it will be impossible later to lift these limits. And then, there will be some centralization pressure, because then you will have to share UTXOs, to process any smaller payments.

I'm not going to discuss my full proposal here. But my proposal would make the dust limit at 5000 SATs at the consensus level. So spam mines would not be able to bypass it. And it would decrease by half at every halvening. So 2500 SATs dust limit after the next halvening, and 1250 SATs after the next halvening, and so on....

Also, introducing any dust limit into consensus, will block all features, where coin amounts could be hidden. And of course, it will also hit anchors, used by Lightning Network, where you can have a transaction with zero fees, and where the next transaction uses CPFP to pay the proper fees (because then, you don't have to predict them in advance).

Two types of outputs would be example from the dust limit: the miner fee (which isn't really an output) and if one of the outputs re-uses and input for change. Since a few wallets are still re-using addresses. And on some cases the user might not care about the privacy set of <5000 SATs.

The user or wallet would also have the option to add more inputs to increase the change to >5000 SATs.

Than you got the idea of forcing all outputs to have a time expiring signed message.

If it will expire after some time, then it will be impossible to verify the history later. Also, it would force users to move coins, before these things will expire, or otherwise, they will be unspendable. Which means, that it is a hidden way to confiscate all coins in all cold storages, because if nobody will touch them, then they won't have such signatures, so they won't be spendable under new rules.

You are not making any sense at all. I'm starting to think you are either stupid, or you think I'm stupid, or you are in bad faith.

If I give you an address, me wallet signs a message to thar address. And you have, say one week, to name your spend to that address, until the signed message expires. If there is no signed message, or if you send after the message expires, your tx is denied by the network and you still have your coin safe in your wallet.

You just like to use the confiscation FUD brush on everything, don't you?

Another thing is if you force users to make signatures, or move their coins, then you will have more spam, not less. Because people will be forced to make self-payments, only to keep their coins spendable (which they don't have to do in the current consensus).

You make no sense. Only outputs would need to have a signed message, not inputs.

It's not like youe coin is gone if your wallet doesn't update.

So, how do you know, if some output was never signed, or if the signature simply expired? You don't. If nobody can give you that signature, then you don't know, if it was ever there in the first place.

You make no sense at all. If I give you an address that does not have a signed message, your tx will be rejected by the network as the address I gave you is a possible fake pubkey.

The real problem is core not willing to do anything about fake pubkeys

If protecting your house means destroying all walls in the process, then it is not worth it. In case of fake public keys, the cure is worse than the disease, and if you block them, then your coin will be worth less, than it currently is.

Yup, that is a coretard talking point: "We have to allow jpeg and other spam on bitcoin for bitcoin to survive, and even go as far as blowing up existing working spam filters."

Sorry, not buying it.

it's a bit stupid to deny ourselves a beneficial upgrade just because we fear wallet devs might not upgrade

If you require making signatures, or moving coins, to not lose them, then it is not "a beneficial upgrade". It produces more data in the process, so there will be more spam, not less, if such idea will be implemented.

Stop spewing bullshit. Nobody would have to move any coin or sign any message in order to not lose their coin. You are in bad faith or you don't understand what you are talking about.

What takes more bytes: fake public keys alone, or fake public keys with fake signatures?

A fake pubkey is by definition a pubkey without a valid private key. A signed mesage requires that you have a valid private key, or it can't be signed. So a pubkey with a signed message is a provably spendable output.

So, what do you want? Some UTXO with fake pubkey, taking 32 bytes, or some transaction, taking around 3x more on-chain space for every input?

At this point, trying to discuss anything with you is clearly unproductive.

[ertil]

And you have, say one week, to name your spend to that address, until the signed message expires. If there is no signed message, or if you send after the message expires, your tx is denied by the network and you still have your coin safe in your wallet.

We can't safely do OP_BLOCKNUMBER.  In the event of a block chain reorg after a segmentation, transactions need to be able to get into the chain in a later block.  The OP_BLOCKNUMBER transaction and all its dependants would become invalid.  This wouldn't be fair to later owners of the coins who weren't involved in the time limited transaction.

Which means, that if you make a signature, which can expire, then it doesn't work, when you have chain reorganizations. Which is why we have the opposite: a signature, which is valid only after a given timestamp.

Edit:

A fake pubkey is by definition a pubkey without a valid private key. A signed mesage requires that you have a valid private key, or it can't be signed. So a pubkey with a signed message is a provably spendable output.

Yes, sure. Then who owns 1psPJZYEJrjPtY6kw5Tqtj4mW2yXSSDuH address?

Code:

message="Hello World"
address="1psPJZYEJrjPtY6kw5Tqtj4mW2yXSSDuH"
signature="GwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAE="

See? The signature is valid, but nobody knows the private key to 1psPJZYEJrjPtY6kw5Tqtj4mW2yXSSDuH for some reason. And secp256k1 would be unsafe, if anyone would move coins from addresses like that.

[PepeLapiu]

Edit:

A fake pubkey is by definition a pubkey without a valid private key. A signed mesage requires that you have a valid private key, or it can't be signed. So a pubkey with a signed message is a provably spendable output.

Yes, sure. Then who owns 1psPJZYEJrjPtY6kw5Tqtj4mW2yXSSDuH address?

Code:

message="Hello World"
address="1psPJZYEJrjPtY6kw5Tqtj4mW2yXSSDuH"
signature="GwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAE="

See? The signature is valid, but nobody knows the private key to 1psPJZYEJrjPtY6kw5Tqtj4mW2yXSSDuH for some reason. And secp256k1 would be unsafe, if anyone would move coins from addresses like that.

This is why I need to block you or ignore you. Because I can't decide if you are dumb of if you think everyone else is dumb.

You gave no clue how bitcoin works. Spammers use fake pubkeys because they replace the scripthash with a hash of their spam. Or most commonly a hash of a piece of their spam. Because they don't indend to send bitcoin, they only intend to post data on chain and abuse the 90,000 nodes into hosting their crap spam data for the rest of eternity.

And since the scripthash is faked or replaced, any private key you would have would not match and the UTXO becomes unspendable. The private key, if you have one, would not work because the scripthash is fake, hence the pubkey is fake, and unspendable.

However, spammers have wised up and they can make fake pubkeys spendable with a multisig. I'll spare you the details.

So in the end, since spammers can make fake pubkeus spendable, fame pubkrys are not that much of a problem in my book.

What I do see as a problem is core perpetually using fake pubkey FUD as an excuse to keep giving in to spammers and cater more and more to spammers while never actually doing anything about fake pubkeys.

And the first part of your post is bullshot too. Not even worth addressing it.

[ABCbits]

and limiting Segwit data to 200 bytes per input

That's crazy. It would make some some Bitcoin no more spendable, including N-of-M multisig address with high total of N + M.

Can you show an example of this on mempool.space?

https://mempool.space/tx/d6e21694db97fb4c922ddd5f3fdbb30bbf92bb35a0f455adfb800a09642ac7bd?showDetails=true

It shows 3-of-5 multisig address, where the witness data contain 3 signature and the redeem script.

Code:

30440220635eba3b496d9dd329f2e586f33d61e43dd52b83cfbb770265eadc53d724cd9602201890abc1789d932032f9a55baff4c5313b6dda3bfb41b8ff4824933ba5b0b58601

30440220033e82c12614dade424b2c04369e271babf86176f8c39d16148b0899a8950b4302203f775c93eb69aaaa0d6e0eb6712455ec360844ac1bdc275c70d2a652491a095d01

3045022100f9818762a1bb6420d981599fdc41b5bb2b56ace9240f294a15f4b82a1377a3d702207a688039c7566dc1c44a7c8b06e40d5718727e54564fa99903d8867ad7f4614401

5321026e69dea7d67e3084b7f9e79c793098c0e2cfeac9de1d8bcd46ff1aab976959562102c863c9eaf5c00d4974ffefd7abb9771f4990ef8612b79beb176520228d71ccb421033aa3d0a4f773562d380a864792d3cd0230caab8b3bc55897b4a8b75a5f21b4dd21034b2df4f98451d49b734bb7658263816f32a72280bea0925d6094540194fa2c1a21039e5351859950d9d6995154b033749d797176fcb7a61a7a2645211de10be41f1d55ae 

It has 772 total hex characters, where hex character have size 0.5 byte. So the size of each input is 386 bytes. CMIIW.

[PepeLapiu]

and limiting Segwit data to 200 bytes per input

That's crazy. It would make some some Bitcoin no more spendable, including N-of-M multisig address with high total of N + M.

Can you show an example of this on mempool.space?

https://mempool.space/tx/d6e21694db97fb4c922ddd5f3fdbb30bbf92bb35a0f455adfb800a09642ac7bd?showDetails=true

It shows 3-of-5 multisig address, where the witness data contain 3 signature and the redeem script.

Code:

30440220635eba3b496d9dd329f2e586f33d61e43dd52b83cfbb770265eadc53d724cd9602201890abc1789d932032f9a55baff4c5313b6dda3bfb41b8ff4824933ba5b0b58601

30440220033e82c12614dade424b2c04369e271babf86176f8c39d16148b0899a8950b4302203f775c93eb69aaaa0d6e0eb6712455ec360844ac1bdc275c70d2a652491a095d01

3045022100f9818762a1bb6420d981599fdc41b5bb2b56ace9240f294a15f4b82a1377a3d702207a688039c7566dc1c44a7c8b06e40d5718727e54564fa99903d8867ad7f4614401

5321026e69dea7d67e3084b7f9e79c793098c0e2cfeac9de1d8bcd46ff1aab976959562102c863c9eaf5c00d4974ffefd7abb9771f4990ef8612b79beb176520228d71ccb421033aa3d0a4f773562d380a864792d3cd0230caab8b3bc55897b4a8b75a5f21b4dd21034b2df4f98451d49b734bb7658263816f32a72280bea0925d6094540194fa2c1a21039e5351859950d9d6995154b033749d797176fcb7a61a7a2645211de10be41f1d55ae 

It has 772 total hex characters, where hex character have size 0.5 byte. So the size of each input is 386 bytes. CMIIW.

Based on my proposal idea, we only need to worry about the total amount of Segwit data and the total amount of inputs.

I count 31 inputs. With my 0.2 kB per input limit, that would allow him 6.2 kB of Segwit data.
And that specific tx used 9.15 kB of Segwit data.

I think these are pretty niche transactions, not very common. Two different tjomgs could be done to allow this tx under my proposed limit. Either I imcrese my limit to 0.3 kB of Segwit data per input. Or the sender could use more inputs (about 15-25 more inputs) to increase his max Segwit data.

Can you think of other cases where my limit would interfere?

The idea is not to prevent spam or prevent transactions with large amounts of Segwit data. My idea would simply make spam with Segwit discount prohibitively expensive. Because it would force the sender to usevup a whole bunch of existing UTXOs or create a whole bunch of UTXOs to use as inputs to increase their allowed Segwit data.

[ABCbits]

I think these are pretty niche transactions, not very common.

Not true, N-of-M multisig address sometimes used by exchange, custodial service or big company that hold lots of Bitcoin. Besides, i found that address on https://bitinfocharts.com/top-100-richest-bitcoin-addresses.html.

Or the sender could use more inputs (about 15-25 more inputs) to increase his max Segwit data.

Sounds very not practical to me.

The idea is not to prevent spam or prevent transactions with large amounts of Segwit data. My idea would simply make spam with Segwit discount prohibitively expensive. Because it would force the sender to usevup a whole bunch of existing UTXOs or create a whole bunch of UTXOs to use as inputs to increase their allowed Segwit data.

I expect forcing people to make lots of new UTXO leads to faster blockchain size and UTXO set growth.

[ertil]

And since the scripthash is faked or replaced, any private key you would have would not match and the UTXO becomes unspendable.

But that's the point: you don't need to know the private key, to make a valid signature. I already demonstrated you how: https://mempool.space/signet/tx/7cf7a21e3e2b6e7381bf6438e1a76b3c239f896e48ba8500c83f187a4c42598c

What's the private key to 0382782bf703c61db99280b27c088da84fde58308648eb2c64a7e6488c718f9d23 public key? Nobody knows. Because if anyone would know that, then, the private key to 024974206973206861726420746f2073746f702066616b65207075626c6963206b would also be known. And, as you can see, the R-value contains the ASCII string, as well as the s-value. So, it is not something you could easily get by randomly generating private keys.

[PepeLapiu]

I think these are pretty niche transactions, not very common.

Not true, N-of-M multisig address sometimes used by exchange, custodial service or big company that hold lots of Bitcoin. Besides, i found that address on https://bitinfocharts.com/top-100-richest-bitcoin-addresses.html.

Or the sender could use more inputs (about 15-25 more inputs) to increase his max Segwit data.

Sounds very not practical to me.

The idea is not to prevent spam or prevent transactions with large amounts of Segwit data. My idea would simply make spam with Segwit discount prohibitively expensive. Because it would force the sender to usevup a whole bunch of existing UTXOs or create a whole bunch of UTXOs to use as inputs to increase their allowed Segwit data.

I expect forcing people to make lots of new UTXO leads to faster blockchain size and UTXO set growth.

I browsed and seached for hours, dare I say days and days on mempool.space. I was looking for txs that would have more than 0.2 kB per input. All I found was a bunch of spam, every single one of them were spam, not a single legit monetary tx.

Some of yours found exceptions to this. You here, and someone else on a different venue.

So those cases where legit monetary use would go over the 0.2 kB limit exist, but they are rare edge cases, not very common.

And I offer a fix for those rare cases, and you are not happy that it's not convenient enough?

The very large majority of txs with more than 0.2 kB of Segwit data per input are spam. My proposed limit would still make those transactions possible. Albeit less convenient or more expensive.

In my book the Segwit discount is a mistake, a form of price fixing that leads to perverse incentives. I don't think anyone should be entitled to Segwit discounts. Even more so if it's more of a discount than average users.

And you are completely wrimg to assume figthing spam in the manner I propose would lead to chain bloat.

It would force those who want to use more Segwit data to pay more while leaving the discount intact for 99% of the monetary users.

But hoping every wallet follow same rule unlikely to happen, when some wallet either lagging behind or never implement certain feature.

It is impossible, especially with wallets that have many shitcoins and tokens on them. We may not be favorable to those here but they have huge user bases and are often also lagging behind in changes that may not be urgent.

I'm pretty sure if the change makes their wallet no longer functional, that would qualify a pretty urgent. I would expect most wallets would get in line within the first week.

In any way, if a change is deemed beneficial, it's ridiculous to reject it just because it might create work for wallet devs. As if bitcoin belonged to wallet devs and we somehow owe them a smaller work load and the expense of rejecting beneficial upgrades.

And since the scripthash is faked or replaced, any private key you would have would not match and the UTXO becomes unspendable.

But that's the point: you don't need to know the private key, to make a valid signature. I already demonstrated you how: https://mempool.space/signet/tx/7cf7a21e3e2b6e7381bf6438e1a76b3c239f896e48ba8500c83f187a4c42598c

What's the private key to 0382782bf703c61db99280b27c088da84fde58308648eb2c64a7e6488c718f9d23 public key? Nobody knows. Because if anyone would know that, then, the private key to 024974206973206861726420746f2073746f702066616b65207075626c6963206b would also be known. And, as you can see, the R-value contains the ASCII string, as well as the s-value. So, it is not something you could easily get by randomly generating private keys.

You can't sign a message without valid private keys. You are just being stoopit, or you think I'm stoopit.