221706 (3) [Avatar] Offline
Hi, Kalle,

in chapter 8.4 you argue in detail about pending v. confirmed. You also explain double spending attacks. But I couldn't find much about the (surely practically relevant) problems when a transaction did first get confirmed but afterwards another branch won (except some time barriers and a height difference needed in chain continuation). I think it would be worth do say sth. more about that.

Moreover, a reference to a mining program might be welcome, too.

And last: the OP_RETURN explanations were a bit too sparse for me (it would be marvellous to have a really detailed Ampere example).

Many thanks. Kindest Uwe.Hostmann@gmx.de
Kalle Rosenbaum (20) [Avatar] Offline

Hi! Thank you for you thoughtful comments.

I think I actually don't mention what happens to the transactions in the abandoned branch. Thanks for pointing it out. I'll probably have to figure something out here. I'll explain here in case you haven't already figured it out. Say that transaction T is included in branch A but not in branch B, and branch B gets stronger than A. Nodes following branch A will then switch to B. Such a node will mark all transactions of branch A, that's not already in B, as pending again. So T becomes "up for grabs" for new blocks of branch B. Nodes maintain a memory pool of pending transactions, generally called the mempool. To mark a transaction as "pending" means to put it in the mempool.

Re: Mining program: Hmm, not sure, since most mining today is done with specialized hardware, Application Specific Integrated Cirtuits, ASICs.. However, you *could* mine bitcoins on your CPU using a Bitcoin Core node, but you won't have a chance against the specialized hardware.

Unfortunately (or fortunately?), there are space (and time) limitations to this book, so I had to keep the Ampere example short.

I hope I captured your questions correctly.

Thank you