You can use this to increase the fee of a transaction after the fact. So, suppose A has a fee of 0.001 in the first transaction, and the current fee needs to be 0.01 . Then, B has this transaction, but no-one will put it into a block, so B hasn't really received his money yet. A could sign another transaction with a higher fee that would send the money back to A. This could happen until the original transaction was actually deep enough in the chain.
But using your situation, B can do the same thing as A. B can create a transaction sending his own 0.999 BTC to another address of his, and include a fee here of 0.019 . In this fee, there is 0.01 to fund this transaction, and another 0.009 to fund the fee A forgot to include. Miners will see this, and include both transactions, and B is guaranteed he has his money.
Someone should have volunteered to help the Pineapple Fund do this instead of switching to Bitcoin Cash (or maybe this is what "Child-Pays-For-Parent" is, and it cost too much). https://news.ycombinator.com/item?id=15995391
>> Since this created a series of unconfirmed transactions, we had to do something drastic: use Child-Pays-For-Parent with a very significant fee.
Yep, this is what that means. The downside is that the 'child' transaction doesn't just pay for the 'parent' transaction, but also for the 'child' transaction itself. If you make the child transaction a really complex one that draws from many parents, that transaction becomes larger (in terms of bytes) and thus becomes more expensive.
Edit: You are always spending a specific input, so to broadcast B->C, B would have to wait for A->B and specifically name that transaction. The miner _could_ receive these transactions out of order, but that should not be an issue.
https://blockchain.info/tx/cffa18e3d519c31c8624fc2c3e498c0d9...
https://blockchain.info/tx/f24eaa493071e96f5bdf931204b893098...
Both transactions are in the same block (203732), the f24eaa tx is spending an output of cffa18.
Check again: the first TX pays to 12Pws7qasVjt7uKfT6woQptx1MLNj2mo44, the second spends from it.
[0] https://blog.keep.network/miners-arent-your-friends-cde9b6e0...
However, B can broadcast txB after receiving txA (txB essentially needs to know txA in order to "use" it).
The way this works is txA essentially says "send 1BTC I received from some tx to B". txB says "send 1BTC I received from txA to C". So, when creating the txB, B needs txA in order to use it.
Keep in mind this has nothing to do with txA or txB being included in blocks. txB can use txA if txA is not yet confirmed (so not in a block), however txB can only be included in a block (so confirmed) if txA is already confirmed in a previous block, or if both transactions are in the same block (this is where the part of a miner "ordering" the transactions from some other replies comes in play).
Part of being a valid block is "only spend BTC you have". B-to-A-first violates that.
Other miners would reject such a block as invalid and refuse to propagate it. Even if some did, the vast majority would not consider it valid, and the next published block (new transactions + proof of work) would extend from a block that didn't have that transaction in it.
There is no unspent transaction that B owns, so any transaction B creates to send money to C is invalid.
This is just not true at all?
for B to refer to A, it needs to know the transaction id.
Transaction ids are sha256(sha256(raw_transaction)) and a raw transaction consists of inputs and outputs. All this is known before the transaction gets put in a block--and has nothing to do with blocks.
Blocks and mining mitigate against double spending (...by burning an insanely huge amount of energy to do so, inefficiently. But that's a separate issue, at least right here)