Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
On Thu, Oct 9, 2014 at 6:33 AM, Peter Todd 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=154622311&iu=/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
On Thu, Oct 09, 2014 at 06:28:19AM +, Gregory Maxwell wrote: > On Thu, Oct 9, 2014 at 6:14 AM, Adam Back 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=154622311&iu=/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
On Thu, Oct 9, 2014 at 6:14 AM, Adam Back 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=154622311&iu=/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
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 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 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=154622311&iu=/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=154622311&iu=/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=154622311&iu=/4140/ostg.clktrk
Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
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 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=154622311&iu=/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=154622311&iu=/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
On Tue, Oct 7, 2014 at 6:08 PM, Mike Hearn 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=154622311&iu=/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
> > 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=154622311&iu=/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
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=154622311&iu=/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
> > 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=154622311&iu=/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
On Sat, Oct 4, 2014 at 8:58 AM, Mike Hearn 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=154622311&iu=/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
> > 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=154622311&iu=/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
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=154622311&iu=/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
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 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=154622311&iu=/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=154622311&iu=/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
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=154622311&iu=/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
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=154622311&iu=/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
On Fri, Oct 3, 2014 at 7: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? 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=154622311&iu=/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
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 wrote: > > > > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA256 > > > > > > > > > > > > On 1 October 2014 17:55:36 GMT-07:00, Luke Dashjr 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 > > > >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) > > > >> 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=154622311&iu=/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=154622311&iu=/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
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 wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > > > > > > > On 1 October 2014 17:55:36 GMT-07:00, Luke Dashjr 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 > > >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) > > >> 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=154622311&iu=/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=154622311&iu=/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
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 wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > > > On 1 October 2014 17:55:36 GMT-07:00, Luke Dashjr 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 > >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) > >> 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=154622311&iu=/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=154622311&iu=/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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 1 October 2014 17:55:36 GMT-07:00, Luke Dashjr 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 >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) >> 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=154622311&iu=/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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 1 October 2014 08:01:28 GMT-07:00, Gavin Andresen 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=154622311&iu=/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
On Thursday, October 02, 2014 12:05:15 AM Peter Todd wrote: > On 1 October 2014 11:23:55 GMT-07:00, Luke Dashjr 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) > 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=154622311&iu=/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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 1 October 2014 14:34:33 GMT-07:00, Gavin Andresen wrote: >On Wed, Oct 1, 2014 at 5:04 PM, Alan Reiner >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=154622311&iu=/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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 1 October 2014 11:23:55 GMT-07:00, Luke Dashjr 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) 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=154622311&iu=/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
On Wed, Oct 1, 2014 at 5:04 PM, Alan Reiner 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=154622311&iu=/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
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=154622311&iu=/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
On Wed, Oct 1, 2014 at 2:23 PM, Luke Dashjr 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=154622311&iu=/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
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=154622311&iu=/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
-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 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=154622311&iu=/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=154622311&iu=/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
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=154622311&iu=/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
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=154622311&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
