Gold collapsing. Bitcoin UP.

[awemany]

@Jihan: Given the current situation, what's your plan forward regarding the 1MB limit?

 

[lunar]

Can anyone help me understand how this would optimistically play out?

Currently we've got a bit of a signalling issue. ( very approx % of total hashrate/month)
ViaBtc ~10% unlimited
Slush ~ 2% unlimited/classic
Bitcoin.com 1% unlimited/classic
KnC ~ 3% classic
F2Pool 1% classic
BW pool 8% signalling 8MB blocks

My point: That's already ~25% of the network hashrate, and as much as i'd like to see a hardfork to larger blocks, forking the network in a haphazard and uncoordinated manner seems needlessly risky, as many larger block supporting nodes will not follow the longest chain.

The Game here is a little odd, but it seems to me that the lowest common denominator would be for all miners who want larger blocks to run Unlimited as the Classic (750/1000 block activation) precludes them from following the longest chain should a 1.1MB block be mined. Yet by doing this we loose the rather useful activation threshold and risk forking the network (at the minimum viable 51% (and hence highest risk point)) rather than a more reasonable 2/3rds or 75% majority.

Thoughts?

 

[awemany]

@lunar: What you see as a danger I see as BU's advantage.

HOWEVER: Of course this needs informed participants, especially on part of the miners. I believe an agreement between them when to start mining the first larger block is probably going to help smooth the transition.

 

[_mr_e]

Firstly I would like to thank you guys for finally getting rid of the BIP109 75% vs 25% flag, I think this is huge progress towards larger blocks.

Please can you guys clarify the situation, ViaBTC is signalling they will build on any block up to 2MB and the Bitcoin.com pool is signalling they will build on any block up to 16MB. Is that correct?

Does this lack of convergence of the two main BU pools not offer an additional unnecessary advantage to the miners enforcing the 1MB rules?

Please consider the following example:

Hashrate distribution example:

• Miners enforcing the 1MB limit - 40%
• ViaBTC pool running BU, will build on blocks up to 2MB - 30%
• Bitcoin.com pool running BU, will build on blocks up to 16MB - 30%

Scenario:

1. Bitcoin.com pool sees 60% of the hashrate showing BU flags.
2. Bitcoin.com pool decides to mine a 1.1MB block, there is now a 40% vs 60% chain fork
3. A subsection of miners trying to enforce the 1MB limit engages in defensive strategies and decides to mine one 2.1MB block on top of the larger block chain.
4. The subsection of miners who wish to enforce the 1MB limit then switch back to the smaller block chain after finding one block
5. The ViaBTC and Bitcoin.com pool's and now competing with each other on different chains, each with a lower hashrate than the smaller block chain. (In my view there is no reason to believe that ViaBTC and Bitcoin.com will quickly converge. However many BU supporters seem to believe they will converge reasonably fast for some reason, the reasoning is something like that the people running the miners want to converge, so will update the clients to do so. Although I cannot understand why they do not run a convergent client in the first place)
6. Perhaps ViaBTC and Bitcoin.com converge reasonably fast, either because ViaBTC gets the lead or Bitcoin.com gets a 4 block lead. I have not run the maths, but lets say in our example they converge in 10 blocks and are still ahead of the 1MB chain
7. After ViaBTC and Bitcoin.com converge to one chain, the miners repeat the defensive strategy again
8. Eventually, after several defensive blocks, the miners enforcing the 1MB limit retake the lead and the people buying coins in the chain with blocks over 1MB lose their funds.

Please could somebody let me know if this is right? Or is the BU philosophy built on the idea that everyone agrees with BU, so the above does not matter?

As a supporter of doing a hardfork to increase the blocksize limit, I kindly ask you join the majority like the Core team for example (see BIP103), who want to increase the limit without giving such an unnecessary, massive and decisive asymmetric advantage to the chain enforcing the 1MB rule.

These miners who you say will mine a 2.1 would be extremely stupid to do so given it is ONLY bitcoin.com accepting their block, which is < 50% of the mining power. They would be taking a huge risk of their block getting orphaned and therefore losses of big chunks of cash that these miners cannot afford. Given that the two pools would be likely to converge on the 1.1 block chain, as this will guarantee the attacking pools lose money, the attacking pools would realize this and therefore not take the risk in attacking at all.

 

[lunar]

@awemany

Long term I see BU as a very elegant solution, its the immediate disruption surrounding the first Hardfork that I find troubling. The Dam and Blocking the Stream analogy couldn't be more perfect. We have two years of pent up bikeshedding, censorship and unscientific political viewpoints to be released.

BU is like the invention of the Sluice gate for on chain transactions. I just wish we didn't have to install it in the dam at high water. Last summer in the drought would have been much more suitable.

Perhaps XT and Classic will release a patch to follow the longest chain <2MB without the activation limit, and the larger pools release a joint statement if/when 51% supporting hashrate is achieved?

 

[awemany]

@lunar: I understand the sentiment. I am not afraid, even if it is hours of unclear situation regarding the chain. I am absolutely certain that the dust will settle.

However, the media/propaganda battle by Core at that point might be the fiercest, and I think there is a chance still for Core to spin any uncertainty into their favor.

Which means, I think, that it would make sense for miners to announce their intent to mine bigger blocks in advance. As soon as enough HP and nodes have been secured.

That said, a complete different topic: @solex, does BU have an official twitter account? That question came up on reddit.

EDIT: Typo fixed.

 

[AdrianX]

Firstly I would like to thank you guys for finally getting rid of the BIP109 75% vs 25% flag, I think this is huge progress towards larger blocks.

Please can you guys clarify the situation, ViaBTC is signalling they will build on any block up to 2MB and the Bitcoin.com pool is signalling they will build on any block up to 16MB. Is that correct?

Does this lack of convergence of the two main BU pools not offer an additional unnecessary advantage to the miners enforcing the 1MB rules?

Please consider the following example:

Hashrate distribution example:

• Miners enforcing the 1MB limit - 40%
• ViaBTC pool running BU, will build on blocks up to 2MB - 30%
• Bitcoin.com pool running BU, will build on blocks up to 16MB - 30%

Scenario:

1. Bitcoin.com pool sees 60% of the hashrate showing BU flags.
2. Bitcoin.com pool decides to mine a 1.1MB block, there is now a 40% vs 60% chain fork
3. A subsection of miners trying to enforce the 1MB limit engages in defensive strategies and decides to mine one 2.1MB block on top of the larger block chain.
4. The subsection of miners who wish to enforce the 1MB limit then switch back to the smaller block chain after finding one block
5. The ViaBTC and Bitcoin.com pool's and now competing with each other on different chains, each with a lower hashrate than the smaller block chain. (In my view there is no reason to believe that ViaBTC and Bitcoin.com will quickly converge. However many BU supporters seem to believe they will converge reasonably fast for some reason, the reasoning is something like that the people running the miners want to converge, so will update the clients to do so. Although I cannot understand why they do not run a convergent client in the first place)
6. Perhaps ViaBTC and Bitcoin.com converge reasonably fast, either because ViaBTC gets the lead or Bitcoin.com gets a 4 block lead. I have not run the maths, but lets say in our example they converge in 10 blocks and are still ahead of the 1MB chain
7. After ViaBTC and Bitcoin.com converge to one chain, the miners repeat the defensive strategy again
8. Eventually, after several defensive blocks, the miners enforcing the 1MB limit retake the lead and the people buying coins in the chain with blocks over 1MB lose their funds.

Please could somebody let me know if this is right? Or is the BU philosophy built on the idea that everyone agrees with BU, so the above does not matter?

As a supporter of doing a hardfork to increase the blocksize limit, I kindly ask you join the majority like the Core team for example (see BIP103), who want to increase the limit without giving such an unnecessary, massive and decisive asymmetric advantage to the chain enforcing the 1MB rule.

Concern troll right on cue. it's not like he shouldn't understand how the BU works after all we've invested countless hours explaining how it works.

Bottom line worst case scenario is a miner losses a block and gains imperial evidence of the block size the network will accept. The reality is small block proponents are invested in mining blocks on the network the majority use. It's the same for large block proponents.

We are all invested in being on the one network. @jonny1000 stop preaching subdivisio. The centralized small block proponent network will be abandoned should a minersucceed in mining a 1.1MB bloc..

 

[Justus Ranvier]

 

[awemany]

What I really REALLY REALLY like about ViaBTC going forward is that with >10% of hashpower, the wheels are falling of Core's bullshit tactic of conflating various forms of consensus and launching cognitive and political attacks. (Thanks @Zangelbert Bingledack for putting the topic of consensus so nicely earlier)


Apparently they already start to switch to 'we are stopping progress' rhetorics.

But that is a very clear "The emperor has no clothes" moment.

One of our problem lies in the amount of entropy of sane arguments needed to counter the Gregian and Backian bullshit.

Going from 'we're conservatives, we do no want to change Bitcoin' towards 'those big blockers are blocking progress' means opening an opportunity for us to counter the bullshit in less than a couple hundred bits.

That's rare, and I like those moments. Allows for snarky but correct arguments that punch at the right spot.

 

[freetrader]

Hi /r/btcfork

I need to inform you all of a circumstance affecting the BTCfork project at the moment.

Unfortunately /u/singularity87 currently does not have time to engage actively in the project. He remains with BTCfork in all his current roles. We just have to make allowance for other priorities which preclude his active involvement. This will go on for an unknown amount of time, although I hope singularity will be able to rejoin the project soon.

My last contact with him was September 30, when we managed to successfully transition nearly all project resources.

Unfortunately we did not secure the @btcfork twitter account, so that's dormant for now. I'm hoping singularity still finds some time to hand that over to a trusted party so that it remains available to the project, otherwise we'll need to transition to a new Twitter account.

This is obviously a little bit of a set back to BTCfork, since singularity was extremely active in drawing up and refining the roadmap and liaising with pools, exchanges and other companies supportive of the BTCfork. And that's among a ton of other things

But such setbacks are natural and to be expected in any project as real life interferes with our plans. We've dealt with similar before, and we might need to again in future.

As far as I and other contributors are concerned, this just means a little more work for us. The project goes on - we are forking Bitcoin.

If you are with a business that has interest in the spin-off and have be contacted by singularity in this regard, please re-establish contact through me on our Slack channel or via PM on Reddit, so that we can continue where we left off. I'll try my best to co-ordinate things in this regard.

We have also extended the moderators in this subreddit to compensate for singularity's absence.

My personal imminent focus of work will be to implement the first spin-off client (MVF) as described in the BTCfork roadmap.

Finally, thanks to all involved and who have and continue to support us on Reddit and elsewhere. Your efforts are making this possible!

https://www.reddit.com/r/btcfork/comments/56ua9q/ann_singularitys_temporary_hopefully_leave_of/

 

[Norway]

It was a lot of brainpower and hashpower at Hard Fork Café.

 

[solex]

@awemany, Great to see you back here!
This is the Bitcoin Unlimited twitter account. Early days, but lots of good content to come...
https://twitter.com/BitcoinUnlimite

A pox on short names causing our "d" to be guillotined as ruthlessly as Marie Antoinette.
Suggestions for (unused) alternatives are welcome.

 

[albin]

I think what's going to happen if sufficient hashpower blocks segwit activation is that they're going to go through another re-brand of the propaganda of how soft forks are characterized.

There's undoubtedly business projects in which Core devs are involved that rely on segwit happening, and it would be extremely politically unpalatable to 51% attack non-segwit activating blocks.

What I imagine they would do is invent some new terminology to divide soft forks into different types. Segwit only actually needs reliably >50% hashing power to work, because the segwit tx type was nonstandard beforehand, and existing nodes happily validate blocks with NOP tx's, so there is no way to stop miners from effectively doing it so long as there is enough hashing power to support a main chain that reliably orphans blocks that maliciously contain NOP tx's that the segwit clients would reject as invalid.

This is in contrast to the strict-DER softfork, where the new rules applied to tx's that were previously valid and standard to the existing nodes (in the case of segwit, the new tx's are all valid but non-standard), which creates the situation where minority hashing power on the old rules routinely creates blocks invalid to the new rules.

So that being the case, as long as they have enough hashing power > 50%, my guess is they might abandon the softfork terminology entirely, activate regardless of 95%, and pretend it's some kind of metalayer application (this really isn't in principle any different than say Counterparty, other than some benefits from being on the inside of core dev allowing the dusting off of an opcode) instead of an actual consensus change. The only way to prevent this political interpretation of segwit as some type of embedded metalayer consensus is to hardfork away the placeholder opcodes.

 

[freetrader]

@jonny1000 , you're still confused...


And because I've started not to trust people with keeping their posts up...

It is true. In the past some 1MB supporters were creating a client to "false flag" BIP109 to trick Bitcoin Classic nodes. Now amazingly BU people, who appear to support the Bitcoin Classic people, seem to also want to false flag them. Either to be disruptive or pure idiocy. I do not know which.

However it is great people are finally ending the false flags

 

[freetrader]

Won't someone fix Adam Back's slide?

It was supposed to read "Controversial soft-forks CANNOT happen", but someone messed up the Powerpoint. Mystery solved!

A fun project would be to construct a "what if Blockstreamers told the truth" world

 

[lunar]

@solex who owns this one? https://twitter.com/BTC_Unlimited

 

[solex]

@lunar Someone we don't know, but they may accept an offer for it.
Edit. someone I don't know. Maybe on this forum though...
Looks very supportive, which is nice.

 

[Roger_Murdock]

Won't someone fix Adam Back's slide?

It was supposed to read "Controversial soft-forks CANNOT happen", but someone messed up the Powerpoint. Mystery solved!

A fun project would be to construct a "what if Blockstreamers told the truth" world

Indeed, it's funny how Core's position on hard forks vs. soft forks is almost completely backwards. Controversial hard forks aren't a problem. But the more "controversial" a soft fork is, the closer on the spectrum it gets to something that should be considered a "51% attack."

 

[Justus Ranvier]

Not only is Core's position on forks backwards, they've invested a huge amount of their various forms of personal capital in the wrong position.

The sunk cost fallacy is wreaking havoc with their decisions right now.

 

[Zarathustra]

[URL='https://www.reddit.com/r/btc/comments/56wxf8/market_surprise_controversial_softforks_cannot/']Market 'surprise': "Controversial soft-forks CANNOT happen"
[/URL]