Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1QrVfH-0001JG-1y for bitcoin-development@lists.sourceforge.net; Thu, 11 Aug 2011 13:51:15 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.82.175 as permitted sender) client-ip=74.125.82.175; envelope-from=andyparkins@gmail.com; helo=mail-wy0-f175.google.com; Received: from mail-wy0-f175.google.com ([74.125.82.175]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1QrVfF-0002sq-Vb for bitcoin-development@lists.sourceforge.net; Thu, 11 Aug 2011 13:51:15 +0000 Received: by mail-wy0-f175.google.com with SMTP id 19so2152606wyf.34 for ; Thu, 11 Aug 2011 06:51:13 -0700 (PDT) Received: by 10.227.176.65 with SMTP id bd1mr7989744wbb.78.1313070673529; Thu, 11 Aug 2011 06:51:13 -0700 (PDT) Received: from dvr.localnet (mail.360visiontechnology.com [92.42.121.178]) by mx.google.com with ESMTPS id et16sm1566316wbb.53.2011.08.11.06.51.10 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 11 Aug 2011 06:51:11 -0700 (PDT) From: Andy Parkins To: Mike Hearn Date: Thu, 11 Aug 2011 14:51:04 +0100 User-Agent: KMail/1.13.6 (Linux/2.6.38-2-686; KDE/4.6.3; i686; ; ) References: <201108102213.09632.andyparkins@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1564652.Xm4cfOt2Zi"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201108111451.09296.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: 1QrVfF-0002sq-Vb 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 13:51:15 -0000 --nextPart1564652.Xm4cfOt2Zi Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2011 August 11 Thursday, Mike Hearn wrote: > 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. That wasn't the part I said he didn't understand. It was assuming that you= =20 can just declare that people should work on bug fixes and not features was = a=20 misunderstanding. People work on open source (at least at first) to get a= =20 feature they want. They aren't just going to show up and cry "command me=20 lord". > 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. I don't expect them to; as I said, I'm not after everything I say being=20 accepted out of hand, certainly as I haven't even turned up with patches. = And=20 you are absolutely correct that that would be worrying if it were so. What= I=20 object to is no guidance is offered to get the suggester what they want, a= =20 "you could have this if you did it like this", or "perhaps if you explained= a=20 bit more". It's just "no, your idea is based on your weak understanding of= =20 bitcoin," perhaps I'm being overly arrogant, but I think I understand it a = lot=20 more than you presume I do. I do try not to get emotional about these things; and email is not the best= =20 medium for conveying level of distress -- I'm certainly not banging on my=20 keyboard, close to a heart attack. My motivation is only that I would like= to=20 see bitcoin do well, and I do see that the treatment of potential new peopl= e,=20 while not offensive (nobody says f*ck off), is not encouraging. > Now let's review these ideas: Honestly you needn't have bothered. They've been reviewed to death at this= =20 point; and I'm not that interested in fighting to get them into a project t= hat=20 doesn't want them. I'll just play with my bricks over in the corner if tha= t's=20 okay? I offered the list as a demonstration that ideas don't get construct= ive=20 help as to how progress can be made on them (i.e. how to make them=20 acceptable), they just get rejected. Anyway; as you've put the time in, I'll do the same and respond. > > Don't believe me? Here's a list of ideas > >=20 > > - 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. >=20 > 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. The service bits just seemed like the "bitcoin way" as the field already=20 existed. Personally I would prefer an additional "capabilities" request wi= th=20 a variable number of ASCII strings in it, each indicating a capability, and= if=20 that's good with all of you -- excellent. > > - 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. >=20 > 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. I know you "told me this", but I think you are wrong. This is an example o= f=20 the problem I'm trying to get across -- I see things differently; but rathe= r=20 than try and either fix my misunderstanding or see what I'm trying to achie= ve,=20 it's rejected. I've already got it well on its way to being implemented is how I know you = are=20 wrong. It's perfectly possible to validate backwards because you are=20 constructing a coherent chain based on an unvalidated start point. You the= n=20 request the parent block and either (a) you finally reach the genesis block= ,=20 you have reached a hard-coded valid point and the entire chain is therefore= =20 instantly validated or (b) you have a new start block, floating but validat= ed=20 to be part of the chain, if not absolutely validated. Further, with some=20 checkpoints hard coded you don't even need to reach the genesis block to ge= t a=20 validated chain. The body of a block obviously can't be faked because of t= he=20 Merkle hash. And finally... who says I care about validation? Perhaps I plan a situatio= n=20 where I implicitly trust the peer I'm talking to (which is exactly what I d= o=20 plan). "There are more things in heaven and earth, Horatio, than are dream= t=20 of in your philosophy". > > - Query miners for pending transactions >=20 > Or just have them send an inv containing them after connect. I don't > remember this one being "shot down". I was told it had severe privacy implications; and you told me that it woul= d=20 be better to wait for some sort of filtering system that was planned, which= =20 I'd not heard of. I admit it wasn't exactly clear to me how what you=20 described helped with my suggestion. Your suggestion here is a good=20 alternative; but wouldn't it waste bandwidth? After all a receving node ha= s=20 no idea whether I have been connected to another node for 24 hours before I= =20 connect to it, and hence wouldn't need the list. > > - Application version separate from client version >=20 > You mean separate from protocol version, right? Yep. I can well imagine that when alternative clients start appearing, som= e=20 will have bugs. It will be very handy to either work around those bugs or= =20 simply deny version 1.4.17 of "Andy's Sexy Bitcoin Client" from connecting.= =20 Even just for monitoring network state it's useful. There is already talk,= I=20 see, of establishing how much of the network runs each released bitcoin=20 version. > > - A way of requesting block bodies without headers (saving a lot of > > traffic for a thin client upgrading) >=20 > 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. The benefit I'm aiming at is to imagine a thin client that has done a fast= =20 startup and only downloaded the headers. Then, it has a finite number of=20 addresses it's interested in and wants to grab only the relevant bodies fro= m=20 the full chain. Or, fast startup is to grab all the headers, and then slow= ly=20 grab the transactions from the blocks. The cost is if( !bodyOnly ) sendHeader(); sendBody(); I can't say I'm that invested in it; but it was another one for the list of= =20 "well I don't see what use that is" responses. > > - Double SHA-256 for a packet checksum? Seriously? >=20 > 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. I do feel free to write any patch I like. It's such a trivial patch though= ,=20 that I feel certain you are being faceitous, knowing full well that it=20 wouldn't be accepted. I'm trying to look five years in the future. I'm no= t=20 suggesting it be turned off now -- that's impossible and I'm not an idiot. = =20 I'm trying to think of what the protocol should be and have a way of moving= to=20 that. The patch that is needed then is the one that makes the change gracefully. > > - Sequence number as part of TxIn instead of part of the whole > > transaction >=20 > 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. The sequence number (and perhaps I've misunderstood) allows me to replace a= =20 transaction I've already submitted. I can't replace just one of the inputs= , I=20 have to replace the whole transaction. It's therefore the transaction that= =20 should have the sequence number. A signed transaction received with a high= er=20 sequence number should displace a lower one. I'm happy to accept that I have missed the use of the current sequence numb= ers=20 in contracts. (To be fair, the wiki says "Transaction version as defined b= y=20 the sender. Intended for "replacement" of transactions when information is= =20 updated before inclusion into a block.") Perhaps putting it in TxIn was because no one thought of having=20 OP_PUSH_SEQUENCENUMBER as a script operator. > > 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? >=20 > 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. Of the above, only one could be lack of understanding (txIn). As to not valuing backward compatibility -- I certainly do. That shouldn't= be=20 used as an excuse to freeze the protocol forever. There are version fields= in=20 there, sensibly so; they should be used to fix problems. As I said a few= =20 times, the incompatible changes don't have to activate straight away, they = can=20 be delayed using the block number. Make it a block number four years away = if=20 you want, but the sooner those changes go in (whatever they may be), the mo= re=20 likely it is you'll get the majority of the network to change over. And on= ce=20 the alternative clients start appearing, the opportunity is gone -- if it's= =20 hard to get one client to change, imagine how hard it will be to change fiv= e. As I said above though, I don't want these fights. I know full well that w= hat=20 I want is not what you all want as far as client ideas go. I only started= =20 this response because I thought Gavin's "we don't want new developers for n= ew=20 features, we want bug fixes" was a bit of a foolish thing to say. Andy =2D-=20 Dr Andy Parkins andyparkins@gmail.com --nextPart1564652.Xm4cfOt2Zi Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk5D3kkACgkQwQJ9gE9xL22A7QCgsjSJBGBnydNQX967YFXp0Y8T FckAn2nCIXW6ALm5Xl4ACETR6sV5qdsw =MoAT -----END PGP SIGNATURE----- --nextPart1564652.Xm4cfOt2Zi--