Gold collapsing. Bitcoin UP.

[Peter R]

So Pieter Wiulle supports people who want to make the choice of forking themselves off the network by enforcing segwit without the mining majority, but he doesn't support people who want to make the choice to not fork themselves off the network by accepting bigger blocks along with the mining majority.

He's clearly a very intelligent person. It's either cognitive dissonance, or he's walking on grEggShells.

 

[AdrianX]

Support to move the limit seems to be increasing while the new bitcoin enthusiast don't like the old bitcoin. I am looking forward to a lot of cheep coins when we do finally remove the 1MB limit.


Luke-Jr is in there ready to abandon ship.

 

[Tomas van der Wansem]

@Zangelbert Bingledack

As asked, here is my 2 cents.

Although, 973 pages is a bit much to wade through, I think I am aware of some of the arguments against SegWit.

I personally think SegWit is fine though I have two objections:

• The priority makes no sense. Sure we should fix malleability, but the primary problem is fixing the block size. Any cryptographer pushing for SegWit is completely ignoring engineering practices of solving important and urgent matters first.
• I think baby steps are always better, which is why I have a slight preference for BIP 140. The more you change at once, the harder it is to reach consensus (thereby increasing risk). In addition it makes it harder to compare the costs and benefits.

That said, I think many objections to SegWit as a malleabilty fix are flawed.

• Hardfork is better than softfork. Both a hardfork and a softfork require support. Neither can be done with only a minority supporting it. What matters most is what you change. All things equal, a softfork is much easier to deploy so that is a strict and important advantage.
• Discount for witness data is bad. I am not in favor of a blocking limit at all safe for spam, but if there is a blocking limit (aka one that is smaller than demand), I think a weight limit instead of a size limit makes some sense as this better encompass the cost to the network.
  
• SegWit has a "3 body problem". It only does so because of the stupid limit, and even then, I don't see why this is such a problem.
  
• SegWit gives developers more power. I don't understand this at all. SegWit introduces script versioning, but this still requires a softfork for any change, just like now. That said, I am not particularly enthusiastic about script versioning. I think OP_NOP redefinition is cleaner, because you can never deprecate old versions in Bitcoin, which makes versions kind of useless. IF v1 THEN X ELSE Y, is always more complex then X. This is why simple OP_NOP redefinions is more elegant IMO.
  
• SegWit is too complex. For what it changes, SegWit isn't complex at all IMO. This is actually the advantage of changing many things at once, as taking baby steps would result in more complexity overall.
  
• SegWit is hacky as softfork. I don't see much difference in a HF and SF here. The coinbase seems like a reasonable spot to store the witness commitment, as this reduces the amount of "forced" changes to the rules.
  
• SegWit w/o HF breaches Hongkong. I don't think we should rely on off chain agreements.
• Blockstream has a different aganda. I find this hard to believe. I don't think money can so easily buy top cryptographers to destruct bitcoin. Much more likely is that people have difficulty embracing trust-by-financial-incentives model of Bitcoin. As it seems, especially expert cryptographers (which the community trust the most for their expertise) seem to have difficulty understanding this as they are taught to think differently about trust.

That said, I which BU and Classic would embrace BIP 140 and push it to Core, as it has very little against it.

Implementations disagree on the block size, but there seems to be no reason to disagree on a malleability fix. Let's decouple these issues.

 

[awemany]

This all is more and more looking like a war of inside Bitcoin vs. the outside world.

 

[sickpig]

Speechless, this is from Tadge Dryja‏ LN whitepaper coauthor:


Whereas Luke seems to be pretty coherent /s

 

[sickpig]

Yours pivoting to litecoin due to bitcoin fees being too high.

 

[xhiggy]

That said, I which BU and Classic would embrace BIP 140 and push it to Core, as it has very little against it.

The biggest problem with Segwit is the people behind it. They have no integrity and continually manipulate and lie. If we adopt Segwit these people are required to be involved in Bitcoin, and it will be hard to remove them.

Conceptually, there's nothing wrong with having a debate about the witness data being separated. I think it's not the right approach, however I get that others disagree. If this concept is so important it will be re-imagined again, however these people won't change.
[doublepost=1495123543][/doublepost]

Blockstream has a different aganda. I find this hard to believe. I don't think money can so easily buy top cryptographers to destruct bitcoin. Much more likely is that people have difficulty embracing trust-by-financial-incentives model of Bitcoin. As it seems, especially expert cryptographers (which the community trust the most for their expertise) seem to have difficulty understanding this as they are taught to think differently about trust.

Lightning looks like a manifestation of this. Something that was devised in private
https://petertodd.org/2016/mit-chainanchor-bribing-miners-to-regulate-bitcoin

 

[lunar]

 

[AdrianX]

That's a crazy post. we've been lead to believe up until now that we can't do a coordinated hard fork because there is a remote risk of a dangerous split. Wladimir (lead maintainer) should step down.

Reading that post Luke has created a false dilemma with a 75% odds of BIP148 activating - my favorite assumption:

On the other hand, the longer the chain split goes on, the more likely the BIP148 side grows in hashrate relative to the legacy side.

Risks only for BIP148 nodes
Hey, there are none!

http://archive.is/F2SIO for the record.

I think it's very likely that if there is a prolonged split, Core will abandon the legacy chain. But each developer would need to decide for themselves.

I know that personally, I will be sticking to the BIP148 chain. At least Wladimir (lead maintainer) is also running BIP148.

 

[go1111111]

@Zangelbert Bingledack

As asked, here is my 2 cents.

Good to see another person on this forum who thinks segwit is fine.

If we adopt Segwit these people are required to be involved in Bitcoin, and it will be hard to remove them.

I think the "if we adopt segwit, that gives Core control over Bitcoin!" position is false. Are you a developer? Have you read the code? . The code is not so complex that only a grizzled Core dev can work on Bitcoin software after SegWit is adopted. Any competent dev should be able to understand it and make changes. There's nothing really stopping SegWit from being activated and then the economic majority from forking away from Core to increase the blocksize even more.

Speechless, this is from Tadge Dryja‏ LN whitepaper coauthor:

I love this tweet from Taj. It concisely sums up the proper relationship between users and miners.

Many BU folks seem to have a deference to miners, as if they're on "our team" and we should be nice and show loyalty to them. This seems totally wrong to me. There is no need to be "nice" to miners. Mining activity follows price. If block rewards are $X, we'll get $X worth of mining activity. Miners aren't doing us any favors by mining, and we don't owe them anything. The only reason Jihan should have any more say in how Bitcoin works than anyone else is to the extent that he owns more coins than other people.

I'm somewhat surprised that more people here aren't more annoyed with miners. It's in their power to raise block size, but they refuse to. Miners could either activate SegWit, or do a hard fork to 4 MB or 8 MB or something. Either of those would be much better than letting the current situation continue. But they appear paralyzed and afraid to act. Fuck them. If they refuse to enact the will of the economic majority, we need new miners.

 

[AdrianX]

I don't think we should be overly nice to miners. I think they should have no transaction limit and compete for a marginal profit on the cost of producing valid blocks. Miners are late adopters of BU, we have not pandered to them at all, they've come to us.

Users who want a limit or even BIP100 want to give miners more power than they have. Fuck them too.

Users supporting the Segwit or UASF with an active transaction limit are inviting competition that degrades bitcoin security in time. Fuck them too.

I'm not only annoyed with miners I'm pissed it took them so long to act and adopt BU. Before miners adopted BU we were prepared to fork off with a spin-off (Taj position is BU's position 1.5 years ago). The majority of miners are acting like idiots, Jihan and Roger being among the very few independent thinkers.

or do a hard fork to 4 MB or 8 MB or something. Either of those would be much better than letting the current situation continue. But they appear paralyzed and afraid to act. Fuck them.

I fully support this. Not Segwit that solves nothing, It leaves a transaction limit in place and any competition forces fees of-chain onto a Layer 2 transaction network - degrading long term security as the subsidy diminishes.

Competition among miners should grow security and benefit users with cheep transactions. Competition should not move fees of-chain. Miners are killing the long term growth of the network I agree.

I literally give then just this halving to play with before they kill the goose that lays the golden eggs they have to wake up soon. BS/Core developers are also to blame - they have fuck all control, and though miners do what they are told. Miners are taking a long time to wake up.

Exchanges and service providers are Idiots too. They have not prepare for a block of valid transactions with a valid proof of work that is not limited in capacity? Fuck them too.

 

[AdrianX]

 

[xhiggy]

I think the "if we adopt segwit, that gives Core control over Bitcoin!" position is false. Are you a developer? Have you read the code? . The code is not so complex that only a grizzled Core dev can work on Bitcoin software after SegWit is adopted. Any competent dev should be able to understand it and make changes. There's nothing really stopping SegWit from being activated and then the economic majority from forking away from Core to increase the blocksize even more.

No, I operate at a philosophical and social level primarily. If we accept the solution that was hammered home by group x we are accepting group x. It has nothing to do with code and everything to do with the social tendencies of humans.

While there is nothing strictly stopping them, it will be much less likely once it's accepted. The code is essentially inconsequential compared to the quality and motivations of the people involved.

 

[freetrader]

I hope miners and operators of major businesses in the Bitcoin sphere soon realize that all good intention of not splitting the network will be frustrated by Core devs like Luke-jr and the supporters whipped up by them.

And with the Blockstream CEO not speaking out clearly against BIP148, they approve it. Heck, their communications / trolling officers are the ones promoting it - that tells you all.

There is no more good reason to stand on the sidelines, hoping for compromises. This goes double for miners who have been trying to remain neutral. Please support scaling the chain through bigger blocks. A majority hard fork can still happen - don't wait until it's too late for that as well, because then it will be much more difficult for your businesses.

 

[awemany]

@freetrader: Well said. Miners have let a problem grow that could have been nipped in the bud before the HK consensus. To those who didn't see the writing on the wall yet: Wake up!

@AdrianX : Quite funny how their 95% activation threshold is lowering to just 51% now. They must not get >50%. And they won't.

By the way ... where's Jonny1000's calls for extreme consensus?

 

[jonny1000]

By the way ... where's Jonny1000's calls for extreme consensus?

I oppose BIP148.

Here are my calls:

https://www.reddit.com/r/Bitcoin/comments/69v3ts/lets_make_the_uasf_as_safe_as_possible/


I give the Core/SegWit supporters EXACTLY the same advice I have give on this forum again and again:

• No narrow victory. The victory must be resounding and decisive
• Assume bad case scenarios
• No half measures
• Make the hardfork/UASF as safe as possible
• Consensus across the community, before enforcing the new rules
• At least 1 year grace period (patience is important)

Stop accusing me of being a hypocrite, can you not see my messages are exactly the same?

I want a blocksize increase, whether it is done by a UASF or hardfork is not that important to me. What i important is that its done in a safe, calm and patient way.

 

[freetrader]

The UASF does not require a certain percentage of mining support. Otherwise it would be a MASF .
How do you propose to make a UASF "safe" if it explicitly disregards miners?
It's a contradiction in terms. You say

If BIP148 has strong support, I would support it.

Yet, you do not specify any numbers, which are usually your game. So how would you measure that "strong support"? I see...
Number of signatories on a strongly worded letter. That seems safe /s
And further:
Seeing that you seem to be supportive of the idea of a UASF, it is now opportune to ask questions about its safety and correctness.

 

[jonny1000]

So how would you measure that "strong support"?

• Letters of support from the industry and exchanges. As I said, ironically the letter against BU is a great example of how to safety fork and makes a hardfork to increase the blocksize limit much more likely, in my view
• What people say at your local Bitcoin meetup
• Miner flags of support
• What the technical community say
• What economic nodes are running
• If the UASF has been implemented in the popular Bitcoin client software

The letter from the industry may be necessary, but not sufficient for a safe UASF.

Luckily Jihan has released a hardfork with the asymmetric disadvantage is a bad idea. However, a UASF can have something a hardfork cant, the asymmetric advantage.

Seeing that you seem to be supportive of the idea of a UASF, it is now opportune to ask questions about its safety and correctness.

Yes, I support a UASF in principal, just like I support a hardfork in principal. But I want both to be as safe as possible. I am full of suggestions on how to make both safe. To me, the key safety mechanism is:

• A hardfork should not have the asymmetric disadvantage
• A softfork or UASF should have the asymmetric advantage

Therefore, in my view, Classic, XT and BU have it totally wrong

 

[Mengerian]

Some thoughts on BIP100.

Thinking though possible scenarios of a contentious block-size increase hard fork, it seems to me one of the strategic advantages of the big-block chain is that it could clear the mempool transaction backlog quickly.

For example, imagine there is a big-block hard fork at ~60% hash rate support. This would mean that the big-block chain miners would initially find blocks at a rate of about 3.6 blocks per hour, and the 1MB-block miners would find ~2.4 blocks per hour.

This means that the 1MB block chain would have severely constrained transaction throughput, creating even worse backlogs and problems than exist before the fork.

The big-block chain, on the other hand, could start to quickly clear transaction backlog, and maintain high transaction throughput - as long as blocks are big enough to accommodate large increased number of transactions per block.

This gives a strategic advantage to the big-block side in the event of a chain split. You would have a reliable quick transaction confirming chain competing against a high-fee throughput hobbled chain. As long as there is a big-enough block size increase to fit the additional transactions per block.

For this reason, I think it's important that any hard fork to bigger blocks make a significant initial step increase in block size. 2MB may be sufficient, but something like 8MB would provide even more of a reliability buffer in terms of being able to quickly clear the transaction backlog and maintain reliable transaction confirmation.

For this reason, I think that the feature of BIP100 that limits block size increases to smaller increments puts a big-block fork at an unnecessary competitive disadvantage. At least for the initial break from 1MB to >1MB.

 

[jonny1000]

No, I operate at a philosophical and social level primarily. If we accept the solution that was hammered home by group x we are accepting group x. It has nothing to do with code and everything to do with the social tendencies of humans.

We should go for the best technical solution, whoever proposed it.

After all Satoshi is anonymous, yet you use Bitcoin. This was a great example to set, and shows it doesn't matter whose idea it was, only the merit of the idea matters.