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.

When I tried building things that need nlocktime I found it quite
inconvenient that it was wasnt a function rather than a script
property, so I like this proposal.

Adam

On 9 October 2014 04:13, Alan Reiner etothe...@gmail.com wrote:
 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 ID-association:
 You want to make N recurring payments of 1 BTC each month to a service.
 Sign N transactions each of them use a CHECKLOCKTIMEVERIFY block number
 approximately X months in the future (one for each month).   The script
 allows the customer to move the coins at any time, but after the locktime
 the merchant/service has signing access.  The merchant software will
 continually watch for and sweep all coins that become available via this
 mechanism and credit the appropriate customer account.  The customer
 maintains control of the funds until payment time, the merchant can
 automatically collect it each month without requiring user interaction, and
 the customer can cancel it just by spending it elsewhere before the
 locktime.

 This scheme has an added benefit:  both the merchant's address and the
 user's address is in the script.  Given an appropriate scheme for linking
 addresses to accounts (perhaps sending the service a watch-only BIP32
 branch), the service can use the other address in the script to recognize
 and link that payment to the user's account.  This allows you to continue
 paying and extending your subscription without having to explicitly link
 each payment to the account.  The wallet will simply make sure to use a
 return address that is in a BIP32 branch that was provided to the service
 during signup, and the service will automatically extend your subscription
 every month based on that info when it sweeps payments.

 Along with everything else that was mentioned by Peter in his original
 proposal, I see OP_CHECKLOCKTIMEVERIFY as an enabling feature, not just a
 simple improvement.

 -Alan



 On 10/08/2014 06:26 AM, Wladimir wrote:

 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 (0.9.4) could have Gavin's change already.

 I don't think CHECKLOCKTIMEVERIFY will make it into the next major
 release though. Once headers-first and pruning is merged (which is
 expected to be a matter of weeks). I'd like to split off the 0.10
 branch and give it some time to stabilize with a feature freeze, then
 do a release before the end of the year.

 So 0.11, in say 6 months, would be soonest.

 Wladimir

 --
 Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
 Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
 Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
 Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
 http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development



 --
 Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
 Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
 Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
 Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
 http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___

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 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).

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 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
12367d385ad11358a4a1eee86cf8ebe06a76add36dfb4622


signature.asc
Description: Digital signature
--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 good example.

Yea, no problem since we lack covenants.

Or a least no problem making an example, maybe you'll find it too
contrived since I'm not sure what would motivate it:

You and I put 5 btc each into a kickstarter-escrow to pay Alice+some
oracle that decides if alice did her job.  But if a timeout expires
before alice manages to get the sign off the funds must be returned
completely to their original payers.

Returning them to in two outputs, one to me, one to you is trivial
with a pre-signed refund.

You could make there be multiple alice outputs or refund, but then you
can't guarantee an atomic reversal (e.g. maybe Alice gets half if we
race).

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 sure why it'd be any different. Soft forks are just as disruptive -
everyone who needs a correct node has to upgrade on time. Given that, I
guess there will be a desire to roll out several changes at once too,
regardless of what happens to older nodes.
--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 (0.9.4) could have Gavin's change already.

I don't think CHECKLOCKTIMEVERIFY will make it into the next major
release though. Once headers-first and pruning is merged (which is
expected to be a matter of weeks). I'd like to split off the 0.10
branch and give it some time to stabilize with a feature freeze, then
do a release before the end of the year.

So 0.11, in say 6 months, would be soonest.

Wladimir

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 ID-association_:
You want to make N recurring payments of 1 BTC each month to a service. 
Sign N transactions each of them use a CHECKLOCKTIMEVERIFY block number
approximately X months in the future (one for each month).   The script
allows the customer to move the coins at any time, but after the
locktime the merchant/service has signing access.  The merchant software
will continually watch for and sweep all coins that become available via
this mechanism and credit the appropriate customer account.  The
customer maintains control of the funds until payment time, the merchant
can automatically collect it each month without requiring user
interaction, and the customer can cancel it just by spending it
elsewhere before the locktime. 

This scheme has an added benefit:  both the merchant's address and the
user's address is in the script.  Given an appropriate scheme for
linking addresses to accounts (perhaps sending the service a watch-only
BIP32 branch), the service can use the other address in the script to
recognize and link that payment to the user's account.  This allows you
to continue paying and extending your subscription without having to
explicitly link each payment to the account.  The wallet will simply
make sure to use a return address that is in a BIP32 branch that was
provided to the service during signup, and the service will
automatically extend your subscription every month based on that info
when it sweeps payments.

Along with everything else that was mentioned by Peter in his original
proposal, I see OP_CHECKLOCKTIMEVERIFY as an enabling feature, not just
a simple improvement.
 
-Alan


On 10/08/2014 06:26 AM, Wladimir wrote:
 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 (0.9.4) could have Gavin's change already.

 I don't think CHECKLOCKTIMEVERIFY will make it into the next major
 release though. Once headers-first and pruning is merged (which is
 expected to be a matter of weeks). I'd like to split off the 0.10
 branch and give it some time to stabilize with a feature freeze, then
 do a release before the end of the year.

 So 0.11, in say 6 months, would be soonest.

 Wladimir

 --
 Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
 Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
 Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
 Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
 http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 a good idea to
get an -alertnotify sooner rather than later for EITHER a hard fork or a
soft-fork. Better to be told you have to upgrade while the block.version is
on its way to being a super-majority than after you are either hard-forked
off the main chain (or soft-forked).

I don't have any opinion on the hard- versus soft- fork debate. I think
either can work.

-- 
--
Gavin Andresen
--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 future rule changes, it helps more.

It would be good if getblocktemplate was updated at the same time to serve
errors if the fork warning is active. I'd hope miners have some way to
automatically handle IBD/getting forked off the chain, but I guess some
(newer) pools might not, and refusing to serve work should be the safest
option that shuts them down.

I don't have any opinion on the hard- versus soft- fork debate. I think
 either can work.


P2SH was a soft fork and the sky did not fall, but miners did lose money
and waste electricity mining blocks on the wrong side of the chain:

https://bitcointalk.org/index.php?topic=75294.0

Presumably they didn't notice for longer because it looked like a run of
unusually bad orphaning luck. It seems safer to have a clean fork, with
alerts telling people during the lockin period before new rule enforcement
starts (and possibly automated termination if there's no upgrade by the
flag day?). Miners who ignore it would still risk losing money, but
merchants who wait for a block at least would not be at risk.

One open question is how can you actually trigger a hard fork? Coinbase
scriptSigs are not executed, so putting some ignored but failing opcode
sequence there wouldn't work. One possibility would be to have a special
invalid tx in the block that marks the start of new rule enforcement. New
nodes would know to ignore it. But this risks corrupting block explorers.
Alternatively the coinbase outpoint structure could have its hash set to 1
instead of 0.
--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 throw in.  To minimize the frequency of hard-forks, the 
time for that is when the change being considered actually requires one.

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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
 bitcoinj should.


Nobody said hard forks shouldn't have an associated block version number
increase - that's a straw man. They should! The difference is only whether
older clients are presented with data they would refuse to accept thus
ensuring they don't accept the new version blocks.

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: it's noisier, and if the user followed the
instructions printed to the console when there is no config file present,
he/she should also get an email or some other kind of more meaningful alert.

Finally, please stop trying to imply that all this is settled and I'm
somehow an idiot for bringing it up. You've done that on the pull request
and now here, it gives me a headache. Instead of making hand-waving
references to stuff on IRC ages ago, explain why it's better to keep
these nodes in some fantasy world where they think they're fully validating
but are actually not.
--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 well as complex 
logic with alternative key groups with differing time constraints.

OP_CHECKLOCKTIMEVERIFY, as conceived, seems too limited, IMHO.


On Thursday, 2 October 2014, at 4:05 pm, Flavien Charlon wrote:
 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 17:55:36 GMT-07:00, Luke Dashjr l...@dashjr.org wrote:
  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 GET-TXIN-BLOCK-(TIME/HEIGHT)-EQUALVERIFY operator.
   scriptPubKey would be:
   GET-TXIN-BLOCKHEIGHT-EQUALVERIFY
   (fails unless top stack item is equal to the txin block height)
   delta height ADD
   (top stack item is now txin height + delta height)
   CHECKLOCKTIMEVERIFY
  
  This sounds do-able, although it doesn't address using timestamps.
 
  For timestamps replace height with time in the above example; the
  minimum block time rule will prevent gaming it.
 
 
   You'd want these sacrifices to unlock years into the future to
  thoroughly
   exceed any reasonable business cycle; that's so far into the future
  that
   miners are almost certain to just mine them and collect the fees.
  
  For many use cases, short maturity periods are just as appropriate IMO.
 
  Very easy to incentivise mining centralisation with short maturities. I
  personally think just destroying coins is better, but it doesn't sit well
  with people so this is the next best thing.
  -BEGIN PGP SIGNATURE-
  Version: APG v1.1.1
 
  iQFQBAEBCAA6BQJULKWsMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
  cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhcg8CACueZNGfWaZR+xyG9/o
  JwDBCnqOtwr6Bnosg3vNcRIDUnmsh+Qkk5dk2JpqYNYw7C3duhlwHshgsGOFkHEV
  f5RHDwkzGLJDLXrBwxxcIDdm3cJL8UVpQzJ7dD7aSnfj7MU/0aru3HaIU2ZfymUb
  63jhul6FGbXH3K6p3bOoNrfIrCCGOv8jOIzeAgxNPydk8MVPgRhlYLAKBJxu8nMr
  1oJGeaKVSGSPSrRdgS8tI4uOs0F4Q49APrLPGxGTERlATmWrr+asHGJTIxsB2IEm
  vrNgVRpkaN4Of9k96qzD9ReKfBfqm0WQKLolcXCVqGpdoHcvXh2AeWdjB/EFTyOq
  SOgO
  =WybM
  -END PGP SIGNATURE-
 
 
 
  --
  Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
  Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
  Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
  Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
 
  http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
  ___
  Bitcoin-development mailing list
  Bitcoin-development@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/bitcoin-development
 

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 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 well as 
 complex logic with alternative key groups with differing time constraints.
 
 OP_CHECKLOCKTIMEVERIFY, as conceived, seems too limited, IMHO.
 
 
 On Thursday, 2 October 2014, at 4:05 pm, Flavien Charlon wrote:
  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 17:55:36 GMT-07:00, Luke Dashjr l...@dashjr.org wrote:
   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 GET-TXIN-BLOCK-(TIME/HEIGHT)-EQUALVERIFY operator.
scriptPubKey would be:
GET-TXIN-BLOCKHEIGHT-EQUALVERIFY
(fails unless top stack item is equal to the txin block height)
delta height ADD
(top stack item is now txin height + delta height)
CHECKLOCKTIMEVERIFY
   
   This sounds do-able, although it doesn't address using timestamps.
  
   For timestamps replace height with time in the above example; the
   minimum block time rule will prevent gaming it.
  
  
You'd want these sacrifices to unlock years into the future to
   thoroughly
exceed any reasonable business cycle; that's so far into the future
   that
miners are almost certain to just mine them and collect the fees.
   
   For many use cases, short maturity periods are just as appropriate IMO.
  
   Very easy to incentivise mining centralisation with short maturities. I
   personally think just destroying coins is better, but it doesn't sit well
   with people so this is the next best thing.
   -BEGIN PGP SIGNATURE-
   Version: APG v1.1.1
  
   iQFQBAEBCAA6BQJULKWsMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
   cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhcg8CACueZNGfWaZR+xyG9/o
   JwDBCnqOtwr6Bnosg3vNcRIDUnmsh+Qkk5dk2JpqYNYw7C3duhlwHshgsGOFkHEV
   f5RHDwkzGLJDLXrBwxxcIDdm3cJL8UVpQzJ7dD7aSnfj7MU/0aru3HaIU2ZfymUb
   63jhul6FGbXH3K6p3bOoNrfIrCCGOv8jOIzeAgxNPydk8MVPgRhlYLAKBJxu8nMr
   1oJGeaKVSGSPSrRdgS8tI4uOs0F4Q49APrLPGxGTERlATmWrr+asHGJTIxsB2IEm
   vrNgVRpkaN4Of9k96qzD9ReKfBfqm0WQKLolcXCVqGpdoHcvXh2AeWdjB/EFTyOq
   SOgO
   =WybM
   -END PGP SIGNATURE-
  
  
  
   --
   Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
   Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
   Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
   Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
  
   http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
   ___
   Bitcoin-development mailing list
   Bitcoin-development@lists.sourceforge.net
   https://lists.sourceforge.net/lists/listinfo/bitcoin-development
  

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 would result in transactions which
once mined could not be restored in a reorg through no fault of the
participants, which makes the coins less fungible and differently safe
to accept. It risks creating weird pressures around immediate block
admission since a one additional block delay could forever censor such
a transaction (E.g. increases the power of single miners to censor or
steal). Avoiding this is a conscious decision in Bitcoin and also part
of the justification for the 100 block maturity of newly generated
coins.

It also would require violating the script/transaction/block layering
more substantially, complicating implementations, and making the
validity of a script no longer a deterministic pure function of the
transaction.

Avoiding these issues is a conscious design in OP_CHECKLOCKTIMEVERIFY.
I would strenuously oppose a proposal which failed in any of these
respects.

 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 well as complex logic with alternative key groups with differing 
 time constraints.

You can already achieve the not spendable after logic with a
cancellation spend that moves the coin in the usual way. (Which
doesn't even require the participant be online, with the help of some
network service to queue unlocked transactions).

 OP_CHECKLOCKTIMEVERIFY, as conceived, seems too limited, IMHO.

It is intentionally so, and yet it covers the intended use cases;
including ones with alternative key groups, they are just not
exclusive.

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 and also output can ONLY be spent until a certain
 time, as well as complex logic with alternative key groups with differing
 time constraints.

This cannot be done in a softfork.

Furthermore, output can ONLY be spent until a certain time contradict's 
Bitcoin's present security assumptions: that assuming a honest sender, the 
transaction will remain valid and simply re-confirm if a reorg kicks it out.

Luke

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 that it'd be good for anything beyond wasting space in the
database. But this is a minor point.

So I guess it's time to start the deployment discussion.

Bitcoin is a consensus system. It works best when everyone is following
exactly the same rules at the same time. A soft fork works against this
principle by allowing nodes to think they're following the majority
ruleset, even if they aren't, effectively downgrading them to something a
bit like SPV security without them realising.

A hard fork has multiple desirable properties. Most importantly, it means a
node can detect it's no longer in the consensus because it'll find its own
chain height has diverged significantly from its peers. Core already has
code that knows how to detect this condition and log errors about it as
well as running the alertnotify script i.e. emailing the admin. Ideally it
would also stop serving work so miners shut down or fail over, but this is
easily added to the CheckForkWarningConditions() function.

In other words, this gives the cleanest failure we can give, such that any
procedures a node operator has put in place to alert them of divergence
will be triggered.  Any code which is waiting for confirmations will wait
forever at this point, thus minimising the risk of loss.

Additionally, forcing old peers to fall behind means SPV clients will pick
the right chain, and not end up downloading transactions or blocks that are
about to be doomed at the next re-org. They can easily choose to ignore
transactions relayed by peers that are too far behind and thus not end up
accepting transactions that are no longer valid according to the majority
(a scenario which can cause monetary loss).

I don't think hard forks should be scary. Mechanisms are in place to warn
people and they can be scheduled with plenty of time in advance. The main
stated justification for a soft fork is backwards compatibility, but in a
system like Bitcoin you really don't want to be running behind the
consensus and it's hard to imagine any node operator deliberately choosing
to stay on the wrong side of the fork. It's not like other software where
people can choose to skip an upgrade and things still work just like before.
--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 in for just that... less disruptive
upgrades that don't require 100%.



On Fri, Oct 3, 2014 at 4:58 PM, Mike Hearn m...@plan99.net wrote:
 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 that
 it'd be good for anything beyond wasting space in the database. But this is
 a minor point.

 So I guess it's time to start the deployment discussion.

 Bitcoin is a consensus system. It works best when everyone is following
 exactly the same rules at the same time. A soft fork works against this
 principle by allowing nodes to think they're following the majority ruleset,
 even if they aren't, effectively downgrading them to something a bit like
 SPV security without them realising.

 A hard fork has multiple desirable properties. Most importantly, it means a
 node can detect it's no longer in the consensus because it'll find its own
 chain height has diverged significantly from its peers. Core already has
 code that knows how to detect this condition and log errors about it as well
 as running the alertnotify script i.e. emailing the admin. Ideally it would
 also stop serving work so miners shut down or fail over, but this is easily
 added to the CheckForkWarningConditions() function.

 In other words, this gives the cleanest failure we can give, such that any
 procedures a node operator has put in place to alert them of divergence will
 be triggered.  Any code which is waiting for confirmations will wait forever
 at this point, thus minimising the risk of loss.

 Additionally, forcing old peers to fall behind means SPV clients will pick
 the right chain, and not end up downloading transactions or blocks that are
 about to be doomed at the next re-org. They can easily choose to ignore
 transactions relayed by peers that are too far behind and thus not end up
 accepting transactions that are no longer valid according to the majority (a
 scenario which can cause monetary loss).

 I don't think hard forks should be scary. Mechanisms are in place to warn
 people and they can be scheduled with plenty of time in advance. The main
 stated justification for a soft fork is backwards compatibility, but in a
 system like Bitcoin you really don't want to be running behind the consensus
 and it's hard to imagine any node operator deliberately choosing to stay on
 the wrong side of the fork. It's not like other software where people can
 choose to skip an upgrade and things still work just like before.

 --
 Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
 Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
 Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
 Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
 http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development




-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 inattentive,
 now-inconsequential miners.
 
 There is some headroom built in for just that... less disruptive
 upgrades that don't require 100%.

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
bitcoinj should.

Someone with more time should write all this up for the bitcoin.org
developer docs BTW... There's extensive discussions on #bitcoin-dev and
others about all of this.

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


signature.asc
Description: Digital signature
--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 17:55:36 GMT-07:00, Luke Dashjr l...@dashjr.org wrote:
 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 GET-TXIN-BLOCK-(TIME/HEIGHT)-EQUALVERIFY operator.
  scriptPubKey would be:
  GET-TXIN-BLOCKHEIGHT-EQUALVERIFY
  (fails unless top stack item is equal to the txin block height)
  delta height ADD
  (top stack item is now txin height + delta height)
  CHECKLOCKTIMEVERIFY
 
 This sounds do-able, although it doesn't address using timestamps.

 For timestamps replace height with time in the above example; the
 minimum block time rule will prevent gaming it.


  You'd want these sacrifices to unlock years into the future to
 thoroughly
  exceed any reasonable business cycle; that's so far into the future
 that
  miners are almost certain to just mine them and collect the fees.
 
 For many use cases, short maturity periods are just as appropriate IMO.

 Very easy to incentivise mining centralisation with short maturities. I
 personally think just destroying coins is better, but it doesn't sit well
 with people so this is the next best thing.
 -BEGIN PGP SIGNATURE-
 Version: APG v1.1.1

 iQFQBAEBCAA6BQJULKWsMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
 cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhcg8CACueZNGfWaZR+xyG9/o
 JwDBCnqOtwr6Bnosg3vNcRIDUnmsh+Qkk5dk2JpqYNYw7C3duhlwHshgsGOFkHEV
 f5RHDwkzGLJDLXrBwxxcIDdm3cJL8UVpQzJ7dD7aSnfj7MU/0aru3HaIU2ZfymUb
 63jhul6FGbXH3K6p3bOoNrfIrCCGOv8jOIzeAgxNPydk8MVPgRhlYLAKBJxu8nMr
 1oJGeaKVSGSPSrRdgS8tI4uOs0F4Q49APrLPGxGTERlATmWrr+asHGJTIxsB2IEm
 vrNgVRpkaN4Of9k96qzD9ReKfBfqm0WQKLolcXCVqGpdoHcvXh2AeWdjB/EFTyOq
 SOgO
 =WybM
 -END PGP SIGNATURE-



 --
 Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
 Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
 Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
 Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer

 http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[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 unittests for the
opcode semantics can be found at:

https://github.com/petertodd/bitcoin/compare/checklocktimeverify

pre
  BIP:
  Title: OP_CHECKLOCKTIMEVERIFY
  Author: Peter Todd p...@petertodd.org
  Status: Draft
  Type: Standards Track
  Created: 2014-10-01
/pre

==Abstract==

This BIP describes a new opcode (OP_CHECKLOCKTIMEVERIFY) for the Bitcoin
scripting system that allows a transaction output to be made unspendable until
some point in the future.


==Summary==

CHECKLOCKTIMEVERIFY re-defines the existing NOP2 opcode. When executed it
compares the top item on the stack to the nLockTime field of the transaction
containing the scriptSig. If that top stack item is greater than the transation
nLockTime the script fails immediately, otherwise script evaluation continues
as though a NOP was executed.

The nLockTime field in a transaction prevents the transaction from being mined
until either a certain block height, or block time, has been reached. By
comparing the argument to CHECKLOCKTIMEVERIFY against the nLockTime field, we
indirectly verify that the desired block height or block time has been reached;
until that block height or block time has been reached the transaction output
remains unspendable.


==Motivation==

The nLockTime field in transactions makes it possible to prove that a
transaction output can be spent in the future: a valid signature for a
transaction with the desired nLockTime can be constructed, proving that it is
possible to spend the output with that signature when the nLockTime is reached.
An example where this technique is used is in micro-payment channels, where the
nLockTime field proves that should the receiver vanish the sender is guaranteed
to get all their escrowed funds back when the nLockTime is reached.

However the nLockTime field is insufficient if you wish to prove that
transaction output ''can-not'' be spent until some time in the future, as there
is no way to prove that the secret keys corresponding to the pubkeys controling
the funds have not been used to create a valid signature.


===Escrow===

If Alice and Bob jointly operate a business they may want to
ensure that all funds are kept in 2-of-2 multisig transaction outputs that
require the co-operation of both parties to spend. However, they recognise that
in exceptional circumstances such as either party getting hit by a bus they
need a backup plan to retrieve the funds. So they appoint their lawyer, Lenny,
to act as a third-party.

With a standard 2-of-3 CHECKMULTISIG at any time Lenny could conspire with
either Alice or Bob to steal the funds illegitimately. Equally Lenny may prefer
not to have immediate access to the funds to discourage bad actors from
attempting to get the secret keys from him by force.

However with CHECKLOCKTIMEVERIFY the funds can be stored in scriptPubKeys of
the form:

IF
now + 3 months CHECKLOCKTIMEVERIFY DROP
Lenny's pubkey CHECKSIGVERIFY
1
ELSE
2
ENDIF
Alice's pubkey Bob's pubkey 2 CHECKMULTISIG

At any time the funds can be spent with the following scriptSig:

Alice's signature Bob's signature 0

After 3 months have passed Lenny and one of either Alice or Bob can spend the
funds with the following scriptSig:

Alice/Bob's signature Lenny's signature 1


===Non-interactive time-locked refunds===

There exist a number of protocols where a transaction output is created that
the co-operation of both parties to spend the output. To ensure the failure of
one party does not result in the funds becoming lost refund transactions are
setup in advance using nLockTime. These refund transactions need to be created
interactively, and additionaly, are currently vulnerable to transaction
mutability. CHECKLOCKTIMEVERIFY can be used in these protocols, replacing the
interactive setup with a non-interactive setup, and additionally, making
transaction mutability a non-issue.


Two-factor wallets

Services like GreenAddress store Bitcoins with 2-of-2 multisig scriptPubKey's
such that one keypair is controlled by the user, and the other keypair is
controlled by the service. To spend funds the user uses locally installed
wallet software that generates one of the required signatures, and then uses a
2nd-factor authentication method to authorize the service to create the second
SIGHASH_NONE signature that is locked until some time in the future and sends
the user that signature for storage. If the user needs to spend their funds and
the service is not available, they wait until the nLockTime expires.

The problem is there exist numerous occasions the user will not have a valid
signature for some or all of their transaction outputs. With

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 about whether it should
roll out as a soft fork, wait for a hard fork, be combined with some other
things that it would be nice to add or change, etc.

-- 
--
Gavin Andresen
--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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, but that
peer is one block behind in the blockchain, the transaction will be
rejected by the peer and the source will be banned.

Another option will be not to ban peers sending transactions failing to
verify OP_CHECKLOCKTIMEVERIFY , but I don't like this.

Still another option would be that the sender checks periodically the
height of it's peers (using the version command) in order to be sure to
send the transaction having OP_CHECKLOCKTIMEVERIFY only to the peers
that are up to date with the blockchain.

Regards,
 Sergio.




--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 another minor release or two.


On 1 October 2014 11:29:48 GMT-04:00, Sergio Lerner sergioler...@certimix.com 
wrote:
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, but that
peer is one block behind in the blockchain, the transaction will be
rejected by the peer and the source will be banned.

Another option will be not to ban peers sending transactions failing to
verify OP_CHECKLOCKTIMEVERIFY , but I don't like this.

Still another option would be that the sender checks periodically the
height of it's peers (using the version command) in order to be sure to
send the transaction having OP_CHECKLOCKTIMEVERIFY only to the peers
that are up to date with the blockchain.

Regards,
 Sergio.




--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS
Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQFQBAEBCAA6BQJULDR7MxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhS8ACADKQYHqOvmKJBYv+ZZM
Vs6358sMEtHGIEoTEjPio/vGbM0TkCGvRAnvzXDYz20WQcQsWZ4jflP1BihdbszE
NrQ+4JYm11Sw6vK5RpxeI4rJSb/hMUJooR0WQn8TOSZowtVxhINUnBku+N21Dhuf
IBCzji5bW2wjeN50psWOjJkBo1gZP761tjfmpI9kdNFe6RYIceAIWIIhccKX4PhA
FucuPawjB8+Ajd707UGHew82VHbXis+6Oxzob7hVJRH/wNKpkR6LXRxh2dwVaRAw
/Eytbt8LZRcRZGNXvMZ4GKG0xP79cBQI30QhrgM88gGyioMxrWcP2hVhtADOVl40
E4yh
=C9fu
-END PGP SIGNATURE-


--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 the target 
height/time directly, is that miners may choose not to mine the first 
transaction until they can also take the burn to fee. So, one may prefer to 
say cannot be spent until 100 blocks after the first transaction is mined, 
in effect reproducing the generation maturity rule.

I propose any stack item under 0x4 be incremented by the height at which 
the scriptPubKey was mined for comparison. Maybe there is a use case for doing 
something similar for time too?

Luke

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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
 transaction until they can also take the burn to fee.


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).


-- 
--
Gavin Andresen
--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 proof-of-burn scheme, wouldn't using P2SH
defeat the purpose of it?

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 transaction is final and
  relayed/broadcast).

 If you're doing some kind of proof-of-burn scheme, wouldn't using P2SH
 defeat the purpose of it?


No, the burner would supply the funding transaction plus the redeeming
script as the proof-of-burn to whoever needed the proof.

Only after at least one confirmation, if there was some risk that revealing
the redeeming script would make miners refuse to mine that first
transaction because they want to get it plus the CHECKTIMELOCKVERIFY burn
transaction.

-- 
--
Gavin Andresen
--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 GET-TXIN-BLOCK-(TIME/HEIGHT)-EQUALVERIFY operator. 
scriptPubKey would be:

GET-TXIN-BLOCKHEIGHT-EQUALVERIFY

(fails unless top stack item is equal to the txin block height)

delta height ADD

(top stack item is now txin height + delta height)

CHECKLOCKTIMEVERIFY

 A limitation of encoding the
target
height/time directly, is that miners may choose not to mine the first
transaction until they can also take the burn to fee. So, one may
prefer to
say cannot be spent until 100 blocks after the first transaction is
mined,
in effect reproducing the generation maturity rule.

You'd want these sacrifices to unlock years into the future to thoroughly 
exceed any reasonable business cycle; that's so far into the future that miners 
are almost certain to just mine them and collect the fees.
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQFQBAEBCAA6BQJULJa7MxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhYlFB/4r2Hv82RK85BDe+hAT
ZQJtzXv1JRCa+o7Y344unMJ8y7rSDJRFSH+X+4VeCln833XKb8FNgj2loniQAq5H
FIH04gPf7yuXvDrKI6HwCj9Q3KLPv4UZM1+LjijczOM/y4e/C82squpTpgFaton+
6VXU/WyaCDYDS4he975E14YhBBVhoadZZMOW3Moxgpnde2RwAYZdkcdhqvh/3dJC
/9VOEUBu0ENyraL5HHGdZyjSJT2MsY4CBTCCd54RxBBMoMZqFRvIi4Xrt2vE1T+Y
R2DtKs7upjydnfg9KPm484upvO2U3lcnPBW9rqOVQyV2q81TcloRtUIU4QQ9GCAk
ayj2
=p0BG
-END PGP SIGNATURE-


--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 proof-of-burn to whoever needed the proof.

No, the redeemScript has to be provably published to miners for the sacrifice 
to be valid; if not you can exploit the scheme by hiding the redeemScript and 
having a big miner mine it at lower-than-face-value cost when it unlocks.

Only after at least one confirmation, if there was some risk that
revealing
the redeeming script would make miners refuse to mine that first
transaction because they want to get it plus the CHECK TIME BLOCK VERIFY
burn
transaction.

Yes, you could do that in a followup tx containing the redeemScript in an 
OP_RETURN output to prove publication. That said as I said to Luke-Jr, the 
sacrifices need to unlock pretty far into the future, so I don't see miners 
bothering to do this.





-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQFQBAEBCAA6BQJULJiDMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhTwKCACD+GWzID7Qhn2no1p9
KYNiYlQVNt+DPZY0QB7MujL8riAmyJBliF9zptfjEdvglShoIzonJien/DOCjp9S
Lw2wMvPhtZGgSttJEvlr3wclty6TfWygd4Y+v/MR8TnYC99su7HhiQ1pkqohkklv
RxeF9jXhcJMERzN6wPUyeowfziBAfbWw+M5CwiXRlzLLBWO37eoDTXzUD0Np5Nia
nFxQ7sAsSbLijVpvigh9uIi3/1347VqwMc+0ZsZoZ2AnMICA8Q+XKNHv7DKpChxw
Xa+P532Di34uu8dlG/Z/UwYdENvb15P1yUZ7CEDfqNqrZp0RM7x+XKMA7QPwhuz3
YSBp
=mvKP
-END PGP SIGNATURE-


--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 GET-TXIN-BLOCK-(TIME/HEIGHT)-EQUALVERIFY operator.
 scriptPubKey would be:
 GET-TXIN-BLOCKHEIGHT-EQUALVERIFY
 (fails unless top stack item is equal to the txin block height)
 delta height ADD
 (top stack item is now txin height + delta height)
 CHECKLOCKTIMEVERIFY

This sounds do-able, although it doesn't address using timestamps.

  A limitation of encoding the target
 height/time directly, is that miners may choose not to mine the first
 transaction until they can also take the burn to fee. So, one may
 prefer to
 say cannot be spent until 100 blocks after the first transaction is
 mined,
 in effect reproducing the generation maturity rule.
 
 You'd want these sacrifices to unlock years into the future to thoroughly
 exceed any reasonable business cycle; that's so far into the future that
 miners are almost certain to just mine them and collect the fees.

For many use cases, short maturity periods are just as appropriate IMO.

Luke

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 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 about whether it should
roll out as a soft fork, wait for a hard fork, be combined with some
other
things that it would be nice to add or change, etc.

Agreed. People should keep in mind that leaving the deployment details as TBD 
was quite deliberate. There is some code in the repo to implement a softfork, 
but it's only meant to be illustrative.
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQFQBAEBCAA6BQJULKT9MxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhevAB/0eTWleef5GehrH03tZ
NrOdtJ881NhXJpB3p81jPyT9z4gv9u3M5bkjMOvClQaf8PX551ICgKbWDQTNf9oS
TF/blkqWRWX28VLkNsMUQNN/dd7rdqDMpnwcN8worgHToRMa4drFBU/MXapedMLQ
Sb2ETXGYPm4b/HqgFf9j/EGt8jhmnk4HiSwZ6wdhdYLbbZ6NhplSR8tTs+GouAWp
PHntN6DQI8oFDaIKkMbs2dDlpXSGG9hxr6m46LBwp/CHBY9aKkwLyaJXkMVovP3J
HrSYTzlCmjrDNbLJwIze+fyO2UDkgZUzjVENfMvixcQNdz0pVoCzJ2BK8b4fAc7Y
maRA
=Mz3E
-END PGP SIGNATURE-


--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development