From: Jeff Garzik <jgarzik@exmulti•com>
To: Andy Parkins <andyparkins@gmail•com>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Change to multiple executables?
Date: Wed, 10 Aug 2011 17:35:01 -0400 [thread overview]
Message-ID: <CA+8xBpd9QCPt50E0VohfP8THwzf34UuT8gMtCE=gXZw1Sf0BBQ@mail.gmail.com> (raw)
In-Reply-To: <201108102213.09632.andyparkins@gmail.com>
On Wed, Aug 10, 2011 at 5:13 PM, Andy Parkins <andyparkins@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.
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.
> - 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.
My own 'supernode' proposal also includes using the nServices bits.
There's nothing fundamentally incompatible or wrong about that.
> - Remove verack, as it's completely unnecessary.
Compatibility issues?
> - 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.
> - Application version separate from client version
Consensus has already approved this one, AFAIK.
> - 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.
> - Double SHA-256 for a packet checksum? Seriously?
Compatibility issues?
> - Sequence number as part of TxIn instead of part of the whole transaction
Compatibility issues?
> - 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?
> - MSG_DOUBLESPEND... nope
Does consensus want this?
> - getblocks to accept MSG_TX and do something sensible
Link to elaboration of use case and need?
> You can imagine then that when I read moans about there not being enough new
> developers fixing bugs, that I am unsurprised and unsympathetic. I like
> bitcoin enough to hover on this list; and offer a view of your world from a
> potential developer who was chased away.
Well, one unfortunate current aspect of bitcoin is... there seem to
be problems aplenty right now :)
However demotivating it may be, keeping the current system running
must take priority over new features.
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.
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.
--
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti•com
next prev parent reply other threads:[~2011-08-10 21:35 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 [this message]
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
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='CA+8xBpd9QCPt50E0VohfP8THwzf34UuT8gMtCE=gXZw1Sf0BBQ@mail.gmail.com' \
--to=jgarzik@exmulti$(echo .)com \
--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