From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1QfzQb-0006db-T0 for bitcoin-development@lists.sourceforge.net; Sun, 10 Jul 2011 19:12:29 +0000 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; Received: from smtpauth.rollernet.us ([208.79.240.5]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1QfzQa-0001oO-OR for bitcoin-development@lists.sourceforge.net; Sun, 10 Jul 2011 19:12:29 +0000 Received: from smtpauth.rollernet.us (localhost [127.0.0.1]) by smtpauth.rollernet.us (Postfix) with ESMTP id 028B859400A for ; Sun, 10 Jul 2011 12:12:09 -0700 (PDT) Received: from mail.bluematt.me (unknown [IPv6:2001:470:9ff2:2:20c:29ff:fe16:f239]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: @bluematt.me) by smtpauth.rollernet.us (Postfix) with ESMTPSA for ; Sun, 10 Jul 2011 12:12:06 -0700 (PDT) Received: from [IPv6:2001:470:9ff2:1:2c0:caff:fe33:858b] (unknown [IPv6:2001:470:9ff2:1:2c0:caff:fe33:858b]) by mail.bluematt.me (Postfix) with ESMTPSA id 90A46B3C7 for ; Sun, 10 Jul 2011 21:12:11 +0200 (CEST) From: Matt Corallo To: bitcoin-development@lists.sourceforge.net In-Reply-To: <201107101442.43605.luke@dashjr.org> References: <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 X-Mailer: Evolution 2.32.2 X-Rollernet-Abuse: Processed by Roller Network Mail Services. Contact abuse@rollernet.us to report violations. Abuse policy: http://rollernet.us/abuse.php X-Rollernet-Submit: Submit ID 2a58.4e19f986.c456a.0 X-Spam-Score: -1.5 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1QfzQa-0001oO-OR Subject: Re: [Bitcoin-development] Useful bitcoin patches... X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 19:12:30 -0000 --=-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--