diff options
| author | Andy Parkins <andyparkins@gmail.com> | 2011-08-11 14:51:04 +0100 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2011-08-11 13:51:15 +0000 |
| commit | 0cec098399155cb7f7dc9c8ac7ba4c9b6c42990f (patch) | |
| tree | 36f7926c9da653d0466970f4a9067ba62386d601 | |
| parent | cf8957a8f87cb67753c1226ec6cb75969797a029 (diff) | |
| download | pi-bitcoindev-0cec098399155cb7f7dc9c8ac7ba4c9b6c42990f.tar.gz pi-bitcoindev-0cec098399155cb7f7dc9c8ac7ba4c9b6c42990f.zip | |
Re: [Bitcoin-development] Change to multiple executables?
| -rw-r--r-- | f5/b3e6353b901d28e6d9a9839ad0dbcf2611442c | 364 |
1 files changed, 364 insertions, 0 deletions
diff --git a/f5/b3e6353b901d28e6d9a9839ad0dbcf2611442c b/f5/b3e6353b901d28e6d9a9839ad0dbcf2611442c new file mode 100644 index 000000000..518235832 --- /dev/null +++ b/f5/b3e6353b901d28e6d9a9839ad0dbcf2611442c @@ -0,0 +1,364 @@ +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 <andyparkins@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>; + 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 <andyparkins@gmail.com> +To: Mike Hearn <mike@plan99.net> +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: <CAJNQ0sudgAnr9hMUMt8grSNTYswunyNnp25Uzw5t17ucxTBoGA@mail.gmail.com> + <201108102213.09632.andyparkins@gmail.com> + <CANEZrP16NhS=4rqKcqBBqdDzd7XbDR_aXudBeq-_51ddmcLd_w@mail.gmail.com> +In-Reply-To: <CANEZrP16NhS=4rqKcqBBqdDzd7XbDR_aXudBeq-_51ddmcLd_w@mail.gmail.com> +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: <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: 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-- + + |