Andy Parkins [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 improvements to the Bitcoin protocol, but they are met with resistance due to concerns about backward compatibility and disrupting monetary access.
📝 Original message: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
🗒️ Summary of this message: A developer suggests improvements to the Bitcoin protocol, but they are met with resistance due to concerns about backward compatibility and disrupting monetary access.
📝 Original message: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