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; 
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>
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Change to multiple executables?
Precedence: list

--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--