Jeff Garzik [ARCHIVE] on Nostr: 📅 Original date posted:2011-08-10 🗒️ Summary of this message: A developer ...
📅 Original date posted:2011-08-10
🗒️ Summary of this message: A developer suggests several ideas for improving Bitcoin, but emphasizes the importance of maintaining backward compatibility to avoid disrupting monetary access.
📝 Original message: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.
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 at exmulti.com
🗒️ Summary of this message: A developer suggests several ideas for improving Bitcoin, but emphasizes the importance of maintaining backward compatibility to avoid disrupting monetary access.
📝 Original message: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.
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 at exmulti.com