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] bitcoind as a library
On Thu, Nov 27, 2014 at 6:54 PM, Wladimir laa...@gmail.com wrote: On Thu, Nov 27, 2014 at 5:27 PM, Mem Wallet memwallet.i...@gmail.com wrote: Is there an intention that the various internal libraries could/should be strengthened and heirachicalized such that they would be suitable for 3rd party development of bitcoin related services and tools, or is that not a goal, and some other project would have to fill such a role ? The plan is to provide the consensus functionality as a library, the essential parts that make bitcoin bitcoin. 0.10 will have a basic transaction/script verifier available. In the version after that, I expect this will be extended to further utxo set management, but no API has been worked out for that yet. There are also plans to add a library for transaction signing. However there is no goal to expose *everything* as a library. Certainly not wallet- or user interface related functionality. Specialized utility libraries would fill this purpose better. See for example https://github.com/bitcoin/libbase58 for base58 processing. Sorry for the off-topic but while reading this I like to ask you for picocoin, see: https://github.com/jgarzik/picocoin For a research project I'm looking for a C library to operate some block chain analysis (parsing raw blocks and transactions). Has anyone of you experience with picocoin for that? Are there any relevant limitations? - oliver -- 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] bitcoind as a library
On Fri, Nov 28, 2014 at 5:22 PM, Oliver Egginger bitc...@olivere.de wrote: Sorry for the off-topic but while reading this I like to ask you for picocoin, see: https://github.com/jgarzik/picocoin For a research project I'm looking for a C library to operate some block chain analysis (parsing raw blocks and transactions). This might be useful for you https://github.com/MatthewLM/cbitcoin -- 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
