Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1QrU6p-0008Kv-Ka for bitcoin-development@lists.sourceforge.net; Thu, 11 Aug 2011 12:11:35 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.220.175 as permitted sender) client-ip=209.85.220.175; envelope-from=mh.in.england@gmail.com; helo=mail-vx0-f175.google.com; Received: from mail-vx0-f175.google.com ([209.85.220.175]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1QrU6o-0008DG-MV for bitcoin-development@lists.sourceforge.net; Thu, 11 Aug 2011 12:11:35 +0000 Received: by vxj14 with SMTP id 14so2315218vxj.34 for ; Thu, 11 Aug 2011 05:11:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.30.47 with SMTP id p15mr8034243vdh.130.1313064689258; Thu, 11 Aug 2011 05:11:29 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.52.164.165 with HTTP; Thu, 11 Aug 2011 05:11:29 -0700 (PDT) In-Reply-To: <201108102213.09632.andyparkins@gmail.com> References: <201108102032.00373.andyparkins@gmail.com> <201108102213.09632.andyparkins@gmail.com> Date: Thu, 11 Aug 2011 14:11:29 +0200 X-Google-Sender-Auth: KuRZbBmFGjsdrhCYwUSTe_x09NY Message-ID: From: Mike Hearn To: Andy Parkins Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) 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 (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 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.8 AWL AWL: From: address is in the auto white-list X-Headers-End: 1QrU6o-0008DG-MV 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 12:11:35 -0000 I don't think Gavin misunderstands how open source works at all. It's completely normal for project maintainers to say "no" more often than they say "yes". When I worked on open source for a living this was part of the natural flow of things. It's important to understand that ideas which receive "maybe" or "yes but later" or "no unless you convince me" or "perhaps in a different way" are not being shot down. These answers are requests for more work to be done. You *cannot* get emotional about open source contributions and any veteran will tell you this. Open source maintainers cannot and do not say yes to every patch or idea that is proposed. I would be very worried if Gavin did. Now let's review these ideas: > Don't believe me? =C2=A0Here's a list of ideas > > =C2=A0- Extra bits in the service field of the version message to allow n= odes > =C2=A0 to indicate if they are mining; if they are willing to be seed nod= es; > =C2=A0 if they relay transactions; if they want relayed transactions. I think the concept is reasonable but service flags might not be the best way to do it, for instance, asking for a filtered transaction feed is useful for lightweight clients so you'd want more precision that can be fit into service bits. > =C2=A0- getblocks in reverse chronological order so clients can start up = quicker > =C2=A0 while downloading the blocks in the backround. =C2=A0Ironically I = was told > =C2=A0 "patches welcome" by someone who didn't reject this one instantly. I already told you this won't help startup time because you have to connect blocks together in sequence. You can't build up the block chain backwards unless you don't care about validation at all. > =C2=A0- Query miners for pending transactions Or just have them send an inv containing them after connect. I don't remember this one being "shot down". > =C2=A0- Application version separate from client version You mean separate from protocol version, right? > =C2=A0- A way of requesting block bodies without headers (saving a lot of= traffic > =C2=A0 for a thin client upgrading) The cost/benefit ratio of this one isn't obvious at all. The resource requirements for running a full node are large enough that re-downloading 80 bytes per block is the least of your worries if you're upgrading. > =C2=A0- Double SHA-256 for a packet checksum? =C2=A0Seriously? Feel free to submit a patch to disable checksum validation and see if Gavin accepts it. It needs to still be calculated at send time for other implementations. > =C2=A0- Sequence number as part of TxIn instead of part of the whole tran= saction Sequence numbers are already part of the tx inputs. Or do you mean they should be part of the whole transaction? If the latter then this is indeed an idea that will be shot down, it's deliberate that seqnums are part of the txinputs and it needs to be that way for contracts. It can't be changed without forking the protocol anyway. > Every single one of those has been shot down by one or more of the main > developers. =C2=A0I'm not a genius, and not arrogant enough to assume tha= t > everything I say is right, but _nothing_? =C2=A0Really? =C2=A0There is no= problem that > one of the above addresses? Some of your proposals address problems that need to be solved, but it's not clear that way is the right way to solve them. Others reflect either lack of understanding of the system or the fact that you don't value backwards compatibility whereas other people do.