The MOST Important Change to Bitcoin

[nybble41]

...

What's the one thing you would change?

Short answer: versioning (point two).

Long answer: The first point is my greatest long-term concern, but since fixing it depends on being able to change the protocol without breaking the network I suppose I'd have to start with the versioning issue. After that, or perhaps for the same release, I'd probably work on the interval between difficulty adjustments, which is a fairly trivial change. With proper protocol versioning in place there would be no need to worry about the transaction issue for quite some time.

On the other hand, if you're serious about only allowing one change (ever), then versioning would be rather pointless and I'd probably fix the long-term blocks vs. transactions issue to keep the transactions going.

[NewLibertyStandard]

...

What's the one thing you would change?

Short answer: versioning (point two).

Long answer: The first point is my greatest long-term concern, but since fixing it depends on being able to change the protocol without breaking the network I suppose I'd have to start with the versioning issue. After that, or perhaps for the same release, I'd probably work on the interval between difficulty adjustments, which is a fairly trivial change. With proper protocol versioning in place there would be no need to worry about the transaction issue for quite some time.

On the other hand, if you're serious about only allowing one change (ever), then versioning would be rather pointless and I'd probably fix the long-term blocks vs. transactions issue to keep the transactions going.

No, one change for all time is not assumed. Versioning sounds like version numbering to me, but anyway, if you were to go back and improve the ability of Bitcoin to be more backwards compatible with then future changes, then yeah, that sure would make it more flexible. Good choice!

[nybble41]

Versioning sounds like version numbering to me, but anyway, if you were to go back and improve the ability of Bitcoin to be more backwards compatible with then future changes, then yeah, that sure would make it more flexible. Good choice!

I realize there are already version numbers. However, as things stand older clients will just reject anything with a new version number, which results in splitting the block list. There is no protocol in place to allow new clients and old clients to coexist (which would be rather impressive--the changeable parts would have to be moved to some Turing-complete language that could be downloaded at runtime) or, perhaps more practically, to allow older clients to detect when a new change is being introduced and insist on an upgrade rather than proceeding under the old rules.

What I had in mind was something like this:
- The client is distributed with the developers' public keys.
- When a breaking release is introduced, the developers first add a special transaction to the block list warning about the upgrade.
- The client validates the signature of this warning and, if valid, passes it on to the user.
- The new client is released with support for both the old rules and the new ones. (This is already necessary, as the old blocks must be validated.)
- The client's highest supported protocol version goes into each transaction.
- After a fixed number of block are produced after the warning with no client protocol versions less than the announced version, the upgrade is committed and the new rules take effect. (Blocks with older protocols are accepted, but do not count toward the goal.)
- At this point new transactions with obsolete protocol versions will be rejected, and older clients will cease to operate rather than attempting to start their own independent block chain. Obviously this can be worked around by modifying the code, but there is little benefit in doing so. Anyone who wants to continue using Bitcoin will be driven to upgrade instead.

This way, rather than starting and abandoning a bunch of mini-block-chains as different users upgrade at different times, there would be a window during which upgrades could take place while maintaining compatibility, after which all the upgraded clients would switch to the new rules at the same time. The critical changes are (a) the upgrade notice transaction and associated key distribution & validation; (b) a protocol version field in the transaction structure (already present?); and (c) kill-switch code in the current client to detect a committed upgrade based on the upgrade notice and subsequent blocks.

[FreeMoney]

Versioning sounds like version numbering to me, but anyway, if you were to go back and improve the ability of Bitcoin to be more backwards compatible with then future changes, then yeah, that sure would make it more flexible. Good choice!

I realize there are already version numbers. However, as things stand older clients will just reject anything with a new version number, which results in splitting the block list. There is no protocol in place to allow new clients and old clients to coexist (which would be rather impressive--the changeable parts would have to be moved to some Turing-complete language that could be downloaded at runtime) or, perhaps more practically, to allow older clients to detect when a new change is being introduced and insist on an upgrade rather than proceeding under the old rules.

What I had in mind was something like this:
- The client is distributed with the developers' public keys.
- When a breaking release is introduced, the developers first add a special transaction to the block list warning about the upgrade.
- The client validates the signature of this warning and, if valid, passes it on to the user.
- The new client is released with support for both the old rules and the new ones. (This is already necessary, as the old blocks must be validated.)
- The client's highest supported protocol version goes into each transaction.
- After a fixed number of block are produced after the warning with no client protocol versions less than the announced version, the upgrade is committed and the new rules take effect. (Blocks with older protocols are accepted, but do not count toward the goal.)
- At this point new transactions with obsolete protocol versions will be rejected, and older clients will cease to operate rather than attempting to start their own independent block chain. Obviously this can be worked around by modifying the code, but there is little benefit in doing so. Anyone who wants to continue using Bitcoin will be driven to upgrade instead.

This way, rather than starting and abandoning a bunch of mini-block-chains as different users upgrade at different times, there would be a window during which upgrades could take place while maintaining compatibility, after which all the upgraded clients would switch to the new rules at the same time. The critical changes are (a) the upgrade notice transaction and associated key distribution & validation; (b) a protocol version field in the transaction structure (already present?); and (c) kill-switch code in the current client to detect a committed upgrade based on the upgrade notice and subsequent blocks.

This goes fundamentally against the decentralized nature of the project. Absolutely no one is special except as people choose them to be. Anyone can distribute any version, breaking or not, that they wish.

[FreeMoney]

Anyone can distribute any version, breaking or not, that they wish.

Absolutely true. If people who propose changes can phrase the changes in terms of "a client" rather than "the client", that will help to filter out impossible proposed changes.

Having said that, there are ways that breaking changes could be addressed. A client could be programmed with dual behavior. It keeps using the old behavior unless it sees that more than a certain percentage of clients on the network have signalled that they can support some new behavior and are willing to switch to it.

At that point, clients which support the scheme will switch to the new behavior, and everyone using other clients will need to change their software if they want to keep playing with the majority.

The devil is in the details, of course, because different clients have different peers and will see different percentages of those peers being able to support the new behavior. You could have two thresholds. A client could switch to the new behaviour if it saw (say) 85% of nodes capable of supporting the new behaviour, AND was receiving new-behaviour transactions. If it saw (say) 95% of nodes capable of supporting the new behaviour, it would switch unilaterally even if it had not seen a new-behaviour transaction yet (someone's gotta get the ball rolling).

Personally, I think it's going to be years, if ever, before a breaking change is needed. To address the topic at hand, the MOST important change to Bitcoin isn't any technical change, it's just to gain more users who actively trade, so that Bitcoin doesn't fade away.

Nice.

Is it possible to put any kind of message in a block or does it have to be 'clean' or 'perfect' in a sense? I ask because that's more important than the number of nodes you talk with being willing to change. If you see that 80 of the 100 most recent blocks were created by clients ready to change then you could be confident and switch.

[RHorning]

Versioning sounds like version numbering to me, but anyway, if you were to go back and improve the ability of Bitcoin to be more backwards compatible with then future changes, then yeah, that sure would make it more flexible. Good choice!

I realize there are already version numbers. However, as things stand older clients will just reject anything with a new version number, which results in splitting the block list. There is no protocol in place to allow new clients and old clients to coexist (which would be rather impressive--the changeable parts would have to be moved to some Turing-complete language that could be downloaded at runtime) or, perhaps more practically, to allow older clients to detect when a new change is being introduced and insist on an upgrade rather than proceeding under the old rules.

Please don't make a mistake at presuming that the client version has anything to do with the protocol version.  We are talking two completely different issues here that can (and I think should) be separated if you are talking about bitcoins.

It is precisely for this reason that I have been called for a second and perhaps more full re-implementation of the protocol, as it would be healthier for Bitcoins for a whole bunch of reasons, and to concentrate on the protocol independently from any sort of central control over the CVS repository for the reference implementation of Bitcoins.

It is also possible to make protocols that are forward compatible to changes that may be made in the future.  It does take anticipating what those changes might be or at least providing "hooks" to be able to allow for some future changes, such as allowing for extended precision numerical values on transactions that has been discussed earlier.  It is also important that such future changes can't destroy the fundamental principles that are being sought after for the protocol as well... so in this case it is a particularly fine line to cross if any sort of protocol change will happen.

Even though real money is now being used for Bitcoins, I do think it would be useful for at least the present users to know this is very much experimental and there may be some unstoppable flaw in the current protocol that may require a "reboot" with a more secure protocol.  I've seen that happen with other peer-to-peer networks where a major upgrade forced a major segmentation between the "old" clients and the "new" clients.  Hopefully the change would only be done in such a way that could preserve the Bitcoins that have already been generated in some fashion, but that may not always be a guarantee either.

[nybble41]

- The client is distributed with the developers' public keys.

This goes fundamentally against the decentralized nature of the project. Absolutely no one is special except as people choose them to be. Anyone can distribute any version, breaking or not, that they wish.

The point was not to prevent alternate versions (it's still open source, anyone can change the accepted keys). The point was simply to ensure that only those who released the user's client could trigger an update, as opposed to any node in the network.

Please don't make a mistake at presuming that the client version has anything to do with the protocol version.  We are talking two completely different issues here that can (and I think should) be separated if you are talking about bitcoins.

I was referring exclusively to the protocol version supported by a given client. The version/release of the client software in use is, as you say, irrelevant in this context.

A client could be programmed with dual behavior. It keeps using the old behavior unless it sees that more than a certain percentage of clients on the network have signalled that they can support some new behavior and are willing to switch to it. ... The devil is in the details, of course, because different clients have different peers and will see different percentages of those peers being able to support the new behavior.

That would be why I suggested keying the changeover to the transactions in the block list, which are common to all clients, rather than the versions reported by one's peers.

Personally, I think it's going to be years, if ever, before a breaking change is needed.

I wouldn't be so sure about that. Most of the changes I've seen proposed are breaking changes--for example, anything which affects the difficulty calculation must be common to all the clients. As I pointed out, the period of the current calculation leaves Bitcoin vulnerable to certain attacks against the transaction confirmation rate. We might not care that the minting rate is cut by 3/4 for months on end, but taking 4x longer to complete a transaction is a fairly big deal.

[FreeMoney]

  We might not care that the minting rate is cut by 3/4 for months on end, but taking 4x longer to complete a transaction is a fairly big deal.

You mean it will be slow for months because it was difficulty was ramped up and then someone bailed? In order fall to 25% wouldn't 75% of the computing power have to be pulled? If someone can do that they control the project anyway.

[nybble41]

We might not care that the minting rate is cut by 3/4 for months on end, but taking 4x longer to complete a transaction is a fairly big deal.

You mean it will be slow for months because it was difficulty was ramped up and then someone bailed? In order fall to 25% wouldn't 75% of the computing power have to be pulled? If someone can do that they control the project anyway.

Yes, the complete attack would require adding 3x the current CPU capacity for 3-4 days, long enough for the difficulty to increase by 4x, and then removing it. It's not necessary that all that CPU capacity be under the control of one person, however. A sudden, temporary surge of interest from many unrelated individuals could do the same thing (think "slashdotting"). So the attack could happen even without anyone taking control of the project.

[NewLibertyStandard]

A breaking change could be made without breaking the network by setting the change to not take affect until a certain block six months or more in the future. That would give most everyone plenty of time to upgrade their client. The few that didn't notice, would notice still notice sometime after the change and would still be able to upgrade and retain bitcoins obtained before the change.

[eyu100]

I would make the rate of coin generation constant rather than decreasing, so that there would not be constant deflation as people lose coins.  If one assumes that coins are lost at a constant proportional rate (-kC, where C = the number of coins and t = time), and coins are generated at a constant (unchanging) rate (G), then there is some circulation C for which G - kC = 0 (in other words, the circulation stays constant).  That level is C = G/k.  So if we want the circulation to stabilize at C_f, then G should be set to kC_f.  For example, if 5% of coins are lost each year, then k is equal to -ln(0.95) per year = 0.0513 per year (a weird unit).  If we want C_f to be a trillion bitcoins, then roughly 51.3 bitcoins per year (a bit more than 5% of 1 trillion bitcoins) should be created.

[Red]

I would make the rate of coin generation constant ...

You might try reading in the economics forum. Lot's of competing suggestions in there.

Beware, it's a hornet's nest!

[martin]

It is also possible to make protocols that are forward compatible to changes that may be made in the future.

Making forward compatible protocols is something I've been trying to tackle for my Computer science final year project, the solution I came up with was protocol buffers, it just struck me that they're perfect for bitcoin for a whole load of reasons:

-> Small (suitable for entworking and hard disk storage)
-> Very fast
-> Implementations in loads of languages (So writing new clients become a lot simpler)
-> Forwards compatible (indeed, this is most of the point of protocol buffers)
-> Dead simple to use in code
-> Support for custom fields in packets (so, for example, a new client could start embedding messages in packets, and all the other clients would silently ignore this field)

So I guess the most important change to bitcoin for me is to start using protocol buffers for networking and saving the wallet file

[lachesis]

It is also possible to make protocols that are forward compatible to changes that may be made in the future.

Making forward compatible protocols is something I've been trying to tackle for my Computer science final year project, the solution I came up with was protocol buffers, it just struck me that they're perfect for bitcoin for a whole load of reasons:

-> Small (suitable for entworking and hard disk storage)
-> Very fast
-> Implementations in loads of languages (So writing new clients become a lot simpler)
-> Forwards compatible (indeed, this is most of the point of protocol buffers)
-> Dead simple to use in code
-> Support for custom fields in packets (so, for example, a new client could start embedding messages in packets, and all the other clients would silently ignore this field)

So I guess the most important change to bitcoin for me is to start using protocol buffers for networking and saving the wallet file

Wow, that's awesome. That seems a lot like what the SCRIPT part of transactions was designed to address, but this seems like a better way...

[martin]

I don't know much about the scripts, but if you're right and this is what scripts were designed to address then I'd push for protocol buffers, they're designed and built by google so (no offence to satoshi) they're probably better

Also, the fact that protocol buffer are supported by lots of other languages would make building clients (without generation) in other languages (with protobuffer support) absolutely trivial.

Edit:: Changing the packet structure to use protocol buffers would be difficult to do, although I would still highly recommend it. However, changing the structure of the local files to use protocol buffers isn't a breaking change, which means that it would be an excellent idea to do in my opinion (smaller, faster, neater code, easier to parse in other languages etc etc)

[Babylon]

Google maintains the rights to code they have designed.  Incorporating it would require data reporting to google.  Generally not a good thing.

[martin]

Nope, the standard implementation of protocol buffers is under the new BSD license. Furthermore, there are loads of versions of protocol buffers in many different languages all published under a variety of licenses. Some people have even written entire probuf parsers in 100 lines, so if we really wanted bitcoin could have its own implementation of a protobuf parser and that code is entirely ours. However, the standard implementation is just fine

[RHorning]

It is also possible to make protocols that are forward compatible to changes that may be made in the future.

Making forward compatible protocols is something I've been trying to tackle for my Computer science final year project, the solution I came up with was protocol buffers, it just struck me that they're perfect for bitcoin for a whole load of reasons:

Generally a compact custom format works better in terms of bandwidth and disk usage, but I do see some advantages for something like this.  I am curious about how this works for forward compatibility where a new field or some aspect is added that wasn't accounted for in an earlier specification.  It does become a big deal, and I'll admit that XML and similar kinds of data protocols tend not to break as easily compared to rigid custom protocols.

Another problem with something of this nature is that you have to stay within the framework of the specification language or however else this data structure is organized, and it doesn't anticipate things like encryption and compression.

While there certainly are many applications that could use a tool of this nature, I'm not entirely sure that Bitcoins is necessarily "a perfect application" of this particular tool.  Considering the nature of this project and anticipated scales of operation, overhead and abstraction can be quite costly for bandwidth even if it is just a couple of bytes and a few extra machine cycles.  That is something which matters.

[martin]

I don't understand what you'resaying about speed, protocol buffers were designed by google to satisfy three requirements:

1) Forwards compatibility (Google changes their protocols all the time, protocol buffers allow them to do this with ease)
2) Speed (every millisecond matters, and protocol buffers are around the fastest serialisation method out there, the documentations says "are 20 to 100 times faster [than XML]")
3) Size (Protocol buffers are tiny, the documentation says "are 3 to 10 times smaller [than XML]")

Protocol buffers were designed almost for the exact problem bitcoin is facing.

Addendum: If you want to know how they work, have fun

[nimnul]

ASN.1