Re: [Bitcoin-development] Version 0.9 goals
Sounds awesome! Pieter told me at lunch that headers first cut sync time to 45 minutes for him, which is another amazing improvement from the master of optimisations. Pieter, Matt and I also agreed that for maximum impact we should really try to ship payment protocol support in at least two clients simultaneously and ideally with a big merchant signed up too - to send a powerful message that we really mean it. Someone volunteered last week to do it for bitcoinj and if he doesn't pull through, I have some old code from EOY 2012 that I could update to the latest spec and ship at least some basic support. I'd hope that we can get Bitcoin Wallet or MultiBit updates out once bcj has support pretty fast. Also, Jeff said that BitPay want to be a leader in support for the protocol. So let's try and co-ordinate release dates so we can make a bit of a splash and grab the ecosystems attention. On Thu, Aug 15, 2013 at 2:29 AM, Gavin Andresen gavinandre...@gmail.comwrote: I plan on spending about half my time on code review and helping get pull requests tested, and the other half of my time working on code that probably won't make it into the 0.9 release. Sounds brilliant. It'll be nice to see the pull request queue drain. Any ideas what the non-0.9 code will be? Fee rework? DoS work? -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Version 0.9 goals
On Thu, Aug 15, 2013 at 10:09:48AM +0200, Mike Hearn wrote: Sounds awesome! Pieter told me at lunch that headers first cut sync time to 45 minutes for him, which is another amazing improvement from the master of optimisations. Just to make sure nobody expects a magic bullet: this was on a hexacore Xeon CPU, with several GB of -dbcache, libsecp256k1 for verification, and a very good network connection. It is repeatable and from random network peers, though. The code is here: https://github.com/sipa/bitcoin/commits/headersfirst It's usable and seems to be stable (including reindexing, which needs support for block files with out-of-order blocks now), but I still want to clean some things up before pullreq'in. There are probably some heuristic tweaks possible as well - Gregory found that performance is reduced for the first part of the chain on high-latency networks. Pieter, Matt and I also agreed that for maximum impact we should really try to ship payment protocol support in at least two clients simultaneously and ideally with a big merchant signed up too - to send a powerful message that we really mean it. Someone volunteered last week to do it for bitcoinj and if he doesn't pull through, I have some old code from EOY 2012 that I could update to the latest spec and ship at least some basic support. I'd hope that we can get Bitcoin Wallet or MultiBit updates out once bcj has support pretty fast. Also, Jeff said that BitPay want to be a leader in support for the protocol. So let's try and co-ordinate release dates so we can make a bit of a splash and grab the ecosystems attention. I believe we do need some wider support than just Bitcoin-Qt, indeed, as the number of people actually using the reference client as a wallet is quite low now. Ideally, several clients and merchants start support for it in a short timeframe... -- Pieter -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Version 0.9 goals
On Thu, Aug 15, 2013 at 10:22 AM, slush sl...@centrum.cz wrote: We're planning to support payment protocol in Trezor as well, if it counts. I think it's a missing piece in absolute security of hardware wallets. Yup, that's always been the plan :-) Any idea how much work it is, and would it be a v1 feature of the Trezor or added later via firmware update? -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Version 0.9 goals
Pieter, Matt and I also agreed that for maximum impact we should really try to ship payment protocol support in at least two clients simultaneously and ideally with a big merchant signed up too - to send a powerful message that we really mean it. Someone volunteered last week to do it for bitcoinj and if he doesn't pull through, I have some old code from EOY 2012 that I could update to the latest spec and ship at least some basic support. I'd hope that we can get Bitcoin Wallet or MultiBit updates out once bcj has support pretty fast. We're planning to support payment protocol in Trezor as well, if it counts. I think it's a missing piece in absolute security of hardware wallets. slush -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Version 0.9 goals
On Thu, Aug 15, 2013 at 2:29 AM, Gavin Andresen gavinandre...@gmail.comwrote: It feels to me like we're close to a 0.9 feature freeze / start of release cycle; I'd like to talk a little bit about what we'd like to see in the final 0.9 release. Payment Protocol support is ready to be pulled ( https://github.com/bitcoin/bitcoin/pull/2539) . Unless there are major objections, I will pull it tomorrow (it has already gone through two rounds of bounty-driven QA testing, so I'm convinced it is ready). No objections from me, I've already looked at the code a few times and did some testing here and there, looks good for merging. I'd love for 0.9 to contain sipa's headers first initial block download optimization; I think it is a big enough improvement to justify making the 0.9 test/release cycle longer. Yep, that'd be great. Coin control (https://github.com/bitcoin/bitcoin/pull/2343). The autotools work (https://github.com/bitcoin/bitcoin/pull/2805). Gitian-build with the latest openssl and Qt5. Perhaps update the version of Debian VMs that we gitian-build with. Fully agreed about payment protocol, autotools and Qt5 build. I'm still not very excited about coin control (and last time I looked at the code, it has an issue that it introduced statefulness into the wallet model - a bane for concurrency. But that may be resolved?) . Anyway, many people seem to want that so it's fine with me, given that the issues are fixed. Wladimir -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Version 0.9 goals
On Thu, Aug 15, 2013 at 12:49 PM, Wladimir laa...@gmail.com wrote: Fully agreed about payment protocol, autotools and Qt5 build. I'm still not very excited about coin control (and last time I looked at the code, it has an issue that it introduced statefulness into the wallet model - a bane for concurrency. But that may be resolved?) . Anyway, many people seem to want that so it's fine with me, given that the issues are fixed. As far as I can see, that state is gone, and is now passed in a separate object to the transaction-creation methods. I'd like to see it go in, as I believe it can be helpful in understanding the difference between the high-level abstraction (wallet) and the underlying implementation (individual coins) - something that many people are confused about. I think that's even a more important advantage than the ability for micro-management it offers. Multiwallet would be more appropriate for avoiding linkage between identities, but it seems there's little progress on that front now. -- Pieter -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Version 0.9 goals
Our plan is to add support for that into v1 firmware, but it also depends on readiness of surrounding infrastructure; mainly if there'll be support for payment protocol in multibit in the time of v1 release (I suppose that the Multibit will be the first wallet compatible with Trezor AND supporting payment protocol). Yeah, OK. Let's see how much progress Gary makes. Supporting HD wallets is the trickiest part and I don't know how much time I will have - the Android RNG issue and getting bcj 0.10 released have sucked up a lot of my time lately and I need to refocus on other things for a bit. But between the guy who volunteered to do payment protocol, and Gary doing TrezorJ, and Matija already having done the core algorithms, I'm hoping the only parts I'll have to do are integrating the HD code with the core wallet code. Possibly if we're running out of time I can do a real basic HD wallet implementation that only iterates a key once and doesn't generate new keys for each transaction, as that's really the trickiest part (because of the need for lookahead/behind and memory bloat on phones). -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Version 0.9 goals
On Thu, Aug 15, 2013 at 11:02 AM, Mike Hearn m...@plan99.net wrote: On Thu, Aug 15, 2013 at 10:22 AM, slush sl...@centrum.cz wrote: We're planning to support payment protocol in Trezor as well, if it counts. I think it's a missing piece in absolute security of hardware wallets. Yup, that's always been the plan :-) Any idea how much work it is, and would it be a v1 feature of the Trezor or added later via firmware update? Our plan is to add support for that into v1 firmware, but it also depends on readiness of surrounding infrastructure; mainly if there'll be support for payment protocol in multibit in the time of v1 release (I suppose that the Multibit will be the first wallet compatible with Trezor AND supporting payment protocol). slush -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Version 0.9 goals
Mike, If bitcoinj will be ready and you will help us, we are willing to implement it right away in Hive as well. We will also keep BitcoinKit.framework updated with the new bitcoind and bitcoinj implementations. BitPay taking the lead here would be tremendous. Hopefully cool sites like Bitcoin Store will also be game to hit the ground running. I'll ask them. -wendell grabhive.com | twitter.com/grabhive | gpg: 6C0C9411 On Aug 15, 2013, at 10:09 AM, Mike Hearn wrote: Pieter, Matt and I also agreed that for maximum impact we should really try to ship payment protocol support in at least two clients simultaneously and ideally with a big merchant signed up too - to send a powerful message that we really mean it. Someone volunteered last week to do it for bitcoinj and if he doesn't pull through, I have some old code from EOY 2012 that I could update to the latest spec and ship at least some basic support. I'd hope that we can get Bitcoin Wallet or MultiBit updates out once bcj has support pretty fast. Also, Jeff said that BitPay want to be a leader in support for the protocol. So let's try and co-ordinate release dates so we can make a bit of a splash and grab the ecosystems attention. -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Gavin's post-0.9 TODO list...
Mike asked what non-0.9 code I'm working on; the three things on the top of my list are: 1) Smarter fee handling on the client side, instead of hard-coded fees. I was busy today generating scatter-plots and histograms of transaction fees versus priorities to get some insight into what miner policies look like right now. 2) First double-spend relaying and alerting, to better support low-value in-person transactions. Related: *Have *a *Snack*, Pay with *Bitcoins*http://www.tik.ee.ethz.ch/file/848064fa2e80f88a57aef43d7d5956c6/P2P2013_093.pdf 3) Work on 2-3 whitepapers on why we need to increase or remove the 1MB block size limit, how we can do it safely, and go through all of the arguments that have been made against it and explain why they're wrong. -- -- Gavin Andresen -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Gavin's post-0.9 TODO list...
On 16 August 2013 03:00, Gavin Andresen gavinandre...@gmail.com wrote: Mike asked what non-0.9 code I'm working on; the three things on the top of my list are: 1) Smarter fee handling on the client side, instead of hard-coded fees. I was busy today generating scatter-plots and histograms of transaction fees versus priorities to get some insight into what miner policies look like right now. +1 2) First double-spend relaying and alerting, to better support low-value in-person transactions. Related: *Have *a *Snack*, Pay with *Bitcoins*http://www.tik.ee.ethz.ch/file/848064fa2e80f88a57aef43d7d5956c6/P2P2013_093.pdf +1 3) Work on 2-3 whitepapers on why we need to increase or remove the 1MB block size limit, how we can do it safely, and go through all of the arguments that have been made against it and explain why they're wrong. What block size do you think is ideal? -- -- Gavin Andresen -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
