FIRST WEEKLY XBT SPAM REPORT This is the first of weekly spam reports for XBT. It's not looking good. If we ignore the replayed transactions which are going to go away gradually, and we look at the transactions only on the XBT chain, here are some of the results: - 59% of the tx outputs on XBT are dust (1000 sats or less) or of 0.8¢ or less - 93% of the tx inputs on XBT are dust amounts, under 0.8¢. - 88% of the XBT transaction size is spam. - 99.9% of multisig inputs on XBT are spam. - 99.6% of dust inputs on XBT are spam. I won't name the site responsible for this garbage. But it's a single disgusting person who is trying to gain traction to drum up clients for his sick spam busines. THE SOLUTION? A filter that enforces a 500 sats (0.4¢) for every sig in a multisig would cost 1500 sats (1.2¢) to this most commom multisig tx, instead of the 158 sat (0.1¢) he paid: 16221b6d42bf7c88f989cb9875d0ef7396e61250881d747d18b5417accc7a326 A less common multisig like this one would cost 10,500 sats (8.1¢) instead of the 1,467 sats (1.1¢) fee that was paid: a1bb7a5569b25ab30217fa0db039e3b0abfaf2a92d61eac4ad9c7e496c18003c But a smallish spam tx like this one would end up having to pay 1,912,500 sats ($14.82) instead of the 48,029 sats (37.2¢) he actually paid: 6e5f40c41e004b3b2cc8a459b73e42e2e8a8eb43fb761d07c7757927684ec59f And the larger spam tx like this one would end up having to pay 3,595,000 sats ($27.78) instead of the 179,996 sats ($1.40) he paid: 9440286ef590cfaaf8c10f27097343c50be8f2de767cdfe2daabb5627748a685 Personally, I would be comfortable with a 1000 sats (0.8¢) per multisig sig. During the scan period, that asshole spent 30,317,400 sats ($299.75) to post his garbage. Even a 500 sat/sig tax would force him to spend 1,075,905,000 sats ($8,202) or roughly $1,170 per day. The problem is about adjusting the tax with price. I though that a magic number from an external index would be a problem. I think a fairly acceptable proxy of fiat price within the system would be to adjust the tax with difficulty adjustments. I don't know if that is possible or reasonable. That's were we need the big brain devs to come in. And other way to adjust the "spam tax" fee price would be to rely on updates to adjust the default. Or just trust the individual nodes to adjust properly. But let's not pretend here that defaults don't matter. Until a better "spam tax" adjustment method comes along, I am going to trust updates to do it. That's the most simple solution too. It's still in it's early stages. Please support this filter and ask that it be merged in the next Knots release. This filter, or something else that would mitigate this nonsense. github.com/bitcoinknots/bitc…

WEEKLY SPAM CHAIN REPORT Weekly report of the state of spam on the spam chain (BTC). This week, spam took up 43.5% (692.74 MB) of the blocks size and paid only 16.3% of the miner fees, resulting in spam paying 4x cheaper than monetary users for the same block space. Thank you core devs for protecting our right to dickbutt.jpeg and other garbage. I should also mention that I'm updated my spam detection rules. With #3 and #4 as spam tangent txs. A tx is marked as spam if: #1- it would have been made invalid by BIP110 #2- or it contains an OP_RETURN output of any size. #3- or it contains 3 or more inputs of less than 1000 sats AND at least 50% of the inputs are under 1000 sats #4- or it contains 3 or more outputs of less than 1000 sats AND at least 50% of the outputs are under 1000 sats. Rules #3 and #4 detect spam tangent txs. Those are transactions that should not be prevented, but would very likely not exist if spam was not there. These amount for a little bit less than 10% of the spam. While a monetary transaction might possibly be flagged as spam under rule #3 or #4, it's very very unlikely a monetary user would ever do such a transaction.