Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of bluematt.me
	designates 208.79.240.5 as permitted sender)
	client-ip=208.79.240.5; envelope-from=bitcoin-list@bluematt.me;
	helo=smtpauth.rollernet.us; 
From: Matt Corallo <bitcoin-list@bluematt.me>
To: bitcoin-development@lists.sourceforge.net
In-Reply-To: <201107101442.43605.luke@dashjr.org>
References: <BANLkTinus7PWNLJi9rEvTtSB93hjLKhFpg@mail.gmail.com>
	<201107101442.43605.luke@dashjr.org>
Content-Type: multipart/signed; micalg="pgp-sha1";
	protocol="application/pgp-signature";
	boundary="=-je9n/RNZmB5NUWR6N4R7"
Date: Sun, 10 Jul 2011 21:12:12 +0200
Message-ID: <1310325132.2230.20.camel@Desktop666>
Mime-Version: 1.0
Subject: Re: [Bitcoin-development] Useful bitcoin patches...
Precedence: list


--=-je9n/RNZmB5NUWR6N4R7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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
> >=20
> > Includes several useful features that all the big pools have been
> > screaming for...  notably HTTP/1.1 keep-alive support.
>=20
> There seems to be a new version at:
> 	http://davids.webmaster.com/~davids/bitcoin-4diff.txt
> I haven't compared them yet.
>=20
> For the "3diff" version, I extracted and made proper git branches for eac=
h=20
> 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 woul=
d
>                      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.
>=20
> In addition, I also consider these branches valid candidates for merging:
>   coinbaser (popens a given command and reads coinbase outputs from stdou=
t)
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 f=
ees
>                 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 cu=
rrent
>           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.
>=20
> All available from git://gitorious.org/~Luke-Jr/bitcoin/luke-jr-bitcoin.g=
it
>=20
> -------------------------------------------------------------------------=
-----
> All of the data generated in your IT infrastructure is seriously valuable=
.
> Why? It contains a definitive record of application performance, security=
=20
> threats, fraudulent activity, and more. Splunk takes this data and makes=
=20
> 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


--=-je9n/RNZmB5NUWR6N4R7
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAABAgAGBQJOGfmCAAoJEBrh01BD4I5UDsgP/2EmwoT6UAho03P7djfNZBsb
qva2mFD1MaaURSFkXPulOnjemZrDcM9yskiKbM38r+yL3Ef9IMf9rzHoPo2wOv78
n6/+vLkXKFRKmD567ey7g7WyA5gtJWMMDrMwNeGiacn4RVnBhTYR+b0H0kfVuVby
XAru5H662o3DrPzAPirz27rasDf4ACn4mlrbLX0F1MPP4DlcG3Cxze9RGGCzTj3V
irID/J2dW1+anbVVWRaSPdCdkR7tFBA3WISSqVO74sP9qiXOmSTQjFnrgtAZ7RR3
UgmwjbdvQSKnBxAijWNgGkb29huGR9xX6pT0l3bMXftDWm+52IpGAIwBDtEZkYnE
31QwnWMFQb4Epml60cZXVhVsK/WSIhXvUYWbfZ9/1Pkgc+8fYgJW+zZa0v8kpJ25
hs0BnicTXHZVYLQIbXekQt+6uxXe7L/B0zQND5QMncfda83wSUn4FEWMYPwaKS7J
Aal/n73qR131MspvSuEYXdZRcFyDCllPiDmWJzO+4rpH6y03PpqfVx/u/NFg/BZp
1PVwXkSxdm6Kl1nGZZENGGlsbTSU7w0O1l5kLag87JAZLVAMmPQ4EQXD4e0cEHTb
tE4aCOr1TqDWt8EosvGA6lM1Sg7wjxG8yUWWT0Jys4T7/Js2+CFLtEjtQi+Gvunt
rSBOLGjdi2aPDfUEgab0
=a92K
-----END PGP SIGNATURE-----

--=-je9n/RNZmB5NUWR6N4R7--