BIP65 CHECKLOCKTIMEVERIFY #118

petertodd commented at 9:49 AM on November 10, 2014: contributor

@gmaxwell As discussed.

First draft 5f6cb04d9c

petertodd renamed this:
~~Bip65 checklocktimeverify~~
BIP65 checklocktimeverify
on Nov 10, 2014

petertodd renamed this:
~~BIP65 checklocktimeverify~~
BIP65 CHECKLOCKTIMEVERIFY
on Nov 10, 2014

in bip-0065.mediawiki:None in 759c1f535b outdated

  83 | +
  84 | +
  85 | +===Non-interactive time-locked refunds===
  86 | +
  87 | +There exist a number of protocols where a transaction output is created that
  88 | +the co-operation of both parties to spend the output. To ensure the failure of

harding commented at 12:58 PM on November 10, 2014:

I think there's a missing "requires" between line 87 and 88: "is created that [requires] the co-operation of both parties"

petertodd commented at 1:22 PM on November 10, 2014:

Thanks!

petertodd force-pushed on Nov 10, 2014

BIP65 assigned for CHECKLOCKTIMEVERIFY b05bc1ef53

in bip-0065.mediawiki:None in b05bc1ef53

 167 | +non-trivial, and even the best existing technqiue - announce-commit sacrifices
 168 | +- could encourage mining centralization. CHECKLOCKTIMEVERIFY can be used to
 169 | +create outputs that are provably spendable by anyone (thus to mining fees
 170 | +assuming miners behave optimally and rationally) but only at a time
 171 | +sufficiently far into the future that large miners profitably can't sell the
 172 | +sacrifices at a discount.

luke-jr commented at 2:18 PM on November 10, 2014:

Specific example on how to ensure the transaction is mined prior to its output's lock time?

petertodd commented at 2:26 PM on November 10, 2014:

Point is, with CHECKLOCKTIMEVERIFY you don't have to prove that as it's a transaction output that can't be spent. All you need to do is prove that txout was created a prior to the lock time.

luke-jr commented at 2:42 PM on November 10, 2014:

Created and mined prior to the lock time. Nothing stops someone from holding on to a proof-of-sacrifice until they find the later-block themselves, and nothing guarantees the fair person's transaction will be mined until that point either...

petertodd commented at 2:45 PM on November 10, 2014:

I think making that distinction is rather pedantic; in the context of the paragraph it should be obvious to anyone who might need proof-of-sacrifice that when we say an output is 'created' we mean the transaction has been mined.

luke-jr commented at 2:47 PM on November 10, 2014:

Anyhow, this use case is not supported by the current draft as far as I can see. If it is, an example would be helpful.

petertodd commented at 2:52 PM on November 10, 2014:

What would you expect to see in the BIP for that usecase to be "supported"?

luke-jr commented at 2:56 PM on November 10, 2014:

A way to convey "<N blocks | N seconds> after the block height/time this transaction was mined in"

petertodd commented at 3:12 PM on November 10, 2014:

For proof-of-sacrifice you want the txout to be locked for months if not years to get past miner business cycles. I'm not worried about a transaction being censored when the timeframes are that long.

Anyway, a future BIP can define a CHECK-BLOCKHEIGHT-VERIFY opcode that leaves a block height on the stack, which could be used in conjunction with ADD to do what you want. But that's a heck of a lot of complexity right now for a very niche use-case.

luke-jr commented at 3:15 PM on November 10, 2014:

Censorship isn't likely to be the problem. More likely the miner just won't see value in mining the initial transaction until they can at the same time redeem the sacrificed funds.

Since this has a section of its own, it is obviously a primary use case and should be addressed. No need to mess with the stack for it, either...

petertodd commented at 3:23 PM on November 10, 2014:

Doing what you want would be about another order of magnitude more actual code changes; not worth it. If other people have strong feelings about this use-case I'd rather just remove it from the BIP.

Quite seriously, every additional line of consensus-critical code changed represents at minimum hours if not tens of hours of work.

in bip-0065.mediawiki:None in b05bc1ef53

  18 | +
  19 | +CHECKLOCKTIMEVERIFY re-defines the existing NOP2 opcode. When executed it
  20 | +compares the top item on the stack to the nLockTime field of the transaction
  21 | +containing the scriptSig. If that top stack item is greater than the transation
  22 | +nLockTime the script fails immediately, otherwise script evaluation continues
  23 | +as though a NOP was executed.

luke-jr commented at 2:49 PM on November 10, 2014:

This fails to distinguish between block-height and timestamp locktimes. Admittedly, this is just a summary, so maybe full details aren't needed here - but I don't see a proper Specification section in this BIP either.

petertodd commented at 2:53 PM on November 10, 2014:

The proper specification is the reference implementation, a very delibrate choice.

luke-jr commented at 2:57 PM on November 10, 2014:

The specification should be documented in the BIP.

petertodd commented at 3:13 PM on November 10, 2014:

Yes, and that reference implementation is included in the BIP, both in the form of a few lines of code, as well as a reference by git commit hash to a implementation including all dependencies.

gmaxwell referenced this in commit a3715c2de5 on Nov 12, 2014

gmaxwell merged this on Nov 12, 2014

gmaxwell closed this on Nov 12, 2014

ghost commented at 1:50 PM on November 12, 2014: none

The process described under the escrow portion is technically not escrow. Escrow is when a third party has control of the funds.

hoffmabc commented at 2:37 PM on November 12, 2014: none

@millybitcoin I'm not sure what you mean by that. There is technically a third-party represented by the multisig signing group. It is not a single person but rather a group fulfilling this role. I believe this meets your definition perfectly fine.

ghost commented at 3:02 PM on November 12, 2014: none

It is not "my definition," it is the normal definition of escrow which means a third party has custody of the funds. This is also a legal definition and escrow operators normally need a special license and bonding because they have custody of the funds. In my State an escrow agent needs a special license and needs to be fingerprinted.

If you have a 2-of-3 transactions where 2 people are doing a transaction and a third party has authority to sign the transaction as a mediator then that is not escrow because the mediator does not have custody of the funds.

May people also confuse escrow with dispute resolution. Dispute resolution is a separate and distinct process from escrow and is usually a conflict of interest for one party to do both. You can see the agreement at escrow.com as an example of how these functions are separate

ghost commented at 3:24 PM on November 12, 2014: none

maybe it should be labeled "Escrow Alternative" or "Mediated Transaction"