13

You're confusing transactions (the abstract object) and their serialization (the bytes on the wire in the P2P protocol or on disk). Sure, SegWit introduces an extension to the P2P protocol (BIP144), which relays witnesses along with transactions, and old clients wouldn't understand such messages. But old clients don't see them. Witnesses are only included ...


7

Yes, since blacklisting a set of UTXOs would be done by adding more rules and thus restricting the set of allowed transactions, technically such a change could be introduced as a soft fork by the miners. However, I would sincerely doubt that censoring Satoshi from spending her coins would find broad community support. I suspect that such an endeavour would ...


5

Others have commented on the technical possibility of this, so I'll address the economics: I don't believe any smart miner would do this. Why? Because it would destroy confidence in the network. If the miners were willing and capable of blacklisting the coins stored at Satoshi's addresses, then who's to say they won't do the same to the coins stored at any ...


5

This could be implemented theoretically, but this idea will certainly never be implemented. It's because: You don't know which addresses exactly are owned by Satoshi Nakamoto. This idea is against all Bitcoin-principles. If you have Bitcoin, nobody should be able to steal it unless he has your private key. Bitcoin would become unreliable if you can't be ...


4

I was wondering why a soft fork cannot in principle divide the Bitcoin network as a hard fork can. A soft fork absolutely can divide the Bitcoin network, in principle, if you don't specify any other assumptions. However, the relevant point that distinguishes soft and hard forks is that the network will always converge as long as a majority of the hashrate ...


3

It's considered a source code fork, or an altcoin, neither a hard fork nor soft fork of bitcoin. To be classified as a soft/hard fork, it should share some of the same chain from the genesis block. LN has a completely different chain right from the start so it's not a fork of the bitcoin chain. Note that even coins sharing the same chain as bitcoin from the ...


3

Yes, it is possible. The rule regarding the coinbase reward is that a miner cannot take more than the block subsidy plus the transaction fees in the block. This means that a miner can opt to take less than the full reward that they are entitled to. This has happened before in Bitcoin a few times. The coins that they did not collect are gone forever. So, you ...


3

Your observation is correct, except that a fork is expected to be activated by a supermajority of nodes and miners in the network. The most recent soft fork had an activation threshold of 950 blocks in specific segments of 1,000 blocks signaling readiness (95% hashrate) for the new rules. So, assuming that only 5% of the mining power don't follow the new ...


3

Most past soft forks have been deployed with miner activated soft forks, and we know this because the deployment mechanisms used only allowed for miner activated soft forks. For a user activated soft fork to happen, the deployment mechanism would have to have some form of activation that is not reliant on miners. Thus far, the activation methods used have ...


2

There is a paper that provides extensive detail on the history of all kind of forks on Bitocin, Ethereum and Ethereum Classic, you can read it here, Atomically Trading with Roger: Gambling on the success of a hardfork. Here is the list of Forks so far, The following content is sourced from the above paper, So far, Bitcoin has implemented over six ...


2

Bitcoin.org's developer documentation has a pretty good description of the consensus rules, but it does not and cannot describe them fully. This is because the consensus rules are dictated by the code that enforces them, not by a document. AFAIK, there is no list of things that can be hard forked and things that can be soft forked as such lists would be ...


2

There are two related risks: Activating without a majority of hashpower supporting it over the long term. Let's use BIP 66 as an example. Imagine it had activated at the 95% threshold, but 30 minutes later, more than half of the miners reverted to the old implementation that doesn't support BIP66. What you now have is a situation where nodes that enforce ...


2

What are the next forks of the Blockchain that have been announced? Just to be clear, anyone can "announce a fork", but adoption and news of said fork depends on the market demand for the new coin. Most recently, Bitcoin was forked to create Bitcoin Cash (BCH). Bitcoin SegWit2x (a bitcoin hard fork), Bitcoin gold (a bitcoin hard fork), and Bitcoin ABC (a ...


2

The fix is in deciding when the change takes effect, and only validating with the stricter rule from that point onwards. The easiest way is to decide upon a block height, say: 695,837 and all the blocks before that one are validated with the old rules, and blocks 695,837 and onward are validated with stricter rules. Something a bit more sophisticated was ...


2

Bit 31 is sometimes referred to as the hard fork bit. BIP34 put a constraint on version numbers to be 2 or higher. As the block version is a 32-bit signed integer, setting its highest bit results in a negative number, which would violate BIP34. As a result, any usage of that bit results in a backward incompatible change to the rules - a hard fork - that is ...


2

Under a hard fork, new nodes think old-style blocks are invalid, and old nodes think new-style blocks are invalid. Thus if old nodes continue creating old blocks, we get a chain of old blocks, and a chain of new blocks. Each community thinks theirs is the one true blockchain. Under a soft fork, new nodes think old-style blocks are invalid, but old nodes ...


2

Soft forks cannot divide the network because they occur with miner consensus. For this to happen, miners signal that they are ready and will enforce the new rules after they activate by setting certain bits in their block version numbers. Once enough blocks signal readiness (with BIP 9, this is typically 1916 out of a 2016 block retarget period, so 95% of ...


2

The way block reward is computed today is : CAmount blockReward = nFees + GetBlockSubsidy(pindex->nHeight, chainparams.GetConsensus()); Which means that the block reward is the total fees in the block plus the current base block subsidy. It's definitely possible to change this line to (pseudocode) : CAmount blockReward = std::min(nFees + ...


2

When an old node connects to a new node the new node detects that the old node doesn't support the new transaction format and so it converts any transaction it sends it-- e.g. segwit transactions in blocks-- to the old format. The old format does have the witness data fields in it, but old nodes don't have any requirements for witness data so they don't ...


2

This is correct. As an upgrade mechanism, nodes do not relay or mine transactions which they know that they can not correctly validate. The P2P network expressly avoids situations in which it could cause invalid transactions to be included in a block. It will however accept these transactions in a block.


2

The two thresholds enable two different rules. If more than 750 of the last 1000 blocks are version 2, the network starts enforcing BIP34 - at this point, blocks that claim to be version 2 but do not comply with the requirements outlined in BIP34 are rejected. Version 1 blocks continue to be accepted. Once more than 950 of the last 1000 blocks are valid ...


2

If the users who want to keep the use of timelocks do not constitute even a significant minority of users, they're simply out of luck. There's no mechanism for a minority to force the majority to tolerate rules the majority doesn't want. Assuming the users who want to keep the user of timelocks are significant, they first communicate their intention to ...


2

Why don't we force miners to embed the height of the TX Merkle tree in the first two bytes of the 4-byte block header version? That would be a sane softfork, but it would need to take into account that due to BIP65, the block version (which is a signed integer) needs to be at least 4, restricting it to 2^31-4 values. Maintaining compatibility with BIP9 and ...


2

The way Signet will likely address this is to have two classes of Signet full nodes. The first class of Signet full nodes will stay on a stable Signet version and only update once the proposed soft fork is activated on mainnet. The second class of Signet full nodes will run experimental Signet versions and as a result will need to update every time a new ...


2

Soft fork and hard fork here, if you want to accurate, are statements about the conditions under which all nodes are guaranteed to eventually agree on the same chain. So it is about avoiding permanent forks, and the conditions to avoid them. Temporary splits are always possible, even when there is no consensus change at all. A consensus rule change is called ...


1

I'll start with explaining the confusing documentation. BIP34 says it activates when 950 out of 1000 blocks signal for Version 2. It is not clear if this includes the current block or refers to previous blocks It refers to previous blocks. To determine whether the rules are active for the block at height n, we check whether 950 of the blocks from n-1001 ...


1

Because a soft fork by definition follows stricter rules than the normal chain, you would have to make assumptions based on the block data. For example, if a soft fork no longer allows certain scripts, you might be able to determine that by noticing that those scripts are no longer present in any blocks from that miner. However, it would be a guess since it ...


1

Although the devil is of course in the details, how could such an upgrade process look like? and What are the different upgrade mechanism for the major [v1 - v16] and minor [v1.0 - v1.127] version changes? As Pieter Wuille mentioned in the comments, "There isn't even a proposal. Discussion about activation and all its implications is something to be ...


1

Found it in bip 144: Rationale for the 0x01 flag byte in between: this will allow us to easily add more extra non-committed data to transactions (like txouts being spent, ...). It can be interpreted as a bitvector. So the 0x01 flag is indicating that the witness data should be included in the (bip144) transaction serialization.


1

However, if a majority of miners agrees on the activation of soft forks, could they activate it? If so, does it mean that only 15 mining pools could control Bitcoin? No. Soft forks requires full nodes and users to validate the new consensus rules. Miners can "force" soft forks, but that actually wouldn't do anything if no one uses or follows the soft fork ...


Only top voted, non community-wiki answers of a minimum length are eligible