* [Bitcoin-development] Roadmap/schedules @ 2011-08-10 16:29 Gavin Andresen 2011-08-10 16:59 ` Matt Corallo ` (2 more replies) 0 siblings, 3 replies; 8+ messages in thread From: Gavin Andresen @ 2011-08-10 16:29 UTC (permalink / raw) To: Bitcoin Dev I've been wading through the pull requests and bug lists to figure out a roadmap for the next few months. Here are the things on my priority list: 1. Where are we at with network health? What metrics should we be using? Is there work to be done? And meta-issue: can somebody volunteer to be the Bitcoin Network Health Inspector to keep track of this? 2. We've got a chronic problem with new code causing CRITICAL_SECTION deadlocks (see issue #453 for the latest). Detecting potential deadlocks early should be done; longer term I think re-architecting to be single-threaded/asio is probably the right thing to do. 3. Wallet security. I'd like to get Matt's wallet encryption shipped soon, along with all or part of groffer's Multisign patch (#319 -- since that will enable the creation of trojan-resistant secure wallet solutions). 4. Bug fixing. 44 bugs in the issue list, some of which I think are already fixed. Anybody else want to volunteer to be BugKeeper? (job would be: prioritize/assign bugs, make sure they get closed when they're fixed). 5. Testing. I don't have time to personally test every PULL request, but if a pull involves more than trivial code changes I'm not going to pull it unless it has been thoroughly tested. We had a very good rule at a company I used to work for-- programmers were NOT allowed to be the only ones to test their own code. Help finding money and/or people for a dedicated "core bitcoin quality assurance team" is welcome. More unit tests and automated testing is also certainly welcome. If this was open source blogging software I'd be much less uptight about testing and code review and bugs. But it's not, it is software for handling money. Stuff I'd like to see in the release-after-next: fClient mode (download headers only, for faster initial startup; I've started the work, talk to me if you want to take over) Sipa's wallet and key export/import Move from wxWidgets to qt for the GUI Un-hardcode fee handling (anybody already working on this?) And research-y features I'd like to see happen soon: "Impolite peer" detection/reaction to prevent various DOS/Sybil attacks Better detection/reaction to double spend attempts or block-chain splits Code for mining pool participants that helps keep mining pool operators honest Everything else I consider lower priority. But if it is important to you, is important to other people (and non-controversial), you thoroughly test it, and there's zero chance it introduces a security vulnerability... then I'll have no objections to pulling it. Did I miss anything important? I'll create a Roadmap page on the bitcoin wiki if there is general consensus about priorities. -- -- Gavin Andresen ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] Roadmap/schedules 2011-08-10 16:29 [Bitcoin-development] Roadmap/schedules Gavin Andresen @ 2011-08-10 16:59 ` Matt Corallo 2011-08-10 18:57 ` Pieter Wuille ` (2 more replies) 2011-08-10 20:41 ` Jeff Garzik 2011-08-11 18:20 ` Rick Wesson 2 siblings, 3 replies; 8+ messages in thread From: Matt Corallo @ 2011-08-10 16:59 UTC (permalink / raw) To: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 5971 bytes --] On Wed, 2011-08-10 at 12:29 -0400, Gavin Andresen wrote: > I've been wading through the pull requests and bug lists to figure out > a roadmap for the next few months. > > Here are the things on my priority list: > > 1. Where are we at with network health? What metrics should we be > using? Is there work to be done? We really don't have too many metrics here. AFAIK the only real metric keeping place would be my dnsseed (as well as the one run by IO- ) and they don't look good (I show about 3x as many 0.3.23 nodes listening as 0.3.24, likely due to the rate that 0.3.23 nodes will drop connections, made worse by recent block size increases). > And meta-issue: can somebody volunteer to be the Bitcoin Network > Health Inspector to keep track of this? Very much needed, didn't TD say something about a friend who wanted to do research in this area? > > 2. We've got a chronic problem with new code causing CRITICAL_SECTION > deadlocks (see issue #453 for the latest). Detecting potential > deadlocks early should be done; longer term I think re-architecting to > be single-threaded/asio is probably the right thing to do. Sipa had begin looking at doing some redoing of the locking system (to support more broad stuff like read-only locks, etc) to solve that exact bug, but I never heard anything about if he actually started writing code or how far he got. > > 3. Wallet security. I'd like to get Matt's wallet encryption shipped > soon, along with all or part of groffer's Multisign patch (#319 -- > since that will enable the creation of trojan-resistant secure wallet > solutions). I was under the impression all that was left on the to-do for 0.4 was wallet import/export testing and merge (and a few bug fixes like #453), I agree #319 should be pulled sometime soon, but maybe for 0.4 just the IsStandard parts in 0.4 as those need to get out first anyway? > > 4. Bug fixing. 44 bugs in the issue list, some of which I think are > already fixed. Anybody else want to volunteer to be BugKeeper? (job > would be: prioritize/assign bugs, make sure they get closed when > they're fixed). Personally, I'd like to see a better bug tracking system used anyway, ie one with a full feature set, better tagging system, etc (I really hate github's system here, but moving would be hard...). Anyway, many of them are future "would be nice to have things" or a minor or annoying bug which effects almost no one (or is at least doesnt keep anyone from using the client) but require a lot of effort to fix. > > 5. Testing. I don't have time to personally test every PULL request, > but if a pull involves more than trivial code changes I'm not going to > pull it unless it has been thoroughly tested. We had a very good rule > at a company I used to work for-- programmers were NOT allowed to be > the only ones to test their own code. Help finding money and/or people > for a dedicated "core bitcoin quality assurance team" is welcome. > More unit tests and automated testing is also certainly welcome. Would be really nice. I'm looking to move the jenkins server somewhere (moving to college means move as much as possible to VPSs instead of my parent's basement where I can't manage it) but it could allow for pretty good sanity tests on patches (which they often currently fail) including unit tests and build tests. If someone trusted wants to part with a VPS or can spare some bitcoins so I can grab one myself, it would be much appreciated (or if someone wants to take over that server, that would be nicer). > > If this was open source blogging software I'd be much less uptight > about testing and code review and bugs. But it's not, it is software > for handling money. > > > Stuff I'd like to see in the release-after-next: > > fClient mode (download headers only, for faster initial startup; I've > started the work, talk to me if you want to take over) Need to talk here, I started work on splitting the block/transaction check/store and net with the ultimate goal of making a nice api that they communicate over (as well as wallet and potentially other) and allowing for a different block/transaction check module for lightweight nodes. It would also mean a bit cleaner codebase which could allow for, say, a partial rewrite of net code without far-reaching changes. Whether or not its even a good idea, I don't know, but I've written some code anyway. > Sipa's wallet and key export/import I was under the impression the plan was for this to go in 0.4 aka next release, but personally, I don't care too much either way. > Move from wxWidgets to qt for the GUI > Un-hardcode fee handling (anybody already working on this?) Sipa did some good thinking through for algorithms that could be really useful here, but I don't think any code was ever written, nor did he finish (is he off doing the studying thing?) > > And research-y features I'd like to see happen soon: > > "Impolite peer" detection/reaction to prevent various DOS/Sybil attacks > Better detection/reaction to double spend attempts or block-chain splits Not sure what is meant here. Personally, I'm animately against any kind of notification to spread through the network in case of a double spend, and I really think it double-spend detection could be very efficiently done now. I was under the impression block-chain splits were fairly efficiently handled already? > Code for mining pool participants that helps keep mining pool operators honest > > > Everything else I consider lower priority. But if it is important to > you, is important to other people (and non-controversial), you > thoroughly test it, and there's zero chance it introduces a security > vulnerability... then I'll have no objections to pulling it. > > Did I miss anything important? I'll create a Roadmap page on the > bitcoin wiki if there is general consensus about priorities. Matt [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] Roadmap/schedules 2011-08-10 16:59 ` Matt Corallo @ 2011-08-10 18:57 ` Pieter Wuille 2011-08-11 11:56 ` Mike Hearn 2011-08-11 17:49 ` bgroff 2 siblings, 0 replies; 8+ messages in thread From: Pieter Wuille @ 2011-08-10 18:57 UTC (permalink / raw) To: bitcoin-development On Wed, Aug 10, 2011 at 06:59:14PM +0200, Matt Corallo wrote: > On Wed, 2011-08-10 at 12:29 -0400, Gavin Andresen wrote: > > I've been wading through the pull requests and bug lists to figure out > > a roadmap for the next few months. > > > > Here are the things on my priority list: > > > 2. We've got a chronic problem with new code causing CRITICAL_SECTION > > deadlocks (see issue #453 for the latest). Detecting potential > > deadlocks early should be done; longer term I think re-architecting to > > be single-threaded/asio is probably the right thing to do. > Sipa had begin looking at doing some redoing of the locking system (to > support more broad stuff like read-only locks, etc) to solve that exact > bug, but I never heard anything about if he actually started writing > code or how far he got. No I didn't start writing anything - I've been quite busy the past few weeks, and will be more so the coming weeks. Anyway, some ideas: Either we try to make everything single threaded, and aim towards a bitcoin library which you pass events (which can be network, rpc, UI, ...) and it always processes in finite time, without any separate threads. That would be a serious rewrite, and maybe a limitation on potential growth (there *will* be a time where a full node doesn't run on anything but a 16-core machine...). The alternative is doing a very careful checking/rework of the locking system. I think you want some per-object locking instead of per single data structure. Making it so fine-grained forces careful checking of the order in which things are locked. That is hard to keep track of, and probably doesn't gain you very much (just a guess, experiments could prove me wrong, obviously) I would propose a system with one lock for the node-handling code (mapTransactions, mapBlockIndex, mapOrphanBlocks, ...), one lock for the wallet-handling code (mapWallet, CKeyStore), and one lock for network-handling code. No access to any inner data structures of these components is exposed, and everything goes through accessor functions. All exposed functions of each component take the respective lock upon entering the component. This includes functions that only need read-only access (which currently often don't take a lock at all, iirc). However, I think we can move to reader-writer locks (boost's shared_mutex). A lot of code does not need an exclusive lock on the data, as multiple threads reading the internal data structures simultaneously is not a problem. This would mean that all inspector functions are wrapped in a lock_shared/unlock_shared blocks, all mutator functions are wrapped in a lock_upgrade/unlock_upgrade block, and code that actually modifies data structures is wrapped in a unlock_upgrade_and_lock/ unlock_and_lock_upgrade block. This is clearly part of a larger code-cleanup effort, as it would mean moving all code in GUI and RPC that take locks on various things, to the component they are taking locks on. That's immediately a nice step towards "librarification" of the code... > > Sipa's wallet and key export/import > I was under the impression the plan was for this to go in 0.4 aka next > release, but personally, I don't care too much either way. I think it should be more or less finished by now in terms of functionality, at least for dumpprivkey, importprivkey, removeprivkey. I'm somewhat less sure about dumpwallet/importwallet, as some changes to the json dump format might be useful still. It does require testing though... > > Move from wxWidgets to qt for the GUI I'd really like to see that - with or without autotools, if some degree of consistent config/build architecture can be maintained for the different platforms. > > Un-hardcode fee handling (anybody already working on this?) > Sipa did some good thinking through for algorithms that could be really > useful here, but I don't think any code was ever written, nor did he > finish (is he off doing the studying thing?) I was working on a draft for a reworked fee system. I didn't get to write things out nicely, but the main idea was: assign a score to each transaction group, in a way that scores always keep increasing over time. Keep the memory pool sorted according to those scores, and drop the lowest scoring ones when a configurable memory limit is reached (no limit on the score itself). Finally, for mining, select the top N transaction groups from the pool in such a way that an average configurable fee per byte is maintained. As each mining node chooses a (hopefully more or less fixed, or at least only slowly changing) cutoff score above which transactions are included, the network should converge to a more or less fixed probability distribution for the score at which transactions are included. Nodes can measure and estimate this distribution, and calculate expected time to inclusion for a given fee. The devil is in the details, as it is kinda hard to define a scoring system for transactions that is independent from the current exchange value of bitcoins, from which kind of transactions are common on the network, but still tries to mimic the cost for the network to handle that transaction. Anyway, as said, I currently don't have the time to implement these ideas right now. I do read the mailing list, though :) -- Pieter ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] Roadmap/schedules 2011-08-10 16:59 ` Matt Corallo 2011-08-10 18:57 ` Pieter Wuille @ 2011-08-11 11:56 ` Mike Hearn 2011-08-11 17:49 ` bgroff 2 siblings, 0 replies; 8+ messages in thread From: Mike Hearn @ 2011-08-11 11:56 UTC (permalink / raw) To: Matt Corallo; +Cc: bitcoin-development > they don't look good (I show about 3x as many 0.3.23 nodes listening as > 0.3.24 *cough* Upgrade alerts. > Very much needed, didn't TD say something about a friend who wanted to > do research in this area? I don't know if he'll actually do anything. Best assume this "position" is still open. >> 2. We've got a chronic problem with new code causing CRITICAL_SECTION >> deadlocks I've seen locks that track ordering relative to other locks and assert when they are locked out of order. Though it's not inversion related, running ThreadSanitizer might help find other thread safety issues: http://code.google.com/p/data-race-test/wiki/ThreadSanitizer ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] Roadmap/schedules 2011-08-10 16:59 ` Matt Corallo 2011-08-10 18:57 ` Pieter Wuille 2011-08-11 11:56 ` Mike Hearn @ 2011-08-11 17:49 ` bgroff 2 siblings, 0 replies; 8+ messages in thread From: bgroff @ 2011-08-11 17:49 UTC (permalink / raw) To: Matt Corallo; +Cc: bitcoin-development Matt Corallo wrote: > On Wed, 2011-08-10 at 12:29 -0400, Gavin Andresen wrote: >> I've been wading through the pull requests and bug lists to figure out >> a roadmap for the next few months. >> ... >> 3. Wallet security. I'd like to get Matt's wallet encryption shipped >> soon, along with all or part of groffer's Multisign patch (#319 -- >> since that will enable the creation of trojan-resistant secure wallet >> solutions). > I was under the impression all that was left on the to-do for 0.4 was > wallet import/export testing and merge (and a few bug fixes like #453), > I agree #319 should be pulled sometime soon, but maybe for 0.4 just the > IsStandard parts in 0.4 as those need to get out first anyway? I'm not sure splitting the patch this way makes a big difference. The IsStandard part depends on the construction of the multisign script, which is what most of the patch does anyway. In other words, if upon further review the script construction needs to change, IsStandard will change. So a full review would be better. Also, with unit test coverage for both this feature and existing script.cpp code, I'm hoping that this patch is relatively low risk and actually pays down some existing test debt. -- Bobby Groff ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] Roadmap/schedules 2011-08-10 16:29 [Bitcoin-development] Roadmap/schedules Gavin Andresen 2011-08-10 16:59 ` Matt Corallo @ 2011-08-10 20:41 ` Jeff Garzik 2011-08-11 8:48 ` Matt Corallo 2011-08-11 18:20 ` Rick Wesson 2 siblings, 1 reply; 8+ messages in thread From: Jeff Garzik @ 2011-08-10 20:41 UTC (permalink / raw) To: Gavin Andresen; +Cc: Bitcoin Dev On Wed, Aug 10, 2011 at 12:29 PM, Gavin Andresen <gavinandresen@gmail.com> wrote: > 1. Where are we at with network health? What metrics should we be > using? Is there work to be done? > And meta-issue: can somebody volunteer to be the Bitcoin Network > Health Inspector to keep track of this? Seems like this would be a useful companion website + project. bitcoin/networkmon.git could be a central point for contributors to add various monitors and tests. Getting on-going network health information is critical to bitcoin's success. We need to know if incoming nodes are getting DDoS'd... > 2. We've got a chronic problem with new code causing CRITICAL_SECTION > deadlocks (see issue #453 for the latest). Detecting potential > deadlocks early should be done; longer term I think re-architecting to > be single-threaded/asio is probably the right thing to do. Agree > 3. Wallet security. I'd like to get Matt's wallet encryption shipped > soon, along with all or part of groffer's Multisign patch (#319 -- > since that will enable the creation of trojan-resistant secure wallet > solutions). IMO the only thing lacking is docs. There is no real admin guide describing how to prepare bitcoind installations for encryption; doc/README does not mention RPC encryptwallet at all, nor does it describe the various states your wallet may be in, when before and after encryptwallet has been run. The information is very general, and not adequate for a competent admin to be able to evaluate. It does not describe encryption method or other security parameters. It does not describe the specific technical relationship between the master key and other keys. > 4. Bug fixing. 44 bugs in the issue list, some of which I think are > already fixed. Anybody else want to volunteer to be BugKeeper? (job > would be: prioritize/assign bugs, make sure they get closed when > they're fixed). I have never seen an open source project with a successful Bug Czar, unless that is an actively compensated position. > 5. Testing. I don't have time to personally test every PULL request, > but if a pull involves more than trivial code changes I'm not going to > pull it unless it has been thoroughly tested. We had a very good rule > at a company I used to work for-- programmers were NOT allowed to be > the only ones to test their own code. Help finding money and/or people > for a dedicated "core bitcoin quality assurance team" is welcome. > More unit tests and automated testing is also certainly welcome. I think Q/A will naturally grow out of some sort of dedicated support organization, rather than have a dev fiat requirement. Testing like that is always desireable in the "I'd love it, if it were this way" vein, but not always realistic at all for open source projects. Especially with open source, time has shown that the best testing comes from the field, and we have the biggest test lab in the world: the Internet. So IMO focus less on roadblocks to publishing software, and more on widely distributed test software. For new features, simple "it works" test at a minimum seems reasonable, most of the time. But in open source the testing and such tends to happen in the periphery, by organizations and individuals with the incentive to focus on those issues. In my recent emails describing linux-next and a proposed "bitcoin-next", one attribute of linux-next is that it is run through automated tests on a daily basis, right after the merge is complete. It forms a useful layer on top of the primary linux project & tree. > If this was open source blogging software I'd be much less uptight > about testing and code review and bugs. But it's not, it is software > for handling money. Although I do agree, remember that it is the nature of open source that you always have less control than you'd like :) If the Iron Fist of Developer Justice squeezes too tightly, people will simply route around the bottleneck with their own trees and software releases. genjix is already pushing for his libbitcoin branch, for example. > Stuff I'd like to see in the release-after-next: > > fClient mode (download headers only, for faster initial startup; I've > started the work, talk to me if you want to take over) Nice to have, but I think it's just a short term fix. Long term, it will be SPV clients vs. full nodes, and bringing up a full node will be so costly that you'll just mirror the block database directly out of band, then boot the node at 99%+ block height. > Sipa's wallet and key export/import Yes. I was hoping to get that for 0.4. > Move from wxWidgets to qt for the GUI Not a big deal to me, I never use GUI :) > Un-hardcode fee handling (anybody already working on this?) Has anyone actually come up with a good idea to code? This is a widely acknowledged problem, sure, but where are the good solutions, even on paper? > Everything else I consider lower priority. But if it is important to > you, is important to other people (and non-controversial), you > thoroughly test it, and there's zero chance it introduces a security > vulnerability... then I'll have no objections to pulling it. > > Did I miss anything important? I'll create a Roadmap page on the > bitcoin wiki if there is general consensus about priorities. Parting shot: there is a reason Linus specifically says there is no roadmap for the kernel. That's because it is always driven by the community, and like a free market, the collective motivations and goals of the group. Projecting into the future, _and then attempting to stick to that roadmap_, will end in much frustration. Open source contributions are far more organic and unpredictable. Roadmaps work better in fiat organizations where developers do what they're paid/told to do :) -- Jeff Garzik exMULTI, Inc. jgarzik@exmulti.com ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] Roadmap/schedules 2011-08-10 20:41 ` Jeff Garzik @ 2011-08-11 8:48 ` Matt Corallo 0 siblings, 0 replies; 8+ messages in thread From: Matt Corallo @ 2011-08-11 8:48 UTC (permalink / raw) To: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 3524 bytes --] > > 3. Wallet security. I'd like to get Matt's wallet encryption shipped > > soon, along with all or part of groffer's Multisign patch (#319 -- > > since that will enable the creation of trojan-resistant secure wallet > > solutions). > > IMO the only thing lacking is docs. There is no real admin guide > describing how to prepare bitcoind installations for encryption; > doc/README does not mention RPC encryptwallet at all, nor does it > describe the various states your wallet may be in, when before and > after encryptwallet has been run. The information is very general, > and not adequate for a competent admin to be able to evaluate. It > does not describe encryption method or other security parameters. It > does not describe the specific technical relationship between the > master key and other keys. My fault, Ill write something up on the train back today. > > > 5. Testing. I don't have time to personally test every PULL request, > > but if a pull involves more than trivial code changes I'm not going to > > pull it unless it has been thoroughly tested. We had a very good rule > > at a company I used to work for-- programmers were NOT allowed to be > > the only ones to test their own code. Help finding money and/or people > > for a dedicated "core bitcoin quality assurance team" is welcome. > > More unit tests and automated testing is also certainly welcome. > > I think Q/A will naturally grow out of some sort of dedicated support > organization, rather than have a dev fiat requirement. Testing like > that is always desireable in the "I'd love it, if it were this way" > vein, but not always realistic at all for open source projects. > Especially with open source, time has shown that the best testing > comes from the field, and we have the biggest test lab in the world: > the Internet. So IMO focus less on roadblocks to publishing software, > and more on widely distributed test software. > > For new features, simple "it works" test at a minimum seems > reasonable, most of the time. But in open source the testing and such > tends to happen in the periphery, by organizations and individuals > with the incentive to focus on those issues. > > In my recent emails describing linux-next and a proposed > "bitcoin-next", one attribute of linux-next is that it is run through > automated tests on a daily basis, right after the merge is complete. > It forms a useful layer on top of the primary linux project & tree. Jenkins + a large enough test suite could do very nice automatic sanity testing IMHO...that is what it is designed for (even if not to automatically test pre-merge, but it could be adapted). Many pull requests build on Linux, but not on MinGW, OSX, etc so just that would be useful IMHO. > Not a big deal to me, I never use GUI :) > > > Un-hardcode fee handling (anybody already working on this?) > > Has anyone actually come up with a good idea to code? > > This is a widely acknowledged problem, sure, but where are the good > solutions, even on paper? Sipa's stuff is quite good IMHO, it still has some problems left to solve (like choosing minor details of the underlying priority algorithm) but aside from those, I think it could work. I'm not sure if sipa wants to just publish the stuff he did so far and let this list debate on the remaining details and eventual implementation, or if he wanted to come up with something complete before publishing, it up to him, but it is doable. Matt [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] Roadmap/schedules 2011-08-10 16:29 [Bitcoin-development] Roadmap/schedules Gavin Andresen 2011-08-10 16:59 ` Matt Corallo 2011-08-10 20:41 ` Jeff Garzik @ 2011-08-11 18:20 ` Rick Wesson 2 siblings, 0 replies; 8+ messages in thread From: Rick Wesson @ 2011-08-11 18:20 UTC (permalink / raw) To: Gavin Andresen; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 964 bytes --] On Wed, Aug 10, 2011 at 9:29 AM, Gavin Andresen <gavinandresen@gmail.com>wrote: > I've been wading through the pull requests and bug lists to figure out > a roadmap for the next few months. > > Here are the things on my priority list: > > 1. Where are we at with network health? What metrics should we be > using? Is there work to be done? > And meta-issue: can somebody volunteer to be the Bitcoin Network > Health Inspector to keep track of this? > > I'm already on it, leveraging bitcoinj to do the work. I've added async capabilities to bitcoinj so that I can peer with everything that will let me with the goal of publishing quality peer lists via the DNS. Once I can build some metrics off the network its a matter of creating the visualizations. I just started on this project last week. Happy to work with others on what a healty network looks like as well as best ways to communicate status. also need advise on how to not be an impolite peer. -rick [-- Attachment #2: Type: text/html, Size: 1357 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2011-08-11 18:20 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-08-10 16:29 [Bitcoin-development] Roadmap/schedules Gavin Andresen 2011-08-10 16:59 ` Matt Corallo 2011-08-10 18:57 ` Pieter Wuille 2011-08-11 11:56 ` Mike Hearn 2011-08-11 17:49 ` bgroff 2011-08-10 20:41 ` Jeff Garzik 2011-08-11 8:48 ` Matt Corallo 2011-08-11 18:20 ` Rick Wesson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox