Yeah, I know, that is their 3423th backup plan,  but they didn't implement it. This is why I'm disappointed.
Captagon (guida)  mentioned this numerous times in their Discord, as well as burning retroactively coinbase rewards,  and Luke and the other reatreded in charge did too, I am sure they would want that but they are afraid of doing it.

Also, since I was clearly wrong on the motifs of some of the decisions, this is probably also more aimed at keeping Convoy afloat and grabbing more coins while gatekeeping minor farms without liquidity...


Their "plebs" are insane!
The migrated sia miners will probably take the gamble!

Afraid of loosing control. Already there is at least 1 pool that is not following the fork.
https://x.com/CTRLpool

I am sure there will be others.

As for the no spam in the chain, we all knew it was going to happen. Waiting for some automated tool to do it with so I can dump a bunch of dust coins and jpgs into their chain.



I do disagree with the everyone who wanted to sell coins has statement. I think for some whales sitting on 100s of BTC it's on the to do list.
But, if you are sitting on 100s you can sell one with just about no effort and get $83k +/- at the moment. To sell lukecoin you have to split it, and then sell in batches (or dump the price to sub $200) and if you have 300 BTC you still don't get the $83k you could have gotten for selling 1 coin.

---

The entire game really seems to be "make luke money" and "give luke control"

-Dave

I already linked you one of the tools, this page has an "upload" button. If you don't trust this website with dust coins, then you can build it from source code, and run it locally: https://github.com/bitfiles-io/bpub

Also, they support even testnets. Another thing is you can download JSON file with all details, before actually sending the coins, and verify everything manually, if you want to, or replace their autogenerated private key with your own.

Of course, if Knots developers will decide to block 1-of-15 multisig, or other things like that, then people will switch to other methods. Because you never know, if something will be blocked in the future or not. They blocked harmless P2PKs, even though they are always smaller than 80 bytes, but they allow OP_RETURNs of that size. I don't fully follow their logic, if there is any.

Some example: https://bitfiles.io/btcb2/898c9c3e8bad6604e7be8b9d8c0dabbf4a6e7e3853b0354484d8ce19176b199d

For some reason, this transaction seems to be perceived as less spammy than P2PK, even though using P2PK would actually make it smaller, when it comes to the total number of bytes pushed on-chain. Which was also funny, when I used P2PK to split coins: transactions on non-BIP-110 chain actually took less bytes, than on BIP-110 side.

So.....
Anyone taking credit for this?
https://mempool.guide/tx/453d77ba2803878cd14def995f9ae55c73d42fb8886a810e1748cddae0b08da5

I was curious how long it will take till we see porn on blake...blakeporn... sounds already like a porn category
Now, if someone is willing to risk a Discord ban and tell the blaketards about them and record the meltdown, I would be immensely grateful.

It seems inconsistent to me to keep multisig-based tricks open. The reasoning behind the P2PK ban makes sense (IMHO) once you realise that it's about "permanent UTXO set bloat" rather than "total bytes pushed on-chain."

Whereas with an OP_RETURN output the data is known to be unspendable so it can be discarded from the UTXO set as soon as the transaction is confirmed and doesn't need to be kept in memory/on disk (unless a block containing the tx is requested, since it's part of that block's data), a P2PK output could conceivably be spent, so its data must be kept in the UTXO set permanently, meaning that all nodes have to keep it in memory/on disk permanently. So, even though it's a smaller size it has a worse effect under this criterion (permanent UTXO set bloat) than OP_RETURN does.

Under this criterion I think banning P2PK but allowing the equivalent multisig trick makes no sense though...

Then, why P2TR or P2WSH is not banned as well? If you compare compressed P2PK, then it is one byte more, than in P2TR. And when it comes to P2PK, then it is always spent by a single DER signature, while P2TR can push a lot of data through TapScript.

So, if someone wants to use fake public keys in P2PK, then that person could simply use P2TR or P2WSH, and get it one byte cheaper. And, as you can see in practice, it doesn't really matter for spammers, if they consume one byte more, or one byte less, because existing spam usually allocates more coins than needed in advance, and there is some change, which is usually sufficient to post the same spam again. And because the price of BIP-110 coin is much lower than non-BIP-110 ones, then it is actually cheaper, to use even very inefficient methods.

Also, it is funny to see, that they consider Satoshi's early transactions to be incompatible with BIP-110. Was Satoshi a spammer? It only shows, that they cannot create a good rules, which would filter the actual spam, without affecting real payments in any way.

I can see no reason to block P2PK, when it actually leads to less bytes pushed on-chain in some scenarios. And if blocking P2PK would really work, then spammers would simply switch to other address types, for example P2TR or P2WSH, and would achieve the same UTXO pollution, while also wasting one byte less per UTXO. So, blocking P2PK actually affects mainly some early adopters, who may need to use P2PK for that reason, or another, while leaving actual spammers completely unaffected, because they have a lot of options to choose from.

Switching to storing data in private keys, and revealing them through weak signatures, solves that problem completely. And it already happened in practice, for example: https://web.archive.org/web/20251108213635/https://www.bitmex.com/blog/the-unstoppable-jpg-in-private-keys

Don't worry, they plan to block 1-of-15 multisig: https://github.com/bitcoinknots/bitcoin/pull/422

However, if for example 2-of-3 or 15-of-15 multisig will be unaffected, then guess what: weak signatures will still allow pushing the same data. And even if the cost of doing so will be bigger, low price per coin will still make it doable, and probably still cheaper, than on a non-BIP-110 chain.

I don't check the actual code yet, but it seems to works by counting total size of M keys (without it's signature) as part of DatacarrierBytes with certain tolerance or threshold.

But if i were spammer, i'll just switch to OP_PUSHDATA1, which should be about as cheap as current 1-of-15 multisig. For example, https://mempool.guide/tx/9c34287f805e622b86ac140ef10475750214cf60c3310441b9b9ea9f429bb1bc.

P.S. If someone is bold enough, consider mentioning that link as real example on the PR discussion.

And they would at that point start bragging that their chain is so popular that their blocks are always full.
Way outside of my programming ability, but makes you wonder how difficult it would be for someone to write a script that just keeps pushing crap to their chain all day.
I mean think about it. Just 1000s and 1000s of jpgs all day long.

Side question, in addition to bitfiles.io that @athanred mentioned are their any others that will put things on the 110 chain? Figure we should compile a list and test them all to verify that they work properly :-)

-Dave

The simplest of all is the classic way: a tumbler/mixer script!
You can't blacklist the address as it continuously moves the funds, there is no pattern in the number of inputs/outputs, they are tiny compared to the classic consolidations and are not immediately suspicious by the time you have identified one chain, the funds have moved 20 hops away from that and filled another 2-3 blocks.

But if I took my time and script this, I would probably use multisig for it, not to carry JPGs, but to throw at them a block full of tx with multisig inputs, as it also affects the CPU usage when syncing a node , totally unrelated to Luke telling plebs they should buy a better computer to run a node 


Common, let's be realistic here, I gave that as an example of the limit blaketards might propose with their censorship of things we don't like, there is no way a chain like that would ever function, unless they abandon the Bitcoin model and go for a ledger solution like Solana. I believe Luke to be capable of many things, but this one, nope...
But I do suspect he would try to find a way to block large consolidations or to create some freezing mechanism so that coins are not immediately spendable, cause blakecoin is money only when he wants to.