It can be useful to frame such discussions in some conventional reference, thus here's my top of head summary of Bitcoin vs. the well established three main uses of money; ie. money as a...
Unit of account: Works fine but has issues due to the relative volatility of its value. Also, the complexity of accounting that can result from blockchain rollbacks and other Bitcoin-specific issues (new "invoices/receipts" scheme, etc...)
Store of value: Far too volatile at present to be much good; though it has been heading upwards, an individual party could easily destabilize the entire economy.
Medium of exchange: Excellent speed and reach, theoretically an improvement on existing systems due to a lack of chargebacks (finality). Realistically, increasingly complex to implement, particularly securely, and especially for real time goods and services. Unfortunately the market is relatively small and spotty right now, so any benefits here are largely negated for general commerce.
I can't help but feel the blockchain-tricks referenced by the author (in addition to the upcoming "invoices/receipts" mechanism) are nought but scope creep, best left out as violators of "do one thing and do it well", and in general a bad sign for Bitcoin's future.
That said, I am all for Bitcoin, I think it's great. It's just important to be realistic about its objective properties vs. other systems.
> I can't help but feel the blockchain-tricks referenced by the author (in addition to the upcoming "incoices/receipts" mechanism) are nought but scope creep, best left out as violators of "do one thing and do it well", and in general a bad sign for Bitcoin's future.
The bitcoin core developers have strict policy - they don't accept these additional features such as distributed DNS to the main chain. However alternative chains can be developed for these features.
I think that there can be a tremendous value for other kind of public, distributed, databases as well, not just currency.
Sharing the same network-resource with those 'tricks', official or not, is not going to come free. However, I was mostly referring to the recent "invoices/receipts" thing, which is being included. IMHO as an implementer of a Bitcoin-integrated system, that's not helpful, rather it's a PITA. But I am not framing any of my development with Bitcoin purely in mind, rather I am trying to bridge arbitrary settlement systems objectively. (If interested, see http://ifex-project.org/ for more info there.)
Worth mentioning what Gavin's response was to this proposal:
> RE: Mr. Stanish's suggestion to punt all of this and wait for a Grand Unified Solution:
> No, we have problems that need a solution right now. And, having written one (I was the lead author of the ISO/IEC 14772-1 international standard) I'm very pessimistic about your chances for anything like IFEX to actually be adopted.
Right, that was understandable if a little disappointing.
First, let us unravel the underlying assumption, which is false. When sharing a standards proposal, one isn't necessarily hoping everyone blindly adopts it as gospel but rather it provides some basis for reasonable research and/or provisional implementation within a given area that (hopefully) benefits from previous research and provides a basis for the community building upon the knowledge gained through implementation of systems in that area. The idea is that, given some common ground, people can move forward (ie. towards interoperability) while benefiting from each others' experience, and hopefully the better connected, more heterogeneous and stronger community that results.
In the particular case of IFEX, we have thus far been dealing with extremely basic areas that remain ignored by Bitcoin, ie. market identification, asset identification, and a viable decentralized internet-based financial endpoint identification scheme that provides familiar syntax, checksum protection against transposition errors, ease of integration with legacy financial systems, typo-squat-protection, and other key features. Also in the works but far more complex and slower moving are more holistic approaches to the transaction metadata/invoicing problem area than Bitcoin is apparently prepared to tackle.
The other thing that is notable in Gavin's response was the apparent notion that engineering decisions affecting the entire Bitcoin community's future are being made on a rapid basis because of perceived short-term needs. I am not sure this is necessarily a trend, but as an implementer it doesn't give me the greatest peace of mind.
Hmm I understood that the invoice/receipt stuff is not related to blockchain, just an additional protocol for these. However it might be questionable if this kind of stuff should be included in the main client.
I'd also add that I'm not sure bitcoin ever needs to be anything more than a medium of exchange. In digital commerce there is no reason not to denote in one currency, exchange in another while marking to a third.
Chargebacks, speed, etc all get translated to transaction costs. Lower transaction costs by an order of magnitude or two and all sorts of things become possible.
You miss one thing, though: the block chain has real costs. If you want another block chain for the document timestamping, for instance, then you'll have to convince people to mine that block chain. Inevitably, it'll be just another currency not very different from Bitcoin. And since both have almost the same objective properties and Bitcoin is already more valuable, nobody will spend CPU on your currency. So you'll end up using the Bitcoin block chain anyway.
This is exactly what is happening to Namecoin: initially, it was just another blockchain, but very soon people realized that nobody is willing to spend any CPU/GPU time on Namecoin if Bitcoin is worth more (no matter how much more). So Namecoin guys proposed "merged mining", which is just a fancy way to reuse proof-of-work done on Bitcoin block chain without asking people to devote any resources specifically to Namecoin.
I'm not sure bitcoin ever needs to be anything more than a medium of exchange
My sentiments exactly. The other stuff will sort itself out. (Historical example: GUI client in codebase!) IMHO what integrators really need is a fixed target, and what they have now is spiralling complexity and ill-defined scope... ie. very suboptimal.
These things are not "scope creep" because (for instance) timestamping can be done on top of the existing block chain - no modifications to the protocol needed. You simply pay for your transactions, miners include them and no one cares if you interpret them in some fancy manner.
It's still scope creep. The scope of implementing a real, user-facing bitcoin client is much greater than it was when the project started. Bitcoin reimplementors or those building tooling need to either support everything or risk fracturing an already fragmenting community.
There is no risk of fracturing. I'm not suggesting changing the protocol, or UI of the existing clients. You may use your client to send/receive money, no problem. I may build another client which will allow you to do manipulations with transactions without affecting anyone at all. E.g. timestamping is just a funny way to create an address and send back-and-forth the money. No one else needs to be concerned about it except for the people who wish to verify existence of a document. Money was not destroyed and it did not change its shape. This is not fragmentation, it is "building on top of" in a very compatible manner.
Unit of account: Works fine but has issues due to the relative volatility of its value. Also, the complexity of accounting that can result from blockchain rollbacks and other Bitcoin-specific issues (new "invoices/receipts" scheme, etc...)
Store of value: Far too volatile at present to be much good; though it has been heading upwards, an individual party could easily destabilize the entire economy.
Medium of exchange: Excellent speed and reach, theoretically an improvement on existing systems due to a lack of chargebacks (finality). Realistically, increasingly complex to implement, particularly securely, and especially for real time goods and services. Unfortunately the market is relatively small and spotty right now, so any benefits here are largely negated for general commerce.
I can't help but feel the blockchain-tricks referenced by the author (in addition to the upcoming "invoices/receipts" mechanism) are nought but scope creep, best left out as violators of "do one thing and do it well", and in general a bad sign for Bitcoin's future.
That said, I am all for Bitcoin, I think it's great. It's just important to be realistic about its objective properties vs. other systems.