From: Mike Hearn <mike@plan99•net>
To: Andy Parkins <andyparkins@gmail•com>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Change to multiple executables?
Date: Thu, 11 Aug 2011 14:11:29 +0200 [thread overview]
Message-ID: <CANEZrP16NhS=4rqKcqBBqdDzd7XbDR_aXudBeq-_51ddmcLd_w@mail.gmail.com> (raw)
In-Reply-To: <201108102213.09632.andyparkins@gmail.com>
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.
next prev parent reply other threads:[~2011-08-11 12:11 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-10 9:36 John Smith
2011-08-10 10:14 ` Matt Corallo
2011-08-10 10:26 ` John Smith
2011-08-10 10:43 ` Pieter Wuille
[not found] ` <CAJNQ0ssWeU2vgR8XmCyGiZ3UHPv=zjLZEKVM=gqP0ozSC7Wmiw@mail.gmail.com>
2011-08-10 13:18 ` John Smith
2011-08-10 16:49 ` Gavin Andresen
2011-08-10 17:45 ` John Smith
2011-08-10 18:41 ` Gavin Andresen
2011-08-10 19:32 ` Andy Parkins
2011-08-10 19:57 ` Jeff Garzik
2011-08-10 21:13 ` Andy Parkins
2011-08-10 21:35 ` Jeff Garzik
2011-08-10 22:38 ` Andy Parkins
2011-08-11 3:20 ` Jeff Garzik
2011-08-11 5:47 ` Andy Parkins
2011-08-11 11:45 ` Joel Joonatan Kaartinen
2011-08-11 12:01 ` Christian Decker
2011-08-11 14:04 ` Andy Parkins
2011-08-11 12:11 ` Mike Hearn [this message]
2011-08-11 13:51 ` Andy Parkins
2011-08-11 12:19 ` John Smith
2011-08-11 13:08 ` Pieter Wuille
2011-08-10 18:43 ` Luke-Jr
2011-08-10 19:48 ` Jeff Garzik
2011-08-10 21:37 ` Jeff Garzik
2011-08-11 13:50 ` Pieter Wuille
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CANEZrP16NhS=4rqKcqBBqdDzd7XbDR_aXudBeq-_51ddmcLd_w@mail.gmail.com' \
--to=mike@plan99$(echo .)net \
--cc=andyparkins@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox