Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
Already on GitHub? Sign in to your account
Revise Hard Fork Policy #899
Conversation
harding
commented on the diff
Jun 16, 2015
| It also applies to wallets and services that have the ability to detect | ||
| -the contentious hard fork, and which release code or make announcements | ||
| -indicating that they will cease operating on the side of the previous | ||
| -consensus. | ||
| -It does not apply to software that cannot detect the contentious hard | ||
| -fork and which continues doing whatever it would've done anyway. | ||
| +hard forks, and which release code or make announcements indicating that | ||
| +they will cease operating on the side of the majority consensus. | ||
| + | ||
| +>>Wallet authors and service providers who would like to discuss their opinions | ||
| +>>or contributions relating to hard forks should open an issue or submit | ||
| +>>a pull request specific to their requested change. |
harding
Contributor
|
|
NACK; the policy is really trying to politely address handling of altcoins that share a subset of Bitcoin's blockchain, not hard forks. "Contentious" is being used to try to get diplomatic language that regular end users can understand - but removing this word makes it problematic. Furthermore, this modified policy seems to imply censorship on discussions, which is not part of the current policy at all. |
|
@luke-jr I understand you don't approve this request. But let's be honest, you said contentious is hard to define and should be in the current merged policy, it is not. You also mention changing block sizes being similar to creating altcoins, yet neither of those terms are mentioned in the current policy, either. Yet you do not NACK that one for those reasons but do so with this one - it would be helpful if you could try to apply symmetrical logic to your perspective, here. Lastly, not sure where you are getting that this revised proposal implies censorship, because it's the same proposal as before, with bias/censorship removed and one sentence about telling people where the proper place is to have a discussion about hard forks (issues/pull requests) - perhaps you can comment on that line in the PR. Chances are it's already in the current merged one. |
|
@Coderwill thank you for helping me understand the phrasing. It seems to me that, if we're going to process PRs to stop promoting software related to hard forks, we should have a policy that explains for what reasons we'll stop promoting that software. Handily, we now do have that policy and it received a lot of approval.
Please note that I didn't intend the policy to change the way we usually operate. In the case that software or services seem to violate one of our other policies, we usually follow one of these procedures:
So there should still be a period of time for discussion before any particular software is removed. |
|
If, for some reason, the main repo of bitcoin core does not follow the majority of the hash power, will bitcoin.org change to download another version of bitcoin core, from another repo which support the majority ? If it is not the case, then we would simplify things by just admitting we only promote code which follow the rule of the github main repository. For those we don't know (closed source), we will remove then once we observe on which side on the fork they are. I think this would be the most straight to the point version we can make which does not endanger users.
I think that bitcoin, should remain bitcoin even in the event of not being on not having more hash power than another branch. So I would rephrase it this way :
The potential repository which would cause an hard fork should be the one responsible to explain to user what will happen in a hardfork, not bitcoin.org. |
Not to follow a contenious hard fork. Think about what you're asking in other terms: if 51% of the miners decide to steal your bitcoins, should Bitcoin.org help them?
No, the statement explicitly says that it will apply against Bitcoin Core if a released version has code to power a contentious hard fork. This is why I feel the statement is neutral: it applies to all software equally. |
|
If 90% of the network -on 1000 blocks- decides for the sake of the example, to follow bitcoinxt. Will bitcoin.org point the download link to the one provided by bitcoinxt maintainers ? Is it even possible to tag it "contenious hard fork" if it has the majority of hashing power ? I'm not specifically for or against any choice. Just it should be crystal clear what bitcoin.org promote and what it does not. And the only crystal clear thing which exists are : Hash power and the github repo of bitcoin core. |
Yes; it is even possible to have a contentious partial hard-fork (which is what everyone is actually talking about), where the game of chicken fails and there are at least two or more different blockchain histories that different nodes are sticking with. The hashrate power can be distributed across all of these different chains in various ways, or they could all stick with the one chain they find the most promising; every single one of these scenarios is broken. |
|
@NicolasDorier To quote @theymos from here
|
|
@saivann so in this case, it would make sense for this policy to say : We promote only wallet and services which are on the 90% side of the hashing power isn'it ? But this would beg the following contradiction : if Bitcoin core is preparing an hard fork for 0.12, since it is not the majority of the hashing power, it should not be promoted on bitcoin.org, in the same way than bitcoinxt. |
|
@NicolasDorier The answer from @theymos is not constrained to hashing power. I agree this is very hard to measure and defining "contentious" is in itself contentious, but here we are. |
|
So what about the following :
It would stay neutral and be clear what "Bitcoin" means. |
|
@NicolasDorier To reuse @harding's comment, if 90% of miners were to make a hard fork to steal coins, all users, nodes, businesses would be against them, yet you'd still have the vast majority of miners. In other words, it's an exagerated example to illustrate that users, businesses, miners, full node operators can have diverging interests and opinions. You can't measure adoption and consensus only with the hash rate, although it is certainly one of the most accurate indicators. |
|
Indeed, but it will be very obvious to anyone if such a thing happen.
I added "used by the ecosystem", even if ecosystem seems vague. The 90% and the current repo is not, and they define the limit more severely than the "ecosystem". |
|
@NicolasDorier The current policy defines what software we won't promote in the case of a contentious hard fork. I think adding a codicil that defines what software we'll promote instead is both unnecessary and confusing. |
|
I can't help but feel that this policy is a slippery-slope policy. I think it's safe to assume that most users (wrongly) think that bitcoin.org == Bitcoin Core == Bitcoin (the consensus network), partly because bitcoin.org has always promoted wallets whose consensus rules have been defined by Bitcoin Core. With the new policy, bitcoin.org has made its first consensus-rule requirement. However good its intent may be, bitcoin.org should not be in the business of defining consensus rules of any type IMO. It's effectively substituting bitcoin.org's own technical judgement over that of Bitcoin Core's, and as such is significantly new behavior. @NicolasDorier's (first) suggestion, or something similar, seems much better. It removes bitcoin.org from any consensus-related decision making, eliminiates any perceived bias (real or not), and it likely(?) achieves the same goals. In the event a non-Bitcoin Core fork succeeds, bitcoin.org may die off (presumably in favor of bitcoinxt.org) or it may choose to adapt to new policies the same way it can today. |
|
It's ironic that for how much people criticize @mikehearn or @gavinandresen or any other person for having a discussion about something controversial or potentially making a change without concensus, that Bitcoin.org would do the same thing. There have been plenty of people in PR #894 that have objected to the current blog post stating that it needs revision. We can argue all day about what constitutes concensus, but the fact of the matter is that PR #894 was one of the most commented PRs in the history of this website. There were plenty of people that said that it needed some work. Yet, @harding submitted it mid-morning and didn't hesitate to close and merge it right away with very little revision, early in the night. The only thing that was revised yesterday was the removal of one sentence, a typo and an adverb. It's pretty clear you all aren't open to compromise, nor do you care about the losing side of a concensus. At the very best it's going to make people on the losing side feel disenfranchised. At the very worst, it's going to make Bitcoin.org permanently lose its value for them - sound familiar? |
|
Well, I think that bitcoin.org dying off if Bitcoin Core loose is fine, and bitcoinxt.org will do their own stuff. My first proposal, (being clear that bitcoin.org will follow the github repo at any cost) seems the easier and clearer. As @gurnec said, it would remove the website from the discussion. (the main repo might always merge changes from bitcoinxt to conforms once again to the consensus, and the website would just follow the repo) Now since, I'm not the owner of the domain, I can only point out policy which would impose irrefutable boundaries about how the "Bitcoin" branding will be used in the future. I think it is essential to minimize the impact of vague terms (like "ecosystem", "consensus", "contentious"), and to do that, imposing a minimum hash rate is very effective. That said, I like the version that was merged yesterday, even if it can certainly be improved. |
Also a sentence was added in 30cf561 based on some feedback from Mike.
I'm sorry you feel that way. Since you feel compromise is not possible, I'm going to close this PR now---but if you have any future suggestions for improvement, I am more than happy to hear them. |
harding
closed this
Jun 16, 2015
|
@harding - do you always react so quickly to close PRs? I'm not the only one with a dissenting opinion here. Or are you just being told what to do at this point? |
|
@Coderwill I think you're starting to use personal attacks. There is no way this topic will satisfy everyone and David is actually pretty courageous for doing all of this. I for one am not always satisfied with everything but I respect the opinion of others, and I know the weight that comes with coordinating any such hard change. You've been very vocal but the opinion of others matter too, and you can't win by exhausting someone who's already doing his best. |
|
@gurnec sorry, I didn't notice your comment until just now. (Everybody: if I fail to respond to something you said, please email me, dave@dtrt.org, or ping me on Freenode (harding). I'm doing my best to process all of these comments.)
Are you using "consensus rules" in a technical context or as a metaphor?
I did that in an early unreleased draft of the statement. However, Bitcoin.org is independent of Bitcoin Core, and domain owners @theymos and @Cobra-Bitcoin have indicated that they would not allow the site to continue promoting Bitcoin Core if it did something they strongly opposed. In other words, to say Bitcoin.org would follow Bitcoin Core no matter what would be incorrect. |
I close PRs and issues when I think they've been resolved or when I think they've become incapable of being resolved. Your stated belief that we aren't capable of compromise made me think you were done making proposals. If that was not the case, I'd be happy to re-open.
But this is your PR. Other people can open their own PRs---they don't cost anything. I'm happy to continue discussion here, on the original PR, on a new PR, on Reddit, on IRC, on BitcoinTalk, privately by email, etc...
No, and I think that was an inappropriate accusation. |
|
@harding - Ok, I apologize.
|
|
Reminder: Miners are not the network. They only provide one specific service for the network, which inherently places them in charge of soft forks. They have no standing at all to make any decision in hard forks. |
|
@luke-jr Kind of like how Bitcoin.org doesn't either. |
|
@harding Thanks for the response.
In a technical context: the current policy effectively hard-codes the consensus rules to those released in Bitcoin Core 10.2, unless an update is judged non-"contentious" by... someone.
In this particular case, they certainly agree with the simple majority here. However to me, this statement more generally reads as: "if we (two owners) feel strongly enough about something, then it's my way or the highway" (apologies for the colloquailism). Of course, owners of a site should be able to control the content of their site. (And now I'm straying off-topic...) but if it's the intent to run bitcoin.org under a BDFL policy, I think it should be transparently explained on the about-us page. If I feel strongly about it, I'll open a new issue or PR. |
Well, that's not true since the policy only covers hard forks. Soft forks that change the consensus rules are fine.
@saivann and I agree, and I'm working on a revision of that page. It's going to take time, as I'm also adding details about the history of Bitcoin.org and I want to get Theymos and Cøbra to review it before opening a PR since those historical details come from them. However, if I haven't opened a PR in a week, please feel free to poke me publicly or privately. |
Of course you're right, I just missed a qualifying adjective....
Sounds good. As always, thanks. |
|
@harding There's almost no difference between a soft fork and a hard fork in practical terms of what people must do, so basing a website policy on it doesn't make much sense to me. The notion that they are fundamentally unrelated is not backed by much: both miners and merchants must upgrade after a soft fork, or else they could accept blocks that are guaranteed to be orphaned by the majority hash power. Thus if you're a miner and stay behind you can lose money, and if you're selling something and stay behind you may see that your tx appeared in a block (or even two!) made by old doomed miners without realising the blocks are doomed, so you can also lose money that way too. Thus - required upgrading is inevitable unless you don't care about fully validating every transaction, in which case you could save a lot of resources by just admitting that and using an SPV wallet. The biggest difference is really whether your node knows it's out of date or whether it's tricked into believing it's not. This is called 'backwards compatibility' by people who like soft forks, but as you must eventually notice and upgrade anyway or suffer the consequences ..... it's rather questionable whether this unusual notion of backwards compatibility is useful. Hence I think trying to make a website policy based on this distinction doesn't make technical sense. |
I think you're turning a crack into a chasm. For every soft fork that has yet occurred (or which is currently proposed in a BIP) non-upgraded software is still able to fully validate the transactions it understands to be received to its wallet. It's true that for non-upgraded software during a well-designed soft-fork, confirmation scores are less reliable than they were before. That's a crack in the security model, and one that's easy to plaster over by simply increasing the number of required confirmations---Bitcoin's exponential drop-off in fraud risk over number of confirmations is a wonderful thing. Compare that to traditional SPV security where the UTXO set isn't consulted at all. I can create a transaction with a 21 million bitcoin output, send it to a BitcoinJ-based wallet, and get it mined by a rouge miner so the wallet will show it as confirmed. We've gone from a crack in the security model to a chasm. I'm not saying there isn't a place for traditional SPV security---there is---but a full node doesn't magically lose it's security after a successful soft fork. If it did, miners could soft fork in secret to reduce the security of everyone's nodes---even of nodes that ran the latest public software.
I don't know of anyone besides you that questions the usefulness of soft forks, and I think I've made a compelling case above for why they don't have to significantly reduce the security strength of non-upgraded software. Compare that to hard forks which, upon a hard-forking change being made by the majority hash rate, immediately and permanently and massively reduces the security strength of non-compliant nodes. That seems to me to be a more-than-significant-enough difference upon which to base a policy. Reminder to myself: with the newish |
|
I think there's some misunderstanding here.
Consider your own example: let's say I create a transaction that relies on some new rule that your old software cannot validate, but thinks it can, because there's a soft fork. Now I spend that transaction to your wallet. Your wallet thinks it can fully validate this transaction. But it may or may not be actually valid. You really have no idea at all until the transaction is buried under blocks. For example, the P2SH soft fork introduced a new type of output for which anyone can make it evaluate to true, once the redeem script is visible. So I could spend someone elses money to you, and it'd show up in your software as totally A-OK. That's exactly the SPV security model, as you already note.
There is no difference between not consulting the UTXO set, and consulting it but deriving the wrong answer because of some always-true script. The outcome is identical.
Once your node is hard forked off, it knows immediately that it can't process the block chain any more and will start printing alerts and errors. Your wallet won't see transactions confirm at all. This is a strong sign that you need to either upgrade, or drop to SPV security (or somewhere in between, but at least, do it consciously). So it doesn't reduce the security of non-compliant nodes: the security reduction is there anyway the moment you can't check everything anymore. It simply lets them know what's happened. The distinction you're looking for is shifting sand. That's why it makes no sense to have a policy based on it. |
Ah, crud, I did indeed neglect to think about that. I'll look at your original post again, and reconsider its points. Thank you. |
|
No worries! |
|
With a softfork, the old nodes will follow the main chain and reorg off the attacking chain as long as the attacker has <50%. So the standard 6-block confirmation is still fairly strong. With a hardfork, however, the old nodes are left completely vulnerable to long non-main chains. |
ABISprotocol
commented
Jun 23, 2015
|
Hello, |
gurnec
referenced this pull request
Jun 23, 2015
Merged
Move Bitcoin.org Repository To New GitHub Organization #912
|
@ABISprotocol calling something a "[name] tragedy" is a personal attack, which are not acceptable here. I'd appreciate it if you would edit your comment above to remove or substantially revise that line. |
ABISprotocol
commented
Jun 23, 2015
|
@harding At times I think one must acknowledge that there indeed are only a few people (or less than a few) that could possibly have ownership of certain issues and circumstances. That notwithstanding, I have changed it from HT to ET as noted. In the end, we are all Entities muddling through this universe. |
|
@ABISprotocol thank you. |
|
@luke-jr "Remaining vulnerable" doesn't mean much, you need to be more precise. Here's how it plays out from the perspectives of different people in the ecosystem, for those who don't upgrade in time. All; let me know which part you disagree with. MinersSoft fork: miners will accept a bogus transaction when someone inevitably makes one and believe it's valid. They will include it in their blocks, and those blocks will then be ignored by other miners who will orphan them. Net result: none of the blocks the un-upgraded miners create will make it into the main chain. They start to bleed money immediately and lose exactly as much as they would in a hard fork. We know this because it's what happened in the P2SH soft fork as well as just being common sense. Hard fork: miners will start to generate blocks on a separate chain. These new blocks will not, however, include the bogus transaction - because the transaction will fail validation under the old rules. Miners lose an identical sum of money to in a soft fork. We can see that for miners the "backwards compatibility" argument is irrelevant (nb: there is some terminological abuse here, they actually mean forwards compatibility). Miners must upgrade immediately in both cases. However, there is a difference in the amount of information the miners get. Their blocks are now being attached to a non-longest-work chain and this is extremely detectable just by looking at the heights of mined blocks. Core will trigger alerts in this case too. Of course, we would hope that there have been broadcast alerts before that, because as I already pointed out miners must upgrade immediately anyway. But at least miners have multiple ways to find out. In a soft fork though, the blocks will always be mined at the tip of the chain, and it can just look like the blocks are being orphaned through natural bad luck. The failure mode here is identical to an expected occurrence. If a miner doesn't see the alerts, eventually they'll realise their luck can't possibly be so bad, investigate, and discover the problem. But it may take longer. So in the hard fork vs soft fork competition for miners, hard forks are always better. The outcome is identical: you must upgrade immediately (really: before the fork), but you get better information and the failure is clearer with the hard fork. There's one additional reason miners should prefer a hard fork: it's better for merchants. MerchantsA new type of transaction appears. From the POV of old nodes, it's spending an output correctly. From the POV of new nodes, it isn't: it's a bogus attempt to spend somebody else's money. What happens depends on the exact details. Let's consider the best case when the new transaction is considered non-standard. So the merchant will ignore the transaction when broadcast. So will most miners. However, some miners alter the IsStandard rules and would accept it, e.g. for a fee. Soft fork: the bogus spend may be initially rejected by the merchant because it violates IsStandard, but later appear in a block on the tip of the main chain and the merchants node will then attempt to verify it, fail, but think it's succeeded because it ran a bunch of NOPs. They may then go ahead and proceed with the trade, and later lose the money when the transaction is re-orgd out by the upgraded miners. Hard fork: the bogus spend will not appear in any block, not even on the weaker chain the merchant is now following, because in a hard forking case no effort has been made to trick older nodes into accepting something meaningless to them. They understand they can't check the transaction and thus reject it. Bloom filtering nodesSome nodes just serve SPV clients. It's better if they fully validate transactions because SPV wallets randomly pick some nodes and count how many announce transactions as a kind of heuristic to estimate validity. If they don't upgrade, whilst nobody will lose money directly, they may contribute to misleading UI on mobile wallets. ConclusionI've made these arguments before. The rebuttals are usually of the following forms:
See Luke's comment above. This is the SPV argument again. If you can't validate transactions yourself, just wait long enough until the miners have done it for you. If you want to run an SPV wallet go right ahead, I've written lots of code to help you do just that. But if you don't want to, then you shouldn't be relying on 6 blocks for anything except resolution of double spends. The other problem with this response, of course, is that it's totally unrealistic. Lots of trades don't wait six blocks. Many of them don't even wait for one. Whether you like that or not is irrelevant - it is how the ecosystem works.
This happened after I last made these arguments. That's good! But it just supports my claim in this thread: the difference between hard and soft forks is actually quite small, has got smaller with time and is thus hardly the policy-founding chasm you seem to think it is. |
|
@mikehearn this is a re-reply to your previous post (thanks again for correcting my flawed thinking in the first reply).
It seems to me that the essential difference between hard and soft forks is that eventual consensus convergence is assured during a soft fork and not assured during a hard fork. Software that will leave the previous consensus during an intentional and contentious hard fork does not provide an upgrade path for all users---it only provides an upgrade path for users who agree with the new rules. I don't think that's acceptable for Bitcoin.org. We should promote software that follows the consensus rules everyone has agreed to so far by using Bitcoin today, or to follow new rules that everyone seems to agree to follow tomorrow, but we should not promote software that will likely split its users off from other parts of the Bitcoin payment network.
Failure to provide consensus-compatible software seems to me like a sufficient technical distinction upon which to base a policy. It might, as others have pointed out by using the term altcoin, be the single most relevant basis for a policy on a domain named Bitcoin.org. |
I'm not sure how you're using the term consensus here. If someone tricks you into agreeing to something you didn't understand, did you have consensus with each other? I would say no.
You must upgrade no matter what in both types of fork. As I have explained above! Just look at it from the miners perspective: to not upgrade and be in the minority is to lose money. They lose an identical amount regardless of which type of fork there is. Therefore all miners must upgrade to the new rules even if they would rather not ..... or they must stop mining. That means whilst merchants/other users don't have to upgrade in some pedantic technical sense, it's a meaningless choice because the new rules will be enforced by miners no matter what. The distinction between fork types is merely whether you accept that or pointlessly deny it and silently downgrade your own security in the process! I think that's a critical point you must address if you want to defend this policy: for each user, to end up with the same income or security level as before they must upgrade. It doesn't matter if they disagree with the change. It's simply not feasible to stay behind. And that is fundamental to the notion of a shared economic system! It's a basic truth of trading with others. Not something that can be worked around with strange technical hacks. |
This is not true, as coin value and security depends on more than the amount of POW protecting a coin. If there's a hard fork to give long-unspent coins to miners, or to create a permanent block subsidy of 50 BTC per block, or to replace POW with some entity's cryptographic signature, upgrading does not give users the same income or security level as before. The reason we have full nodes---and hard forks---is because we don't want miners by themselves to be able to change the consensus rules in certain ways.
By that conclusion, we have to do whatever the hash rate majority wants. Do you really believe that? If so, you should probably open a pull request, because I'm pretty sure the Bitcoin.org FAQ (and other documents on this site) say that miners aren't in charge. |
You're right, in those cases it wouldn't. But the same is true in a soft fork scenario to do those things as well. Again, the distinction just isn't as deep as it may seem. If someone gets together enough of the community and economy, and convinces them to accept 50 BTC per block in perpetuity, then whether it's a hard or soft fork is irrelevant. You're going to eventually get paid with a coin rooted in a 50 BTC coinbase and then you have to decide whether to go ahead with the trade or refuse, but if you're in a small minority then you're going to encounter that situation every day. Eventually you won't really be able to claim you accept Bitcoin anymore, because it would just confuse and annoy buyers who are completely sure they have bitcoins in their pocket. I realise that this outcome is feared and the possibility is even hated by many people. I've seen some people in the past say that it's impossible for some things about Bitcoin to change because it's "guaranteed by maths". But it's not - if 90% of the userbase decides that tomorrow the word "Bitcoin" refers to a system with different rules, and they implement those different rules in the software they run, then the meaning of Bitcoin changes. It's just inherent to the nature of trade and language.
I guess I should have written that sentence more clearly. By "user" in that case I meant "user who is running the minority rule set", and the term user could mean miner or trader. The case where the hash rate majority wants different rules to the economic majority is one of the worst case scenarios for Bitcoin. Nobody is quite sure what would happen then. Hopefully everyone's needs are aligned closely enough that we'll never find out. But in theory in such a conflict, the economic majority should win, because that's who is willing to swap newly mined coinbases for useful goods and services. What happens if you're in the economic minority and calculate a different ledger? Well, whether miner or trader, see above: you will go and try to trade with someone who advertises they accept Bitcoin, and then you'll discover that your transaction isn't recognised by them. You could get upset and turn it into a semantic fight over whether they are accepting the One True Bitcoin or merely an Imposter Altcoin, but that's unlikely to solve your actual problem. |
It sounds like we're in fundamental agreement, but is it 89%, 90%, or 91%? With this policy, we're saying that Bitcoin.org expects it to be close or equal to 100%, or we're going to continue to promote the previous rules as Bitcoin and only list software that support them.
I completely agree, but when I was a boy, my mother---and many other boys' mothers---told us that getting into actual fights wouldn't solve anything, yet we fought anyway. And I think that's the real danger here: if we don't have near-universal agreement on what changes to make and if we end up with competing networks, it's likely to be to the detriment of all Bitcoin users no matter what consensus rules they follow. Our policy attempts to discourage such a problem from occuring, which seems good to me. |
I don't know. The last time I encountered a situation where a word changed meaning and a tiny minority insisted on staying behind, it was my grandmother, who still thinks the word gay means colourful :) In practice you don't have to worry about Bitcoin splitting into two competing networks. This situation has come up before when the inflation subsidy dropped from 50 BTC to 25 BTC per block. There were some people who had become convinced that the network couldn't survive long term without the monetary inflation and they patched their software to fork onto a 50-forever chain. They didn't last very before rejoining the majority. Bitcoin certainly did not split in two. Nor did the majority care that the minority wanted the status quo of 50 BTC. The majority told the 50-forever minority to (literally) get with the program or get out of dodge. Sucks to be them, but that's how shared infrastructure works. Now, I do see your dilemma - why should a bigger-blocks rule change be on the bitcoin.org website but not, say, "25 BTC forever" if some people want to try again next time the subsidy drops? And I think there's a common sense solution to this: pick a reasonable amount of hash power supporting a change (or a reasonable number of wallet devs or exchanges or payment processors etc) and say, this amount of support indicates "community interest". That filters out lone wolves who are just crazy whilst still allowing bitcoin.org to reflect genuine differences that the community must work through together. Your current policy on the other hand has a couple of problems:
If I were you, I'd have a policy like this:
This filters out random people trying to make random alt coins with the Bitcoin name, and ensures that there's some meaningful choice that can be presented on the website to users. It doesn't get distracted by the fairly trivial soft/hard fork distinction, which is merely a difference in deployment mechanism and doesn't change the need to follow the economic majority ruleset to trade with that majority. And it encodes the neutrality of the website via a fairly algorithmic approach, so should avoid disputes like this one where the bitcoin.org admins try and 'pick a winner'. |
I am worried, and I think a lot of other people are too (I can find sources for other peoples' statements if you want). Is this story about the 50BTCers the only reason you're not worried?
That wasn't really a concern to me when I wrote the policy. It's easy to say "no" to someone with minimal support. The more challenging problem is deciding if, and when, we should say "no" to someone with significant support.
Hey, watch the hyperbole. If anything Bitcoin.org could do would make or break the entire system, the system would already be broken. Moreover, I want to make it clear that this policy does not prevent Bitcion.org from listing information about hard fork proposals; it only restricts us from promoting software that is already programmed to intentionally leave the previous consensus during a contentious hard fork. You already know from a private thread between you, me, and two others dated May 8th that I'm in favor of resources related to the debate appearing on Bitcoin.org. |
No, not the only reason. It's also clear from the way the system works: the incentives to stick with the majority are very strong, especially for miners. As any software that wants to trigger a fork must watch to see how much support it has before doing so, it is guaranteed that a fork would not happen until the new rules are supported by the hashpower majority. In the case of Gavin's patch, a supermajority of 75%+. At that point miners left behind would switch to the main chain because otherwise their coinbases won't make it into the main chain ledger (note: this is also true of a soft fork if a miner accidentally accepts a bad transaction e.g. due to modifying IsStandard or because the soft fork doesn't trigger the IsStandard rules). So such a fork should resolve extremely quickly without much activity on the less supported side. As indeed happened during the 50BTC fork attempt. It makes little sense for people who want tiny blocks to try and continue on an abandoned chain, even if they genuinely believe the sky will fall if blocks go above the arbitrary 1mb threshold. It makes much, much more sense to stick with the majority, keep your coins useful, and then try and convince the community to throttle the network in some other way or possibly change the limit to be lower again via another fork. |
|
Irrespective about whether the hard/soft fork would resolve quickly and without pain (which I don't agree, a permanent split followed by legal suit to service providers who choose the "wrong side" from customer's perspectives), it is not the place of bitcoin.org to promote an altcoin. Sure, in the case it works as you said, then will people refers to XT as Bitcoin, then bitcoin.org would change and consider that the altcoin is Bitcoin Core and not XT. (from what I understand, it is the site's owners will) If you want a precise terminology I would define altcoin this way : Any git fork of Bitcoin which has a different libconsensus source code than the one that can be downloaded on the download page of this website. I like the current version, but I would not be against a more precise definition which drop out subjective stuff (like whether it is dangerous or not), while respecting the will of the owners of this site. (If fork happens AND if it is clear that XT wins AND the hold main chain dies or is clearly irrelevant, then bitcoin.org will switch the download to XT) |
ABISprotocol
commented
Jul 1, 2015
|
-----BEGIN PGP SIGNED MESSAGE----- Having read through the most recent posts on this thread, it seems Apparently the community feels otherwise, including those who have Perhaps it is time to move on and stop hammering on this issue. Thank you. On 06/25/2015 12:02 PM, Mike Hearn wrote:
iQEcBAEBAgAGBQJVlEy6AAoJEGxwq/inSG8CA4gIALRoSyKBfhaSsvJTjI4LZfZN |
wbnns commentedJun 16, 2015
It's pretty clear that no matter what, a group of people want to have some sort of policy. Obviously, me and some others would prefer we not have one at all, but that doesn't mean we can't try to work like a team and a community of developers and contributors to find a compromise.
Let's try again and find something in the middle of what I'm suggesting and what @harding posted.
We can't always do things that everyone's going to be happy about or agree with, but we could have done better to try and more comprehensively represent our community today. That's what Bitcoin.org is about. That's what Bitcoin is about.
Not like this.