Gold collapsing. Bitcoin UP.

[Mengerian]

Right - beginning to look like i just lost $120,000. Bad day.

Sorry to hear that!

 

[cliff]

@Mengerian - its an interesting issue. the law is there - exchanges gotta comply if they're going to do certain things (e.g., offer margin trading). its possible bitfinex settled for a compliance solution too quickly to avoid loss of business due to a prolonged closure or something, but who knows. this incident might bring awareness to various regulatory agencies about the importance of security vis-a-vis laws and compliance - perhaps some laws can change later on down the line. having said that, its way too early to draw many, if any, reliable conclusions about contributing causes and so forth - facts are still being gathered.

 

[Mengerian]

@cliff Yeah, I guess they have to comply with the law. Kind of strange that a Hong Kong-based business registered in the British Virgin Islands has to kowtow to a branch of the US government though. :/

One of the problems with regulations is that it gives businesses an excuse to avoid responsibility. They can say "we complied with the rules! It's not our fault!" instead of bearing full responsibility to their customers. The regulators have little direct incentive to actually make rules that protect the clients, they are far more likely to serve the interests of their political masters. They also often end up in regulatory capture to the industry they are supposedly overseeing.

 

[freetrader]

 

[Epilido]

So let's game this out. Many of the core developers are suggesting that a roll back is part of the incentive mechanism of bitcoin. Ie when the economic value is great enough to overcome the block reward than its OK to rollback.

What if the miners included a hard fork to the block size at the same time. If the reorganization is successful than the blocks could be ready for 2 or more megs and the bitcoin unlimited nodes and the classic nodes would be ready to relay transactions. Someone could even set up a fund to pay extra into all of the reorged blocks to sweeten the pot. If the miners are really tired of core than this seems like the perfect opportunity.

And if they don't win the reorged then they still have all of the current fees in the last 1000 blocks

 

[freetrader]

@Epilido : Many of the core developers?

I'm only seing Mark who's advocated it, but now retracted:

EDIT2: To be absolutely clear I hope that this doesn't happen. If it does, I'm not sure what value proposition bitcoin would have left. Uncensorable, nonpolitical money is what bitcoin is about, and without that it is nothing. If this manages to go through, I hope the outrage pushes people to fight for more decentralization and fungibility at the protocol level. Otherwise I don't know what future bitcoin would have.

(edit to his original comment post to zanetackett)

 

[Epilido]

@freetrader

Sorry jumped the shark.

Clearly Greg thinks that the thief would just use RBF to up the ante and mark made an edit to clarify, that was not in the original post.

I am still surprised that a core developer would promote this.

The economic an trust issues would destroy Bitcoin. IMO

 

[Justus Ranvier]

Ie when the economic value is great enough to overcome the block reward than its OK to rollback.

If you restate this in positive terms rather than normative terms, it is correct.

Bitcoin's security model can tell you how to calculate expensive it would be for miners to reverse a transaction.

Bitcoin never promises infinite resistance to reversal, only deterministic and calculable cost.

A first order approximation about Bitcoin's security guarantee is that any transaction whose value is lower than the accumulated miner revenue since it was mined which must be forfeited(*) to reverse it is safe to consider finalized.

This doesn't mean it's ok for miners to deliberately reverse transactions just because people sometimes assume more about Bitcoin's security model than it actually promises. Behaving that way is harmful to their long term profitability, as a second order effect.

(*) Right now this revenue only consists of the block reward, but transaction fees could also be made capable of contributing to double spending security with appropriate changes to output scripts.

 

[Zangelbert Bingledack]

Once the campaign to activate Classic becomes insignificant, I think you will be surprised about how [united] everyone is on the desire for large capacity increases.

Since you agree that only an assymetric fork requires strong consensus, this shouldn't be an issue if the fork is symmetric.

You're still retaining some of the really bizarre aspects* of your argument, which is obscuring the valid thread of a point you are making (that Classic is not suitable for fork arbitrage; that a symmetric fork is needed - I disagree with @Justus Ranvier and @Peter R on this one because Core can easily come back with a change in difficulty of its own, perhaps even by some soft-fork machination).

*the 25% miner "lock-in" (this is frankly just silly), the need to get support for Classic low before forking (only applies if you want to do another asymmetric fork, and even then assumes a weird fetishization of Classic which no one has), the almost-continual assumption that we here are stuck on Classic as the solution (usually most people talking here of a HF to up the cap are not talking about Classic nor even necessarily assuming a threshold), the lack of recognition of how much like trolling your arguments look (almost like you want people to assume you're trolling so you can call them out when they insult you), and the blind eye turned to Core's general insistence on tiny blocks with piddling rube-goldberg on-chain scaling. This is merely a footnote, though, because it seems to me none of this is relevant to the larger argument.

@all

To understand @jonny1000, realize he's specifically saying Classic is doing it wrong with the 75% threshold. He has been pushing for a 95% threshold, but he would be fine with no threshold at all, as I understand it. In other words, he holds a more radically big block position than Classic, not less. He is saying that if you want a threshold it needs to be extremely high but that really there is no need for a threshold in the first place. (Correct me if I misrepresented you.)

 

[cliff]

@Zangelbert Bingledack - you have an understanding of jonny similar to mine. i've always understood him as saying he wants big blocks and that it could be done by tweaking the current proposals - specifically the 75% threshold in the Classic proposal. Initially, I took that as a very risky and possibly insulting suggestion b/c it would require big blocker to give up more ground in exchange for a promise from a party that may or may not be creditworthy. The Core slack is revealing - undeniably some people consider Classic and so forth to be attacks against Bitcoin. Knowing that, combined with prior knowledge of various public spats and brouhahas RE: scaling, one can easily infer that any non-core involved/blessed fork attempt is going to be interpreted as a declaration of war against BTC and will be met with loud and damaging resistance. Popescu alone has promised that, and he doesn't strike me as a guy that plays around on that type of thing. This heightens the risk of a fork (whether its an acceptable risk is a different question that I'm not talking about here). I think Jonny has basically been describing a possible avenue for avoiding the type of war that Classic and other proposals would very possibly trigger. I think his point is somewhat subtle but not disingenuous.

 

[Justus Ranvier]

Popescu alone has promised that, and he doesn't strike me as a guy that plays around on that type of thing.

The last public demand of his that I saw was for a poorly-designed proof of storage to be added to the consensus rules. That wouldn't be satisfied by a 95% activation threshold change.

 

[go1111111]

Anyways, this conversation is largely pointless: there's no practical concern that the minority chain will overtake the majority chain.

Doesn't the ETC/ETHF situation suggest otherwise? Do you think it's not analogous, or do you think ETC has no real chance? If the later, I'd be willing to bet you.

IMO what this conversation shows is that it'd be useful to have some sort of convention for how hard forks happen, allowing SPV wallet users to specify ahead of time how they want their wallets to handle hard forks. Users could specify "Always follow the majority hashpower, but alert me", "Default to staying on the original chain, but alert me", etc.

This would work as long as forkers followed the convention. Of course people forking a chain could violate this convention, but that might make people less willing to support their cause.

 

[jonny1000]

To understand @jonny1000, realize he's specifically saying Classic is doing it wrong with the 75% threshold. He has been pushing for a 95% threshold, but he would be fine with no threshold at all, as I understand it. In other words, he holds a more radically big block position than Classic, not less. He is saying that if you want a threshold it needs to be extremely high but that really there is no need for a threshold in the first place. (Correct me if I misrepresented you.)

Yes this is mostly right. I am not saying if you want a threshold it needs to be extremely high, but if you want to do an asymmetric hardfork, then you need an extremely high threshold.

This logic is based on the idea that if you want to do an asymmetric hardfork, then there needs to be no significant opposition to ensure the hardfork wins rather than loses. There are many other ways of hardforking or increasing the effective capacity of the system without an asymmetric hardfork. Also getting the high level of consensus needed is also pretty straightforward, as long as the proponents of the fork try to achieve it.

Yes I do have a strong large block position. I want larger blocks, Classic is a terrible way of achieving it and therefore I strongly oppose Classic. Many in the Core team also strongly oppose the Classic methodology and it is a misconception that the Core team do not want on-chain capacity increases. This miscommunication has caused problems and divisions in the community. Once more people realize this, then we do not need to do a symmetric hardfork that splits the chain and community in two. We can just sit down in a calm non confrontational way and do a careful, cautious and sensible hardfork, with an unnecessarily high level of strong consensus across the community. It is great that more people are now starting to appreciate the potential problems with Classic's activation methodology.

 

[Peter R]

"Doesn't the ETC/ETHF situation suggest otherwise? Do you think it's not analogous..."

I think it's sort of analogous, but Bitcoin's difficulty algorithm is going to make keeping the minority chain alive a significant challenge (I calculated a ~$16 million dollar cost to reset difficulty back to ~10 min blocks).

Furthermore, the reason for forking Ethereum--whether to bail out the DAO or not--seems more acute than arguing over the precise timing of when to increase the block size limit. With ETC vs ETH, there are two clear value propositions: ETC is immutable and true to its promise, while ETH doesn't have the problem of a hacker in possession of a large amount of stolen funds. The market is presently at work weighing the pros and cons of each against the other. I just don't see the market getting excited in the same way in the case of a big-block fork.

"...or do you think ETC has no real chance? If the later, I'd be willing to bet you."

At this point I think ETC has a small chance of becoming the dominant chain. I would give it 1 in 8 odds, and I'd accept a bet at 1:3 odds if you're interested. (If Bitcoin forked via BIP109, I'd probably give the minority chain 1 in 200 odds of becoming dominant.)

Lastly, I don't even see it as that big of a deal if the minority chain eventually did become dominant. That to me would be the free market at work. The users of the other chain could use a check point to avoid the reorg, or just accept the death of that chain. They'll have plenty of warning time to figure something out.

 

[jonny1000]

The users of the other chain could use a check point to avoid the reorg

Classic/XT/BIP109 do not have such a checkpoint. If you do not agree with the Classic process and instead would like a checkpoint, please end the support for Classic and put forward your checkpoint idea. Perhaps the level of opposition to your new proposal will not be that large.

or just accept the death of that chain.

Bitcoin is already a weird, unknown, complex and abstract concept to at least 99.5% of people. I am not convinced a long period of uncertainty over the "one true chain" and then a large group of people losing funds is particularly helpful.

I am likely to oppose any hardfork that results in a large amount of network downtime or mass loss of funds. It is not necessary to do the hardfork in this way.

 

[Peter R]

Jonny, you're too worried about all these far-fetched "what ifs" that we can deal with when and if they become actual problems. But you're not worried enough about the big problem that is staring us in the face TODAY: the lack of block space!

Sure, I gave the odds of the minority fork overtaking the majority fork as 1 in 200. But I'd give the odds of bitcoin slowly dying at 50-50 if we keep bike-shedding over when and how to increase the block size limit!

The proposal I like is Bitcoin Unlimited (at least for non-mining nodes) and I have no concerns with the risk. If you're worried, why don't you write a BUIP to give the user an option to never re-org deeper than X blocks, or use a checkpoint, or whatever it is that would make you happy? Bitcoin Unlimited is all about giving choice to the user.

 

[priestc]

IMO what this conversation shows is that it'd be useful to have some sort of convention for how hard forks happen, allowing SPV wallet users to specify ahead of time how they want their wallets to handle hard forks. Users could specify "Always follow the majority hashpower, but alert me", "Default to staying on the original chain, but alert me", etc.

This is already possible with wallets that are built using moneywagon. You can select which nodes you want to pull information from. After the fork occurs, you can tell it to only use nodes that are on your preferred side of the fork. Or better yet, you can have it follow both forks...

 

[Zangelbert Bingledack]

@jonny1000

Why isn't there a list of preferred blocksize caps (via hard fork, since that is your claim) among Core devs? If you are really correct that almost everyone wants at least 2MB and would support a hard fork to do it, a 95% consensus requirement is innocuous at least since it will be met immediately. But that's a huge "if" to me.

Also, if such a list existed and we had a clear statement from the Core committers and that they will release a fork to 2MB if people stop "supporting Classic" (mining Classic?), I am sure people would stop supporting Classic and give Core one last chance, but Core is miles from anything like this. It is them you should be convincing, not us. We have already bent over backwards to accomodate them but they haven't budged nor even shown a credible sign of release of an increase to 2MB.

Instead they try to give us segwit as the increase, and both Greg and Luke say they would prefer a smaller cap. Greg is the most prominent Core dev and is the boss of one (or two?) Core committers, and Wlad requires consensus of all committers for a hard fork, so your story doesn't seem to hold water.

 

[go1111111]

please end the support for Classic and put forward your checkpoint idea

Like some others here, I don't understand your fixation with stamping out all support for Classic before moving on to more productive discussion. Yes, the Classic thing was handled in a divisive way, and the code is not ideal, but I don't see many people agitating for Classic specifically right now. People just want a reasonable block size increase. It seems like you are way more fixated on Classic than anyone else.

Here's something you could do that would be way more effective than badgering people about how they need to renounce Classic before anything else can happen: create a PR (with help from a dev if you're not a dev) where the HF is symmetric, the activation period is longer than 28 days (60 seems good to me), and the miner threshold is above 75% (I suggest 90%). I'll happily endorse your PR as preferable to Classic (partially because I do think it would get more support).

Then, your message to people on this forum can transform from "Admit you were wrong! Say Classic is bad!" to "Would you support this alternative?"

 

[Dusty]

it is a misconception that the Core team do not want on-chain capacity increases

You are playing with words (like Kore): they want to increase on-chain capacity only with soft forks and with changes that only accidentally or marginally make room for more txs.

They do not want to hard fork the network in order to increase the non-witness data, so please stop spreading false rumors.
[doublepost=1470206738][/doublepost]

Why isn't there a list of preferred blocksize caps among Core devs? If you are really correct that almost everyone wants at least 2MB, a 95% consensus requirement is innocuous at least since it will be met immediately

Because they don't want to increase the 1MB (non-witness) block size, ever.