Version 2 of transaction

[Frodek]

In block 209920 is one transaction, its version=2. What changes of format?

[1715127462]

1715127462

[1715127462]

1715127462

[1715127462]

1715127462

[1715127462]

1715127462

[1715127462]

1715127462

[1715127462]

1715127462

[xhomerx10]

Version 1 was introduced in the genesis block (January 2009).


•Version 2 was introduced in Bitcoin Core 0.7.0 (September 2012) as a soft fork. As described in BIP34, valid version 2 blocks require a block height parameter in the coinbase. Also described in BIP34 are rules for rejecting certain blocks; based on those rules, Bitcoin Core 0.7.0 and later versions began to reject version 2 blocks without the block height in coinbase at block height 224,412 (March 2013) and began to reject new version 1 blocks three weeks later at block height 227,930.


•Version 3 blocks were introduced in Bitcoin Core 0.10.0 (February 2015) as a soft fork. When the fork reach full enforcement (July 2015), it required strict DER encoding of all ECDSA signatures in new blocks as described in BIP66. Transactions that do not use strict DER encoding had previously been non-standard since Bitcoin Core 0.8.0 (February 2012).

•Version 4 blocks specified in BIP65 and introduced in Bitcoin Core 0.11.2
•(November 2015) as a soft fork became active in December 2015. These blocks now support the new OP_CHECKLOCKTIMEVERIFY opcode described in that BIP.

per the Bitcoin Developer Reference

[achow101]

Version 1 was introduced in the genesis block (January 2009).


•Version 2 was introduced in Bitcoin Core 0.7.0 (September 2012) as a soft fork. As described in BIP34, valid version 2 blocks require a block height parameter in the coinbase. Also described in BIP34 are rules for rejecting certain blocks; based on those rules, Bitcoin Core 0.7.0 and later versions began to reject version 2 blocks without the block height in coinbase at block height 224,412 (March 2013) and began to reject new version 1 blocks three weeks later at block height 227,930.


•Version 3 blocks were introduced in Bitcoin Core 0.10.0 (February 2015) as a soft fork. When the fork reach full enforcement (July 2015), it required strict DER encoding of all ECDSA signatures in new blocks as described in BIP66. Transactions that do not use strict DER encoding had previously been non-standard since Bitcoin Core 0.8.0 (February 2012).

•Version 4 blocks specified in BIP65 and introduced in Bitcoin Core 0.11.2
•(November 2015) as a soft fork became active in December 2015. These blocks now support the new OP_CHECKLOCKTIMEVERIFY opcode described in that BIP.

per the Bitcoin Developer Reference

He's taking about the coinbase transaction being version two instead of version one, not the block version.


There of no difference between version one and that transaction that is supposedly version two. It is the same format, just that the miner changed the version number to two. I'm guessing it had to do with a bug in the mining software since the block version number was being bumped to two as well around that time.

[xhomerx10]

Version 1 was introduced in the genesis block (January 2009).


•Version 2 was introduced in Bitcoin Core 0.7.0 (September 2012) as a soft fork. As described in BIP34, valid version 2 blocks require a block height parameter in the coinbase. Also described in BIP34 are rules for rejecting certain blocks; based on those rules, Bitcoin Core 0.7.0 and later versions began to reject version 2 blocks without the block height in coinbase at block height 224,412 (March 2013) and began to reject new version 1 blocks three weeks later at block height 227,930.


•Version 3 blocks were introduced in Bitcoin Core 0.10.0 (February 2015) as a soft fork. When the fork reach full enforcement (July 2015), it required strict DER encoding of all ECDSA signatures in new blocks as described in BIP66. Transactions that do not use strict DER encoding had previously been non-standard since Bitcoin Core 0.8.0 (February 2012).

•Version 4 blocks specified in BIP65 and introduced in Bitcoin Core 0.11.2
•(November 2015) as a soft fork became active in December 2015. These blocks now support the new OP_CHECKLOCKTIMEVERIFY opcode described in that BIP.

per the Bitcoin Developer Reference

He's taking about the coinbase transaction being version two instead of version one, not the block version.


There of no difference between version one and that transaction that is supposedly version two. It is the same format, just that the miner changed the version number to two. I'm guessing it had to do with a bug in the mining software since the block version number was being bumped to two as well around that time.

 Thanks.  I see it now.  I never thought to look at the raw transaction.