Gold collapsing. Bitcoin UP.

[rocks]

Given everything that has happened over the past week, it is worthwhile to read Pieter's statement from last July that core is committed to no changes to the consensus rules essentially forever. This is really when things broke down, or at least they finally showed their true intentions and people started to push back.

He states that developers have no authority to change consensus rules, and without full consensus the default is no change. He also takes the position the economic change to a fee market (actually a user cap) is just something that will eventually happen because oh well we can't change the cap, and there is nothing anyone can do. To some extent this is correct, centralized devs shouldn't make consensus rules, but what they did not understand is change to the consensus rules can and will be done by users when needed.
This post to me also shows a complete lack of ability to lead, he is basically saying that he won't even discuss anything that is slightly controversial, but in a leadership position if you do that and don't make decisions eventually controversy is everywhere.

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009515.html

"Some people have called the prospect of limited block space and the development of a fee market a change in policy compared to the past. I respectfully disagree with that. Bitcoin Core is not running the Bitcoin economy, and its developers have no authority to set its rules. Change in economics is always happening, and should be expected. Worse, intervening in consensus changes would make the ecosystem more dependent on the group taking that decision, not less.

So to point out what I consider obvious: if Bitcoin requires central control over its rules by a group of developers, it is completely uninteresting to me. Consensus changes should be done using consensus, and the default in case of controversy is no change."

 

[solex]

Why does it accept it when it is in a block. I thought blocks were validated too?

Old nodes see SW tx as being signed anyone_can_pay, so they will accept them but remain in the dark about whether coins are being moved by the valid owners. Old nodes become a glorified lightweight client that just knows the UTXO set.

There is a point where a soft-fork is so brutal to users of existing software that they are better off being pushed to upgrade. SW is borderline or in that category.

 

[cypherdoc]

@rocks

i hate that bullshit. as if all the softfork changes they're introducing don't change things. SW itself is a massive change:

"Regarding SegWit, I don't know if you have actually looked at the code but the amount of code changed, including consensus code, is huge. (maybe ~500 lines). I think such change has never been attempted in the history of Bitcoin. We cannot just say lightly that a couple of weeks after the 2mb hard-fork we're going to deploy segwit. That code needs months of review. Also I'm against the complexity of segwit as a soft-fork (probably requires 200 additional lines of code of consensus critical code). Segwit almost prevents consensus-compatible re-implementations of Bitcoin in other languages."
[doublepost=1453142767][/doublepost]

Old nodes see SW tx as being signed anyone_can_pay, so they will accept them but remain in the dark about whether coins are being moved by the valid owners. Old nodes become a glorified lightweight client that just knows the UTXO set.

There is a point where a soft-fork is so brutal to users of existing software that they are better off being pushed to upgrade. SW is borderline or in that category.

no, SW tx's will get ignored and won't relay as they are non std. but they will accept the block that contains them. according to Gavin.
[doublepost=1453143145][/doublepost]oh no, theymos enters Bitcoin Classic Welcome channel to troll.

 

[solex]

@cypherdoc that's not the real thermos

@rocks the comment from F2Pool about not believing in the concept of a fee-market, I think means that they do not believe that the 1MB can force a fee-market.

 

[rocks]

oh no, theymos enters Bitcoin Classic Welcome channel to troll.

When you have a shovel and are head deep in a hole, the only thing you can keep doing is to dig more.

All this does is expose them for what they are to more and more people, and push more borderline people away from core. We should be revealed by this, if everyone in the core camp took a conciliatory approach, they might have been able to keep most of the user base on core and lived to negatively influence Bitcoin another day. But they are not, and in the process losing all future influence. This is what the echo chamber of censorship does to people.
[doublepost=1453144060][/doublepost]

Old nodes see SW tx as being signed anyone_can_pay, so they will accept them but remain in the dark about whether coins are being moved by the valid owners. Old nodes become a glorified lightweight client that just knows the UTXO set.

There is a point where a soft-fork is so brutal to users of existing software that they are better off being pushed to upgrade. SW is borderline or in that category.

They way they forced SW as a soft fork is absolutely crazy. Just think about this implementation.

They are asking users to send completely unprotected transactions according to the old rules, while also not forcing everyone to upgrade to the new rules. What if a majority of the hash rate does not upgrade? SW users are exposed to their coins being stolen. How can anyone think this is a secure solution?

 

[AdrianX]

That seems odd

It's not it's just a new way of looking at the role of non mining nodes.

By guaranteeing to relay block below a certain size miners still have an incentive to mine small blocks.

On the upside should there be a need for bigger blocks miners can make them and the non mining node can still use the network without forking. They have the same function as non relay nodes if block size is bigger than their threshold.

 

[cypherdoc]

Old nodes see SW tx as being signed anyone_can_pay, so they will accept them but remain in the dark about whether coins are being moved by the valid owners. Old nodes become a glorified lightweight client that just knows the UTXO set.

There is a point where a soft-fork is so brutal to users of existing software that they are better off being pushed to upgrade. SW is borderline or in that category.

crap, this seems to confirm what you're saying.

i'll have to double check with Gavin about what he said about old nodes relaying SW tx's:

https://bitcoinmagazine.com/articles/segregated-witness-part-how-a-clever-hack-could-significantly-increase-bitcoin-s-potential-1450553618

 

[sickpig]

from a gmax's post from Jan 2013 (bold is mine)

Bitcoin is valuable because of scarcity. One of the important scarcities is the limited supply of coins, another is the limited supply of block-space: Limited blockspace creates a market for transaction fees, the fees fund the mining needed to make the chain robust against hostile reorganization. I have not yet seen any suggestion as to how Bitcoin is long term viable without this except ones that argue for cartel or regulatory behavior (both of which I don't consider viable: they moot the decentralized purpose of Bitcoin)

nobody can say that he's lacking coherence on this particular matter

 

[rocks]

Spoke too soon on the 80% above. Apparently F2Pool is only behind Bitcoin Classic if it has a 95% threshold and not a 75% threshold. This creates a catch-22 situation where it is not possible to reach the threshold.

If Classic keeps 75%, then F2Pool will not support it. If Classic raises it to 95%, then it is likely too high to get activated, as it would only take BTCC or even a couple small pools to block it.

I will go back to what I said earlier, Classic should view this as an economic fork and set the limit at either a simple majority of 51%, or as a standard super majority of 66%. The 66% threshold is probably doable without both F2Pool and BTCC.

Then after activation we would have a real split, which is fine and it would resolve itself within a day or two. Most miners would be forced to transfer over to the majority, or lose a ton of money if they don't. Given the strong commitment from close to 60% already, a standard super majority is doable.

I am hoping that in the absence of a final Bitcoin Classic release, they are using this time to see the market's response and set the best direction based on that. If I was Jeff and Gavin and looking at the comments out of F2Pool and BTCC compared to comments from the other pools, I would look at different options for the threshold right now.

 

[BldSwtTrs]

Maxwell doesn't understand that the value created by the limited supply is inelastic because the function it's serve (store of value) is price-indenpendent, whereas the value created by the limited blocksize is extremely elastic because the function it serves (transfer of value) is hugely price sensitive.

The store of value function need scarcity to create the max value, the transfer of value function need abundance to create the max value.

Blocksize limit will only drive out the demand and destroy value. He is a freaking moron.

 

[Richy_T]

They are asking users to send completely unprotected transactions according to the old rules, while also not forcing everyone to upgrade to the new rules. What if a majority of the hash rate does not upgrade? SW users are exposed to their coins being stolen. How can anyone think this is a secure solution?

This is kind-of where my thoughts were leading. Thanks.

1)A->B
2)B->C
3)C->D

In order to recognize 3 as valid, one must recognize 2 as valid. Is it really that 2) is B->anyone (But SW nodes know to treat it differently)? If so, that seems like the worst kind of hack.

 

[Peter R]

@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...
[doublepost=1453150367][/doublepost]I also wouldn't include a window to delay the activation. Miners would probably delay producing blocks > 1 MB for a few weeks anyways--just to make sure the other miners and nodes are onboard using out-of-band methods so that their bigger blocks don't get orphaned.
[doublepost=1453150507][/doublepost]Meanwhile, nodes should be running Unlimited, telling miners "I already accept bigger blocks as of TODAY!"

 

[rocks]

The store of value function need scarcity to create the max value, the transfer of value function need abundance to create the max value.

This is the best summary I've seen so far. Thanks

If Bitcoin works as it should, then the economic majority should always favor (and fight for) maximizing value in the system. This would mean protecting the sanctity of the 21M cap while at the same time scaling the system as far as technology will allow it to scale.

So often the blockstream crew claim that if you can change the 1MB limit then you can change the 21M limit. This is true technically, but is a lie because it only tells a half truth. The other part is what you said, that those fighting to change the 1MB cap would also fight to keep the 21M limit.

 

[Justus Ranvier]

The other part is what you said, that those fighting to change the 1MB cap would also fight to keep the 21M limit.

An under-appreciated aspect of this debate is that people who are using logically-incoherent arguments to support the block size limit out of a misguided belief that they are also protecting them issuance formula are just shooting themselves in the foot.

If there ever is a real debate over the coin issuance schedule, all the people who expended their credibility defending the indefensible in this debate won't have any left for that fight.

 

[Zangelbert Bingledack]

Everyone who pushes the "change the 1MB cap and soon the 21M cap will be lost, too" (theymos, Gmax, Mark, and many more) shows they don't even understand the basics of how Bitcoin works. Far from a minor oversight, it's a clear litmus test ruling out any possibility of the person being coherent on the overall question of how Bitcoin works.

It's the equivalent of Peter Schiff saying Bitcoin isn't hard money because it's infinitely divisible, or those people who say gold was fine to use as money 100 years ago, but now the economy is much bigger so "there isn't enough gold to go around." It's that level of "I have no idea what I'm talking about" error. The fact that it is not only mentioned but parroted widely among Core/BS and by their followers shows it's the blind leading the blind. There is no reason to expect any insight from them on how Bitcoin works, and everything they believe about the matter is called into question.

Far from experts on how Bitcoin works, they are proven ignoramuses on the matter in total. Just like the economists who say there isn't enough gold/silver in the world to use it as money, who may have all sorts of knowledge about some aspects of economics, they have gaping holes in their understanding that nevertheless completely disqualify them from being relied on to make decisions about the direction of the project.

 

[albin]

@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.

 

[sickpig]

for those Towns calcs, those are just the "message data" sizes for blocks, right? what are the size totals when you include the witness data? link?

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:

 

[Inca]

Spoke too soon on the 80% above. Apparently F2Pool is only behind Bitcoin Classic if it has a 95% threshold and not a 75% threshold. This creates a catch-22 situation where it is not possible to reach the threshold.

If Classic keeps 75%, then F2Pool will not support it. If Classic raises it to 95%, then it is likely too high to get activated, as it would only take BTCC or even a couple small pools to block it.

I will go back to what I said earlier, Classic should view this as an economic fork and set the limit at either a simple majority of 51%, or as a standard super majority of 66%. The 66% threshold is probably doable without both F2Pool and BTCC.

Then after activation we would have a real split, which is fine and it would resolve itself within a day or two. Most miners would be forced to transfer over to the majority, or lose a ton of money if they don't. Given the strong commitment from close to 60% already, a standard super majority is doable.

I am hoping that in the absence of a final Bitcoin Classic release, they are using this time to see the market's response and set the best direction based on that. If I was Jeff and Gavin and looking at the comments out of F2Pool and BTCC compared to comments from the other pools, I would look at different options for the threshold right now.

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.

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.

 

[Justus Ranvier]

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

 

[cliff]

Everyone who pushes the "change the 1MB cap and soon the 21M cap will be lost, too" (theymos, Gmax, Mark, and many more) shows they don't even understand the basics of how Bitcoin works. Far from a minor oversight, it's a clear litmus test ruling out any possibility of the person being coherent on the overall question of how Bitcoin works.

It's the equivalent of Peter Schiff saying Bitcoin isn't hard money because it's infinitely divisible, or those people who say gold was fine to use as money 100 years ago, but now the economy is much bigger so "there isn't enough gold to go around." It's that level of "I have no idea what I'm talking about" error. The fact that it is not only mentioned but parroted widely among Core/BS and by their followers shows it's the blind leading the blind. There is no reason to expect any insight from them on how Bitcoin works, and everything they believe about the matter is called into question.

Far from experts on how Bitcoin works, they are proven ignoramuses on the matter in total. Just like the economists who say there isn't enough gold/silver in the world to use it as money, who may have all sorts of knowledge about some aspects of economics, they have gaping holes in their understanding that nevertheless completely disqualify them from being relied on to make decisions about the direction of the project.

Big blocks - the gateway drug!