[Bitcoin-development] Change to multiple executables?

[Andy Parkins]

On Wednesday 10 August 2011 22:35:01 Jeff Garzik wrote:

> On Wed, Aug 10, 2011 at 5:13 PM, Andy Parkins <andyparkins at gmail.com> 
wrote:
> > Don't believe me?  Here's a list of ideas I've had "no, no, no"d so
> > far; not one of which would have any financial implication at all.
> >  Only some of which would break backward compatibility.
> 
> Breaking backwards compatibility means breaking people's access to
> their own money.

I wasn't actually giving a full explanation of how these things could be 
done, I was providing a list of "negatively received ideas"; imagine my 
surprise that they have been negatively received by you.

However... The version number field combined with the massive complexity of:

 if( blockNumber > 500000 )
   new_process();
 else
   old_process();

Would sort all of your "compatibility" objections out, and would give nodes 
time to upgrade.

> If you remove an "unnecessary" step that existing nodes expect, then
> the cost of disrupting monetary access seems higher than the value of
> that breaking change.

If only there were some way of sending different things to different nodes, 
based on some sort of version number field.

> >  - Remove verack, as it's completely unnecessary.
> 
> Compatibility issues?

  if( Version < VERSION_INTRODUCED )
    sendVerack();

My point is that you are a clever guy; you are perfectly capable of coming 
up with these answers, but you don't want to.  Nor does any other bitcoin 
developer.  The protocol is perfect and there is no way of changing it.

> >  - Query miners for pending transactions
> 
> I could see value in querying a bitcoind node over JSON-RPC for
> pending transactions... and by extension, supporting that as an RPC on
> various miners' pool servers.  Having a local dump of pending TX's
> would be useful.
> 
> As an optional bitcoin P2P protocol command, available to anyone,
> seems to negatively impact privacy.

Eh?  The transaction list is available on bitcoincharts.  If my node had 
been connected it would have received that list anyway when each one was 
broadcast.  What possible privacy loss could there be by making it possible 
to request it be repeated?

Again though: the detail isn't the point.  It's another half-hearted 
objection.

> >  - A way of requesting block bodies without headers (saving a lot of
> > traffic for a thin client upgrading)
> 
> Do you mean headers without bodies?  Gavin wants to work on
> headers-only, from what I've read, but others are welcome to
> contribute patches.

No; I mean being able to ask for just the block without the header.  The 
reason being that a thin client might request blocks on demand... it's 
already got the header and doesn't need it again.

The response: "it's only 80 bytes, blah, blah".  80*150000*N is a non-
trivial amount of traffic.

> >  - Double SHA-256 for a packet checksum?  Seriously?
> 
> Compatibility issues?

Only for the version message.  But it would be trivial to do both types of 
checksum on the version message, and if either is true to accept the version 
message.  After which the version is known and a much simpler checksum could 
be used for subsequent messages.  Eventually the network would be upgraded 
enough that the old way can be dropped.

Besides... hasn't TCP already got checksumming?  Let's just stop checking 
the checksum.  Or better still, stop calculating it and sending it.  Double 
SHA-256 on every single message on every single node to create four checksum 
bytes is an enormous waste of CPU.

> >  - Sequence number as part of TxIn instead of part of the whole
> > transaction
> 
> Compatibility issues?

If only there were a version field in the transaction and block structures.

Again; casual rejection.

> >  - Script parameters should be stored outside the script, and reference
> > by the script.  All that ridiculous filtering of the scripts in
> > OP_CHECKSIG would then go away.
> 
> Compatibility issues?

See above.

> >  - MSG_DOUBLESPEND... nope
> 
> Does consensus want this?

No, "consensus" doesn't.  I was simply listing all the ideas that got 
rejected out of hand.  The reason "consensus" doesn't think this one is 
necessary is because "we can already detect double spends by being widely 
connected"; ignoring the fact that a light or intermittently connected 
client would not be widely connected.  But that's okay because "eventually 
payment processors will appear".  Yep, my idea for fixing bitcoin is stupid 
because eventually someone else will mitigate it.

> >  - getblocks to accept MSG_TX and do something sensible
> 
> Link to elaboration of use case and need?

It was a few weeks ago; and it was an email from me about getblocks 
enhancements.  It was patronisingly laughed off as being something that all 
you newbie "alternative client" writers go through.

The use case is an on-demand thin client that wants to find the block that 
contains a particular transaction ID without downloading and indexing every 
single block in the chain.  Additionally, _I_ plan to separate the block 
chain and wallet executables, so much so that the wallet executable doesn't 
necessarily need a local blockchain node and relies on a partially trusted 
remote -- it still wants to be able to do spot checks on that remote, and 
confirm whatever it's told.  I would like to be able to do that using only 
commands that are in the official protocol; but I'm rapidly coming to accept 
that nothing I ask for will ever go in because there is no "use case".

> Well, one unfortunate current aspect of bitcoin is...  there seem to
> be problems aplenty right now :)

As with every project.

However, the protocol is being treated as if it is some kind of holy scroll, 
and must not be touched.  Bitcoin's ideas are revolutionary, its 
implementation is not.  If we started again today, it would be done 
differently.  Shouldn't we be trying to move the current protocol toward 
_that_ "done differently" as much as possible while bitcoin is still 
relatively small?  Rhetorical again... I know the answer, it's "no".

What exactly do the developers mean when they keep talking about bitcoin as 
"experimental"?  It seems to me they mean "incredibly conservative, with no 
changes for the rest of time".

> However demotivating it may be, keeping the current system running
> must take priority over new features.

Nothing I've suggested was to "stop the current system".  I'm not even 
asking for developers to prioritise my ideas.  I would just like mine, or 
anyone's ideas to not be instantly rejected out of hand.  I mean for 
goodness sake, even "splitting into multiple executables" has been stomped 
on in this very thread.  If something as trivial as that is "impossible" 
what chance is there that I would ever get "Change the 64-bit timestamp 
field to be microseconds since the epoch instead of seconds" in?

> I also heartily encourage others to do something I always want to do,
> but for lack of time:  work on the design for bitcoin v2 ("theme: any
> breaking change is acceptable, it is a new block chain")  There you
> may improve the protocol, get rid of the patent-cloudy ECDSA, use
> google's protocol buffers for encoding, make the proof-of-work
> algorithm memory-intensive, and other excellent, thoughtful
> breaking-change suggestions that have been made.

There is a popular idea that some other cryptocurrency will come along and 
displace bitcoin.  It's not going to happen.  Networking effects mean that 
there is no reason for people to change.  I can just see the queue around 
the block now for bitcoin.2; identical in function to bitcoin except it 
"doesn't use ECDSA and the it uses protocol buffers on the wire, and uses 
more memory".  Wow; there's a set of unique selling points.  I'll get signs 
made.

Let's be practical: technical-only improvements _have_ to be to bitcoin.1. 
Bitcoin's financial features are already complete or in progress; and it is 
financial features that would make people migrate to a competitor.  Nobody 
is going to move to bitcoin.v2 because the source code has better comments.

> Securing the integrity of money means that a lot of implementation
> decisions have been cemented into stone, however much we may
> personally dislike them.  Backwards compatibility is paramount.

I disagree about how set in stone these things are; but yeah; I've accepted 
that I'm on a loser.  My list was to demonstrate how negative the community 
is; and you have confirmed that for me admirably.  Bear that in mind the 
next time you're discussing the lack of manpower for bug fixes.



Andy

-- 
Dr Andy Parkins
andyparkins at gmail.com