BIP68/113 for generation transaction #415

pull jl2012 wants to merge 1 commits into bitcoin:master from jl2012:bip68_113_coinbase changing 2 files +4 −0

jl2012 commented at 9:30 AM on July 5, 2016: contributor

To clarify the applicability of BIP68 and 113 to generation transaction
luke-jr commented at 2:53 PM on July 5, 2016: member

@maaku @btcdrak @NicolasDorier @afk11
luke-jr added the label Proposed BIP modification on Jul 5, 2016
maaku commented at 3:01 PM on July 5, 2016: contributor

This isn't true. The rules apply as much to outputs of a coinbase as they do any other transaction. Is the proposed text talking about the coinbase's nSequence value? Then that should be specified exactly, although I don't think the clarification is necessary (coinbase is already specially treated).
jl2012 commented at 3:16 PM on July 5, 2016: contributor

@maaku, isn't the SequenceLocks is done only for non-coinbase tx?

https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L2480

And we do need to clarify as some miners are using the nSequence as extranonce (I'm talking about the BIP68, not BIP112)
luke-jr commented at 3:48 PM on July 5, 2016: member

nSequence is about inputs, not outputs... and the new rule for it doesn't make sense for the generation tx input since it's not spending coins.
luke-jr cross-referenced this on Jul 5, 2016 from issue Bugfix: 2016-06-21-csv-softfork-instructions: nSequence is unmodified… by luke-jr
afk11 commented at 4:03 PM on July 5, 2016: contributor

For 113 (MTP), the generation transaction's locktime is checked, so looks good to me: https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L3602 @jl2012 Maybe clarify by saying 68 doesn't apply to the inputs of the coinbase transaction? It can certainly apply to spends of it's outputs.
jl2012 force-pushed on Jul 5, 2016
jl2012 commented at 4:40 PM on July 5, 2016: contributor

@maaku @afk11 @luke-jr Edited

in bip-0068.mediawiki:None in 24eaeedac3 outdated

  48 | @@ -49,6 +49,8 @@ The block produced time is equal to the median-time-past of its previous block.
  49 |  
  50 |  When the relative lock-time is block-based, it is interpreted as a minimum block-height constraint over the input's age. A relative block-based lock-time of zero indicates an input which can be included in any block. More generally, a relative block lock-time n can be included n blocks after the mining date of the output it is spending, or any block thereafter.
  51 |  
  52 | +The new rules are not applied to the nSequence field of the input of generation transaction.

maaku commented at 4:57 PM on July 5, 2016:

"of the generation"

Is this the proper terminology? Should we say "coinbase transaction" here? Honestly not sure what the current accepted terminology is.

btcdrak commented at 5:34 PM on July 5, 2016:

"coinbase tx" is definitely more common.

luke-jr commented at 1:02 AM on July 6, 2016:

The coinbase is the input scriptSig for the generation transaction.

maaku commented at 4:57 PM on July 5, 2016: contributor

Right, the sequence lock checks are not done for the coinbase input. The updated text is better (see comment made)
jl2012 force-pushed on Jul 5, 2016
BIP68/113 for generation transaction 8d40b6ef02
jl2012 force-pushed on Jul 5, 2016
jl2012 commented at 5:54 PM on July 5, 2016: contributor

@maaku @btcdrak fixed
afk11 commented at 6:12 PM on July 5, 2016: contributor

ACK 8d40b6e
btcdrak commented at 6:30 PM on July 5, 2016: contributor

ACK 8d40b6e
maaku commented at 6:45 PM on July 5, 2016: contributor

ACK 8d40b6e
luke-jr commented at 1:02 AM on July 6, 2016: member

Disagree with "coinbase transaction", but this is hardly the first time, and an ACK is an ACK...
luke-jr merged this on Jul 6, 2016
luke-jr closed this on Jul 6, 2016

Contributors

Labels

Proposed BIP modification