Re: [Bitcoin-development] BIP 65 and OP_CHECKLOCKTIMEVERIFY inquiry...
This breaks existing invariants and would make the coins potentially less fungible because they wouldn't be reorg safe. I'm not sure coins are ever reorg safe. All it takes is a double spend in the history of your coins for them to become invalid after a reorg. Because of that, there are already less fungible coins. This is why we recommend 6 confirmations for important payments. On Fri, Nov 28, 2014 at 3:18 AM, Peter Todd p...@petertodd.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 27 November 2014 18:46:23 GMT-05:00, Gregory Maxwell gmaxw...@gmail.com wrote: snip 100% accurate commentary from gmaxwell The things you're suggesting were all carefully designed out of the proposal, perhaps the BIP text needs some more clarification to make this more clear. It does; it is still a draft. That said I think writing up some actual working examples, in code, of CHECKLOCKTIMEVERIFY using protocols is a bigger priority. Micropayment channels comes to mind, as well as a greenaddress-style wallet. When I get a chance I'm going to rebase the initial implementation and add to it a command-line-flag to verify CHECKLOCKTIMEVERIFY as an IsStandard() rule for testing purposes. -BEGIN PGP SIGNATURE- Version: APG v1.1.1 iQFQBAEBCAA6BQJUd+luMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8 cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhWmcB/0UK030Q6TSpi95x0Gh hGYaSAInUWpbZzZtP+1AFrGDGRdGo0glFFf8xggI+U5kuc0woPYrn/VEGcprPhvs KQFZrirXVr7Q09TVlHiPDen5v3Y7xwL5kQDUrBPP71Pe3R2o6IbfdwxsZ8+yYso8 hY6WQmImQpKJd4gEd76w1QrF8Btl1Jz/PGh4EE3GSPGlflvBwA6igSiRoD/czb1x 63y4AsPEil2hrmIjTZHqwnl40BqnmZ8qpNLWeIEjE++pbkxLTjvUcPy03/wtTWZA 5dCGeY5WavgZsPazhSdaTtM5/7wPSQQ0PDXNHdHgmewkvbyBpy78orV/3bEG+xFz 2SWi =4OmI -END PGP SIGNATURE- -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 65 and OP_CHECKLOCKTIMEVERIFY inquiry...
On Fri, Nov 28, 2014 at 11:45 AM, Flavien Charlon flavien.char...@coinprism.com wrote: This breaks existing invariants and would make the coins potentially less fungible because they wouldn't be reorg safe. I'm not sure coins are ever reorg safe. All it takes is a double spend in the history of your coins for them to become invalid after a reorg. Because of that, there are already less fungible coins. This is why we recommend 6 confirmations for important payments. I used the word 'less' intentionally. A double spend requires an active action. Roughly 1% of blocks are lost to reorganizations by chance, longer otherwise harmless reorgs as we've had in the past could forever destroy large chunks of coins if descendants had the unwelcome properties of having additional constraints on them. Past instances where the network had a dozen block reorganization which were harmless and simply confirmed the same transactions likely would have caused substantial losses if it reorganizations precluded the recovery of many transactions which were valid when placed earlier in the chain. Additionally your '6 confirmations' is a uniform rule. The recommendation is just a count, it's tidy. It's not a traverse the recent history of each coin you receive to determine if its script conditions make it unusually fragile and subject to irrecoverable loss, which is the space you can get into with layering violations and transaction validity depending on arbitrary block data. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 65 and OP_CHECKLOCKTIMEVERIFY inquiry...
On Thu, Nov 27, 2014 at 10:56 PM, Richard Moore m...@ricmoo.com wrote:
Heya,
I was wondering about BIP 65 regarding the OP_CHECKLOCKTIMEVERIFY, and
thought it might make more sense to instead have a OP_CHECKLOCKTIME which
would simply push an OP_TRUE or OP_FALSE onto the stack?
Updating the stack is not soft-fork compatible and any use would
immediately fork the network.
A invertible test is also not soft-fork compatible e.g. someone writes
a script that does {new thing) OP_NOT, in other words the test
must fail, then the network would fork because older nodes would see
it as passing (which was the required criteria for non-forking the
network in the non-inverted caes).
You can happily get non-nullable true/false behaviour without these
risks by having the VERIFY test inside a branch and having the signer
provide its falseness as an input to the branch. This is explained in
the BIP.
E.g. OP_IF limit OP_CHECKLOCKTIMEVERIFY OP_ELSE what you'd do if it
doesn't pass OP_END
A useful an powerful mental model is that SCRIPT is not running a
program, but instead the signer is proving to the network that they
know inputs that make the program return true.
(In practise we verify this by actually doing some execution, though
this isn't technically necessary it's the simplest thing to implement
although it is inefficient... but even in this simple model keeping in
mind that we're VERIFYING not executing in the network opens our eyes
to transformations like the IF bracketing of a VERIFY opcode.)
That way someone could include multiple OP_CHECKLOCKTIME conditions in a
single script.
They can do this, with the above approach.
As a second question, would it possibly make more sense to, rather than
relying on the nLockTime in a transaction, allow an opcode that would use
similar semantics, but against an item in the stack? Then you could
essentially include multiple nLockTimes in a single script and make
arbitrarily interesting (complicated?) scripts based on block height and/or
block timestamp.
The OP_CHECKLOCKTIMEVERIFY can still be easily implemented, by using
nLockTimeThatWouldBeInTx OP_CHECKLOCKTIME OP_VERIFY
Then the scripts validity isn't a pure function of the the
transaction, and once valid transactions could become invalid while in
the mempool. This breaks existing invariants and would make the coins
potentially less fungible because they wouldn't be reorg safe. That
locktime validity is basically monotonic is a useful intentional
property. :)
The things you're suggesting were all carefully designed out of the
proposal, perhaps the BIP text needs some more clarification to make
this more clear.
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 65 and OP_CHECKLOCKTIMEVERIFY inquiry...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 27 November 2014 18:46:23 GMT-05:00, Gregory Maxwell gmaxw...@gmail.com wrote: snip 100% accurate commentary from gmaxwell The things you're suggesting were all carefully designed out of the proposal, perhaps the BIP text needs some more clarification to make this more clear. It does; it is still a draft. That said I think writing up some actual working examples, in code, of CHECKLOCKTIMEVERIFY using protocols is a bigger priority. Micropayment channels comes to mind, as well as a greenaddress-style wallet. When I get a chance I'm going to rebase the initial implementation and add to it a command-line-flag to verify CHECKLOCKTIMEVERIFY as an IsStandard() rule for testing purposes. -BEGIN PGP SIGNATURE- Version: APG v1.1.1 iQFQBAEBCAA6BQJUd+luMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8 cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhWmcB/0UK030Q6TSpi95x0Gh hGYaSAInUWpbZzZtP+1AFrGDGRdGo0glFFf8xggI+U5kuc0woPYrn/VEGcprPhvs KQFZrirXVr7Q09TVlHiPDen5v3Y7xwL5kQDUrBPP71Pe3R2o6IbfdwxsZ8+yYso8 hY6WQmImQpKJd4gEd76w1QrF8Btl1Jz/PGh4EE3GSPGlflvBwA6igSiRoD/czb1x 63y4AsPEil2hrmIjTZHqwnl40BqnmZ8qpNLWeIEjE++pbkxLTjvUcPy03/wtTWZA 5dCGeY5WavgZsPazhSdaTtM5/7wPSQQ0PDXNHdHgmewkvbyBpy78orV/3bEG+xFz 2SWi =4OmI -END PGP SIGNATURE- -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
