Mike Hearn [ARCHIVE] on Nostr: 📅 Original date posted:2011-08-11 🗒️ Summary of this message: Open source ...

📅 Original date posted:2011-08-11
🗒️ Summary of this message: Open source maintainers often say "no" more than "yes". Ideas that receive "maybe" or "yes but later" are requests for more work. Some proposals address problems, but may not be the best solution.
📝 Original message: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.

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.

Now let's review these ideas:

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

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

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

>  - Application version separate from client version

You mean separate from protocol version, right?

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

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

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

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