Update bip-0112.mediawiki #381

CHECKLOCKTIMEVERIFY is absolute (not relative) isn't it?

ACK bffcc0c29a25e3fcbf92ee15fa6f23fe53a7c469, my understanding is that OP_CHECKSEQUENCEVERIFY is relative (a.k.a OP_RELATIVECHECKLOCKTIMEVERIFY). Another interesting way to verify this is https://github.com/ElementsProject/lightning/blob/f4e94147a7281ec05e078ff9f3e6d65893417bad/bitcoin/script.c#L377

This is the second time this has come up so maybe it's worth addressing. That's it's an absolute timelock cannot be misunderstood because that's what the opcode does, but I would prefer to notate it as something like <now + 24h> similar to how it's notated in BIP65.

@btcdrak Using <now + 24h> is clear enough. Using a literal "24h" is simply confusing, especially when the two HTLC commitment examples use different string literals as they currently do:

With CHECKSEQUENCEVERIFY, a HTLC payable to Alice might look like the following in Alice's commitment transaction: "24h" CHECKLOCKTIMEVERIFY DROP and correspondingly in Bob's commitment transaction: "2015/10/20 10:33" CHECKLOCKTIMEVERIFY

@dooglus Please make the change then I can ack it.

How would you like the change?

There are currently three examples of CHECKLOCKTIMEVERIFY in the BIP:

    `"2015/12/15" CHECKLOCKTIMEVERIFY DROP`

       `"24h" CHECKLOCKTIMEVERIFY DROP`

  `"2015/10/20 10:33" CHECKLOCKTIMEVERIFY`

Do you want them all to use a relative time offset? Or just the last two? Or do you want the Alice and Bob commitments, which are pretty much symmetrical, to use different types of offset, one relative and one absolute?

I'm not understanding your motivation for wanting any of them to be relative to now when the opcode itself uses an absolute time, and so it's hard to know exactly what kind of a change you would be willing to accept.

@dooglus Yes you are right. OK as is.

ACK bffcc0c

ping @luke-jr please can you merge this.