justusranvier
Legendary
Offline
Activity: 1400
Merit: 1013
|
|
March 27, 2013, 01:55:57 AM |
|
Yes, people do use and invest in Bitcoin because of the brand name and the brand mystique that was built around it. Just look at their reactions to any alternate cryptocurrency that is nearly identical from the technical point of view. What you call "brand name and the brand mystique" I would call "first mover advantage, network effect, and human capital".
|
|
|
|
totaleclipseofthebank (OP)
|
|
March 27, 2013, 02:01:46 AM |
|
Yes, people do use and invest in Bitcoin because of the brand name and the brand mystique that was built around it. Just look at their reactions to any alternate cryptocurrency that is nearly identical from the technical point of view. What you call "brand name and the brand mystique" I would call "first mover advantage, network effect, and human capital". focusing on "brand names" you might as well just use US dollars since they are the king in that department. bitcoin is cool because its a superior technology. your business school paradigms just aren't going to be all that useful here, sorry.
|
|
|
|
2112
Legendary
Offline
Activity: 2128
Merit: 1073
|
|
March 27, 2013, 03:41:37 AM |
|
Oh well, I've tried. I've really tried to point that each coin has at least two sides, and that includes Bitcoin. Time will show what had really mattered: exact standards, network effects, first mover advantage, human capital and other presumed highfalutin concepts. Or just this:
|
|
|
|
TierNolan
Legendary
Offline
Activity: 1232
Merit: 1104
|
|
March 27, 2013, 09:54:38 AM |
|
I agree, but what I think TierNolan was getting at, was just that the spec should count all blocks prior to (say) 250,000 as valid, even if some of them would not actually be under the new spec, i.e. they should be 'grandfathered in' even if the new spec would otherwise reject them. But the spec shouldn't allow future blocks to have the same 'deformities'.
Right. Most of the block chain is presumably pretty clean already. Basically the spec would be a sub-set of what is already acceptable to the current reference clients and also a (small) list of exceptions so that the current block chain is spec compliant. I don't think you need to specify a switch date exactly. The number of "non-standard" elements in the block chain would be finite anyway. Ideally, the spec writers would get the agreement from > 50% of the miners to reject transactions and blocks that violate the draft (at least while the draft is in progress). The exceptions could be a list of scripts that are defined as valid, even though they wouldn't be according to the spec.
|
1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
|
|
|
r.willis
Jr. Member
Offline
Activity: 42
Merit: 11
|
|
March 27, 2013, 08:42:11 PM |
|
No need to enumerate "exceptions" from spec. Apply spec only from certain block number, use checkpoint hash to set all old blocks as valid. New spec-compliant do not need to to verify this old blocks, but only correctly parse them.
|
|
|
|
aantonop
Full Member
Offline
Activity: 196
Merit: 116
Entrepreneur, coder, hacker, pundit, humanist.
|
|
April 01, 2013, 12:21:43 AM |
|
Exactly as r.willis said.
Ideally, we would also implement a very small and lightweight protocol validation engine in Lisp and use that as reference implementation the for the protocol, and for interoperability, quality and eventually security certification.
At some point, "Talks Bitcoin Protocol" needs to be a verifiable statement, as with other protocol implementations. That way, a developer can test and validate that their client implementation passes all interop tests and speaks official "bitcoin".
Just like you can do W3C validation, or test an SSL client for protocol completeness, we should be able to test a bitcoin protocol node against something.
|
|
|
|
TierNolan
Legendary
Offline
Activity: 1232
Merit: 1104
|
|
April 01, 2013, 11:12:24 PM |
|
I think there also needs to be a "core" spec, which describes how blocks are validated and then a separate network spec.
|
1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
|
|
|
doobadoo
|
|
April 02, 2013, 03:24:57 AM |
|
I"m sure no one wants to here this, but maybe we need to start again. Accept bitcoin as a grand experiment. We've learned a lot. Think thru all these issues: block size issues, pruning, bitdust, gpu mining/asics. Build a new client, with a firm protocol. Better, faster, smarter. Then launch it all over again. Of course all the people techinically capable and involved all have a substantial stake in THIS bitcoin blockchain.
Part of me is hoping that satoshi is out there somewhere. Maybe working on this new, better cryptocurrency. And when he returns and publishes the signed code on the alt-currency board every one will dump btc and jump on the new better one.
I think he is the only one with the technical prowess, and the passion to see the idea REALLY work to the point where he may be willing take all his founders coins, cash them the fuck out quietly and then hit us with the REAL solution. Call it the final solution. (No Jews were harmed making this post.)
|
"It is, quite honestly, the biggest challenge to central banking since Andrew Jackson." -evoorhees
|
|
|
doobadoo
|
|
April 02, 2013, 03:32:31 AM |
|
In other words, you've magnamiously forfeited the advantage you had over the competition and commoditized your core product.
Maybe for the moment think of BTC as KFC (Kentucky Fried Coin) and your intention to publish a detailed information about the formula for the Colonel Sanders' secret seasoning and the process of how he arrived at it. You will immediately spawn numerous competitors peddling their version of Fried Chicken Coin.
If you don't like the above analogy then maybe think of how you would like to differentiate your Coca-Cola Coin from Pepsi-Cola Coin and RC-Cola Coin and whole slew of other immitators.
As an engineer you were probably trained to think that your goal is to minimize the number of defects in your software. Try for the moment to think like a CEO and maximize the stock price of your enterprise.
Do you see the problem now?
Dude i'm really having trouble understanding what in tar-nation you mean by this. Are you suggesting that the dev team runs the bitcoin network bc, even though the client is open source, they have written it in a way that makes the spec amorphous, thus forcing every one to keep relying on them? Solidifying Gavin & co's benevolent dictatorship?
|
"It is, quite honestly, the biggest challenge to central banking since Andrew Jackson." -evoorhees
|
|
|
kjj
Legendary
Offline
Activity: 1302
Merit: 1026
|
|
April 02, 2013, 03:56:45 AM |
|
In other words, you've magnamiously forfeited the advantage you had over the competition and commoditized your core product.
Maybe for the moment think of BTC as KFC (Kentucky Fried Coin) and your intention to publish a detailed information about the formula for the Colonel Sanders' secret seasoning and the process of how he arrived at it. You will immediately spawn numerous competitors peddling their version of Fried Chicken Coin.
If you don't like the above analogy then maybe think of how you would like to differentiate your Coca-Cola Coin from Pepsi-Cola Coin and RC-Cola Coin and whole slew of other immitators.
As an engineer you were probably trained to think that your goal is to minimize the number of defects in your software. Try for the moment to think like a CEO and maximize the stock price of your enterprise.
Do you see the problem now?
Dude i'm really having trouble understanding what in tar-nation you mean by this. Are you suggesting that the dev team runs the bitcoin network bc, even though the client is open source, they have written it in a way that makes the spec amorphous, thus forcing every one to keep relying on them? Solidifying Gavin & co's benevolent dictatorship? You are new here.* Over time, you'll learn to discern 2112's pearls from his effluent. In this case, KFC's secret recipe is widely available for everyone to see, and both Coca-Cola Coin and RC-Cola Coin already exist, putting this post solidly in the latter category. * Yes, I know you registered around the same date as me. Not important.
|
17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8 I routinely ignore posters with paid advertising in their sigs. You should too.
|
|
|
2112
Legendary
Offline
Activity: 2128
Merit: 1073
|
|
April 02, 2013, 05:33:19 AM |
|
Dude i'm really having trouble understanding what in tar-nation you mean by this. Are you suggesting that the dev team runs the bitcoin network bc, even though the client is open source, they have written it in a way that makes the spec amorphous, thus forcing every one to keep relying on them? Solidifying Gavin & co's benevolent dictatorship?
Try to forget for a moment everything that you know about software engineering and think about yourself as a brand manager of a consumer product. From now on the discussion isn't going to be about technical facts, it is going to be about the perception of facts amongs the non-technical people. Do you think it possible to reverse engineer the recipe to the Kentucky Fried Chicken to such an accuracy that nobody will be able to distinguish it in a blind tasting? I think yes, but people will insist on sighted tasting and will claim that they are capable of distinguishing the true KFC from your Clone Fried Chicken. If you don't like popular American consumer products then how about French wines? Why for example Veuve Clicquot is considered more valuable than many other "Appellation d'Origine Contrôlée, Méthode Champenoise" beverages? How did they achieved that value and how they maintained it? Do you think that it is impossible to produce a Californian sparkling wine that 99.9% drinkers will not be able to distinguish in a blind tasting from the original? I think that this will be relatively easy, but the clone wine will have much lower market price because everyone buys wine while looking at the labels, not by the taste. For a non-engineer it is very easy to distinguish between say Bitcoin and Litecoin. For now everyone knows that the first Appelation d'Satoshi Controlee and the second is sovetskoye shampanskoye. What if the market gets flooded with Bitcoin clones, e.g. Bitcoin over port 8888 (marketed to Chinese, with some Confucius' proverb in its block 0), etc. And every one of those clones will be able to show that they are produced exactly according to the original Satoshi method. Or they will be able to easily show how they improved the original recipe. Bitcoin currently has a lot of very valuable brand equity, simply because it was first in its niche. The situation may however easily change once experienced brand managers decide to enter this niche with their clone products. Currently all the clones are marketed in a completely amateurish way. Or even much worse than amateurish, like the self-destructive marketing of SolidCoin.
|
|
|
|
wumpus
|
|
April 02, 2013, 05:59:03 AM Last edit: April 02, 2013, 07:10:44 AM by John Smith |
|
So, who dares to start writing a specification and actually getting it reviewed by everyone involved?
This has been the zillionth meta-discussion about this subject, debating whether it is possible or not, or a good idea or not, with other people trying to derail the thread into their own agenda. People will never be unanimous on those things, certainly not on a forum like this. So it is best to just try and see how far it gets.
There are two separate things to be written down, don't confuse them
(1) what is the current behavior of the (a) network and (b) block chain. This includes any satoshi-client specific warts. This is important for people that want to implement a client right now, and is mostly uncontroversial as it just has to be correct, complete and mostly self-contained. This specification should be in the English language, written as clearly as possible and divided into sections, so that it is possible to write test cases against specific rules to validate the spec as well as the client. The spec needs to be the form of human or mathematical descriptions, not "here's code" because code is not well-defined nor self-contained, we've seen this with the upgrade from bdb to leveldb.
(2) what would be the ideal behavior of the (a) network and (b) block chain. This is the above, but simplified, with strange warts and exceptions marked and removed. Through a process of staged upgrades it will eventually be possible to get here. This is very controversial, there will be a lot of disagreement, so it's better to start with (1).
You can start from the wiki document, but I would prefer something in git so that changes can be reviewed before they are pushed. Wikis are great for 'living documents', but not so much for specs.
Note that BlueMatt has already written a package of block chain and network handling tests (used by the pull tester on github, but not specific to the satoshi client), so it is best to synchronize with him.
I post a bounty of 10BTC (offer valid for 6 months) for the first person to take serious effort in the direction of (1). It is a huge, complex, messy job but it needs to be done. We really need a spec that documents what we have now.
|
Bitcoin Core developer [PGP] Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through File → Backup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
|
|
|
gmaxwell
Moderator
Legendary
Offline
Activity: 4270
Merit: 8778
|
|
April 02, 2013, 06:36:17 AM |
|
No need to enumerate "exceptions" from spec. Apply spec only from certain block number, use checkpoint hash to set all old blocks as valid. New spec-compliant do not need to to verify this old blocks, but only correctly parse them. Even the minimal sane behavior is surprisingly complex. But beyond that, "lock old _invalid_ blocks in with checkpoints" is really pretty hideous. You'd still have to distribute code to validate them because part of the point of the system is that none of it depends on some magic values being trustworthy. Though perhaps its preferable to relegate the legacy support to a validation tool. At the same time, there is really not that much legacy stuff that is really worth fixing. Making some of the byte order more consistent— or what have you— is not worth the risk of a hardfork to get it. A lot of the other complexity in the system rules is simply necessary... a lot of things which are easy to specify when you don't need absolutely identical bit exact behavior become difficult when you do... and the nature of what we're doing implies bit exact behavior for almost everything that reads from the blockchain.
|
|
|
|
TiagoTiago
|
|
April 02, 2013, 06:52:06 AM |
|
this is about defining a standard not a brand name (do people use the internet because of its brand name? what a load of bs)
If "bs" stands for "bullshit" then you have a gc above your head, where "gc" stands for "glass ceiling". There isn't anything wrong with being focused on technological aspects of development. But completely ignoring the finacial and game-theoretic aspects of development is a serious disadvantage in career advancement. Yes, people do use and invest in Bitcoin because of the brand name and the brand mystique that was built around it. Just look at their reactions to any alternate cryptocurrency that is nearly identical from the technical point of view. The eggs are already scrambled, Bitcoin is open source. It is not the lack of proper specification that is gonna stop people from launching altcoins. If anything, not having a proper specification actually makes it easier for incompatible competitors to rise than for more development to be done on Bitcoin compliant software. Btw, i hope the people working on this won't be stupid enough to just blindly accept any old block as valid; if you're gonna grandfather old blocks make sure they are the blocks you're looking for, don't accept just any old-looking block, otherwise an attacker could easily rewrite history.
|
(I dont always get new reply notifications, pls send a pm when you think it has happened) Wanna gimme some BTC/BCH for any or no reason? 1FmvtS66LFh6ycrXDwKRQTexGJw4UWiqDX The more you believe in Bitcoin, and the more you show you do to other people, the faster the real value will soar!
|
|
|
TiagoTiago
|
|
April 02, 2013, 06:54:40 AM |
|
...
At the same time, there is really not that much legacy stuff that is really worth fixing. Making some of the byte order more consistent— or what have you— is not worth the risk of a hardfork to get it.
If life-like tests are run on testnet, would there really still be a risk of unintentional hard-forking?
|
(I dont always get new reply notifications, pls send a pm when you think it has happened) Wanna gimme some BTC/BCH for any or no reason? 1FmvtS66LFh6ycrXDwKRQTexGJw4UWiqDX The more you believe in Bitcoin, and the more you show you do to other people, the faster the real value will soar!
|
|
|
r.willis
Jr. Member
Offline
Activity: 42
Merit: 11
|
|
April 02, 2013, 06:59:13 AM |
|
gmaxwell, bitcoind, as I understand, uses checkpoints to speedup initial chain validation. I'm suggesting that this behavior will be documented in spec.
|
|
|
|
gmaxwell
Moderator
Legendary
Offline
Activity: 4270
Merit: 8778
|
|
April 02, 2013, 07:59:24 AM |
|
gmaxwell, bitcoind, as I understand, uses checkpoints to speedup initial chain validation. I'm suggesting that this behavior will be documented in spec.
It does not, however, use it to skip the validation entirely. A chain cannot inflate the supply of coin regardless of what the checkpoints are set as. Checkpoints have absolutely no place in a Bitcoin specification, and as of right now they way they are used do not simplify the enforcement of the protocol rules. Once we have header first syncing we will possibly eliminate checkpoints for any speed purpose. (though may maintain a single one for a rewrite-doomsday security blanket).
|
|
|
|
gmaxwell
Moderator
Legendary
Offline
Activity: 4270
Merit: 8778
|
|
April 02, 2013, 08:01:29 AM |
|
If life-like tests are run on testnet, would there really still be a risk of unintentional hard-forking?
uh. Testnet didn't prevent the hardforking we created in Bitcoin 0.8 even though we believe that the relevant cases were tested already. (there were already super large blocks there).
|
|
|
|
r.willis
Jr. Member
Offline
Activity: 42
Merit: 11
|
|
April 02, 2013, 10:40:57 AM |
|
It does not, however, use it to skip the validation entirely. A chain cannot inflate the supply of coin regardless of what the checkpoints are set as. It's a fine check. I hope there is no quirks associated with this check? Checkpoints have absolutely no place in a Bitcoin specification Why not? It's just another way of limiting scope of some ruleset. It can be "no check", "relaxed check", "check this, do not check that", "check this way" etc. The other alternative is to limit scope with height. But checkpoint has additional benefit of making impossible creation of other spec-compliant chain going all the way to the root.
|
|
|
|
justusranvier
Legendary
Offline
Activity: 1400
Merit: 1013
|
|
April 02, 2013, 12:33:31 PM |
|
What I expect to happen is that somebody is eventually just going to start deploying an alternate implementation that will get significant usage. At some point there will be another chain-splitting bug and people running the alternate implementation, or the reference client, or both, will scramble to upgrade their nodes to fix the bug. We will probably have several more March 11th-style events until all the bugs are shaken out.
The goal of preventing unexpected forks at all cost is demonstrably futile. Better to just accept them as inevitable growing pains and prepare to deal with them as efficiently as possible when they happen.
|
|
|
|
|