On Thu, May 28, 2015 at 1:04 PM, Peter Todd <pete@petertodd.org> wrote:

For that matter, we probably don't want to treat this as a *version*
change, but rather a *feature* flag.

I think it is still a version change. At the moment, the 4 bytes refer to the sequence number and afterwards they mean something else.

For relative locktime verify, I think most use cases could be block count based and don't need to be able to count very high.

I think the main benefit is that protocols can have one party trigger a step while giving the other party guaranteed time to respond.

Fast Channel Close

This assumes that malleability is fixed.

Alice creates

TXA:
output (x) to [multisig A1 & B1]

Refund:
input TXA (signed by Alice)

Output [(A2 & relative_check_locktime(150)) OR (multisig A3 & B2)]

Alice sends Refund to Bob

Bob signs it and sends it back to Alice

Alice verifies the signature, adds her own and sends it to Bob.

She broadcasts TXA (would wait until Bob confirms acceptance).

This means that both Alice and Bob have the refund transaction and can use it to close the channel (assuming TXA is not mutated).

Alice can send money to Bob by creating a transaction which spends the output of the refund transaction (splitting the output x-b for Alice and b for Bob), signing it and sending it to Bob.

Alice can force Bob to close the channel by broadcasting the refund transaction. 150 blocks later, she gets the channel deposit if he doesn't act.

If she had sent some money to Bob, he has 150 blocks to sign the transaction that pays him the most money and broadcast it. Alice gets the remainder of the deposit.

Alice cannot broadcast earlier version, since Bob doesn't send her the signed versions.

This means that the channel doesn't need a defined end date. Either party can close the channel whenever they want.

TXA could be protected against malleability by adding a locktime path. This would only be for use if the transaction is mutated.