diff options
| author | Andy Parkins <andyparkins@gmail.com> | 2011-08-10 22:13:09 +0100 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2011-08-10 21:13:21 +0000 |
| commit | 80816321ce39da979f8f6969ca16db1b16f93f80 (patch) | |
| tree | 7f2f61c0a8d646da265c6b1ccd69c583488036b6 /ec/68fec0f3e8842add59fa602958f641b375ea76 | |
| parent | d6e8c05384c717b056bbeeae6fc121ea4e1fdd09 (diff) | |
| download | pi-bitcoindev-80816321ce39da979f8f6969ca16db1b16f93f80.tar.gz pi-bitcoindev-80816321ce39da979f8f6969ca16db1b16f93f80.zip | |
Re: [Bitcoin-development] Change to multiple executables?
Diffstat (limited to 'ec/68fec0f3e8842add59fa602958f641b375ea76')
| -rw-r--r-- | ec/68fec0f3e8842add59fa602958f641b375ea76 | 160 |
1 files changed, 160 insertions, 0 deletions
diff --git a/ec/68fec0f3e8842add59fa602958f641b375ea76 b/ec/68fec0f3e8842add59fa602958f641b375ea76 new file mode 100644 index 000000000..532894b23 --- /dev/null +++ b/ec/68fec0f3e8842add59fa602958f641b375ea76 @@ -0,0 +1,160 @@ +Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] + helo=mx.sourceforge.net) + by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <andyparkins@gmail.com>) id 1QrG5Z-0007BK-Re + for bitcoin-development@lists.sourceforge.net; + Wed, 10 Aug 2011 21:13:21 +0000 +Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com + designates 209.85.161.47 as permitted sender) + client-ip=209.85.161.47; envelope-from=andyparkins@gmail.com; + helo=mail-fx0-f47.google.com; +Received: from mail-fx0-f47.google.com ([209.85.161.47]) + by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1QrG5Y-0000af-Rl + for bitcoin-development@lists.sourceforge.net; + Wed, 10 Aug 2011 21:13:21 +0000 +Received: by fxg11 with SMTP id 11so2093584fxg.34 + for <bitcoin-development@lists.sourceforge.net>; + Wed, 10 Aug 2011 14:13:14 -0700 (PDT) +Received: by 10.223.102.68 with SMTP id f4mr1775912fao.117.1313010794581; + Wed, 10 Aug 2011 14:13:14 -0700 (PDT) +Received: from grissom.localnet ([91.84.15.31]) + by mx.google.com with ESMTPS id c5sm67612fah.30.2011.08.10.14.13.12 + (version=TLSv1/SSLv3 cipher=OTHER); + Wed, 10 Aug 2011 14:13:13 -0700 (PDT) +From: Andy Parkins <andyparkins@gmail.com> +To: Jeff Garzik <jgarzik@exmulti.com> +Date: Wed, 10 Aug 2011 22:13:09 +0100 +User-Agent: KMail/1.13.6 (Linux/2.6.39-2-686-pae; KDE/4.6.4; i686; ; ) +References: <CAJNQ0sudgAnr9hMUMt8grSNTYswunyNnp25Uzw5t17ucxTBoGA@mail.gmail.com> + <201108102032.00373.andyparkins@gmail.com> + <CA+8xBpdCtYQkKwQZzZY2PsHm=+BrhD4TdoKqoAVoa7R0W9YkRw@mail.gmail.com> +In-Reply-To: <CA+8xBpdCtYQkKwQZzZY2PsHm=+BrhD4TdoKqoAVoa7R0W9YkRw@mail.gmail.com> +MIME-Version: 1.0 +Content-Type: Text/Plain; + charset="iso-8859-1" +Content-Transfer-Encoding: 7bit +Message-Id: <201108102213.09632.andyparkins@gmail.com> +X-Spam-Score: -1.6 (-) +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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider + (andyparkins[at]gmail.com) + -0.0 SPF_PASS SPF: sender matches SPF record + -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from + author's domain + 0.1 DKIM_SIGNED Message has a DKIM or DK signature, + not necessarily valid + -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature + 0.0 AWL AWL: From: address is in the auto white-list +X-Headers-End: 1QrG5Y-0000af-Rl +Cc: bitcoin-development@lists.sourceforge.net +Subject: Re: [Bitcoin-development] Change to multiple executables? +X-BeenThere: bitcoin-development@lists.sourceforge.net +X-Mailman-Version: 2.1.9 +Precedence: list +List-Id: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> +X-List-Received-Date: Wed, 10 Aug 2011 21:13:21 -0000 + +On Wednesday 10 August 2011 20:57:29 Jeff Garzik wrote: + +> > People get itches and they want to scratch them. They aren't paid, so +> > they don't necessarilly want to turn up and be told which part they +> > _should_ be working on. The choice is not "bug fix that Gavin wants" +> > or "new feature that New Developer wants", it is "New Feature" or +> > nothing. +> +> This is true -- though there is value to having a list of "things we +> think people should focus on" for the motivated, and for new people +> interested in tackling a project, but not sure what project to tackle. + +My objection is not that such a list exists, it is that potential new +developers are, essentially, shouted down unless they are working on that +list. I cannot imagine that many new developers arrive under those +circumstances. + +> A centrally managed development branch on bitcoin/bitcoin.git is not +> the way to do it, however. See the description of linux-next, in my +> previous email, for a more distributed method which can easily be +> layered on top of the existing bitcoin dev structure by any motivated +> volunteer(s). + +I don't think I said anything about it being centrally managed. git lets us +store these branches anywhere of course. The fact is that such a branch +exists somewhere. + +> Think distributed. :) The community does not need Linus's help +> (linux-next) or Gavin's help (bitcoin-next) to do this. linux-next + +I didn't say that it required anybody's help; but it does require a bit of +willingess on the part of the master-branch-owning developers to import from +that branch. + +> became so widely used and useful that Linus requires almost all +> changes to be first staged in linux-next. + +They key thing with linux-next is that work done on it _does_ make it into +the kernel. Tell me -- how many feature branches for bitcoin are just +sitting as a pull request on github, and are now months old and abandoned +out of disgust by their original authors? Here's another question: why is +it that so many projects have "specially compiled" versions of bitcoin? +Rhetorical question... it's because the official client doesn't do what they +need, and won't accept their patches to add it (even optionally). + +I've only been watching this list for a few weeks (since the forum turned +into an echo chamber); but I'm completely depressed by the agressive +rejections of every new idea anyone raises. + +Don't believe me? Here's a list of ideas I've had "no, no, no"d so far; not +one of which would have any financial implication at all. Only some of +which would break backward compatibility. + + - Extra bits in the service field of the version message to allow nodes + to indicate if they are mining; if they are willing to be seed nodes; + if they relay transactions; if they want relayed transactions. + - getblocks in reverse chronological order so clients can start up quicker + while downloading the blocks in the backround. Ironically I was told + "patches welcome" by someone who didn't reject this one instantly. + - Remove verack, as it's completely unnecessary. + - Query miners for pending transactions + - Application version separate from client version + - A way of requesting block bodies without headers (saving a lot of traffic + for a thin client upgrading) + - Double SHA-256 for a packet checksum? Seriously? + - Sequence number as part of TxIn instead of part of the whole transaction + - Script parameters should be stored outside the script, and reference by + the script. All that ridiculous filtering of the scripts in OP_CHECKSIG + would then go away. + - MSG_DOUBLESPEND... nope + - getblocks to accept MSG_TX and do something sensible + +Every single one of those has been shot down by one or more of the main +developers. I'm not a genius, and not arrogant enough to assume that +everything I say is right, but _nothing_? Really? There is no problem that +one of the above addresses? + +Given that, what do I do? Hang around and get battered some more, or go +away to my own little corner and work on my own implementation? + +You can imagine then that when I read moans about there not being enough new +developers fixing bugs, that I am unsurprised and unsympathetic. I like +bitcoin enough to hover on this list; and offer a view of your world from a +potential developer who was chased away. + + + +Andy +-- +Dr Andy Parkins +andyparkins@gmail.com + + |