Topic: What does "backwards compatible" mean? (Read 173 times)

Your node ends up with a stale block. It is just like as if 2 miners mined the same block at the same time but the entire network can only build on one of them and the other becomes stale.

You can't "steal" anything when you can't provide a valid signature. It is like saying "I can modify the software and steal all P2PKH outputs"! It doesn't matter if you think a transaction is valid when it really isn't and the rest of the network rejects it.

That is contradictory. A fork will not activate if it hasn't reached majority's support.

This "anyone can spend" concept is interesting.

I read on Jimmy Song's blog that before Taproot is activated, if I transfer coins to a Taproot address, then anyone with or without the private key can just take those coins.

So.... let's say there's a bunch of people running non-mining full nodes that were installed in 2015 and never updated. They use this "anyone can spend" rule and publish transactions stealing coins from bc1q addresses.

A mining node running 2015 software mines a block containing those transactions. This block gets accepted by non-mining nodes running 2015 software, and rejected by non-mining nodes running 2018 software.

What happens? We get a hard fork?

Ok so if I download the Bitcoin software from 2015 and run it. Then I can basically steal all the coins from bc1q addresses. But the miners would refuse to include those transactions?

So let's say Taproot activates, but then majority of the non-mining nodes are too lazy to upgrade. And there still remain a sizeable number of miners who refuse to upgrade. Then a non-mining node publishes a transaction stealing Taproot coins using the "anyone can spend" rule. And this transaction gets mined by a mining node, and the block is accepted by non-upgraded non-mining nodes. We get a hard fork??

Not exactly... SegWit was a bit of a "workaround" to the block size limit. By putting a chunk of data into the Witness, you're theoretically increasing the block size for SegWit compatible nodes. Older Legacy nodes (like your theoretical 2015 software), just ignore the Witness part, strip it off and only store the "legacy" data, so will still end up with max 1 meg blocks.

Also, as a note, the blockchain size increases by a maximum of 1 MB per 10 minutes on average for your old node... it depends on how full the block actually is... sometimes they're empty or only have a few 100s or 1000s of bytes.

One point which might help to understand soft-forks a bit better:

We have two class of full nodes active in Bitcoin mainnet, mining and non-mining nodes, the latter group, nodes which have no part in setting up a block candidate for mining devices to try their luck finding the magical nonce, could go back in the version number almost down to the original Satoshi client, while the other group, nodes that actively generate raw blocks for mining purposes have to upgrade almost to the latest version (forget about the reason behind using the word almost in this context, it doesn't matter).

This way, a soft-fork like segwit is not to be even sensed by non-mining nodes as long as they are not interested in segwit news like who has how many coins in her bech32 addresses, is this segwit utxo spent or untouched, etc. The trick is transferring coins from legacy addresses to segwit ones is seen from the perspective of legacy nodes as a weird ANYONE_CAN_SPEND utxo which is never seized by anyone, as miners have migrated to segwit, and they do not put such seizing transactions in the blocks they generate.
 
Interestingly, miners were not the main supporter of segwit, it was somehow enforced by a majority of non-mining nodes aka users, they would fork out if a block comes with a stupid seize of segwit locked utxo. It was a bit more complicated situation compared to my simplified explanation, a twist that is called User Activated Soft Fork, UASF.

Nobody can prevent a soft fork from taking place due to its backward-compatible nature but also the minority chain (assuming the soft fork was minority like if OP did it on his own) can easily be attacked by breaking the rule they enforce and forcing them to reject the block containing such transaction effectively forcing them to split.

For example take OP_CheckLocktimeVerify case. If it were on minority chain, someone on majority chain could mine a block that had a big number like <220f9212c18d0d0c> OP_CLV OP_DROP and for majority chain the OP_CLV would be a OP_NOP so they don't do anything while the minority chain sees the big number and rejects it as invalid (can only be 5 bytes) hence splitting.

Most of your question is about SegWit, not about soft-fork in general.


1. SegWit could increase block size through block size because the witness part is removed and the block size have size 1MB or less.
2. Old client will treat those block as valid block, but they don't perform verification on transaction which use SegWit.


There are many aspect which prevent you from doing it, but mainly it's because
1. Community support.
2. How do you make your change backward compatible.

Yes it would accept them, but you would not be able to validate and receive transactions since your node would not understand them.


No, if you change things, every other node on the network will see these blocks as invalid and discard / ignore them.
Same as if you started using taproot before it's accepted date.
Doing this you would be creating an altcoin.

-Dave

Ok, so people say that SegWit is a soft fork. What does this mean?

So let's say I was running a version of Bitcoin Core that was downloaded and installed in 2015. And then I just left it running without updating the software.

And then on SegWit activation day, blocks start coming in that contain Segwit transactions, eg. those bc1q addresses. So my 2015 Bitcoin Core will accept those blocks as entirely valid and then add those blocks to my local Block Chain?

====

I also heard people saying that SegWit is actually a block size increase. Wait what? So you can do a soft fork to increase the block size, and Bitcoin Core clients installed in 2015 and never updated will accept those blocks as valid and add those blocks to their Block Chain?

Am I understanding this correctly? Before SegWit, the Block Chain on my PC (running 2015 software) increases by 1 MB per 10 minutes on average. After SegWit, the Block Chain on my PC (running 2015 software) increases by 1 to 2MB per 10 minutes on average?

===

So what is to prevent me from doing my own soft fork? Let's call my soft fork SegCash, and then I buy a bunch of mining equipment and start mining my own blocks. Will those blocks that follow my own soft fork rules be accepted by all the other nodes?

So what is to prevent me from doing my own soft fork and increase the block size to 100MB per block? And then I buy a bunch of mining equipment and mine my own blocks which follow my own soft fork rules, and then those blocks will be accepted by the rest of the network?

So if a miner were to start mining TapRoot blocks right now, those blocks will also be accepted by the rest of the network as valid?