real_miner

Aaah ! It is the C-type "true", that is "not zero". So a scriptpubkey that simply pushes something that is not zero on the stack is an anyone-can-spend output. Right. THAT was the missing piece in my understanding.…

Ah, we might be hitting something I fundamentally misunderstood in bitcoin here. I'd like to understand because clearly there's an inconsistency in how I understand things, and I can't put my finger on it, so this might…

Thanks. Actually I'm indeed essentially trying to wrap my head around segwit (and taproot next). I was interested in the technical side of bitcoin around 2012-2013, then left it for what it was (had other priorities in…

Ah, it was hence actually a problem with the TXID database and not with the blockchain. But let us assume that the new transaction "invalidates" the old one. Now let me try to understand the motivation for that. If it…

Thanks for the explanation ! How would an old node see an output that is meant to be unlocked with a segwit script ? I guess to the old node, this comes down to a scriptpubkey script that is unsolvable as it just pushes…

I do understand that if you leave out the new bytes, the total amount of old bytes will indeed physically be below the old 1 MB physical limit. But I thought that leaving out stuff from a block screws up the hashes…

Ah, OK, this is also how I understood it: these identical TXID render some "honest" UTXO unspendable, there's no way to turn this into a double spend vulnerability, as I thought. I had read this here:…

Having to include the height of the block is exactly what bip34 was about IN ORDER to have the TXID of the coinbase transactions different. It is argued that bip30 and bip34 were introduced to avoid the possibility of a…

Hey everyone, I’m trying to wrap my head around the technical aspects of bitcoin, and I’ve got a few questions that I think are pretty basic, probably covered a lot back in the day. So I’m throwing this in the beginners…