Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time

[Peter Todd <pete@petertodd.org>]

[-- Attachment #1: Type: text/plain, Size: 1458 bytes --]

On Thu, Oct 09, 2014 at 06:28:19AM +0000, Gregory Maxwell wrote:
> On Thu, Oct 9, 2014 at 6:14 AM, Adam Back <adam@cypherspace.org> wrote:
> > I think you can do everything with the existing script level nlocktime
> > in some kind of turing completeness sense (maybe); but there is a
> > complexity cost that often you have to resort to extra dependent
> > transaction(s) (and work-around malleability until that is fully
> > fixed) just to get the effect.
> 
> Right, ... moreover, even with all the malleability fixes, they only
> work if you refrain from using certain features (e.g. cannot do an
> anyone-can-pay) and we cannot be completely sure all accidental
> vectors for malleability are gone (we've been unable to construct a
> proof that our strengthening of ECDSA turns it into a strong
> signature, though it seems likely).
> 
> Having the locktime control in a scriptPubKey sidesteps all those
> limitations and simplifies protocols (e.g. not requiring some three
> step state machine and a bunch of risky validation code to be sure a
> refund you receive is actually workable).

Speaking of, can anyone think of an example of a complex transaction
use-case that is affected by malleability which can't be fixed by
CHECKLOCKTIMEVERIFY? I'm sure they exist, but I'm scratching my head
trying to think of a good example.

-- 
'peter'[:-1]@petertodd.org
000000000000000012367d385ad11358a4a1eee86cf8ebe06a76add36dfb4622

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]