[Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
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
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
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
-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
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
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
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
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
-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
-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
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
-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
[Bitcoin-development] Decreasing block propagation time
https://bitcointalk.org/index.php?topic=145066.0 The idea proposed in the above article seemed like an excellent idea. What is holding this up from being implemented? Does someone need to code it, or write a BIP first? -- 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] Decreasing block propagation time
It already is https://bitcointalk.org/index.php?topic=766190.0;all. Well, ok, a variation on the idea is. Matt On 10/02/14 04:39, Rebroad (sourceforge) wrote: https://bitcointalk.org/index.php?topic=145066.0 The idea proposed in the above article seemed like an excellent idea. What is holding this up from being implemented? Does someone need to code it, or write a BIP first? -- 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
