BIP0034

[optimator]

I am trying to understand BIP0034 and I'm confused (this is normal)

Is the "version" referenced in the specs the version of the tx Message type? Is this version different from the version in the Block Header?

Is the "scriptSig" referenced in the BIP the "signature script" field referenced in the TxIn data type?

I couldn't find a reference to "serialized CScript" on the script wiki page. Does anyone have a reference where I can find to calculate this?

I assume that adding the block number to the coinbase transaction sig doesn't inhibit using the transaction sig as an extra nounce?

Thanks!

[jgarzik]

I am trying to understand BIP0034 and I'm confused (this is normal)

Is the "version" referenced in the specs the version of the tx Message type? Is this version different from the version in the Block Header?

Transactions and blocks both have version fields.  In the specification, rule #1 refers to transaction versions ("transactions with a version [...]") and the other rules refer to block versions.

Is the "scriptSig" referenced in the BIP the "signature script" field referenced in the TxIn data type?

Yes.

I assume that adding the block number to the coinbase transaction sig doesn't inhibit using the transaction sig as an extra nounce?

Correct.  extra-nonce and block-height are both components of the coinbase transaction's script.  The script may have any type of data added via OP_PUSHDATA*

[optimator]

Thanks!

So if I submit a new block with a blockheader version 2 and a coinbase version 2, then how does it get accepted?

"Treat transactions with a version greater than 1 as non-standard (official Satoshi client will not mine or relay them)."

It seems to say that those transaction won't move??

[optimator]

Bump! And I'll also ask another question.

When you create a scriptsig for the coinbase transaction. Is it any random bits? Or is it as jgarzik references?...

The script may have any type of data added via OP_PUSHDATA*

What does that mean? I need to prefix my response with OP_PUSHDATA?

[jgarzik]

What does that mean? I need to prefix my response with OP_PUSHDATA?

Yes.  There are several push-data opcodes, the basic format looks like

     <size of random bytes to push><random bytes>

There may be many different data segments, e.g.

     <size of data field 1><data field 1>
     <size of data field 2><data field 2>
     <size of data field 3><data field 3>

When you create a scriptsig for the coinbase transaction. Is it any random bits? Or is it as jgarzik references?...

nVersion 1 blocks may have any random bytes (subject to the push-data rules above).

nVersion 2 blocks must have the block height as the first pushed-data object.

See https://github.com/bitcoin/bitcoin/blob/master/src/script.cpp source code or on the wiki https://en.bitcoin.it/wiki/Script#Constants for more details.

[runeks]

Thanks!

So if I submit a new block with a blockheader version 2 and a coinbase version 2, then how does it get accepted?

"Treat transactions with a version greater than 1 as non-standard (official Satoshi client will not mine or relay them)."

It seems to say that those transaction won't move??

Some blocks are already version 2:
https://blockexplorer.com/rawblock/00000000000003a81f3b36a46df322ee142a9d2ff1d2785ea539540c23a2d6ee

Now I get why, all of the sudden, the new getmemorypool command sent me data with nVersion=2. I thought it was a bug.

So I guess this means that clients older than 0.7.0 don't consider blocks with nVersion=2 to be invalid? The BIP says the "official Satoshi client will not mine or relay them", but the "official Satoshi client" is suggesting this version number itself, and everything seems to be working now with version 2 blocks included in the block chain.

[kjj]

Some blocks are already version 2:
https://blockexplorer.com/rawblock/00000000000003a81f3b36a46df322ee142a9d2ff1d2785ea539540c23a2d6ee

Now I get why, all of the sudden, the new getmemorypool command sent me data with nVersion=2. I thought it was a bug.

So I guess this means that clients older than 0.7.0 don't consider blocks with nVersion=2 to be invalid? The BIP says the "official Satoshi client will not mine or relay them", but the "official Satoshi client" is suggesting this version number itself, and everything seems to be working now with version 2 blocks included in the block chain.

Read this.

[runeks]

OK. I see. I just didn't think the older versions of the Satoshi client would accept version 2 blocks, but I guess that's the case.

[jgarzik]

OK. I see. I just didn't think the older versions of the Satoshi client would accept version 2 blocks, but I guess that's the case.

Over the P2P network, the Satoshi client will accept and relay nVersion=1 blocks until a super-majority of the network has upgraded to nVersion=2.

Locally, if you are mining, the Satoshi client provides nVersion=2 blocks via 'getwork' or 'getblocktemplate' RPCs.

[optimator]

Over the P2P network, the Satoshi client will accept and relay nVersion=1 blocks until a super-majority of the network has upgraded to nVersion=2.

Locally, if you are mining, the Satoshi client provides nVersion=2 blocks via 'getwork' or 'getblocktemplate' RPCs.

I feel really stupid..... "Over the P2P network, the Satoshi client will accept and relay nVersion=1" does this mean they will reject version 2?

From a mining perspective, if I want to get my block into the chain, it seems I should be mining a Version 1 block because it has the best chance of being propagated as part of the longest block chain, no?

[jgarzik]

I feel really stupid..... "Over the P2P network, the Satoshi client will accept and relay nVersion=1" does this mean they will reject version 2?

No.  Version 2 blocks are accepted and relayed just fine.

From a mining perspective, if I want to get my block into the chain, it seems I should be mining a Version 1 block because it has the best chance of being propagated as part of the longest block chain, no?

Mining a version 2 block will not hurt your chances of propagation.  You should mine version 2 blocks, if possible.