Bitcoin Forum

It is an invalid txn.  It won't be relayed or included in a block by default.  If a miner did include it in a block then the block is invalid.  Similar to a txn with a future nlocktime.

Does the node just drop it though?  It could be placed in the orphan pool and then added to the memory pool once the timeout has expired (and thus relayed).

Interesting - as a potential attack vector it wouldn't be so easy but I'd guess it still could be such a potential if the txs were relayed wouldn't it?

If you spend the coinbase output twice, then the 2nd one wouldn't be relayed, as it is a doublespend.

What happens if a transaction is submitted that spends a coinbase output early?

Is the transaction just placed in the orphan pool and potentially lost by the time the timeout ends?  In theory, they should be higher priority than normal orphans, since they are guaranteed to be valid eventually.

I don't think they are guaranteed to be valid eventually. For example, it could be the case that the first block in which the coinbase becomes spendable (so 100 blocks after the block it is mined in) sends the funds it to a different address than the one you saved in your mempool.

AFAIK, the current invariant of the mempool is that all the transactions could be gathered up into one big block (assuming the 1 MB restriction doesn't apply). This would have to change to allow relaying of prematures coinbase spends. The block building code would have to take this into account as well, making sure it doesn't build a block that will be invalid.

I believe the restriction is more than that; the mempool transactions could be gathered up into one big block (if they fit under the blocksize restriction) *AND* that hypothetical block would be valid as the very next block in the chain.  

Well I think that was his point right.   Valid is sort of implied (one big block = one big valid block). 

The thing I was talking about was not validity, it was about it being valid AS THE VERY NEXT BLOCK.  

Other tx which appear to be valid (and do not actively conflict with tx in the mempool or in the chain as accepted so far),  are retained (as "orphans") even if the transactions that create the txOuts they spend have not yet been received.

Yes that was understood and the person and it was understood from the post you replied to as well.  That post can't be read any other way.


I do not believe that is correct. To be included in the memory pool the inputs of a txn must reference an output in the utxo.  The sending peer is not penalized as there are legitimate reasons but the txn is not added to the memory pool.

https://github.com/bitcoin/bitcoin/blob/687f10d9ec3548f13f929ca14cd813a0919639ec/src/main.cpp#L1021
https://github.com/bitcoin/bitcoin/blob/687f10d9ec3548f13f929ca14cd813a0919639ec/src/main.cpp#L1380

Consensus on the bitcoin-dev IRC chat is that no other versions have penalized forwarding of pre-mature spends of coinbase transactions, but that there doesn't seem to be any real use-case for such a feature.

<hash of tx> OP_HASH_THIS_TRANSACTION OP_EQUALVERIFY

If you'd like to hard fork to deal with the problem of updating the extranonce, the "correct" solution would be to add it to the header.  But that'll never happen.

That would be the correct solution if CPU or GPU mined.  There is no way in hell that there'd ever be miner support for something that would destroy the value of their investment in ASICs.

There is no way in hell that there'd ever be miner support for something that would destroy the value of their investment in ASICs.

- snip -
A while back I proposed a way to expand the header while still maintaining compatibility with existing ASICs (but would require a hard fork and updated mining software). Maybe I can find a link.
- snip -

SHA-256 handles messages larger than 512 bits by breaking the message into blocks that are 512 bits long.  The first block input is fed into the hashing function and that output (h0) is combined with the second input block and that output (h1) is combined with the third input, etc, etc, until all inputs have been hashed. This is how a message of arbitrary size (even say a 4GB ISO) can be reduced to a single 256 bit value.

The "zeroes" are simply spacing bits.  They could be anything as long as the format of the final block (partial hash not bitcoin blocks) remains the same length and ends with a 32 bit nonce.

The current bitcoin block header is 640 bits long
This means the first 512 bits is hashed and the output of the function is stored h0
The next 128 bits is then hashed with the output of h0 to produce h1.  This is then hashed again because Bitcoin uses SHA256d.

Now ASICS are "dumb" they really have no idea what they are hashing.  Since h0 remains relatively static (the nonce is in the second block), the mining software (local miner) will compute the h0 partial hash and feed that plus the 96 bits in the second block to the ASIC.  The ASIC appends the 32 bit counter (nonce) and computes the hash incrementing internally as needed and returning results.

So to remain compatible with existing ASICS requires two things:
a) a 256 bit h(x) partial hash value
b) the last block (partial hash input) must consist of exactly 96 bits + a 32 bit nonce.

Anything different would result in a format that existing ASICS don't understand.   

The comment about "must be zero do not use" just means it is padding and must be consistent in the protocol it could be anything all zeroes, all ones, ASCII code for "Satoshi Rules 123...." as long as it is 48 bytes long.  There is no actual requirement that the protocol/standard must only use zeroes.  If a different format was used the padding would be smaller or longer to to ensure that 96 bits + a 32 bit nonce are the only elements in the final partial hash.  This way no matter how large you want the header to be it will still hash down to a h(x) partial hash plus 96 bits + a 32 bit nonce and be compatible with existing hardware.

Personally I have considered a change like this but I would propose a modified structure.  I would use a 64 bit nonce in the last segment (replacing the nonce, nonce2, and nonce3).  This would support for miners as powerful as 18,446 PH/s without overflowing the nonce.   The larger nonce field could be supported by existing hardware in a backwards compatible mode in a similar manner to how 32 bit values are stored in 64 bit CPU registers.   The upper 32 bits would simply be zeroed.   The existing miners (who only understand the concept of a 32 bit nonce) would simply hash a value which ends with 00000000 plus a 32 bit nonce.  The local miner (cgminer) could increment the upper 32 bits to provide support for higher hashrate hardware.  In time ASIC developers would release "enhanced" hardware which uses a larger nonce space internally to handle higher throughput.

Luckily that is not correct.  A while back I proposed a way to expand the header while still maintaining compatibility with existing ASICs (but would require a hard fork and updated mining software). Maybe I can find a link.  

The header will eventually need to be updated when the Unix time value overflows the 32 bit integer but we have a 'little' while before that happens.

This one?

https://bitcointalk.org/index.php?topic=626377.msg6963192#msg6963192

If the point is to make getting more work easier by not having to hash 10-20 Kb of coinbase data, then why not ...

Either way, I haven't seen any numbers that show that a CPU can't recalculate merkle roots as fast as an ASIC can exhaust a whole 2^32 nonce range. Is that actually an issue?

I agree that it would be better to have the extra nonce right in the header to avoid recalculating the merkle root entirely, but while I find the extended header idea interesting, I'm not sure it's in sufficient need that it would be worth all the extra work and support.