[Bitcoin-development] Bitcoin Core version 0.9.0 released
Bitcoin Core version 0.9.0 is now available from: https://bitcoin.org/bin/0.9.0/ This is a release candidate for a new major version. A major version brings both new features and bug fixes. Please report bugs using the issue tracker at github: https://github.com/bitcoin/bitcoin/issues How to Upgrade -- If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), uninstall all earlier versions of Bitcoin, then run the installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or bitcoind/bitcoin-qt (on Linux). If you are upgrading from version 0.7.2 or earlier, the first time you run 0.9.0 your blockchain files will be re-indexed, which will take anywhere from 30 minutes to several hours, depending on the speed of your machine. On Windows, do not forget to uninstall all earlier versions of the Bitcoin client first, especially if you are switching to the 64-bit version. Windows 64-bit installer - New in 0.9.0 is the Windows 64-bit version of the client. There have been frequent reports of users running out of virtual memory on 32-bit systems during the initial sync. Because of this it is recommended to install the 64-bit version if your system supports it. NOTE: Release candidate 2 Windows binaries are not code-signed; use PGP and the SHA256SUMS.asc file to make sure your binaries are correct. In the final 0.9.0 release, Windows setup.exe binaries will be code-signed. OSX 10.5 / 32-bit no longer supported - 0.9.0 drops support for older Macs. The minimum requirements are now: * A 64-bit-capable CPU (see http://support.apple.com/kb/ht3696); * Mac OS 10.6 or later (see https://support.apple.com/kb/ht1633). Downgrading warnings The 'chainstate' for this release is not always compatible with previous releases, so if you run 0.9 and then decide to switch back to a 0.8.x release you might get a blockchain validation error when starting the old release (due to 'pruned outputs' being omitted from the index of unspent transaction outputs). Running the old release with the -reindex option will rebuild the chainstate data structures and correct the problem. Also, the first time you run a 0.8.x release on a 0.9 wallet it will rescan the blockchain for missing spent coins, which will take a long time (tens of minutes on a typical machine). Rebranding to Bitcoin Core --- To reduce confusion between Bitcoin-the-network and Bitcoin-the-software we have renamed the reference client to Bitcoin Core. Autotools build system --- For 0.9.0 we switched to an autotools-based build system instead of individual (q)makefiles. Using the standard ./autogen.sh; ./configure; make to build Bitcoin-Qt and bitcoind makes it easier for experienced open source developers to contribute to the project. Be sure to check doc/build-*.md for your platform before building from source. Bitcoin-cli - Another change in the 0.9 release is moving away from the bitcoind executable functioning both as a server and as a RPC client. The RPC client functionality (tell the running bitcoin daemon to do THIS) was split into a separate executable, 'bitcoin-cli'. The RPC client code will eventually be removed from bitcoind, but will be kept for backwards compatibility for a release or two. `walletpassphrase` RPC --- The behavior of the `walletpassphrase` RPC when the wallet is already unlocked has changed between 0.8 and 0.9. The 0.8 behavior of `walletpassphrase` is to fail when the wallet is already unlocked: walletpassphrase 1000 walletunlocktime = now + 1000 walletpassphrase 10 Error: Wallet is already unlocked (old unlock time stays) The new behavior of `walletpassphrase` is to set a new unlock time overriding the old one: walletpassphrase 1000 walletunlocktime = now + 1000 walletpassphrase 10 walletunlocktime = now + 10 (overriding the old unlock time) Transaction malleability-related fixes -- This release contains a few fixes for transaction ID (TXID) malleability issues: - -nospendzeroconfchange command-line option, to avoid spending zero-confirmation change - IsStandard() transaction rules tightened to prevent relaying and mining of mutated transactions - Additional information in listtransactions/gettransaction output to report wallet transactions that conflict with each other because they spend the same outputs. - Bug fixes to the getbalance/listaccounts RPC commands, which would report incorrect balances for double-spent (or mutated) transactions. - New option: -zapwallettxes to rebuild the wallet's transaction information Transaction Fees This release drops the default fee required to relay transactions across the network and for miners to consider the
[Bitcoin-development] [QT] how to disable block verification for faster UI testing?
the command line options mention a -checklevel parameter. I've been passing 0 assuming there'd be little to no verification, but it's happened a few times that when I open the official binary (while not doing development) there's some sort of database corruption and Bitcoin-Qt needs to reindex blocks on disk, a process that can take probably a whole day. how do you guys develop the UI and avoid these issues? Cheers, Angel http://twitter.com/gubatron -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [QT] how to disable block verification for faster UI testing?
On Wed, Mar 19, 2014 at 6:27 PM, Angel Leon gubat...@gmail.com wrote: the command line options mention a -checklevel parameter. I've been passing 0 assuming there'd be little to no verification, but it's happened a few times that when I open the official binary (while not doing development) there's some sort of database corruption and Bitcoin-Qt needs to reindex blocks on disk, a process that can take probably a whole day. how do you guys develop the UI and avoid these issues? In general I do very little with the database while developing the UI. I have various seperate bitcoin data directories (both testnet and mainnet) to try things out. Before doing something risky I just make a copy. These days I also do a lot of development with -regtest, as it allows quickly setting up test scenarios. What are you trying to test specifically? The progress bar while reindexing? If you have database problems are you perhaps switching between 0.8.x and 0.9.x with the same directory? In that case see the downgrading warning here: https://bitcoin.org/bin/0.9.0/README.txt . Wladimir -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [QT] how to disable block verification for faster UI testing?
If you have database problems are you perhaps switching between 0.8.x and 0.9.x with the same directory? I think that may have been the issue. Maybe now that I have a 0.9.0 official binary, when I switch to the source builds I won't have the issue. However, I think I'll do what you do and have separate bitcoin data directories, that's probably the best. not trying to test anything specifically, just codign, building, launching over and over, would like to make the startup of the Qt client faster. http://twitter.com/gubatron On Wed, Mar 19, 2014 at 2:22 PM, Wladimir laa...@gmail.com wrote: On Wed, Mar 19, 2014 at 6:27 PM, Angel Leon gubat...@gmail.com wrote: the command line options mention a -checklevel parameter. I've been passing 0 assuming there'd be little to no verification, but it's happened a few times that when I open the official binary (while not doing development) there's some sort of database corruption and Bitcoin-Qt needs to reindex blocks on disk, a process that can take probably a whole day. how do you guys develop the UI and avoid these issues? In general I do very little with the database while developing the UI. I have various seperate bitcoin data directories (both testnet and mainnet) to try things out. Before doing something risky I just make a copy. These days I also do a lot of development with -regtest, as it allows quickly setting up test scenarios. What are you trying to test specifically? The progress bar while reindexing? If you have database problems are you perhaps switching between 0.8.x and 0.9.x with the same directory? In that case see the downgrading warning here: https://bitcoin.org/bin/0.9.0/README.txt . Wladimir -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] HEADS UP: Bitcoin 0.9.0 doesn't work on old Linux
I just upgraded to Bitcoin 0.9.0 and I got this: $ ./bitcoind ./bitcoind: /lib/libc.so.6: version `GLIBC_2.15' not found (required by ./bitcoind) ./bitcoind: /lib/libc.so.6: version `GLIBC_2.14' not found (required by ./bitcoind) $ ./bitcoin-qt ./bitcoin-qt: /lib/libc.so.6: version `GLIBC_2.15' not found (required by ./bitcoin-qt) ./bitcoin-qt: /lib/libc.so.6: version `GLIBC_2.14' not found (required by ./bitcoin-qt) Sniff. Red Hat Enterprise Linux uses glibc 2.12. -- Jesús Cea Avión _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ Twitter: @jcea_/_/_/_/ _/_/_/_/_/ jabber / xmpp:j...@jabber.org _/_/ _/_/_/_/ _/_/ _/_/ Things are not so easy _/_/ _/_/_/_/ _/_/_/_/ _/_/ My name is Dump, Core Dump _/_/_/_/_/_/ _/_/ _/_/ El amor es poner tu felicidad en la felicidad de otro - Leibniz signature.asc Description: OpenPGP digital signature -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] HEADS UP: Bitcoin 0.9.0 doesn't work on old Linux
On Wed, Mar 19, 2014 at 7:28 PM, Jesus Cea j...@jcea.es wrote: I just upgraded to Bitcoin 0.9.0 and I got this: $ ./bitcoind ./bitcoind: /lib/libc.so.6: version `GLIBC_2.15' not found (required by ./bitcoind) ./bitcoind: /lib/libc.so.6: version `GLIBC_2.14' not found (required by ./bitcoind) $ ./bitcoin-qt ./bitcoin-qt: /lib/libc.so.6: version `GLIBC_2.15' not found (required by ./bitcoin-qt) ./bitcoin-qt: /lib/libc.so.6: version `GLIBC_2.14' not found (required by ./bitcoin-qt) This a a known issue: https://github.com/bitcoin/bitcoin/issues/3803 Wladimir -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Bitcoin for W3C Payments Workshop, March 24-25
Hello Bitcoiners, I have been working on some use cases for the W3C payments workshop. I'd like to include Bitcoin, but I might not have the time: Here is what I have: https://www.w3.org/community/webpayments/wiki/WebPaymentsMobileUseCases Which is editable with a w3c username and password. Just be a member of the webpayments community group: http://www.w3.org/community/webpayments/ More formally you can submit a pull request to: https://github.com/w3c-webmob/payments-use-cases - Due to discussions with others am attempting to apply the following template: Name: name of the solution Use Cases: Key use cases for the solution Regions and currencies: Any SDKs or APIs which are available to developers with the following things to consider (for use cases): (1) add real money to the service (2) buy a physical good in the real wold (e.g., a cup of coffee) (3) pay for physical service (e.g., gym membership)? (4) convert virtual money back into paper money (5) transfer money from one person to another (even if the second person is not signed up for the service)? (6) buy product online (7) resolve disputes? (8) view transactions? (9) secure the wallet (10) etc. Thanks for your time and have a great day! -Brent Shambaugh -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin for W3C Payments Workshop, March 24-25
I wish to state that I fundamentally disagree with this proposal of use cases for W3C payments workshop. Please read my following explanation and then do what you will: At one time I was invited to join the Web Payments conference calls. I considered it and then declined due to the very CLAs that Brent mentioned in the message that started this thread. I was trying to remember the language that I objected to relating to the W3C CLA. Found it: https://web-payments.org/minutes/ As mentioned, I was offered to join these calls but I declined due to, in part, the following: Upon review of the page at web-payments.org, I noticed that it provides a means to connect with web payments group by teleconference. However, there is an agreement that the site would require me to accept merely to join the teleconference and collaborate with others in the web payments group. I would say unfortunately, but in my case I will say fortunately, I don't agree with the required agreement as shown here at http://www.w3.org/community/about/agreements/cla/ which is shown as follows at https://web-payments.org/minutes/ There are no costs associated with joining the group or limitations on who may join the teleconference as long as they agree to the Web Payments community Some of the things I don't like about the proposed agreement / requirement are fundamental. At the core, it should be understood that collaborative efforts, or teleconferences involving innovators who strive to develop concepts for eventual development of a social good, for example, should not be subject to a requirement that anyone agree to a license in relation to their participation or contribution. Such requirements inhibit innovation and free thought. For example, the web payments group provides that in order for me to participate, I must first agree to license my Essential Claims under the W3C CLA RF Licensing Requirements and numerous other requirements. Although I was interested in some sort of collaboration with the Web Payments Community Group, these CLAs - lengthy, burdensome, and in my personal view, highly dubious and potentially restricting with respect to innovation and free thought - caused me to reconsider, and thus I will not be entering into web or telephone conferences or related collaborations with the W3C / Web Payments folks until such time as they remove these burdensome requirements which are applied merely to join a call. Hello Bitcoiners, I have been working on some use cases for the W3C payments workshop. I'd like to include Bitcoin, but I might not have the time: Here is what I have: https://www.w3.org/community/webpayments/wiki/WebPaymentsMobileUseCases Which is editable with a w3c username and password. Just be a member of the webpayments community group: http://www.w3.org/community/webpayments/ More formally you can submit a pull request to: https://github.com/w3c-webmob/payments-use-cases - Due to discussions with others am attempting to apply the following template: Name: name of the solution Use Cases: Key use cases for the solution Regions and currencies: Any SDKs or APIs which are available to developers with the following things to consider (for use cases): (1) add real money to the service (2) buy a physical good in the real wold (e.g., a cup of coffee) (3) pay for physical service (e.g., gym membership)? (4) convert virtual money back into paper money (5) transfer money from one person to another (even if the second person is not signed up for the service)? (6) buy product online (7) resolve disputes? (8) view transactions? (9) secure the wallet (10) etc. Thanks for your time and have a great day! -Brent Shambaugh -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin for W3C Payments Workshop, March 24-25
On 20 March 2014 02:41, Odinn Cyberguerrilla odinn.cyberguerri...@riseup.net wrote: I wish to state that I fundamentally disagree with this proposal of use cases for W3C payments workshop. Please read my following explanation and then do what you will: At one time I was invited to join the Web Payments conference calls. I considered it and then declined due to the very CLAs that Brent mentioned in the message that started this thread. I was trying to remember the language that I objected to relating to the W3C CLA. Found it: https://web-payments.org/minutes/ As mentioned, I was offered to join these calls but I declined due to, in part, the following: Upon review of the page at web-payments.org, I noticed that it provides a means to connect with web payments group by teleconference. However, there is an agreement that the site would require me to accept merely to join the teleconference and collaborate with others in the web payments group. I would say unfortunately, but in my case I will say fortunately, I don't agree with the required agreement as shown here at http://www.w3.org/community/about/agreements/cla/ which is shown as follows at https://web-payments.org/minutes/ There are no costs associated with joining the group or limitations on who may join the teleconference as long as they agree to the Web Payments community Some of the things I don't like about the proposed agreement / requirement are fundamental. At the core, it should be understood that collaborative efforts, or teleconferences involving innovators who strive to develop concepts for eventual development of a social good, for example, should not be subject to a requirement that anyone agree to a license in relation to their participation or contribution. Such requirements inhibit innovation and free thought. For example, the web payments group provides that in order for me to participate, I must first agree to license my Essential Claims under the W3C CLA RF Licensing Requirements and numerous other requirements. Although I was interested in some sort of collaboration with the Web Payments Community Group, these CLAs - lengthy, burdensome, and in my personal view, highly dubious and potentially restricting with respect to innovation and free thought - caused me to reconsider, and thus I will not be entering into web or telephone conferences or related collaborations with the W3C / Web Payments folks until such time as they remove these burdensome requirements which are applied merely to join a call. Fair point, but you need to understand that all specs created by the W3C are committed to be royalty free. That's why there's a CLA, but I can totally see if you or your employer feels uncomfortable with that. You might have the best possible interests, but not everyone may be as honest. Personally, have participated as an unaffiliated volunteer and hobbyist at the W3C for a few years, I've never seen an issue with this. In fact, I'm really happy that they have a bullet proof intellectual property framework that guarantees all my contributions will never be encumbered by patents or be charged royalties for. Hello Bitcoiners, I have been working on some use cases for the W3C payments workshop. I'd like to include Bitcoin, but I might not have the time: Here is what I have: https://www.w3.org/community/webpayments/wiki/WebPaymentsMobileUseCases Which is editable with a w3c username and password. Just be a member of the webpayments community group: http://www.w3.org/community/webpayments/ More formally you can submit a pull request to: https://github.com/w3c-webmob/payments-use-cases - Due to discussions with others am attempting to apply the following template: Name: name of the solution Use Cases: Key use cases for the solution Regions and currencies: Any SDKs or APIs which are available to developers with the following things to consider (for use cases): (1) add real money to the service (2) buy a physical good in the real wold (e.g., a cup of coffee) (3) pay for physical service (e.g., gym membership)? (4) convert virtual money back into paper money (5) transfer money from one person to another (even if the second person is not signed up for the service)? (6) buy product online (7) resolve disputes? (8) view transactions? (9) secure the wallet (10) etc. Thanks for your time and have a great day! -Brent Shambaugh -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list
Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
Hi Andreas I'm implementing support for BIP70 in my POS at the moment, and I've just realized that with options you're proposing usecase I'm looking for is not covered. Right now, before BIP70, I'm sending BIP21 URI via NFC or QR code, and I need to still be able to use it for backwards compatibility. But at the same time I want to be able to support BIP70. And also I want to avoid using external servers, the concept of my POS is that everything is happening between just payer's phone and payee's POS device. This means that BIP72 HTTP(S) link inside Bitcoin URI is not suitable for me. You're also offering an option to include Base43 encoded PR body right inside the Bitcoin URI, but in a way that is not backwards compatible with BIP21. In the end this all means that there is no way for me to at the same time keep backwards compatibility with all wallets not supporting NFC and BIP70 (all other wallets right now), and keep things inside POS without need for external servers. I understand your intention behind base43 encoding and noncompatible URI - you want to make most possible use of QR codes. But I wonder - did you compare this base43 to base64 encoded request in a binary QR code format? How much do we actually win in total bytes capacity at a price of noncompatibility and increased complexity? And also maybe we can extend BIP72 to include encoded payment request in the URL directly in a backwards compatible way? Best regards, Alex Kotenko 2014-03-02 11:50 GMT+00:00 Mike Hearn m...@plan99.net: Thanks Andreas. For BIP standardisation, I think the VIEW intent seems like an obvious one. Bluetooth support probably should come later if/when we put encryption/auth on the RFCOMM link (probably SSL). -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
Take a look at BIP 73: https://github.com/bitcoin/bips/blob/master/bip-0073.mediawiki On Wed, Mar 19, 2014 at 10:22 PM, Alex Kotenko alexy...@gmail.com wrote: Hi Andreas I'm implementing support for BIP70 in my POS at the moment, and I've just realized that with options you're proposing usecase I'm looking for is not covered. Right now, before BIP70, I'm sending BIP21 URI via NFC or QR code, and I need to still be able to use it for backwards compatibility. But at the same time I want to be able to support BIP70. And also I want to avoid using external servers, the concept of my POS is that everything is happening between just payer's phone and payee's POS device. This means that BIP72 HTTP(S) link inside Bitcoin URI is not suitable for me. You're also offering an option to include Base43 encoded PR body right inside the Bitcoin URI, but in a way that is not backwards compatible with BIP21. In the end this all means that there is no way for me to at the same time keep backwards compatibility with all wallets not supporting NFC and BIP70 (all other wallets right now), and keep things inside POS without need for external servers. I understand your intention behind base43 encoding and noncompatible URI - you want to make most possible use of QR codes. But I wonder - did you compare this base43 to base64 encoded request in a binary QR code format? How much do we actually win in total bytes capacity at a price of noncompatibility and increased complexity? And also maybe we can extend BIP72 to include encoded payment request in the URL directly in a backwards compatible way? Best regards, Alex Kotenko 2014-03-02 11:50 GMT+00:00 Mike Hearn m...@plan99.net: Thanks Andreas. For BIP standardisation, I think the VIEW intent seems like an obvious one. Bluetooth support probably should come later if/when we put encryption/auth on the RFCOMM link (probably SSL). -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ 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/ -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
