[Bitcoin-development] bitcoinj 0.12
I’m pleased to announce version 0.12 of bitcoinj, one of the worlds most popular Bitcoin libraries. It is used by at least four Android wallets, three desktop wallets, blockchain.info, Circle, biteasy, CryptoCorp, Lighthouse, BlueMatt’s relay network, bitpos, countless alt coin wallets, for academic research projects and much more. This release represents 8 months of work. The biggest new feature is HD wallets. Other notable enhancements include a bundled Tor client that can be activated with one line of code, support for multisig wallets, much faster and deterministic ECDSA, many API improvements and big upgrades to the included GUI wallet which can be seen in a new screencasted tutorial. The commit hash of bitcoinj 0.12 is 83a9a71f3fff3f223d0737ad758b519a39dbbd62. New in this release Privacy enhancements: Wallets are now hierarchical and deterministic (HD) by default, using the BIP32 specification. Support for mnemonic codes (BIP 39) is also included. Change and receive addresses are no longer being reused. Old wallets are upgraded in place using the private key of the oldest non-rotating key as the seed bytes, so old backups remain valid. Thanks to devrandom, we have an integrated Tor mode using the Orchid library. The user does not have to install the Tor client as it’s all pure Java. WalletAppKit users can enable usage of Tor with a single line of code. This support should be considered experimental for now. Thanks to Kosta Korenkov, we have an experimental multisig wallets implementation. Multisig (also “married”) wallets are HD wallets that are connected to a third party risk analysis service or device. When married, the wallet tracks multiple BIP32 key trees, keeps them in sync and starts vending P2SH addresses. As part of this work, transaction signing is now pluggable. TransactionSigner implementations can be added to the wallet and will be serialized into and out of the users saved wallet file. Signers are given a transaction to sign in sequence. This is intended for risk analysis providers to provide a class that talks to their server to get a signature of the right form, so that all bitcoinj based wallets can be easily upgraded to support the new provider. Reject messages are now deserialized and logged, though not yet exposed in the API. Upgraded to Guava 16 and Bouncy Castle 1.51. Thanks to Peter Dettman and the rest of the Bouncy Castle team, bitcoinj now uses deterministic ECDSA for signing and we’re now using an accelerated secp256k1 implementation that exploits the special properties of this curve, for dramatically faster calculations. Payment protocol code improvements: Some X.509 utility code was refactored out of PaymentSession for general usage. StartCom was added to the default trust store which was promoted to override the system trust store on non-Android platforms. A command line tool to dump requests to stdout was added. Thanks to Andreas Schildbach: We are now BIP62 (canonical push encodings) compliant. A new Coin class replaces usage of BigInteger for marking values that are quantities of bitcoin. Formatting has moved into the new MonetaryFormat class. The wallet now saves the fee paid on transactions we calculated ourselves. This is useful for putting it into a wallet user interface. Transactions can have user memos and exchange rates attached, that will be saved by the wallet. Support for decrypting BIP 38 protected private keys has been added. Checkpoints can now be stored textually as well as in the old binary format. There is also a new BtcFormat API that provides an alternative to MonetaryFormat that plugs in to the java.text framework. Added new DNS seed from Addy Yeow. Wallets can now have string-byte[] mappings attached to them, for lighter weight extensions. Thanks to Richard Green, there is now a Python version of the ForwardingService program from the getting started tutorial. This shows how to use bitcoinj from Python using the Jython interpreter. bitcoinj now probes localhost for a Bitcoin node and automatically uses that instead of the P2P network, when present. This means any bitcoinj based app can be easily upgraded from SPV to full security just by running Core at the same time: no setup needed. Thanks to Michael Bumann, there are now more example apps showing how to use parts of the API. WalletTemplate/WalletAppKit improvements. WalletTemplate is a demo app that shows how to create a cross-platform GUI wallet with a modern style and 60fps animations. WalletAppKit is a very high level API for creating apps that have a Bitcoin wallet: Now supports mnemonic code and restore from seed words. A date picker is provided to cut down on the amount of chain that needs to be rescanned. Support for encrypting wallets. Password is requested when needed. The difficulty of the scrypt function is selected to always take a fixed number of seconds even if hardware gets more powerful. Some new animation and utility code
Re: [Bitcoin-development] bitcoinj 0.12
On Fri, Oct 3, 2014 at 2:49 PM, Mike Hearn m...@plan99.net wrote: I’m pleased to announce version 0.12 of bitcoinj, one of the worlds most popular Bitcoin libraries. It is used by at least four Android wallets, three desktop wallets, blockchain.info, Circle, biteasy, CryptoCorp, Lighthouse, BlueMatt’s relay network, bitpos, countless alt coin wallets, for academic research projects and much more. Congrats on the release! Wladimir -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] bitcoinj 0.12
On 10/03/2014 02:49 PM, Mike Hearn wrote: I’m pleased to announce version 0.12 of bitcoinj This release represents 8 months of work. The biggest new feature is HD wallets. Congratulations on this release and I am quite happy that bitcoinj now fully supports BIP32 and BIP39! Does it also support various HD wallet structures such as BIP44 for example? -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk -- 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
Is there a reason why we can't have the new opcode simply replace the top stack item with the block height of the txout being redeemed? Then arbitrary logic could be implemented, including output cannot be spent until a certain time and also output can ONLY be spent until a certain time, as well as complex logic with alternative key groups with differing time constraints. OP_CHECKLOCKTIMEVERIFY, as conceived, seems too limited, IMHO. On Thursday, 2 October 2014, at 4:05 pm, Flavien Charlon wrote: Very good, I like the proposal. A question I have: can it be used to do the opposite, i.e. build a script that can only be spent up until block X? On Thu, Oct 2, 2014 at 2:09 AM, Peter Todd p...@petertodd.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 1 October 2014 17:55:36 GMT-07:00, Luke Dashjr l...@dashjr.org wrote: On Thursday, October 02, 2014 12:05:15 AM Peter Todd wrote: On 1 October 2014 11:23:55 GMT-07:00, Luke Dashjr l...@dashjr.org wrote: Thoughts on some way to have the stack item be incremented by the height at which the scriptPubKey was in a block? Better to create a GET-TXIN-BLOCK-(TIME/HEIGHT)-EQUALVERIFY operator. scriptPubKey would be: GET-TXIN-BLOCKHEIGHT-EQUALVERIFY (fails unless top stack item is equal to the txin block height) delta height ADD (top stack item is now txin height + delta height) CHECKLOCKTIMEVERIFY This sounds do-able, although it doesn't address using timestamps. For timestamps replace height with time in the above example; the minimum block time rule will prevent gaming it. You'd want these sacrifices to unlock years into the future to thoroughly exceed any reasonable business cycle; that's so far into the future that miners are almost certain to just mine them and collect the fees. For many use cases, short maturity periods are just as appropriate IMO. Very easy to incentivise mining centralisation with short maturities. I personally think just destroying coins is better, but it doesn't sit well with people so this is the next best thing. -BEGIN PGP SIGNATURE- Version: APG v1.1.1 iQFQBAEBCAA6BQJULKWsMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8 cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhcg8CACueZNGfWaZR+xyG9/o JwDBCnqOtwr6Bnosg3vNcRIDUnmsh+Qkk5dk2JpqYNYw7C3duhlwHshgsGOFkHEV f5RHDwkzGLJDLXrBwxxcIDdm3cJL8UVpQzJ7dD7aSnfj7MU/0aru3HaIU2ZfymUb 63jhul6FGbXH3K6p3bOoNrfIrCCGOv8jOIzeAgxNPydk8MVPgRhlYLAKBJxu8nMr 1oJGeaKVSGSPSrRdgS8tI4uOs0F4Q49APrLPGxGTERlATmWrr+asHGJTIxsB2IEm vrNgVRpkaN4Of9k96qzD9ReKfBfqm0WQKLolcXCVqGpdoHcvXh2AeWdjB/EFTyOq SOgO =WybM -END PGP SIGNATURE- -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
Oops, sorry. I meant: replace the top stack item with the block height of the txin doing the redeeming. (So the script can calculate the current time to some reference time embedded in the script.) On Friday, 3 October 2014, at 10:28 am, Matt Whitlock wrote: Is there a reason why we can't have the new opcode simply replace the top stack item with the block height of the txout being redeemed? Then arbitrary logic could be implemented, including output cannot be spent until a certain time and also output can ONLY be spent until a certain time, as well as complex logic with alternative key groups with differing time constraints. OP_CHECKLOCKTIMEVERIFY, as conceived, seems too limited, IMHO. On Thursday, 2 October 2014, at 4:05 pm, Flavien Charlon wrote: Very good, I like the proposal. A question I have: can it be used to do the opposite, i.e. build a script that can only be spent up until block X? On Thu, Oct 2, 2014 at 2:09 AM, Peter Todd p...@petertodd.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 1 October 2014 17:55:36 GMT-07:00, Luke Dashjr l...@dashjr.org wrote: On Thursday, October 02, 2014 12:05:15 AM Peter Todd wrote: On 1 October 2014 11:23:55 GMT-07:00, Luke Dashjr l...@dashjr.org wrote: Thoughts on some way to have the stack item be incremented by the height at which the scriptPubKey was in a block? Better to create a GET-TXIN-BLOCK-(TIME/HEIGHT)-EQUALVERIFY operator. scriptPubKey would be: GET-TXIN-BLOCKHEIGHT-EQUALVERIFY (fails unless top stack item is equal to the txin block height) delta height ADD (top stack item is now txin height + delta height) CHECKLOCKTIMEVERIFY This sounds do-able, although it doesn't address using timestamps. For timestamps replace height with time in the above example; the minimum block time rule will prevent gaming it. You'd want these sacrifices to unlock years into the future to thoroughly exceed any reasonable business cycle; that's so far into the future that miners are almost certain to just mine them and collect the fees. For many use cases, short maturity periods are just as appropriate IMO. Very easy to incentivise mining centralisation with short maturities. I personally think just destroying coins is better, but it doesn't sit well with people so this is the next best thing. -BEGIN PGP SIGNATURE- Version: APG v1.1.1 iQFQBAEBCAA6BQJULKWsMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8 cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhcg8CACueZNGfWaZR+xyG9/o JwDBCnqOtwr6Bnosg3vNcRIDUnmsh+Qkk5dk2JpqYNYw7C3duhlwHshgsGOFkHEV f5RHDwkzGLJDLXrBwxxcIDdm3cJL8UVpQzJ7dD7aSnfj7MU/0aru3HaIU2ZfymUb 63jhul6FGbXH3K6p3bOoNrfIrCCGOv8jOIzeAgxNPydk8MVPgRhlYLAKBJxu8nMr 1oJGeaKVSGSPSrRdgS8tI4uOs0F4Q49APrLPGxGTERlATmWrr+asHGJTIxsB2IEm vrNgVRpkaN4Of9k96qzD9ReKfBfqm0WQKLolcXCVqGpdoHcvXh2AeWdjB/EFTyOq SOgO =WybM -END PGP SIGNATURE- -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
On Fri, Oct 3, 2014 at 7:28 AM, Matt Whitlock b...@mattwhitlock.name wrote: Is there a reason why we can't have the new opcode simply replace the top stack item with the block height of the txout being redeemed? This would not be soft-forking compatible. It also would be unsafe in that it would result in transactions which once mined could not be restored in a reorg through no fault of the participants, which makes the coins less fungible and differently safe to accept. It risks creating weird pressures around immediate block admission since a one additional block delay could forever censor such a transaction (E.g. increases the power of single miners to censor or steal). Avoiding this is a conscious decision in Bitcoin and also part of the justification for the 100 block maturity of newly generated coins. It also would require violating the script/transaction/block layering more substantially, complicating implementations, and making the validity of a script no longer a deterministic pure function of the transaction. Avoiding these issues is a conscious design in OP_CHECKLOCKTIMEVERIFY. I would strenuously oppose a proposal which failed in any of these respects. Then arbitrary logic could be implemented, including output cannot be spent until a certain time and also output can ONLY be spent until a certain time, as well as complex logic with alternative key groups with differing time constraints. You can already achieve the not spendable after logic with a cancellation spend that moves the coin in the usual way. (Which doesn't even require the participant be online, with the help of some network service to queue unlocked transactions). OP_CHECKLOCKTIMEVERIFY, as conceived, seems too limited, IMHO. It is intentionally so, and yet it covers the intended use cases; including ones with alternative key groups, they are just not exclusive. -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
On Friday, October 03, 2014 2:28:17 PM Matt Whitlock wrote: Is there a reason why we can't have the new opcode simply replace the top stack item with the block height of the txout being redeemed? Then arbitrary logic could be implemented, including output cannot be spent until a certain time and also output can ONLY be spent until a certain time, as well as complex logic with alternative key groups with differing time constraints. This cannot be done in a softfork. Furthermore, output can ONLY be spent until a certain time contradict's Bitcoin's present security assumptions: that assuming a honest sender, the transaction will remain valid and simply re-confirm if a reorg kicks it out. Luke -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
Alright. It seems there's no real disagreement about how the opcode behaves. Perhaps a time limit would be appropriate to stop people creating outputs locked for 100 years is bitcoin even likely to exist in 100 years? The entire history of computing is not even that old, seems hard to imagine that it'd be good for anything beyond wasting space in the database. But this is a minor point. So I guess it's time to start the deployment discussion. Bitcoin is a consensus system. It works best when everyone is following exactly the same rules at the same time. A soft fork works against this principle by allowing nodes to think they're following the majority ruleset, even if they aren't, effectively downgrading them to something a bit like SPV security without them realising. A hard fork has multiple desirable properties. Most importantly, it means a node can detect it's no longer in the consensus because it'll find its own chain height has diverged significantly from its peers. Core already has code that knows how to detect this condition and log errors about it as well as running the alertnotify script i.e. emailing the admin. Ideally it would also stop serving work so miners shut down or fail over, but this is easily added to the CheckForkWarningConditions() function. In other words, this gives the cleanest failure we can give, such that any procedures a node operator has put in place to alert them of divergence will be triggered. Any code which is waiting for confirmations will wait forever at this point, thus minimising the risk of loss. Additionally, forcing old peers to fall behind means SPV clients will pick the right chain, and not end up downloading transactions or blocks that are about to be doomed at the next re-org. They can easily choose to ignore transactions relayed by peers that are too far behind and thus not end up accepting transactions that are no longer valid according to the majority (a scenario which can cause monetary loss). I don't think hard forks should be scary. Mechanisms are in place to warn people and they can be scheduled with plenty of time in advance. The main stated justification for a soft fork is backwards compatibility, but in a system like Bitcoin you really don't want to be running behind the consensus and it's hard to imagine any node operator deliberately choosing to stay on the wrong side of the fork. It's not like other software where people can choose to skip an upgrade and things still work just like before. -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] bitcoinj 0.12
I'm stunned by what bitcoinj can do these days. Just reading the release notes gives one app ideas. Mike, Awesome. On 10/3/2014 5:49 AM, Mike Hearn wrote: I'm pleased to announce version 0.12 of bitcoinj, one of the worlds most popular Bitcoin libraries. -- 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 Fri, Oct 03, 2014 at 07:12:11PM -0400, Jeff Garzik wrote: RE It's not like other software where people can choose to skip an upgrade and things still work just like before. If you're a minority, sure you can. Still a few nutters out there on a 0.3.x codebase, including one or two inattentive, now-inconsequential miners. There is some headroom built in for just that... less disruptive upgrades that don't require 100%. Anyway the stuff Mike is saying about being able to detect upgrades is incorrect - detecting an upgrade is *easier* with a soft-fork, just look at the block header nVersion numbers and warn the user if they increase beyond what you know is valid. Bitcoin Core implements this IIRC, and bitcoinj should. Someone with more time should write all this up for the bitcoin.org developer docs BTW... There's extensive discussions on #bitcoin-dev and others about all of this. -- 'peter'[:-1]@petertodd.org 12367d385ad11358a4a1eee86cf8ebe06a76add36dfb4622 signature.asc Description: Digital signature -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
