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

2014-10-09 Thread Adam Back
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.

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

2014-10-09 Thread Gregory Maxwell
On Thu, Oct 9, 2014 at 6:14 AM, Adam Back a...@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

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

2014-10-09 Thread Peter Todd
On Thu, Oct 09, 2014 at 06:28:19AM +, Gregory Maxwell wrote: On Thu, Oct 9, 2014 at 6:14 AM, Adam Back a...@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

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

2014-10-09 Thread Gregory Maxwell
On Thu, Oct 9, 2014 at 6:33 AM, Peter Todd p...@petertodd.org wrote: 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

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

2014-10-08 Thread Mike Hearn
Opinion: if a soft work works, it should be preferred, if for no other reason than once a hard-fork is planned, the discussion begins about what else to throw in. To minimize the frequency of hard-forks, the time for that is when the change being considered actually requires one. I'm not

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

2014-10-08 Thread Wladimir
On Tue, Oct 7, 2014 at 6:08 PM, Mike Hearn m...@plan99.net wrote: That is easy to change; I'll submit a pull request. That's certainly a useful improvement. It won't help the existing userbase though - assuming CHECKLOCKTIMEVERIFY is to go in to the next major release. The next minor release

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

2014-10-08 Thread Alan Reiner
By the way, I really like this proposal. I haven't spent much time thinking about the deeper subtleties and risks associated with it, but I see a lot of opportunities. One just came to mind that I didn't see mentioned in his original proposal: _Non-Interactive Recurring payments__with

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

2014-10-07 Thread Gavin Andresen
On Sat, Oct 4, 2014 at 8:58 AM, Mike Hearn m...@plan99.net wrote: Meanwhile, what I said *is* correct. New version numbers result in only a log print. Being hard forked off results in both log prints *and* the -alertnotify being run: That is easy to change; I'll submit a pull request. It is

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

2014-10-07 Thread Mike Hearn
That is easy to change; I'll submit a pull request. That's certainly a useful improvement. It won't help the existing userbase though - assuming CHECKLOCKTIMEVERIFY is to go in to the next major release. If there's going to be an intermediate release (6 months?) which lays the groundwork for

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

2014-10-07 Thread Tom Harding
On 10/7/2014 8:50 AM, Gavin Andresen wrote: I don't have any opinion on the hard- versus soft- fork debate. I think either can work. Opinion: if a soft work works, it should be preferred, if for no other reason than once a hard-fork is planned, the discussion begins about what else to

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

2014-10-04 Thread Mike Hearn
Anyway the stuff Mike is saying about being able to detect upgrades is incorrect - detecting an upgrade is *easier* with a soft-fork, just look at the block header nVersion numbers and warn the user if they increase beyond what you know is valid. Bitcoin Core implements this IIRC, and

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

2014-10-03 Thread Matt Whitlock
Is there a reason why we can't have the new opcode simply replace the top stack item with the block height of the txout being redeemed? Then arbitrary logic could be implemented, including output cannot be spent until a certain time and also output can ONLY be spent until a certain time, as

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

2014-10-03 Thread Matt Whitlock
Oops, sorry. I meant: replace the top stack item with the block height of the txin doing the redeeming. (So the script can calculate the current time to some reference time embedded in the script.) On Friday, 3 October 2014, at 10:28 am, Matt Whitlock wrote: Is there a reason why we can't

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

2014-10-03 Thread Gregory Maxwell
On Fri, Oct 3, 2014 at 7:28 AM, Matt Whitlock b...@mattwhitlock.name wrote: Is there a reason why we can't have the new opcode simply replace the top stack item with the block height of the txout being redeemed? This would not be soft-forking compatible. It also would be unsafe in that it

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

2014-10-03 Thread Luke Dashjr
On Friday, October 03, 2014 2:28:17 PM Matt Whitlock wrote: Is there a reason why we can't have the new opcode simply replace the top stack item with the block height of the txout being redeemed? Then arbitrary logic could be implemented, including output cannot be spent until a certain time

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

2014-10-03 Thread Mike Hearn
Alright. It seems there's no real disagreement about how the opcode behaves. Perhaps a time limit would be appropriate to stop people creating outputs locked for 100 years is bitcoin even likely to exist in 100 years? The entire history of computing is not even that old, seems hard to imagine

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

2014-10-03 Thread Jeff Garzik
RE It's not like other software where people can choose to skip an upgrade and things still work just like before. If you're a minority, sure you can. Still a few nutters out there on a 0.3.x codebase, including one or two inattentive, now-inconsequential miners. There is some headroom built

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

2014-10-03 Thread Peter Todd
On Fri, Oct 03, 2014 at 07:12:11PM -0400, Jeff Garzik wrote: RE It's not like other software where people can choose to skip an upgrade and things still work just like before. If you're a minority, sure you can. Still a few nutters out there on a 0.3.x codebase, including one or two

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

2014-10-02 Thread Flavien Charlon
Very good, I like the proposal. A question I have: can it be used to do the opposite, i.e. build a script that can only be spent up until block X? On Thu, Oct 2, 2014 at 2:09 AM, Peter Todd p...@petertodd.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 1 October 2014

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

2014-10-01 Thread Peter Todd
I've written a reference implementation and BIP draft for a new opcode, CHECKLOCKTIMEVERIFY. The BIP, reproduced below, can be found at: https://github.com/petertodd/bips/blob/checklocktimeverify/bip-checklocktimeverify.mediawiki The reference implementation, including a full-set of

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

2014-10-01 Thread Gavin Andresen
Very nice, semantics are clear and use cases are compelling. Can we defer discussion of how to roll this out for a little bit, and see if there is consensus that: a) benefits of having this outweigh risks b) we're all happy with exact semantics Then we can have a knock-down drag-out argument

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

2014-10-01 Thread Sergio Lerner
I like the proposal. I suggest that applications and nodes should only broadcast transactions having OP_CHECKLOCKTIMEVERIFY a few blocks after the timeout value. If a node broadcasts a TX having OP_CHECKLOCKTIMEVERIFY and nLockTime is equal to the current height and equal to the timeout value,

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

2014-10-01 Thread Peter Todd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Yeah, there are lots of upper-level details to consider; I'm not going to pretend that BIP is complete yet. My thinking is that the first release should include my NOPx blacklist pull-req, and leave NOP2/CHECKLOCKTIMEVERIFY in that blacklist for

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

2014-10-01 Thread Luke Dashjr
On Wednesday, October 01, 2014 1:08:26 PM Peter Todd wrote: I've written a reference implementation and BIP draft for a new opcode, CHECKLOCKTIMEVERIFY. Thoughts on some way to have the stack item be incremented by the height at which the scriptPubKey was in a block? A limitation of encoding

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

2014-10-01 Thread Gavin Andresen
On Wed, Oct 1, 2014 at 2:23 PM, Luke Dashjr l...@dashjr.org wrote: houghts on some way to have the stack item be incremented by the height at which the scriptPubKey was in a block? A limitation of encoding the target height/time directly, is that miners may choose not to mine the first

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

2014-10-01 Thread Alan Reiner
On 10/01/2014 04:58 PM, Gavin Andresen wrote: If the first transaction is P2SH, then the miner won't know there is an advantage to holding it until it is too late (the scriptPubKey is an opaque hash until the second transaction is final and relayed/broadcast). If you're doing some kind of

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

2014-10-01 Thread Gavin Andresen
On Wed, Oct 1, 2014 at 5:04 PM, Alan Reiner etothe...@gmail.com wrote: On 10/01/2014 04:58 PM, Gavin Andresen wrote: If the first transaction is P2SH, then the miner won't know there is an advantage to holding it until it is too late (the scriptPubKey is an opaque hash until the second

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

2014-10-01 Thread Peter Todd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 1 October 2014 11:23:55 GMT-07:00, Luke Dashjr l...@dashjr.org wrote: Thoughts on some way to have the stack item be incremented by the height at which the scriptPubKey was in a block? Better to create a

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

2014-10-01 Thread Peter Todd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 1 October 2014 14:34:33 GMT-07:00, Gavin Andresen gavinandre...@gmail.com wrote: On Wed, Oct 1, 2014 at 5:04 PM, Alan Reiner etothe...@gmail.com wrote: No, the burner would supply the funding transaction plus the redeeming script as the

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

2014-10-01 Thread Luke Dashjr
On Thursday, October 02, 2014 12:05:15 AM Peter Todd wrote: On 1 October 2014 11:23:55 GMT-07:00, Luke Dashjr l...@dashjr.org wrote: Thoughts on some way to have the stack item be incremented by the height at which the scriptPubKey was in a block? Better to create a

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

2014-10-01 Thread Peter Todd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 1 October 2014 08:01:28 GMT-07:00, Gavin Andresen gavinandre...@gmail.com wrote: Very nice, semantics are clear and use cases are compelling. Thanks! Can we defer discussion of how to roll this out for a little bit, and see if there is