* [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: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: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 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