A question on the BIP110 chain and lack of replay protection

[The Hidebehinder]

I didn't pay too much attention to this and considered it a dead project from the start, but after a talk with a few friends last night about what they are planning and what they are, I arrived at some conclusions, be they right or wrong, so just to get this right and not live with a misconception

• Luke Dashjr intentionally faked the target difficulty at the start, knowingly, so their chain could catch up with Bitcoin by pumping two weeks of blocks in 3-4 days, and probably 7 days for the next one, as he has some spare gear he hasn't yet forced onto the network, so he can claim his chain is gaining supporters.
• He and BM forced the smaller block size to make the chain look full of transactions when the capacity is actually down 70%.
• The replay protection was not about him thinking his coin is Bitcoin, but to allow transactions to be picked up by their chain too and not look empty.

If I'm mistaken on the last in some technical thing, just correct me, and there's no need for the rest.

My question is: what happens if I create a valid transaction on the Bitcoin chain but invalid on BIP110, and I send, let's say, X satoshi of dust to 100 addresses of exchanges, casinos, etc. that I know thy auto sweep their balances and consolidate inputs, do those consolidate inputs automatically become invalid on the BIP chain?
Would this kind of "poisoning" start to I don't know how to say this invalidate all further generated transactions from an exchange and forking this completely if done by hundreds of users?

Not that I'm planning to do it, but I was a bit annoyed to check their mempool and see 20 pending transactions to my wallet on their chain.

[Antidote47k]

I think the “poisoning” scenario is plausible though it might not automatically break the chain. If the transaction is valid on only the legacy chain and invalid on the BIP-110 chain, that UTXO would only exist on the legacy chain. If the exchange  later includes that UTXO as part of consolidation transaction, the transaction should also be invalid on the BIP-110  chain cause one of its input doesn’t exist in its UTXO set.

The real question now is what the exchange does with such transactions. If it keeps including those legacy only UTXO into subsequent consolidation transactions, this might potentially cause repeated failures on the BIP-110 side but that shouldn’t necessarily fork or break the exchange, if the exchange identifies the UTXO and exclude it from transactions meant for the BIP-110 chain, it’s other UTXOs should technically still be spendable there.
The only thing I’m wondering about is wether the exchange’s automated sweeping can be able to identify that now there are two different UTXO sets after the split.

[gmaxwell]

The replay protection was not about him thinking his coin is Bitcoin, but to allow transactions to be picked up by their chain too and not look empty.

It's so they can deplete exchange balances of BJr coins to punish insubordinate exchanges that didn't adopt BJr out the gate.  They deposit split bitcoins and withdraw, then the exchange sends an unsplit coin.  Wash rinse repeat.  They specifically discussed performing this action on their discord.

[athanred]

what happens if I create a valid transaction on the Bitcoin chain but invalid on BIP110

Then, your transaction won't be replayed. It is as simple as that, and I already splitted my coins on August 8th, to demonstrate publicly, that it can be done. Nobody replayed any of my transactions since then, so I consider it to be safe, to for example just use P2PK. It is also funny, that using P2PK takes less on-chain bytes, so it is less spammy, but they blocked it for absolutely no reason.

do those consolidate inputs automatically become invalid on the BIP chain?

If you have correctly splitted coins, then they will remain splitted. Unless some miner will take an effort, to make identical coinbase transaction on both chains, and re-unite them, which is hard to do, and probably nobody would try it. Which means, that once your splitted coin touches any other unsplitted ones, everything within a given transaction will be splitted correctly. If you have a transaction, making 100 new outputs, and you include just a single splitted coin as your input, then all 100 outputs are splitted correctly, and won't be replayed on their chain.

I was a bit annoyed to check their mempool and see 20 pending transactions to my wallet on their chain.

The default action of "doing nothing", and "using only unsplitted coins", leads to replaying it into Bitcoin Blake, Bitcoin Purity, Paul Sztorc's eCash, and all not-yet-invented altcoins, which will follow BTC rules. It is just a consequence of making altcoins with copy-pasted code.

It's so they can deplete exchange balances of BJr coins to punish insubordinate exchanges that didn't adopt BJr out the gate.

Exactly. Having no replay protection is beneficial for altcoin makers, so they usually don't implement it. And then, transactions are not replayed, only when users explicitly make them differently than usual.

Edit:

They deposit split bitcoins and withdraw, then the exchange sends an unsplit coin.  Wash rinse repeat.

Note that once splitted coins can be reunited, so the replay attack can be repeated multiple times. It is difficult in practice, but possible in theory. It basically requires making an identical coinbase transaction on both chains. And to do that, it is needed to skip the Segwit commitment inside the coinbase transaction, because if it is present, then it will usually be different in both chains, because of different TXIDs.

https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki

If all transactions in a block do not have witness data, the commitment is optional.

This sentence is quite important. Usually, in a typical block, coinbase transactions commit to the witness of all Segwit transactions in that block. However, if all transactions are non-Segwit, then that commitment can be skipped. Then, the only thing, which is usually different, is related to the block height. However, if a given miner can create two blocks, on two chains, at the same height, then that miner has the power to unsplit any coins.

First, coins are sent to pre-Segwit address types, to make transactions spending them to be non-Segwit. Then, each chain can send all legacy coins into fees, inside the "unsplitting block". And then, they are collected by the identical coinbase transaction, with identical fees, so also identical coinbase outputs, and content. And then, if the coinbase transaction is identical on both chains, transactions can be replayed again.

[ABCbits]

• The replay protection was not about him thinking his coin is Bitcoin, but to allow transactions to be picked up by their chain too and not look empty.

Regardless of their actual goal, this is what a Knots developer say.

This is a hardfork for Bitcoin, not an altcoin. It would be a major issue if legitimate transactions became invalid. The burden to implement replay protection falls to Spamcoin that just airdropped incompetently.

My question is: what happens if I create a valid transaction on the Bitcoin chain but invalid on BIP110, and I send, let's say, X satoshi of dust to 100 addresses of exchanges, casinos, etc. that I know thy auto sweep their balances and consolidate inputs, do those consolidate inputs automatically become invalid on the BIP chain?

Last time i checked BIP 110 spec, there's no dust limit on protocol. If you want wish to make big services create TX that invalid under BIP 110 chain, just send dust to them, but also add one additional output that violate BIP 110 (such as sending dust to uncompressed P2PK "address" or OP_RETURN with 84 bytes data). When those services consolidate their UTXO, it should include UTXO that doesn't exist on BIP 110 chain.

[Danish Ali]

None of this is on dealing with real BTC. The dust-poisoning attack will only be on the BIP110 side of the exchange. Does not require any validation on the real blockchain, their real bitcoins and UTXO are completely unaffected.

So in no way could it be "poisoning", it is just "bothering" a already not valuable ledger. As a result, the exchange is no worse off, apart from not having the ability to credit a coin that no one’s requesting to be withdrawn.

[The Hidebehinder]

The replay protection was not about him thinking his coin is Bitcoin, but to allow transactions to be picked up by their chain too and not look empty.

It's so they can deplete exchange balances of BJr coins to punish insubordinate exchanges that didn't adopt BJr out the gate.  They deposit split bitcoins and withdraw, then the exchange sends an unsplit coin.  Wash rinse repeat.  They specifically discussed performing this action on their discord.

I never imagined this thing, but wouldn't this make sure exchanges will never touch this coin when they realize they have been robbed?

And now that I look again over their mempool, I still have 0.025 blakes in an address from which I already moved my coins on the main chain yesterday night, theoretically I could overpay and move those to one of my own address before the tx gets confirmed on that chain too, and I got free blakes, the only problem is that they will be probably worth less than the power spent by my laptop to do this.

Nobody replayed any of my transactions since then, so I consider it to be safe, to for example just use P2PK. It is also funny, that using P2PK takes less on-chain bytes, so it is less spammy, but they blocked it for absolutely no reason.

Thanks for this, far easier and without risks to mess up, I'll just invalidate one output via a tx and consolidate everything afterwards.