From: Matt Corallo <bitcoin-list@bluematt•me>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Useful bitcoin patches...
Date: Sun, 10 Jul 2011 21:12:12 +0200 [thread overview]
Message-ID: <1310325132.2230.20.camel@Desktop666> (raw)
In-Reply-To: <201107101442.43605.luke@dashjr.org>
[-- Attachment #1: Type: text/plain, Size: 4117 bytes --]
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
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2011-07-10 19:12 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-01 3:23 Jeff Garzik
2011-07-01 16:03 ` Christian Decker
2011-07-01 16:23 ` Gregory Maxwell
2011-07-01 16:25 ` Matt Corallo
2011-07-01 18:59 ` Luke-Jr
2011-07-10 18:42 ` Luke-Jr
2011-07-10 19:12 ` Matt Corallo [this message]
2011-07-10 20:30 ` Luke-Jr
[not found] ` <1310335963.2230.29.camel@Desktop666>
[not found] ` <201107101846.09997.luke@dashjr.org>
2011-07-10 22:58 ` Matt Corallo
2011-08-04 20:29 ` Luke-Jr
2011-08-04 20:42 ` Luke-Jr
2011-08-04 23:43 ` Jeff Garzik
2011-08-05 3:01 ` Luke-Jr
2011-09-03 15:27 ` [Bitcoin-development] Last try: Fixes for 0.4 Luke-Jr
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1310325132.2230.20.camel@Desktop666 \
--to=bitcoin-list@bluematt$(echo .)me \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox