Previously, processors and merchants accepting bitcoin payments would wait until a large fraction of bitcoin nodes listed a 0-conf txn as "valid-but-unconfirmed," the so-called memory pool or mempool (because it is a collection of transactions in RAM). This works well, because we empirically know how nodes operate: they accept these valid-but-unconfirmed txns into the blockchain and reject (both discard and fail to r…
> processors and merchants accepting bitcoin payments Citation needed. The existing behavior is very easy to rip off: You write two transactions, the one paying yourself, one paying the merchant. Simultaneously you hand a big miner the first while handing every other node you can reach the second. It's very likely that the first doesn't propagate at all, but you'll have a decent successrate at reversing. Blockchain.i…
The "greedy" behavior would be when minors explicitly prefer a sequence of transactions such as:
Customer => Merchant: X+ε (1)
Merchant => fees: X+ε (1)
over
Customer => Customer: X+ε (2)
Going so far as to swap out (2) with (1), even if they already have (2). If there is no double spend, presumably the trustworthy merchant would send back ε after sufficient confirmation []. Or, in a world with fees, the ε would be fees in the original transaction (still serving the purpose of costing the malicious customer Bitcoin, even with successful double spend).
That seems like a decent solution.
[*] Or I suppose it could be in the same block. No difference.
Edit: formatting made it unclear.