[Bitcoin-development] Change to multiple executables?

[Andy Parkins]

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 
can just declare that people should work on bug fixes and not features was a 
misunderstanding.  People work on open source (at least at first) to get a 
feature they want.  They aren't just going to show up and cry "command me 
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 
accepted out of hand, certainly as I haven't even turned up with patches.  And 
you are absolutely correct that that would be worrying if it were so.  What I 
object to is no guidance is offered to get the suggester what they want, a 
"you could have this if you did it like this", or "perhaps if you explained a 
bit more".  It's just "no, your idea is based on your weak understanding of 
bitcoin," perhaps I'm being overly arrogant, but I think I understand it a lot 
more than you presume I do.

I do try not to get emotional about these things; and email is not the best 
medium for conveying level of distress -- I'm certainly not banging on my 
keyboard, close to a heart attack.  My motivation is only that I would like to 
see bitcoin do well, and I do see that the treatment of potential new people, 
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 
point; and I'm not that interested in fighting to get them into a project that 
doesn't want them.  I'll just play with my bricks over in the corner if that's 
okay?  I offered the list as a demonstration that ideas don't get constructive 
help as to how progress can be made on them (i.e. how to make them 
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
> > 
> >  - 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.
> 
> 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 
existed.  Personally I would prefer an additional "capabilities" request with 
a variable number of ASCII strings in it, each indicating a capability, and if 
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.
> 
> 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 of 
the problem I'm trying to get across -- I see things differently; but rather 
than try and either fix my misunderstanding or see what I'm trying to achieve, 
it's rejected.

I've already got it well on its way to being implemented is how I know you are 
wrong.  It's perfectly possible to validate backwards because you are 
constructing a coherent chain based on an unvalidated start point.  You then 
request the parent block and either (a) you finally reach the genesis block, 
you have reached a hard-coded valid point and the entire chain is therefore 
instantly validated or (b) you have a new start block, floating but validated 
to be part of the chain, if not absolutely validated.  Further, with some 
checkpoints hard coded you don't even need to reach the genesis block to get a 
validated chain.  The body of a block obviously can't be faked because of the 
Merkle hash.

And finally... who says I care about validation?  Perhaps I plan a situation 
where I implicitly trust the peer I'm talking to (which is exactly what I do 
plan).  "There are more things in heaven and earth, Horatio, than are dreamt 
of in your philosophy".

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

I was told it had severe privacy implications; and you told me that it would 
be better to wait for some sort of filtering system that was planned, which 
I'd not heard of.  I admit it wasn't exactly clear to me how what you 
described helped with my suggestion.  Your suggestion here is a good 
alternative; but wouldn't it waste bandwidth?  After all a receving node has 
no idea whether I have been connected to another node for 24 hours before I 
connect to it, and hence wouldn't need the list.

> >  - Application version separate from client version
> 
> You mean separate from protocol version, right?

Yep.  I can well imagine that when alternative clients start appearing, some 
will have bugs.  It will be very handy to either work around those bugs or 
simply deny version 1.4.17 of "Andy's Sexy Bitcoin Client" from connecting.  
Even just for monitoring network state it's useful.  There is already talk, I 
see, of establishing how much of the network runs each released bitcoin 
version.

> >  - A way of requesting block bodies without headers (saving a lot of
> > traffic 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.

The benefit I'm aiming at is to imagine a thin client that has done a fast 
startup and only downloaded the headers.  Then, it has a finite number of 
addresses it's interested in and wants to grab only the relevant bodies from 
the full chain.  Or, fast startup is to grab all the headers, and then slowly 
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 
"well I don't see what use that is" responses.

> >  - Double SHA-256 for a packet checksum?  Seriously?
> 
> 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, 
that I feel certain you are being faceitous, knowing full well that it 
wouldn't be accepted.  I'm trying to look five years in the future.  I'm not 
suggesting it be turned off now -- that's impossible and I'm not an idiot.  
I'm trying to think of what the protocol should be and have a way of moving to 
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
> 
> 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 
transaction I've already submitted.  I can't replace just one of the inputs, I 
have to replace the whole transaction.  It's therefore the transaction that 
should have the sequence number.  A signed transaction received with a higher 
sequence number should displace a lower one.

I'm happy to accept that I have missed the use of the current sequence numbers 
in contracts.  (To be fair, the wiki says "Transaction version as defined by 
the sender. Intended for "replacement" of transactions when information is 
updated before inclusion into a block.")

Perhaps putting it in TxIn was because no one thought of having 
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?
> 
> 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 
used as an excuse to freeze the protocol forever.  There are version fields in 
there, sensibly so; they should be used to fix problems.   As I said a few 
times, the incompatible changes don't have to activate straight away, they can 
be delayed using the block number.  Make it a block number four years away if 
you want, but the sooner those changes go in (whatever they may be), the more 
likely it is you'll get the majority of the network to change over.  And once 
the alternative clients start appearing, the opportunity is gone -- if it's 
hard to get one client to change, imagine how hard it will be to change five.

As I said above though, I don't want these fights.  I know full well that what 
I want is not what you all want as far as client ideas go.  I only started 
this response because I thought Gavin's "we don't want new developers for new 
features, we want bug fixes" was a bit of a foolish thing to say.




Andy
-- 
Dr Andy Parkins
andyparkins at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110811/18c8c85d/attachment.sig>