On Sun, 2011-07-10 at 14:42 -0400, Luke-Jr wrote:
> On Thursday, June 30, 2011 11:23:56 PM Jeff Garzik wrote:
> > This was posted to IRC:
> > http://davids.webmaster.com/~davids/bitcoin-3diff.txt
> > 
> > Includes several useful features that all the big pools have been
> > screaming for...  notably HTTP/1.1 keep-alive support.
> 
> There seems to be a new version at:
> 	http://davids.webmaster.com/~davids/bitcoin-4diff.txt
> I haven't compared them yet.
> 
> For the "3diff" version, I extracted and made proper git branches for each 
> logical part:
>   hub_mode
No, no, no, no, no.  This has been discussed several times and provides
little to no advantage for miners and has the potential to severely harm
the network.
>   threaded_rpc
>   \-- rpc_keepalive (depends on threaded_rpc, or a single connection would
>                      keep the JSON-RPC interface locked up)
Some form of patch that implements these does need to be pulled soon, I
would say 0.4.1 or maybe sooner.
>   signal_blk_notify (generic version of -pollpidfile, with a bugfix)
Seems to be a feature for such a minority that until the codebase is
cleaned a ton we shouldn't add features for small minorities.  We have
seen even one or two line patches cause regressions so I, personally,
think we should really focus on cleaning the codebase (CWallet was a
great start) and then add all these minority features once the backend
stuff is really clean and efficient.
>   bugfix_CreateThread_leak
Yes, should be in for 0.4 and I think there is a pull request for it.
>   getwork_dedupe (original branch for my bugfix)
I think there is already a pull request, which should be merged for 0.4
IMO.
> 
> In addition, I also consider these branches valid candidates for merging:
>   coinbaser (popens a given command and reads coinbase outputs from stdout)
Seems like you are the only one who would benifit here, as noone else
but eligius changes coinbase output to a random set.
>   gitignore (ignore some common misc files)
>   minfee_modes (internal function changes to allow specifying different fees
>                 for relay, send, or accept-in-block)
We don't need something that just generically changes the functions to
allow whatever fee you want, we need something more generalized to allow
more custom settings, not just blind accept if fee is x per kb or
something.  Sipa has suggested various things that should allow for more
fee control by the users while still preventing users from sending
transactions that lock their coins in limbo.
>   \-- eligius_relay (relay lower fees only Eligius will accept)
>       \-- eligius_sendfee (send lower fees only Eligius will accept)
No, and no.  Just because you are willing to accept lower fees doesn't
mean the incentives are right to prevent DDoS.  The fees aren't there to
support the miners (not for a while, at least) they are there to prevent
stupid users from DDoSing and just generally wasting everyone else's
resources for no reason.
>   txinfo (adds entries to getinfo for transactions accepted for relaying,
>           transactions accepted for the current block-in-progress, and current
>           block-in-progress size)
These are cool numbers to know, but I'm not sure if they have any real
uses making them just useless feature creep.
>   bitcoinuri (compliant support for all bitcoin: URIs)
URI support would be nice.
> 
> All available from git://gitorious.org/~Luke-Jr/bitcoin/luke-jr-bitcoin.git
> 
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security 
> threats, fraudulent activity, and more. Splunk takes this data and makes 
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development