Gold collapsing. Bitcoin UP.

[Richy_T]

@Richy_T

In a way, IsStandard() sort of functions in a way that's conceptually similar to BU wrt blocksize.

It's like your client is deciding that it's not in favor of helping a certain sort of tx, but if the tx actually happens, it will accept it.

Hmm. That doesn't sound quite as bad.

 

[cypherdoc]

link: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012248.html

for what is worth when he said that a fully packed block composed exclusively of SegWit-enabled p2phk txs has an effective block size of 1.7MB it means that:

tx data + overhead + link to witness data + signature data (witness) = 1.7MB

those data are downloaded entirely by nodes that want to perform full validation, witness data could be discarded immidiately after though.

SegWit is a mere, although clever, reorg of the way we store tx data and hence block data.

A way that let you prune not only per block (e.g. keep only last 3000 blocks) but also intra-block, e.g. keep only the "message data" of the last 3000 blocks.

Other SegWit pros: all cases of non intentional malleability will be fixed, SPV clients will need to download less data, fraud proof if implemented will increase SPV client security, new script systems could be introduced easily. Of course SegWit will lessen full node storage requirement.

cons: Sergio's concerns about complexity that are amplified by rushed soft fork deployment. Garzik's complains about lack of economic analysis:

so how will old nodes protect themselves from attacks given ANYONE_CAN_SPEND?

 

[Inca]

From: https://github.com/bitcoin-core/website/issues/50#issuecomment-172668727

brg444 - Alex Bergeron (individual)

 

[cypherdoc]

Hmm. That doesn't sound quite as bad.

i don't think what i told you earlier was correct. it looks like old nodes will validate SW tx's and relay them as solex said.
[doublepost=1453157982][/doublepost]this doesn't sound good from maaku7:

And perhaps of nearest significance to scaling bitcoin, segwitness is one of the two soft-forks required for Lightning, the other being BIP 112 which is very close to being merged into Bitcoin Core. With both soft-forks deployed, the best, most efficient, full version of lightning can be deployed and payment channel networks start to be used to replace on-chain transactions.

 

[JVWVU]

From: https://github.com/bitcoin-core/website/issues/50#issuecomment-172668727

brg444 - Alex Bergeron (individual)

Aka

 

[rocks]

If 75% of the miners support Classic then the network will fork with or without F2Pool. Miners will not mine coins on a chain which cannot be sold for fiat and pay their electricity bills and so F2Pools commentary should be taken with a pinch of salt.

The problem is without F2Pool, the 75% threshold will most likely not activate the fork in Classic, despite a super majority backing the fork. This is why 75% is too high IHMO.

With the pathetic attempts to infiltrate and damage Classic via GitHub it is clear to the entire community that Core are extremely threatened. We have had a year of this shit. They either put up or shut up.

And yet F2Pool and BTCC, which together account for >35% of the hash rate, continue to favor core based solutions and would follow a core if it too raised the cap. Not sure if the reasons are the language barrier or cultural or what, but they don't seem to be turned off to core yet.
[doublepost=1453158795][/doublepost]

@rocks

I would say set it at whatever percentage would make it highly-likely that the big-block fork becomes the longest. "Highly likely" being perhaps 99.999% or something. 510 / 1000 blocks is probably not enough; but I bet 600 / 1000 would be plenty. Would need to do the math to know for sure...

Right now we have 57.5% committed to Classic and just over 60% if we assume Slush joins. Would be great to understand the various options and probabilities in order to maximize the likelyhood of the fork happening given the current hash rate support.

 

[JVWVU]

The reason why F2Pool and BTCC prefer a Core 2MB move then SEG Wit is a financial decision, one I would be approving of also prior to Classic. It's financially the better option for investors looking to get into Bitcoin.

 

[solex]

The problem is without F2Pool, the 75% threshold will most likely not activate the fork in Classic, despite a super majority backing the fork. This is why 75% is too high IHMO.

I think 75% is OK because sometimes a leap of faith is required and will create its own momentum to success. XT failed because 8MB+ was just too scary for the miners. 2MB is fine with them, so if there is 60% hash-power on Classic then F2Pool will likely reconsider as they would have given Core every possible chance to come to the table. F2Pool is not a solo-miner (I believe) so they will have pressure from their hashers, some will leave to support Classic.

Anything less than 75% might have the effect of also scaring miners that there could be two competing forks with coins from each worth less than half the current value. So they would stay away from a client that did a hard-fork too easily.

 

[albin]

@rocks

They are ignoring completely the importance of conceptually differentiating between those attributes that are essential and inessential to the identity of the thing, and shouting down, censoring, and declaring people trolls for wanting to take them to task on that misconception. My question to them would be: if hardforking the blocksize cap opens the door to changing the 21 million, what prevents Bitcoin from being changed to an MMORPG?

 

[rocks]

I think 75% is OK because sometimes a leap of faith is required and will create its own momentum to success. XT failed because 8MB+ was just too scary for the miners. 2MB is fine with them, so if there is 60% hash-power on Classic then F2Pool will likely reconsider as they would have given Core every possible chance to come to the table. F2Pool is not a solo-miner (I believe) so they will have pressure from their hashers, some will leave to support Classic.

Anything less than 75% might have the effect of also scaring miners that there could be two competing forks with coins from each worth less than half the current value. So they would stay away from a client that did a hard-fork too easily.

As a thought experiment, what happens if Classic keeps the 75% threshold, successfully deploys and gains 63% of the hash rate, but then stalls adoption there with F2Pool continuing to refuse to adopt without a 95% level and BTCC continuing to favor core?

One possibility is individual miners leave those two pools in favor of pools voting to scale. F2Pool and BTCC seem to have shrunk a little bit over the past couple of days but it is not clear if this is due to variance or a true change. So we are not sure if we can rely on that happening.

Another possibility is for Classic to lower the threshold. But the optics of doing so at that point would not be great, and it risks some pools leaving.

Another possibility is F2Pool looks and sees that 63% plus it's 22% make 85% and they decide that is good enough and switch.

Something else?

None of these possibilities are guarantees though. Classic is putting itself in the dangerous position that it gains a majority of hash rate but then momentum stops before activating, and it fails then.

If you set the threshold lower at lets say 60%, then during the initial adoption phase it will become very obvious that the fork will happen. This in turns forces the pools on the sidelines to switch over or be left behind, which in turn keeps adoption moving forward until more than 95% of the hash rate has converted. This is purposefully an economic decision making fork. There is no need for wide consensus, just a winner take all result.

 

[solex]

@rocks Another possibility is F2Pool looks and sees that 63% plus it's 22% make 85% and they decide that is good enough and switch.

I also think this is the likely scenario, especially as once the trigger occurs there will be movement across during the grace period. So F2Pool can rationalize their action that the 85% will increase to about 95% before the first >1MB is mined. They will have any number of people making this point to them at the time

 

[Zangelbert Bingledack]

Since F2Pool is a pool, it's really not F2Pool's decision but mostly* that of their miners, so that seems somewhat close to the market deciding. However, the reverse holds for the already-committed pools, as we could see some hashing power move away from them as some presumably won't want to support Classic.

An important consideration is how much of the hashing power committed to Classic is just a proxy commitment by way of the pool (and therefore liable to change as some miners move away), and how much is actual commitment by the owners of the equipment. Only the latter can be counted as solidly committed (though even they could change their minds). Of course the same can be said for the Core-committed hashing power. The rest will be a true market vote, insofar as hashpower represents the market.

Then, given it is clear that it's a true hashrate supermajority, even if we don't get to 75%, it will be known that if a fork happened the Core side could definitely be 51% attacked,** which should move the consensus up past 75% very easily it seems to me.

*People obviously have chosen to mine with F2Pool for other reasons as well, and some will stay just because of inertia.

**Not out of malice, but for tidyness's sake. If Core wants to stay alive in that scenario they would need to either move to 2MB or implement Luke's mining algo change.

 

[solex]

@Zangelbert Bingledack
All true, and then we are into the realm of assessing what the support is for larger-blocks, what I would call: enabling main-chain scaling. It always seemed that support for removing the 1MB was 75% or more. There were about 20 polls on BCT/reddit. I started the first one. @cypherdoc had a major poll, and I don't recall a single one with >25% support for limited blocks. I don't think every one of those polls was manipulated significantly up or down.

Despite the censorship most people should have an unchanged view. If /r/bitcoin moderation had remained independent then we would have a better idea. 75% seems achievable. Any higher, not.

 

[Zangelbert Bingledack]

Aww yesss! Ben Davenport supports fork arbitrage, complete with an easily implementable futures market aspect, and makes a good post explaining it.

What we need is a market on assets that do not exist yet (and actually may not exist, if the fork does not happen). Clearly, these assets cannot be delivered today, so what we’re talking about is a futures market or prediction market. Any Bitcoin exchange could theoretically make such a market.

The first thing an exchange needs to do is to allow a trader with BTC on deposit to split that BTC into virtual coins that we’ll call Alpha and Beta. Beta will be redeemable for B, if and at such time as a fork happens by a certain date. Alpha will be redeemable for A, if a fork happens, OR for BTC, if no fork happens by the deadline. At any time before the deadline, a trader can also re-combine N units of Alpha and N units of Beta into N units of pre-fork BTC, so traders are not locked into these future assets until the deadline.

https://medium.com/@bendavenport/the-bitcoin-block-size-listen-to-the-market-de9ef6607da5#.71ixfqxs1

https://www.reddit.com/r/Bitcoin/comments/41lw30/the_bitcoin_block_size_listen_to_the_market/

https://www.reddit.com/r/btc/comments/41lzgs/the_bitcoin_block_size_listen_to_the_market/

 

[rocks]

@Zangelbert Bingledack
Great post on the arguments for using economic hard forks as a decision making tool.


This is especially pertinent.
"Anything controversial, on which many reasonable people are in disagreement, is the perfect time for a hard fork. The idea that controversial hard forks are to be avoided is not only exactly backwards, to even entertain the idea shows a fundamental misunderstanding of how Bitcoin works and calls into question everything else one might say on the subject."

 

[cliff]

An issue that seems to be lurking behind every proposal to fork thus far (as far as i know) is that it requires working with something bitcoiners inherently don't like: Trust. Trust requires taking on a multifaceted set of risks.

How can these risks be planned for? Like this.

One idea that might work is an automated fork-escrow that includes automated opening and closing times. In short, a smart contract. A smart contract can synthesize technical and market-based planning and commitments into a very workable ecosystem-wide solution.

Pools would be the parties. The Pools would guarantee X% of their mining power to a pool-of-pools (POP) that would be used to cause the fork. The commitment would have to be enforceable and/or securable, possibly through some kind of automated programming and possibly a market/exchange for making collateral deposits and purchasing insurance or bonds. The POP would stay open until the earlier of a) commitments made to POP exceed some amount (and conditions negotiated by miners met) OR b) the time period lapses. If a) happens first, fork-on - escrow releases after X blocks down the fork. But if b) happens first, fork-off - escrow closes and parties go home and carry on.

This idea is similar to the XT et al 75% mechanism, except that it also includes a binding commitment by pool operators. The advantage of this approach means that some, but not all, uncertainty w/ regards to a hardfork (and commitments therefor) can be reduced.

 

[Roger_Murdock]

Aww yesss! Ben Davenport supports fork arbitrage, complete with an easily implementable futures market aspect, and makes a good post explaining it.

I guess I'm still skeptical of fork arbitrage being all that useful in this context. It seems like the information we want is whether or not the market values a Bitcoin with feature A more or less than a Bitcoin without feature A. But the likely huge gulf in value between two chains following a fork attempt is going to be primarily driven by the fork's likelihood of success, which will in turn be driven primarily by the amount of hash power that triggered it. In other words, once the market determines that over 51% of the network has triggered a fork attempt, an overwhelmingly powerful positive feedback loop will drive miners toward convergence on the higher hash power chain. Imagine two ships that are both taking on water and positioned side by side such that it's easy to jump between them. Either ship (but not both) can be saved from sinking if enough people work together to bail it out. You look around and notice that there appear to be slightly more people bailing out the ship you're not on, such that it seems to be sinking at a slightly slower rate. So what do you do? You jump ship ... which makes your original ship sink that much faster, encouraging even more people to jump ship, leading it to sink even faster, etc. etc. Note that it plays out like this even if some people have a strong preference regarding which ship sinks. (Maybe they're part owners in one -- the "S.S. Blockstream"?) Those people may be among the last to jump, but in the end very, very few will be willing to go down with the ship. My point is that once a fork attempt has been triggered, it should resolve itself very quickly in any case - with or without "fork arbitrage." (This dynamic is why I think it's so dumb to claim that we need "overwhelming consensus" before executing a hard fork. Executing a hard fork will produce overwhelming consensus. Indeed, that's essentially the entire purpose of the blockchain -- to produce consensus!)

On the other hand, it does seem like there should be some way to use markets to figure out whether a proposed feature adds value. So maybe you've got a prediction market that says that there's a 50% chance (to make the math simple) that a particular feature will have been successfully forked into the main chain by the end of 2016. Now imagine that there's a conditional call option to buy Bitcoin at $400 on December 31, 2016 that's only executable if the fork has been implemented, and another conditional call option to buy Bitcoin at $400 on that date if the fork has not been implemented. If the first option trades for more than the second, doesn't that provide evidence that the market thinks the fork would be value-adding?

 

[Peter R]

I love the sinking ship analogy!

This is the way I visualize it:

If the fork into coins A and B were to persist, the combined market cap would be less than if all the value was stored in A or B (e.g., via the Metcalfe value argument).

The combined wealth of each participant is thus greater if they place all the value on (the same) one of the two ledgers.

As long as the "ball" starts on the "correct" side of the hill, I figure we'll converge to the most-valuable coin quite quickly.

 

[JVWVU]

It would be interesting to see which exchanges would operate.

Coinbase Bitstamp and such would operate on Classic while Core would have to use a MPEX solution. Would MP really be insane enough to dump on Coinbase while keeping Core coins?

 

[cypherdoc]

no way MP does that.