Gold collapsing. Bitcoin UP.

[freetrader]

UAHF: A contingency plan against UASF (BIP148)

https://github.com/Bitcoin-UAHF/spec/blob/master/uahf-technical-spec.md

Archive link of blog: https://archive.is/9AZcm

I do believe Bitcoin will go up

 

[AdrianX]

There is “must be big” rule at the fork block. The block size of the fork block must be larger than 1,000,000 Byte. Fork block means the first block which adopt the consensus rule change.

Lets see what happens next all you need to do is mine a BIP148 block after august 1 2017

this is so bullish I can could #backflip
[doublepost=1497424274][/doublepost]

There will be a soft fork rule be added into the protocol to limit the sigops per transaction within 20K.

does this mean this http://www.blockbounties.info/ "free money for any miner who takes the first step to mining big blocks!" can't be claimed?

I like the idea of limiting transaction size Keeps Luke bible quoted out of the blockchain. but this is a little sad if this cant be had.

 

[AdrianX]

“Cryptography is a tool. Used correctly, it helps in the creation of secure systems. But like every tool, it comes as a cost risk trade-off. Bitcoin like all secure systems is structured from an economic risk trade-off. Too many people in the community do not seem to understand that it is the economics of the system that make it strong, not the algorithms. Set well, financial incentives create a strong system. There are no absolutes and there is nothing perfect in this world. When we accept that we can progress. When we fight it, we spin our wheels and get nowhere.” https://coingeek.com/craig-wright-interview-part-1-introduction/

 

[freetrader]

 

[bucktotal]

uncertainty, leading to fear and doubt, which is what the UASF and UAHF have both done, does not usually lead to price increases

 

[molecular]

UAHF: A contingency plan against UASF (BIP148)

https://github.com/Bitcoin-UAHF/spec/blob/master/uahf-technical-spec.md

Archive link of blog: https://archive.is/9AZcm

I do believe Bitcoin will go up

This is the best news since roughly 2 years.

Looks like a very well thought-out plan. Also like the outlook they give regarding extension blocks / innovation. This plan was made by people with their head screwed on correctly.

I hope it plays out as a split, don't like the segwit2mb plan much.

The resonance in north-corea is breathtaking. Unbearable.

 

[AdrianX]

uncertainty, leading to fear and doubt, which is what the UASF and UAHF have both done, does not usually lead to price increases

Yes very much so, Uncertainty leads to action in pursuit of certainty.

Hopefully something will change the dynamics supporting the 1MB Nash Equilibrium. I am optimistic that nothing can make enforcing the 1MB limit more stable so maybe industry can start to prepare for a >1Mb block.

In the mean time those with experiences know what to do when there is blood in the streets.

 

[Bagatell]

Who is @zilli ?

 

[Zangelbert Bingledack]

I have new theory that the Silbert Accord (Segwit2MB) is a genius move in this intensifying chess game, designed to jettison Core and its Segwit baggage:

• The semantic ambiguity was deliberate. Barry Silbert knew every miner would interpret it differently. He may have even primed each miner to interpret it as favorable to their own position through informal communications before the formal signing. This was used to make it look like 80%+ of the hashpower is in agreement.
• Whatever his views on blocksize, Silbert sees Core's pathological unwillingness to compromise as a bridge too far. He also sees that everyone is focusing on "Segwit vs. 2MB" so that the obvious move is to offer both. After all, no one except Luke is opposed to 2MB; in theory if a supermajority of miners support it, it should be a done deal. Even Core and its supporters should be happy with it.
• He figured out that Core's lack of compromise is about power, not ideology, so he wrote the Accord to assign a different dev team to implement the rule change.
• This reveals Core's true colors. They absolutely refuse this completely minimal, obvious (for a Segwit supporter) compromise, which shows everyone that they really just care about retaining control of the "reference" implementation.
• Meanwhile, these other dev teams start to do all the optimizations Greg had been discouraging people from doing all this time on the reasoning that "blocks will always be tiny anyway."
• Core is left with no control, exposed as to their motivations, and even made to look like poor engineers. This is even more powerful as it is timed with the fee rise to expose their economic ignorance and business naivety.
• The Silbert Accord falls apart, having served its real purpose of deposing Core, and the ecosystem is free to innovate through dev team competition so that it can restore its competitiveness in the market.

Note: Silbert invested in Blockstream, yes, but I wouldn't be surprised if he's given up and now regrets it. It's not like the VCs can take back the funds now, as far as I know. He seems the type to know not to throw good money after bad.

 

[Dusty]

A gem from our beloved Adam, perfect example of doublethink:


Also, if "it's not for change", why would change it drastically with segwit?

 

[AdrianX]

Still risky, you may get segwit, the benefactors of segwit are the people who paid Core to develop it, they don't care about those developers, they care about layer 2 transaction networks.

Back and Silbers seemed a little too buddy buddy, Silbert giving Back much praise for his guidance over the process.

 

[AdrianX]

There will be replay attack protection that is available for exchanges and wallet developers. You can find the spec here: https://github.com/Bitcoin-UAHF/spec/blob/master/replay-protected-sighash.md

Is this replay protection optional, will it make BU incomparable by default? can BU interact on the HF without implementing this replay protection?

 

[awemany]

@Zangelbert Bingledack : Interesting perspective. A not so nice state of mind that still fits your observations would be 'fuck with Bitcoin and keep the price low for as long as possible'.
[doublepost=1497476298][/doublepost]

Is this replay protection optional, will it make BU incomparable by deftly? can BU interact on the HF without implementing this replay protection?

I believe this is just concerning miners - and folks who are going to want replay protection, of course. A soft fork

As far as I can see, BU EC for non-mining blocks with bigger blocks should be fine either way - and won't really see the sunsetting OP_RETURN rule, for example. Unless we implement it in BU as well, which might make sense, as an option?

 

[freetrader]

Is this replay protection optional, will it make BU incomparable by default? can BU interact on the HF without implementing this replay protection?

BU could send transactions that don't use the protection feature, but to follow the HF chain it would need to be able to validate blocks containing protected transactions (specifically the signature hashing, and BU would need to not accept the special OP_RETURN exclusion transactions).

So no, BU can only follow this HF chain if it makes some adaptations.

These could be enabled by a switch though, to allow users to choose whether they want to run on the fork or the old chain. Depends on how it is implemented.

 

[AdrianX]

So no, BU can only follow this HF chain if it makes some adaptations.

that's the way I understand it, but if it was a module for exchanges as @awemany suggested it could be voluntarily adopted by exchanges and wallets. I for one am quite happy managing my own coins without relay protection.

Forcing it as a part of the HF upgrade makes this less desirable and literally ensures there will be 3 chains.

 

[Norway]

From https://blog.bitmain.com/en/uahf-contingency-plan-uasf-bip148/

Bitmain will mine the chain for a minimum of 72 hours after the BIP148 forking point with a certain percentage of hash rate supplied by our own mining operations.

Bitmain will likely not release immediately the mined blocks to the public network unless circumstances call for it, which means that Bitmain will mine such chain privately first.

In theory, Bitmain could mine empty UASF blocks for a reorg attack during their offline mining. This would be very destructive to the UASF chain.

And the exchanges etc have no way of knowing whether they do it or not when a portion of Bitmain's hashpower vanish from the net.
https://medium.com/@shludvigsen/thanks-for-a-great-article-one-aspect-of-this-should-also-be-highlighted-46941917df37?source=responses---------2-30----------

 

[Zangelbert Bingledack]

I was thinking, Bitcoin is a live system of competing software teams that must coordinate quasi-adversarially and react to absolute hard update deadlines perfectly, as well as have emergency code update ability complete with watertight bug testing. Is there such a system in the world? If so there must be a whole apparatus for managing this with its own jargon and such (and if not, such an apparatus needs to be designed).

 

[freetrader]

@Zangelbert Bingledack : imo what the Linux Test Project (LTP) did for Linux, we need something like that for Bitcoin as a system : a "Bitcoin Test Project" coordinated by major industry players and professionally set up to test changes and clients for conformance (if they wish). I've mentioned this before. [1]

Since it's a permissionless system, participation must remain voluntary, but imo it does need to happen.
If Bitcoin doesn't do it first, another cryptocurrency probably will.

[1] https://ftrader.github.io/posts/weekly_musings/20170415-weekly-musing-002-1.html

 

[awemany]

@AdrianX, @freetrader : What I wrote above is of course from a perspective of "the UAHF as initiated by Jihan will succeed and it will actually be the majority of HP.". And users just caring to follow the longest chain - and not so much about replay protection.

Not exactly what Jihan wrote as his plan, so I guess that was confusing.

 

[lunar]