New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BIP-113: Mempool-only median time-past as endpoint for lock-time calculations #6566

Merged
merged 2 commits into from Oct 26, 2015

Conversation

Projects
None yet
@maaku
Contributor

maaku commented Aug 18, 2015

The lock-time code currently uses CBlock::nTime as the cutoff point for time based locked transactions. This has the unfortunate outcome of creating a perverse incentive for miners to lie about the time of a block in order to collect more fees by including transactions that by wall clock determination have not yet matured. By using CBlockIndex::GetMedianTimePast from the prior block instead, the self-interested miner no longer gains from generating blocks with fraudulent timestamps. Users can compensate for this change by simply adding an hour (3600 seconds) to their time-based lock times.

Transactions are not allowed in the memory pool or selected for inclusion in a block until their lock times exceed chainActive.Tip()->GetMedianTimePast(). However blocks including transactions which are only mature under the old rules are still accepted; this is not the soft-fork required to actually rely on the new constraint in production.

Note: This pull request is NO LONGER dependent on #6312 or #6564. If this pull request is merged first, those PR's will have to be updated to include median time-past codes for relative lock-time as well.

@maaku maaku changed the title from Medianpasttimelock to Mempool-only Median time-past as endpoint for lock-time calculations Aug 18, 2015

@btcdrak

This comment has been minimized.

Show comment
Hide comment
@btcdrak

btcdrak Sep 23, 2015

Member

needs rebase

Member

btcdrak commented Sep 23, 2015

needs rebase

@maaku maaku changed the title from Mempool-only Median time-past as endpoint for lock-time calculations to BIP-113: Mempool-only median time-past as endpoint for lock-time calculations Sep 24, 2015

@maaku

This comment has been minimized.

Show comment
Hide comment
@maaku

maaku Oct 16, 2015

Contributor

This pull request has been updated to no longer be dependent on #6312 or #6564.

Contributor

maaku commented Oct 16, 2015

This pull request has been updated to no longer be dependent on #6312 or #6564.

@dcousens

This comment has been minimized.

Show comment
Hide comment
@dcousens

dcousens Oct 16, 2015

Contributor

@maaku awesome.

Contributor

dcousens commented Oct 16, 2015

@maaku awesome.

@CodeShark

View changes

Show outdated Hide outdated src/main.cpp
// Only accept nLockTime-using transactions that can be mined in the next
// block; we don't want our mempool filled up with transactions that can't
// be mined yet.
if (!CheckFinalTx(tx))
if (!IsFinalTx(tx, chainActive.Height() + 1, nLockTimeCutoff))

This comment has been minimized.

@CodeShark

CodeShark Oct 19, 2015

Contributor

Minor nit: Other than removing the assertion on cs_main, is there any advantage to calling IsFinalTx directly rather than CheckFinalTx? If that difference could be important I would suggest having two versions of CheckFinalTx, one that does not have the assertion and one that has the assertion and calls the other one, since the rest of the logic seems to just be getting duplicated.

@CodeShark

CodeShark Oct 19, 2015

Contributor

Minor nit: Other than removing the assertion on cs_main, is there any advantage to calling IsFinalTx directly rather than CheckFinalTx? If that difference could be important I would suggest having two versions of CheckFinalTx, one that does not have the assertion and one that has the assertion and calls the other one, since the rest of the logic seems to just be getting duplicated.

This comment has been minimized.

@jtimon

jtimon Oct 19, 2015

Member

IsFinalTx is compatible with libconsensus, CheckFinalTx (by using globals) is not.
Consensus functions cannot access globals like chainActive or GetAdjustedTime() directly.

@jtimon

jtimon Oct 19, 2015

Member

IsFinalTx is compatible with libconsensus, CheckFinalTx (by using globals) is not.
Consensus functions cannot access globals like chainActive or GetAdjustedTime() directly.

This comment has been minimized.

@maaku

maaku Oct 19, 2015

Contributor

This isn't consensus code though. @CodeShark is right, we can save some lines by calling CheckFinalTx with an explicit flags parameter. I've made the change.

@maaku

maaku Oct 19, 2015

Contributor

This isn't consensus code though. @CodeShark is right, we can save some lines by calling CheckFinalTx with an explicit flags parameter. I've made the change.

@CodeShark

This comment has been minimized.

Show comment
Hide comment
@CodeShark

CodeShark Oct 19, 2015

Contributor

utACK

Contributor

CodeShark commented Oct 19, 2015

utACK

int64_t nLockTimeCutoff = (nLockTimeFlags & LOCKTIME_MEDIAN_TIME_PAST)
? pindexPrev->GetMedianTimePast()
: block.GetBlockTime();
if (!IsFinalTx(tx, nHeight, nLockTimeCutoff)) {
return state.DoS(10, error("%s: contains a non-final transaction", __func__), REJECT_INVALID, "bad-txns-nonfinal");
}

This comment has been minimized.

@btcdrak

btcdrak Oct 19, 2015

Member

style nit: braces not required for this if

@btcdrak

btcdrak Oct 19, 2015

Member

style nit: braces not required for this if

This comment has been minimized.

@maaku

maaku Oct 19, 2015

Contributor

Braces already existed. Principle of smallest diff :)

@maaku

maaku Oct 19, 2015

Contributor

Braces already existed. Principle of smallest diff :)

This comment has been minimized.

@laanwj

laanwj Oct 22, 2015

Member

There's nothing about brace usage for single-statement blocks in the developer-guide, so let's not nit about this. Also personally I like using braces everywhere where possible to avoid famous bugs like

if (something)
    do_something_else();
    goto handle_error;
@laanwj

laanwj Oct 22, 2015

Member

There's nothing about brace usage for single-statement blocks in the developer-guide, so let's not nit about this. Also personally I like using braces everywhere where possible to avoid famous bugs like

if (something)
    do_something_else();
    goto handle_error;

This comment has been minimized.

@btcdrak

btcdrak Oct 22, 2015

Member

OK, agreed.

@btcdrak

btcdrak Oct 22, 2015

Member

OK, agreed.

@btcdrak

This comment has been minimized.

Show comment
Hide comment
@btcdrak

btcdrak Oct 19, 2015

Member

utACK

Member

btcdrak commented Oct 19, 2015

utACK

@maaku

This comment has been minimized.

Show comment
Hide comment
@maaku

maaku Oct 19, 2015

Contributor

Nits addressed and rebased.

Contributor

maaku commented Oct 19, 2015

Nits addressed and rebased.

@btcdrak

This comment has been minimized.

Show comment
Hide comment
@btcdrak

btcdrak Oct 19, 2015

Member

Looks like Travis randomly borked. Needs another force push.

Member

btcdrak commented Oct 19, 2015

Looks like Travis randomly borked. Needs another force push.

@maaku

This comment has been minimized.

Show comment
Hide comment
@maaku

maaku Oct 20, 2015

Contributor

Travis is happy.

Contributor

maaku commented Oct 20, 2015

Travis is happy.

@dcousens

This comment has been minimized.

Show comment
Hide comment
@dcousens

dcousens Oct 20, 2015

Contributor

How does this mempool-only change stop the miners from just using their own mempool policies?

edit: nvm

This is not the soft-fork required to actually rely on the new constraint in production.


concept ACK, though I'd prefer to see a plan for merging the soft-fork before accepting this.

Contributor

dcousens commented Oct 20, 2015

How does this mempool-only change stop the miners from just using their own mempool policies?

edit: nvm

This is not the soft-fork required to actually rely on the new constraint in production.


concept ACK, though I'd prefer to see a plan for merging the soft-fork before accepting this.

@btcdrak

This comment has been minimized.

Show comment
Hide comment
@btcdrak

btcdrak Oct 20, 2015

Member

@dcousens These rules will be eventually enforced through a soft-fork.

Member

btcdrak commented Oct 20, 2015

@dcousens These rules will be eventually enforced through a soft-fork.

@btcdrak

This comment has been minimized.

Show comment
Hide comment
@btcdrak

btcdrak Oct 20, 2015

Member

@dcousens As discussed at the RC meeting on the 15th, we aim to roll this out with CLTV using standard ISM.

Member

btcdrak commented Oct 20, 2015

@dcousens As discussed at the RC meeting on the 15th, we aim to roll this out with CLTV using standard ISM.

@rustyrussell

This comment has been minimized.

Show comment
Hide comment
@rustyrussell

rustyrussell Oct 21, 2015

Contributor

Ack. Please apply soon :)

Contributor

rustyrussell commented Oct 21, 2015

Ack. Please apply soon :)

@instagibbs

This comment has been minimized.

Show comment
Hide comment
@instagibbs

instagibbs Oct 21, 2015

Member

ACK.

Member

instagibbs commented Oct 21, 2015

ACK.

@jmcorgan

This comment has been minimized.

Show comment
Hide comment
@jmcorgan

jmcorgan Oct 21, 2015

Contributor

utACK

Contributor

jmcorgan commented Oct 21, 2015

utACK

@afk11

This comment has been minimized.

Show comment
Hide comment
@afk11

afk11 Oct 21, 2015

Contributor

ACK

Contributor

afk11 commented Oct 21, 2015

ACK

/** Flags for LockTime() */
enum {
/* Use GetMedianTimePast() instead of nTime for end point timestamp. */
LOCKTIME_MEDIAN_TIME_PAST = (1 << 1),

This comment has been minimized.

@laanwj

laanwj Oct 22, 2015

Member

Why is this (1<<1) and not (1<<0) ? I don't think it interacts with any other flags. Hard to see from the context.

@laanwj

laanwj Oct 22, 2015

Member

Why is this (1<<1) and not (1<<0) ? I don't think it interacts with any other flags. Hard to see from the context.

This comment has been minimized.

@laanwj

laanwj Oct 22, 2015

Member

If the value comes from the BIP, please add a reference

@laanwj

laanwj Oct 22, 2015

Member

If the value comes from the BIP, please add a reference

This comment has been minimized.

@maaku

maaku Oct 22, 2015

Contributor

Because #6312, which this was originally built on top of, uses (1<<0).

@maaku

maaku Oct 22, 2015

Contributor

Because #6312, which this was originally built on top of, uses (1<<0).

@laanwj

View changes

Show outdated Hide outdated src/main.h
@@ -305,7 +305,7 @@ bool IsFinalTx(const CTransaction &tx, int nBlockHeight, int64_t nBlockTime);
*
* Calls IsFinalTx() with current block height and appropriate block time.
*/

This comment has been minimized.

@laanwj

laanwj Oct 22, 2015

Member

Add a comment about the flags field, e.g. where they come from

@laanwj

laanwj Oct 22, 2015

Member

Add a comment about the flags field, e.g. where they come from

@rubensayshi

This comment has been minimized.

Show comment
Hide comment
@rubensayshi

rubensayshi Oct 22, 2015

Contributor

utACK

Contributor

rubensayshi commented Oct 22, 2015

utACK

@gmaxwell

This comment has been minimized.

Show comment
Hide comment
@gmaxwell

gmaxwell Oct 22, 2015

Member

I think this code would be easier to be confident if it was (and would remain) consensus-correct if it introduced a second IsFinal() (or the like) and then used that explicitly from the mempool codepath. The max on the flags is a fairly weird operation.

Concept ACK.

Member

gmaxwell commented Oct 22, 2015

I think this code would be easier to be confident if it was (and would remain) consensus-correct if it introduced a second IsFinal() (or the like) and then used that explicitly from the mempool codepath. The max on the flags is a fairly weird operation.

Concept ACK.

@petertodd

This comment has been minimized.

Show comment
Hide comment
@petertodd

petertodd Oct 22, 2015

Contributor

utACK

@gmaxwell's nit doesn't bother me, as the CheckFinalTx() function wasn't supposed to be used in consensus code anyway.

Contributor

petertodd commented Oct 22, 2015

utACK

@gmaxwell's nit doesn't bother me, as the CheckFinalTx() function wasn't supposed to be used in consensus code anyway.

enum {
/* Use GetMedianTimePast() instead of nTime for end point timestamp. */
LOCKTIME_MEDIAN_TIME_PAST = (1 << 1),
};

This comment has been minimized.

@jtimon

jtimon Oct 22, 2015

Member

almost-bike-shedding: Are we going to have CheckFinalTx flags or something more generic like Transaction validation flags?

@jtimon

jtimon Oct 22, 2015

Member

almost-bike-shedding: Are we going to have CheckFinalTx flags or something more generic like Transaction validation flags?

This comment has been minimized.

@maaku

maaku Oct 23, 2015

Contributor

These flags are passed to LockTime(). Adding a bunch of other flag definitions which are not used by LockTime() would only cause confusion, I think.

@maaku

maaku Oct 23, 2015

Contributor

These flags are passed to LockTime(). Adding a bunch of other flag definitions which are not used by LockTime() would only cause confusion, I think.

@jtimon

This comment has been minimized.

Show comment
Hide comment
@jtimon

jtimon Oct 22, 2015

Member

utACK

Member

jtimon commented Oct 22, 2015

utACK

@dcousens

This comment has been minimized.

Show comment
Hide comment
@dcousens

dcousens Oct 23, 2015

Contributor

Agreed with @gmaxwell, lets remove the flag and just have two functions.
It would be trivially short anyway.

Contributor

dcousens commented Oct 23, 2015

Agreed with @gmaxwell, lets remove the flag and just have two functions.
It would be trivially short anyway.

@@ -261,7 +262,7 @@ BOOST_AUTO_TEST_CASE(CreateNewBlock_validity)
//BOOST_CHECK(CheckFinalTx(tx2));
BOOST_CHECK(pblocktemplate = CreateNewBlock(scriptPubKey));
BOOST_CHECK_EQUAL(pblocktemplate->block.vtx.size(), 3);
BOOST_CHECK_EQUAL(pblocktemplate->block.vtx.size(), 2);

This comment has been minimized.

@luke-jr

luke-jr Oct 23, 2015

Member

I suggest this should check that the correct transaction was included.

Preferably, the test should go on to produce a block that translates into the second transaction being included as well.

@luke-jr

luke-jr Oct 23, 2015

Member

I suggest this should check that the correct transaction was included.

Preferably, the test should go on to produce a block that translates into the second transaction being included as well.

@@ -162,7 +163,12 @@ CBlockTemplate* CreateNewBlock(const CScript& scriptPubKeyIn)
mi != mempool.mapTx.end(); ++mi)
{
const CTransaction& tx = mi->GetTx();
if (tx.IsCoinBase() || !IsFinalTx(tx, nHeight, pblock->nTime))
int64_t nLockTimeCutoff = (STANDARD_LOCKTIME_VERIFY_FLAGS & LOCKTIME_MEDIAN_TIME_PAST)

This comment has been minimized.

@luke-jr

luke-jr Oct 23, 2015

Member

I don't see why this can't be moved to a const like nMedianTimePast, and skip calculating it for every mempool tx?

@luke-jr

luke-jr Oct 23, 2015

Member

I don't see why this can't be moved to a const like nMedianTimePast, and skip calculating it for every mempool tx?

This comment has been minimized.

@maaku

maaku Oct 23, 2015

Contributor

Any compiler more recent than the 1960's will evaluate an expression consisting entirely of literals at compile time. In this case I prefer the clarity of specifying what is being tested in-line.

@maaku

maaku Oct 23, 2015

Contributor

Any compiler more recent than the 1960's will evaluate an expression consisting entirely of literals at compile time. In this case I prefer the clarity of specifying what is being tested in-line.

@luke-jr

This comment has been minimized.

Show comment
Hide comment
@luke-jr

luke-jr Oct 23, 2015

Member

@gmaxwell The max is only in CheckFinalTx (not IsFinal), which is never used for consensus-critical code...

Member

luke-jr commented Oct 23, 2015

@gmaxwell The max is only in CheckFinalTx (not IsFinal), which is never used for consensus-critical code...

@luke-jr

This comment has been minimized.

Show comment
Hide comment
@luke-jr

luke-jr Oct 23, 2015

Member

utACK, although prefer if at least this nit is done before merge.

Member

luke-jr commented Oct 23, 2015

utACK, although prefer if at least this nit is done before merge.

maaku added some commits Jun 3, 2015

Add rules--presently disabled--for using GetMedianTimePast as endpoin…
…t for lock-time calculations

The lock-time code currently uses CBlock::nTime as the cutoff point for time based locked transactions. This has the unfortunate outcome of creating a perverse incentive for miners to lie about the time of a block in order to collect more fees by including transactions that by wall clock determination have not yet matured. By using CBlockIndex::GetMedianTimePast from the prior block instead, the self-interested miner no longer gains from generating blocks with fraudulent timestamps. Users can compensate for this change by simply adding an hour (3600 seconds) to their time-based lock times.

If enforced, this would be a soft-fork change. This commit only adds the functionality on an unexecuted code path, without changing the behaviour of Bitcoin Core.
Enable policy enforcing GetMedianTimePast as the end point of lock-ti…
…me constraints

Transactions are not allowed in the memory pool or selected for inclusion in a block until their lock times exceed chainActive.Tip()->GetMedianTimePast(). However blocks including transactions which are only mature under the old rules are still accepted; this is *not* the soft-fork required to actually rely on the new constraint in production.
@maaku

This comment has been minimized.

Show comment
Hide comment
@maaku

maaku Oct 23, 2015

Contributor

I believe that nits have been addressed and this is ready for merge. @laanwj ?

Contributor

maaku commented Oct 23, 2015

I believe that nits have been addressed and this is ready for merge. @laanwj ?

@laanwj laanwj merged commit dea8d21 into bitcoin:master Oct 26, 2015

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

laanwj added a commit that referenced this pull request Oct 26, 2015

Merge pull request #6566
dea8d21 Enable policy enforcing GetMedianTimePast as the end point of lock-time constraints (Mark Friedenbach)
9d55050 Add rules--presently disabled--for using GetMedianTimePast as endpoint for lock-time calculations (Mark Friedenbach)
int nLockTimeFlags = 0;
int64_t nLockTimeCutoff = (nLockTimeFlags & LOCKTIME_MEDIAN_TIME_PAST)
? pindexPrev->GetMedianTimePast()
: block.GetBlockTime();

This comment has been minimized.

@NicolasDorier

NicolasDorier Oct 27, 2015

Member

nLockTimeCutoff assignment could be move outside the loop.
Is it because nLockTimeFlags will eventually be decided by the version of the transaction ?

@NicolasDorier

NicolasDorier Oct 27, 2015

Member

nLockTimeCutoff assignment could be move outside the loop.
Is it because nLockTimeFlags will eventually be decided by the version of the transaction ?

@luke-jr

This comment has been minimized.

Show comment
Hide comment
@luke-jr

luke-jr Nov 1, 2015

Member

It seems to me BIP 113 is actually a hardfork being treated as a softfork, at least how it currently stands, and this PR will potentially produce invalid blocks. Suggest reverting it and thinking through revising the BIP to be an actual softfork.

Member

luke-jr commented Nov 1, 2015

It seems to me BIP 113 is actually a hardfork being treated as a softfork, at least how it currently stands, and this PR will potentially produce invalid blocks. Suggest reverting it and thinking through revising the BIP to be an actual softfork.

@sipa

This comment has been minimized.

Show comment
Hide comment
@sipa

sipa Nov 1, 2015

Member

In my understanding - but this is just a rough check - it seems that Luke is right. A transaction whose locktime is between a block's nTime and its GetMedianTimePast() will be accepted post-BIP113 and not before. That looks like going from invalid to valid, which is a hard fork.

Member

sipa commented Nov 1, 2015

In my understanding - but this is just a rough check - it seems that Luke is right. A transaction whose locktime is between a block's nTime and its GetMedianTimePast() will be accepted post-BIP113 and not before. That looks like going from invalid to valid, which is a hard fork.

@maaku

This comment has been minimized.

Show comment
Hide comment
@maaku

maaku Nov 1, 2015

Contributor

Could you explain why it is a hard fork?
On Nov 1, 2015 10:58 AM, "Luke-Jr" notifications@github.com wrote:

It seems to me BIP 113 is actually a hardfork being treated as a softfork,
at least how it currently stands, and this PR will potentially produce
invalid blocks. Suggest reverting it and thinking through revising the BIP
to be an actual softfork.


Reply to this email directly or view it on GitHub
#6566 (comment).

Contributor

maaku commented Nov 1, 2015

Could you explain why it is a hard fork?
On Nov 1, 2015 10:58 AM, "Luke-Jr" notifications@github.com wrote:

It seems to me BIP 113 is actually a hardfork being treated as a softfork,
at least how it currently stands, and this PR will potentially produce
invalid blocks. Suggest reverting it and thinking through revising the BIP
to be an actual softfork.


Reply to this email directly or view it on GitHub
#6566 (comment).

@maaku

This comment has been minimized.

Show comment
Hide comment
@maaku

maaku Nov 1, 2015

Contributor

A valid block cannot have a nTime less than GetMedianTimePast + 1.
On Nov 1, 2015 11:03 AM, "Pieter Wuille" notifications@github.com wrote:

In my understanding - but this is just a rough check - it seems that Luke
is right. A transaction whose locktime is between a block's nTime and its
GetMedianTimePast() will be accepted post-BIP113 and not before. That looks
like going from invalid to valid, which is a hard fork.


Reply to this email directly or view it on GitHub
#6566 (comment).

Contributor

maaku commented Nov 1, 2015

A valid block cannot have a nTime less than GetMedianTimePast + 1.
On Nov 1, 2015 11:03 AM, "Pieter Wuille" notifications@github.com wrote:

In my understanding - but this is just a rough check - it seems that Luke
is right. A transaction whose locktime is between a block's nTime and its
GetMedianTimePast() will be accepted post-BIP113 and not before. That looks
like going from invalid to valid, which is a hard fork.


Reply to this email directly or view it on GitHub
#6566 (comment).

@sipa

This comment has been minimized.

Show comment
Hide comment
@sipa

sipa Nov 1, 2015

Member

Assume you have a perfect sequence of blocks, where block at height N has timestamp N*600.

Block 12 has timestamp 7200. Its mediantimepast() is 3600. It is valid as 7200 is >= 3601.

A transaction has nLockTime 5000. It is invalid currently in block 12, as 5000 is below 7200. Post BIP113, it is valid, as it is above 3600.

Member

sipa commented Nov 1, 2015

Assume you have a perfect sequence of blocks, where block at height N has timestamp N*600.

Block 12 has timestamp 7200. Its mediantimepast() is 3600. It is valid as 7200 is >= 3601.

A transaction has nLockTime 5000. It is invalid currently in block 12, as 5000 is below 7200. Post BIP113, it is valid, as it is above 3600.

@gmaxwell

This comment has been minimized.

Show comment
Hide comment
@gmaxwell

gmaxwell Nov 2, 2015

Member

@sipa No, we're being silly. The requirement is that the txlocktime be above $thing. Under the old rule $thing was blocktime, under this rule it is MTP. Since blocktime is already required to be greater than MTP, it's fine.

5000 < 7200 so that transaction is valid now. It is > 3600 so it wouldn't be accepted by MTP.

Member

gmaxwell commented Nov 2, 2015

@sipa No, we're being silly. The requirement is that the txlocktime be above $thing. Under the old rule $thing was blocktime, under this rule it is MTP. Since blocktime is already required to be greater than MTP, it's fine.

5000 < 7200 so that transaction is valid now. It is > 3600 so it wouldn't be accepted by MTP.

@NicolasDorier

This comment has been minimized.

Show comment
Hide comment
@NicolasDorier

NicolasDorier Nov 2, 2015

Member

The requirement is that the txlocktime be above $thing. Under the old rule $thing was blocktime.

So the requirement is : blocktime < txlocktime
[blocktime]7200 < [txlocktime]5000 evaluate to false so the transaction is invalid now.

Member

NicolasDorier commented Nov 2, 2015

The requirement is that the txlocktime be above $thing. Under the old rule $thing was blocktime.

So the requirement is : blocktime < txlocktime
[blocktime]7200 < [txlocktime]5000 evaluate to false so the transaction is invalid now.

@sipa

This comment has been minimized.

Show comment
Hide comment
@sipa

sipa Nov 2, 2015

Member

Indeed, I was wrong. I assumed that the tx timestamp was supposed to be above the block timestamp - not sure why I made that assumption - and even looking at the code didn't convince me otherwise.

I'm now convinced this is not a problem.

Member

sipa commented Nov 2, 2015

Indeed, I was wrong. I assumed that the tx timestamp was supposed to be above the block timestamp - not sure why I made that assumption - and even looking at the code didn't convince me otherwise.

I'm now convinced this is not a problem.

@NicolasDorier

This comment has been minimized.

Show comment
Hide comment
@NicolasDorier

NicolasDorier Nov 2, 2015

Member

The requirement is that the txlocktime be above $thing

The requirement is that the txlocktime be under $thing. Not above !
@sipa your example seemed right and this is indeed a hardfork.

Member

NicolasDorier commented Nov 2, 2015

The requirement is that the txlocktime be above $thing

The requirement is that the txlocktime be under $thing. Not above !
@sipa your example seemed right and this is indeed a hardfork.

@sipa

This comment has been minimized.

Show comment
Hide comment
@sipa

sipa Nov 2, 2015

Member

The requirement is the the blocktime is above the txlocktime, not the other way around.

Member

sipa commented Nov 2, 2015

The requirement is the the blocktime is above the txlocktime, not the other way around.

@NicolasDorier

This comment has been minimized.

Show comment
Hide comment
@NicolasDorier

NicolasDorier Nov 2, 2015

Member

Got it. This is what I said (txlocktime be under blocktime == blocktime be above txlocktime), but got confused by gmaxwell remark who refuted your point by saying wrongly "txlocktime be above blocktime".

I hate comparisons. :(

Member

NicolasDorier commented Nov 2, 2015

Got it. This is what I said (txlocktime be under blocktime == blocktime be above txlocktime), but got confused by gmaxwell remark who refuted your point by saying wrongly "txlocktime be above blocktime".

I hate comparisons. :(

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment