The following is I believe an example of how we can use a transaction (kernel) timelock to implement a timelock on a single output.
I believe this could also be extended to more complex scenarios by using multisig
to allow conditionals like “Output can be spent by Alice after 100 blocks or by Bob immediately”.
We know how to do two things today -
- We can add an absolute, unconditional lock_height to a tx_kernel.
The transaction will not be accepted earlier than block height x.
- We can “split” a private key and use the two parts across two outputs such that they can only be spent as a pair.
k = k1 + k2
(Similar to how we split private keys when generating the kernel offset in https://github.com/mimblewimble/grin/pull/681).
If we use
k1 to sign
k2 to sign
o2) I think we can construct a pair of outputs
[o1, o2] such that they can be spent as a pair.
If we can split the key in such a way that no party knows the individual key parts
k2 then they can only be spent as a pair with key
We now have a situation where
tx2 can be accepted to the blockchain separately.
o2 can only be spent together as a pair in a subsequent tx.
By introducing a simple unconditional lock_height on one of these transactions,
this lock_height will restrict the other output from being spent.
o1) has a lock_height of
x. We cannot broadcast
tx1 until at least block height
We can broadcast
tx2 immediately but the contained output
o2 cannot be spent
x, given the lock_height on
tx2 cannot be spent until height
x, due to the timelock on
Or stated differently - the private key to spend
o2 is only available once
tx1 is accepted at height
x due to
[o1, o2] only being spendable as a pair via the single private key
We have turned a transaction (kernel) timelock into a timelock on a single output, via a private key, allowing us to also potentially introduce conditional logic via multisig.