Topic: The MOST Important Change to Bitcoin - page 2. (Read 17180 times)

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.

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.


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.


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.


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.

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.

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.

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.

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.

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!

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.

What's the one thing you would change?

So far as the long-term economics of Bitcoin are concerned, that is exactly right. However, consider this: the value of any currency has two components, its value as a commodity and its marketability. Right now the marketability of BTC is practically nil--there is very little which you can actually buy with BTC, or sell for BTC, without first converting to some other currency. As a commodity, bitcoins are rather weak, having no direct use and no legal mandate (taxes, legal tender). That pretty much leaves just their novelty value, most of which comes from the (mostly inaccurate) perception of getting something from nothing via minting.

If everyone were to lose interest in minting new bitcoins right now, can you honestly say that Bitcoin would remain a viable digital currency? I think it rather more likely that people would lose interest. Perhaps we will eventually reach a point where the market for bitcoins is self-sustaining, but we're not there yet. In the interim, we have to keep potential BTC users interested, which means small, frequent payouts which pander to the average person's attention span.

Regarding the main topic of this thread, my main concerns/annoyances with Bitcoin are as follows:

• Transactions are dependent on generating new blocks, and the design of Bitcoin has the generation of new blocks eventually becoming non-cost-effective. What happens when the (fixed) minimum work required to generate a new block becomes more than the block itself is worth? No more transactions?
• Versioning will probably become an issue at some point. Very few changes to the Bitcoin design can be made backward-compatible with existing clients. Any breaking change will split the block chain unless everyone manages to upgrade at the same time. Some kind of auto-update system might be in order, and/or a mechanism to mark the formal transition to a new ruleset in the block chain. It is important that Bitcoin transactions continue to work between all users, without any inadvertent barriers resulting from bifurcated block chains.
• It would be nice if the difficult-adjustment algorithm ran more often. The limits could be something like 80-110% difficulty per estimated day (144 blocks) rather than 25-400% per fortnight (2016 blocks), allowing a gradual adjustment over the same period. Under the current system a 4x increase in difficulty immediately followed by a return to previous capacity wouldn't be corrected for up to two months, during which transactions would take 4x as long to be confirmed. With the shorter period and 80-110% limits the same increase in difficulty would begin to be corrected within four days, with complete correction within six adjustment periods (under two weeks). Note that there is no inherent limit on how fast the difficulty can increase in real time; it depends on how much capacity was temporarily added. If we're hitting the limits (either variant) then the minimum rate of increase is about 4x per 3-4 days.
• Related to the previous point: The limits should not be symmetric, as they are now, because upward difficulty adjustments naturally happen more frequently than downward adjustments. I'm not convinced there should be any lower boundary to the adjustment at all, apart from the absolute minimum work required per block. Limiting the downward adjustment rate creates an opportunity for someone to inhibit timely transaction confirmation for an extended period.
• Could we please avoid creating dependencies on unstable development releases of third-party libraries (e.g. wxWidgets 2.9)? The statically-linked binaries help, but only if you don't intend to make any changes.
• Has anyone else noticed that the log.* files in the database subdirectory appear to grow without bound so long as the program is running? Mine were over 160 MB recently, at which point I restarted Bitcoin and the files disappeared.

I still think that the money supply itself should remain fixed and that credit markets should satisfy the demand for money; however, drawing the coin increase to a slowdown rather than a complete cutoff may be a solution for the slight monetary deflation that will occur from the lost coins.

I came up with at least a partial solution to get this to work earlier, and I think it could work too, but it wouldn't be trivial to implement:

https://bitcointalksearch.org/topic/m.2686

The problem right now is the network latency, and the fact that if the bitcoin block generation rate increased substantially that there would start to be some significant collisions between generated blocks and degrade the network.  My suggestion here was to have multiple chains off of chains that could help improve the scalability of the network.

Regardless, if the number of users significantly ramps up to be 100x or 1000x the current user base, even these "reduced difficulty" blocks would still be pretty dang difficult to generate.


I'd have to agree that generating more coin blocks but having those blocks worth less would be useful, and the notion of keeping the rate of increase in bitcoin blocks constant (instead of being halved every 4 years) isn't necessarily going to destroy the currency either.  What is needed is predictability here instead of chaos.

Considering that the once every 4 years change still has yet to happen, going to a constant increase in the coin supply over time isn't necessarily going to change at least current behavior toward the coins.  It also resolves the "lost coin" issue so far as any lost coins would eventually be "recovered" so far as simply being found money through new generation and IMHO would offer some stability against deflation.

I am saying that minting is not overly important, rather than saying that minting should be turned off.

In terms of coin value: A growing Bitcoin economy (number of user making transactions), with no monetary inflation == A static Bitcoin economy (number of user making transactions), with monetary deflation.

Minting is a great way of distributing the coins as the user base grows, but it could be done less arbitrarily. I don't mind the lottery system, but the number of coins in a mined block or the difficulty could be more flexible to demand.

Anyway, I don't want to debate this at length on this thread, as it will take it OT (and we have several threads about this already!); I just wanted to point out my agreement with the OP about this.

Why not switch off minting altogether then, with that logic?

I have no problems with Bitcoin's economic model (remember: money is not like other commodities) nor the decreasing rate of minting, but it would have been cool if done in less of a 'lottery' fashion and distributed equally among the users. It would be great if my laptop could generate even 0.1 BTC a day, for example.

We should be encouraging wealth creation so that people can spend their bitcoins on, not focusing on minting coins.

^^^

+ complete server/client seperation, and an independent way of storing BTCs for the purposes of importing and exporting. I've also read that if someone has 50 BTCs, exports them, and then spends 1 BTC, then ALL 50 BTCs backed up are no longer valid. The backup tool should therefore ideally have a good way of visualizing this.

The big problem for me is that the minting rate doesn't adjust with the size of the Bitcoin economy (ie. the swarm size). I have a feeling that if this isn't changed, the project may run out of steam.

While it may annoy old users a bit that they can't create as many coins, new users are waiting weeks to mint any coins. It is unlikely that Bitcoins will become established if new users aren't given a decent shot at their own minting (especially when the user base should be growing rapidly). Users who discovered Bitcoins early will still have amassed more coins than new entrants, even without the difficulty changing.

The software is very impressive, but the minting rules really need to be looked at again. Self minting is such a good idea for distributing new coins, but IMO it needs some basic economic theory applying to it, rather than a relatively arbitrary setting.

Front end and back end seaprate to allow for different clients to be written without rewriting the backend stuff is the one single most important change for me.