Historical transaction versions

Technical
#1

I’m currently running a very slow data extraction on historical BCH blocks, beginning with the range 400,000 to 719551… (older blocks later on, probably only once that range is completed)

Results are slowly being aggregated in this folder of my bitcoin-cash-data-analysis repository:

https://gitlab.com/freetrader/bitcoin-cash-data-analysis/-/tree/master/txn_versions

The crude and slow Python script which extracts a block’s statistics is also there.

If anyone has much faster blockchain query facilities, @bitcoincashautist would certainly appreciate it :wink:

Otherwise, I’ll be committing automatically to grow the CSV file(s) there until their ranges are completed, and after that I might add a file that tracks daily towards the tip or something.

Just so we can get a better idea of what transactions versions have done, and are doing - mainnet only.

1 Like
#2

tx_versions_big_picture_at_sample_size_2958
tx_versions_big_picture_at_sample_size_2958923×525 35 KB

First picture, which doesn’t sample many blocks in the total range.

Only v1 and v2 transactions spotted. This should change as more blocks are analysed.

2 Likes
#3

Adding a file where I will list anomalous transactions versions found.

It’s a WIP here:

#4

More data on transactions < 400k becoming complete now.

First 200k transactions were all v1 transactions. The following graphs show the growth.

First 100k:

0-99999

Second 100k (from 100,000-199,999):

100000-199999

In the next 50k blocks, we can observe the first v2 transactions

200000-249999

(they are obscured on the graph above, but occur in blocks 209920 (first v2 coinbase!) and 226,637 (another v2 coinbase).

Below is a more up-to-date plot of the >400k range (but only about 10% of blocks sampled so far):

400000-719551_more_than_30k_blocks_analyzed

The bitmap graph doesn’t show it well, but of course there is a ground swell of v1 transactions that is obscured by the majority v2 transactions (green points which dominate these days).

#5

Copying what the scan has picked up so far:

╔═════════════╦══════════════════════════════════════════════════════════════════╦═════════════╗
║ blockheight ║ transaction hash                                                 ║ version     ║
╠═════════════╬══════════════════════════════════════════════════════════════════╬═════════════╣
║ 256818      ║ 637dd1a3418386a418ceeac7bb58633a904dbf127fa47bbea9cc8f86fef7413f ║ -2107285824 ║
╠═════════════╬══════════════════════════════════════════════════════════════════╬═════════════╣
║ 256818      ║ c659729a7fea5071361c2c1a68551ca2bf77679b27086cc415adeeb03852e369 ║ -1703168784 ║
╠═════════════╬══════════════════════════════════════════════════════════════════╬═════════════╣
║ 257644      ║ 35e79ee733fad376e76d16d1f10088273c2f4c2eaba1374a837378a88e530005 ║ -2130706433 ║
╠═════════════╬══════════════════════════════════════════════════════════════════╬═════════════╣
║ 311495      ║ 64147d3d27268778c9d27aa434e8f270f96b2be859658950accde95a2f0ce79d ║ 0           ║
╚═════════════╩══════════════════════════════════════════════════════════════════╩═════════════╝
#6

In block 209,920, a coinbase transaction that’s v2

https://bch.loping.net/tx/a7b0fd34c953aeabe93b984bc0e3690ea0165eacab450a5af453cc0ec3307c44

{
    "txid": "a7b0fd34c953aeabe93b984bc0e3690ea0165eacab450a5af453cc0ec3307c44",
    "hash": "a7b0fd34c953aeabe93b984bc0e3690ea0165eacab450a5af453cc0ec3307c44",
    "version": 2,
    "size": 117,
    "locktime": 0,
    "vin": [
        {
            "coinbase": "030134035175626974506f6f6c204d696e657273d9dd5ac86700000042544331",
            "sequence": 0
        }
    ],
    "vout": [
        {
            "value": 50,
            "n": 0,
            "scriptPubKey": {
                "asm": "OP_DUP OP_HASH160 5d331cb009698ad2d6079a20c194bac1463c1f4a OP_EQUALVERIFY OP_CHECKSIG",
                "hex": "76a9145d331cb009698ad2d6079a20c194bac1463c1f4a88ac",
                "reqSigs": 1,
                "type": "pubkeyhash",
                "addresses": [
                    "bitcoincash:qpwnx89sp95c45kkq7dzpsv5htq5v0qlfg80nk3459"
                ]
            }
        }
    ],
    "hex": "02000000010000000000000000000000000000000000000000000000000000000000000000ffffffff20030134035175626974506f6f6c204d696e657273d9dd5ac86700000042544331000000000100f2052a010000001976a9145d331cb009698ad2d6079a20c194bac1463c1f4a88ac00000000",
    "blockhash": "000000000000024f743ba8fadbeb4310cf6d0a23b4cd403fe59143ba0b4d1f92",
    "confirmations": 510164,
    "time": 1354077445,
    "blocktime": 1354077445,
    "coindaysdestroyed": 0
}
#7

Thanks to both @freetrader and @joshmg we now have the data, and surprisingly there isn’t that many non-standard TX versions:

Version Count First Seen Last Seen
0 1 311495 311495
1 268265490 0 720189
2 82427548 209920 720189
3 1 370002 370002
4 1 407042 407042
2164260863 1 257644 257644
2187681472 1 256818 256818
2591798512 1 256818 256818
1 Like
Restrict transaction version numbers
Pre-release of a new CHIP-SubSatoshi
#8

Do these stats include coinbase txns too? I’m wondering if we restrict version to 1 or 2, even for coinbase, … if that may break some mining software (or not).

#9

Yes:

Reads verbose block JSON output from getblock RPC call and calls bitcoin-cli getrawtransacton for each transaction in the block, then grabs the transaction version and tallies up how many transactions for each version.

1 Like
#10

I have independently scanned the blockchain up to height 745706 and can confirm those 6 TX-es are all non-standard-version transactions that have been mined until that point.

1 Like
#11

we introduced the rule to make a block invalid if a transaction is not following the known transaction versions. I don’t think I looked at the implementation, but I hope it looks at the version as an unsigned, looking at that chart!

I did an update as I needed to get new data anyway. The actual transaction ids and block-heights are listed in my git repo (direct raw csv link), but the overview is here:

Transaction counted between blocks 1 and 823363

Tx Version Amount seen
other (negative) 3
1 285,820,550
2 94,314,334
3 1
4 860
3 Likes
Wider discussion, an OP_ENV for the VM upgrades
#12

The BCHN full node looks at tx versions as a signed 32 bit int. Your table as listing those three versions as negative numbers is more “correct” than what was previously posted in the thread.

2 Likes
#13

Spec says it should be unsigned 32 bit, but in this case the spec was created later, so which one is more ‘correct’ is arguable. There’s no harm in subscribing to ‘the specifications take precedence’ in this instance. The code should probably be adjusted, that goes for BCHN as well as for BCHUnlimited and other implementations which might still inherit from the Satoshi codebase here.

2 Likes
#14

it will add an annoyance into the version comparisons for tx version for subsatoshis and any other features that become version dependent later.
with singed int for tx version you can use >=
unsigned for tx version requires > and some cap on < because those few outlier version numbers become very high numbers instead of low numbers.

also unsure why editing and updating every satoshi based full node rather than a single text line in the spec would be the preferred solution

2 Likes
#15

Both choices have costs - there are nodes (maybe also other code?) that implement tx versions as unsigned.

1 Like
#16

ah, yes. fair point.

#17

It feels like updating the spec to reflect reality makes more sense, we’re absolutely not in the state where the spec is leading. Most people don’t actually write specs before rolling it out and as such the spec is in less than stellar shape. The ‘big int’ upgrade has been quite some years ago and still is not reflected in the spec, for instance.

I don’t know where the ‘unsigned integer’ comes from in the BitcoinCash spec. I’d say it is a mistake as the much much older spec on bitcoin it doesn’t have it; Transaction - Bitcoin Wiki Also the Core spec states it is signed. Transactions — Bitcoin