Gold collapsing. Bitcoin UP.

[freetrader]

in case it has not been noticed, bitmex is offering futures contracts for big block activation and for segwit activation, to expire at the end of 2017.

https://blog.bitmex.com/site_announcement/announcing-new-binary-futures-segwit-big-blocks/

right now traders are betting harder on SW than on big blocks. trading is thin.

"and that chain remains the majority chain for 75% of the next 2016 blocks before the expiry date"

I'm finding this hard to read - do they mean the big blocks chain must have majority hashrate for 75% of the 2016 blocks before Dec 31, 2017 at 12:00 UTC?

In the case of a tight race (let's say both around 50% of hashrate), is it possible to measure each chain's hashrate accurately enough over such a period to decide this future?

Why not decide it in terms of SHA256 work done on each chain at last block before expiry date?

The above conditions may be amended with notice at any time.

What happens when they are amended?

---

EDIT: I think I answered my own question after thinking about it some more. They want to express a clear majority (75% of the hashrate).

But they do not account for the fact that if there is a > 1MB block, the chain will split in two, and it is no longer possible to measure "majority chain" by looking at just one chain.
So for a chain to be declared "majority", it would need 75% of its last 2016 blocks before expiry date to have greater work (SHA256 - otherwise not comparable anymore) than the highest-work block on the other (losing) chain.

- If a Big Block is mined on the Bitcoin chain with the largest hash power

This seems to exclude a big block future where a > 1MB block is mined on a minority chain which becomes the majority in time to satisfy the "75% of last 2016 blocks" condition. Anyone see that differently?

This is actually much less clear than the termination condition - how is the "chain with the largest hashpower" measured at the time a > 1MB block is created ?
Is it 75% over the following 2016 blocks after the fork?
Because by definition, the > 1MB chain will be majority on its own chain (since it split).
Help me make sense of it if you can

 

[Zangelbert Bingledack]

@molecular I would say that is a situation where a second chain simply won't have any signficant value. It seems likely that a second chain can only survive with a PoW change, which should avoid the tx delays.

@albin Wouldn't a spinoff also work as a way to undo Segwit? Or is there something about the change in UTXO that makes it impossible to spin off the ledger? In other words, does Segwit change Bitcoin so it is no longer viewable as a system of ledger entries tied to specific private keys? If so, that seems like a much more worrying change than any I have yet heard of.

 

[albin]

@Zangelbert Bingledack

From what I understand, you would need to support the new opcode to even understand what key owns the new entry.

 

[go1111111]

look at how a non contentious soft fork like the 1MB block limit is hard to revere where there is no money at risk, no try imagine revering segwit where there are coins on unsupported formats. - Its a total lock in, with an 75% discount should you adopt the new format. once activated there is no turning back that is the only way forward.

I'm talking about being locked in to Core's scaling plan. Activating segwit does not do this. Yes, reverting segwit itself sounds messy, but that's not necessary. If you like the non-blocksize-increasing parts of SegWit, which most people seem to, then everything to do with the discount can be changed easily in a hard fork.

Here's a plausible path forward: adopt segwit now. In 6 months, hard fork to remove the discount and set block size to 8 MB. Nothing about segwit prevents this or makes it technically hard, as far as I can see.

 

[79b79aa8]

@go1111111, what backs up that "most people seem to like the non-blocksize-increasing parts of SegWit" claim?

 

[AdrianX]

Core's scaling plan is dependent on just 2 principals.

1. Remove transaction malleability.
   
2. Limit on chain native transactions.

Once those 2 rules changes are implemented the Core's scaling plan is locked in and almost irreversible regardless of which development team fulfills its destiny.

If you think the block size can be set to 8 MB in 6 months, Core should do that now. If you think it is another 2 years, they should do that now.

The FUD around Hard Forks is not going away, it will turn into "fear, certainty and reality". After segwit activation hard forks will be less likely. If a hard fork capacity increase happens, It will happen before segwit.

A hard fork capacity increase within the first 6 years of segwit activation is unlikely, if ever. I'll look real stupid if we get a hard fork within 6 years of segwit activation, @go1111111 I am not willing to chance it. If a hard fork is possible we should do it now not later as it becomes less possible.

I am a nobody, so no need to convince me of anything, but as a nobody, I am willing to compromise and give Core's one of their scaling plan principals. Either Core gives up transaction limits of transaction malleability, there is no compromise if they get both.

 

[Dusty]

Here's a plausible path forward: adopt segwit now. In 6 months, hard fork to remove the discount and set block size to 8 MB. Nothing about segwit prevents this or makes it technically hard, as far as I can see.

There are never been technical problems in hard forking, but after many years of debate we still don't have it, even if this would speed up segwit adoption (think of the segwit2mb proposal).
So, telling that 6 months after segwit activation we can change those rules, with all the blockade that Core did in those last years, I think it's naive at best.

 

[go1111111]

@Dusty, we've also never been in a situation before where our limited tx throughput was as obvious of a bottleneck as it is now. If SegWit was not an option now, I think you'd see a lot more support for a HF.

We've had many years of delay because initially Core said "wait, let's not act too fast. Let's instead have some scaling conferences and talk about possible solutions. We promise we think scaling is important, just trust us!" and enough people gave them the benefit of the doubt that it bought them some time. Then they said "wait, don't HF now, we're going to code up SegWit and it'll be done soon, plus we'll propose a HF of our own after SegWit" and enough of the community gave them the benefit of the doubt. Now they say "wait, don't HF now, SegWit is ready, let's just do that first!". This is the only excuse they've ever had which kinda makes sense.

In a post-SegWit world, Core is basically out of excuses for why they won't support a HF. By opposing SegWit, you're basically giving them cover by letting them keep their somewhat-legitimate sounding story going for why they're not supporting a HF.

Once those 2 rules changes are implemented the Core's scaling plan is locked in and almost irreversible

What specific mechanism locks it in? If the economic majority wants larger blocks, in the long run they'll get larger blocks. SegWit activation doesn't somehow prevent future popular HFs.

@go1111111, what backs up that "most people seem to like the non-blocksize-increasing parts of SegWit" claim?

I think it's pretty obvious from watching the block size debates. You don't really see people arguing against the idea of fixing tx malleability to allow Lightning Network, just against banking on it as our only scaling solution. Even Roger Ver wants the malleability fixes and thinks Lightning is cool. Jeff Garzik wants the malleability fixes but just doesn't like the discount.

IMO most people also like SegWit itself, as-is, because most people think we should do both SegWit and a traditional block size increase. Even big block supporters like Gavin Andresen and Erik Voorhees are in favor of SegWit as-is.

Take a look at https://medium.com/@21/using-21-to-survey-blockchain-personalities-on-the-bitcoin-hard-fork-1953c9bcb8ed. Half of respondents consider themselves big-blockers, 1/3 consider themselves small blockers, and yet 75% want segwit to be activated. There are a lot of big blockers who like SegWit aside from Gavin and Erik.

 

[Zarathustra]

BTCfork has the technology for a flag day / soft-fork triggered minority hard fork.

I'm sure we are not alone. If SegWit gets pushed through, there *will* be spin-offs.

Very important work, and absolutely not a waste of time, even if SegWit never gets pushed through. I think it already influenced some miners. Thank you @freetrader for your efforts.
[doublepost=1492679426][/doublepost]https://www.reddit.com/r/btc/comments/66fk6u/why_i_am_still_not_voting_for_segwit_an_open/
The hero and the cowards ....

------------

I think BIP100 has a great potential. Getting Jeff Garzik and friends into the boat is a very promising strategy.

 

[adamstgbit]

What specific mechanism locks it in? If the economic majority wants larger blocks, in the long run they'll get larger blocks. SegWit activation doesn't somehow prevent future popular HFs.

there are several indirect ways segwit "locks in" the future of bitcoin scaling.

after segwit there will be technical reasons why blocksize increases would be undesirable. segwit changes the way a block weight is calculated, as a result simply increasing blocksize will have more impact the before.

LN will come shortly after segwit, and people will start to use LN as an alternative to on-chain-super-high-fee TX, less poeple making onchain TX == less demand for bigger blocks. The idea of bitcoin as a settlement layer with LN and sidechains picking up most of the TX volume, will become the norm. it went from a controversial idea to a reality, at which point people will praise core for being such "visionaries".

some poeple will most likely sell the price incress segwit will result in, who? Big-Block supporters of course! this will mean less support for big blocks. maybe they will move on to an altcoin, maybe they will sell at ATH fiat prices... New buyers of BTC, will buy-into LN's scaling solution and While BigBlockers sell out of it, less support for Bitcoin + more support for BlockstreamCoin

With all that said and done, we're going to see some altcoins gain more traction then they would have, and some will take the rout of bigger blocks for scaling. their will be a bit of a war, Crypto-with-big-blocks Vs Crypto-with-small-blocks. there will be very little reason to keep fighting for bigger blocks on Bitcoin, Bitcion will have become a "Crypto-with-small-blocks" coin.

 

[xhiggy]

Litecoin should be the small blocks coin because currently no one uses it. It has ideal usage patterns for a 1MB cryptocurrency

 

[Zarathustra]

BIP100 FlexCap coming. Second Pool jumps on the victory train:

https://www.reddit.com/r/btc/comments/66jlsj/viabtc_jumps_on_the_bip100_victory_train/

 

[Erdogan]

Lots of segwit uptalking here. It is still true that segwit is a hodgepodge, 1 MB if larger blocks are dangerous, larger blocks if it is not dangerous, mallability fix, compact signatures, fixing quadratic time of signature checking. Then the central planning of fees.

The flexcap can automatically be implemented using the consensus of miners developing organically using signalling in the blocks and other communication.

We want larger capacity, and second layer systems developing on their own merit. They have to create value by themselves to be of use to the market.

Just hold on, support for larger blocks is coming steadily. It is the only way that creates value for all actors.
[doublepost=1492719210][/doublepost]And it is not a chain split. We will not split the chain. The fork word has now become newspeak.

 

[albin]

I like the idea of proposals like BIP100 and others co-opting the term "Flexcap", because this goes right to the heart of the issue, in the sense that the wizards clique believes that any "Flexcap" proposal has to involve imposing arbitrary pricing on increasing the cap at the consensus level.

 

[AdrianX]

@go1111111 Mazwell is projecting the end of all block size increases with segwit, it's all moving out off the blockchain.

 

[Zarathustra]

I like the idea of proposals like BIP100 and others co-opting the term "Flexcap", because this goes right to the heart of the issue, in the sense that the wizards clique believes that any "Flexcap" proposal has to involve imposing arbitrary pricing on increasing the cap at the consensus level.

Will be difficult to denounce it. Our jonny1000 loves BU compatible BIP100 EC FlexCap.


Ah, and Havar_R

 

[Richy_T]

Another distraction from the slow but continual progress of EC, I think.

 

[Richy_T]

Gregonomics 101 - Lesson 32

(I'm particularly referencing the third paragraph)

 

[majamalu]

The Economics of Soft Forks vs Hard Forks with Daniel Krawitsz


I'm glad he is starting to speak clearly against Core totalitarian attitudes.

 

[go1111111]

after segwit there will be technical reasons why blocksize increases would be undesirable. segwit changes the way a block weight is calculated,

As I mentioned in my post, it's trivial to remove the discount in a hard fork.

LN will come shortly after segwit, and people will start to use LN as an alternative to on-chain-super-high-fee TX, less poeple making onchain TX == less demand for bigger blocks.

This is definitely possible -- but to the extent that LN txns can replace regular txns without impacting users' use cases, this is fine. If LN transactions are worse for some use cases and those use cases are important, then there will still be pressure from the economy to raise the block size. There might be less pressure, but even with SegWit and LN, blocks have to get larger eventually if Bitcoin is going to succeed, and I think the economy realizes this.