Gold collapsing. Bitcoin UP.

[AdrianX]

This seems to confirm my suspicion or confuse them, the developers advising Coindesk prompted them to write:

"BIP 91 is almost identical to BIP 141, why didn't miners signal support for the latter?"

and Miners: (beveling 2MB hard fork is on the BIP 91 road-map while those advising Coindesc believe it is more like BIP 141 free from a 2MB hard fork commitment.)

the key below denoting BIP91 is intended to avoid the hard fork yet the hard fork is on the road map.

 

[satoshis_sockpuppet]

I'm not really sure what to think of nChain+BU collaboration.

CSW made it sound like nChain was already building another Bitcoin implementation, now they suddenly want to expand the (imho still ugly) C++ implementation?
SW is getting activated soon, where is the 20 % HP pool?

And wtf are Jihan and Ver doing activating SW while the other SW2X signee's are already question the HF part?

 

[albin]

@satoshis_sockpuppet

Pure speculation here, but maybe the lead time necessary to roll out a totally new implementation is prohibitive in having an influence or effect on how the current drama plays out?

 

[Norway]

Information for BU members about the nChain announcement.

We have recently been in discussions with nChain about an initiative they have to create a Bitcoin enterprise company which will leverage Bitcoin for commercial solutions. They wish to use Bitcoin Unlimited's codebase as this version permits massive onchain scaling. Their viewpoint on the technical and economic aspects of Bitcoin are highly aligned with the viewpoints promulgated in this thread and other fora such as r/btc, i.e.that scaling should only be constrained by physical limits, that a growing user-base is the best way to grow node counts and ensure decentralization, that miners are custodians of the network, not adversaries, that all participants have an economic interest to collaborate, that fees should be wholly market-driven and not subject to the cancer of quota-rent.

The nChain Bitcoin enterprise will be analogous to RedHat and BU's software analogous to Linux in this future scenario. Hence, BU's software will benefit from testing, QA, technical feedback, and market-driven development.

There is no change suggested to the BU organization, and any financial expenditure on projects, and functional changes to the BU client will remain subject to membership approval or veto by BUIP.

There is a 2-day workshop in Vancouver, BC, this month, and we can provide more information about first steps after that event.

Bullish!

 

[awemany]

@solex, @satoshis_sockpuppet , @Norway, @bluemoon, @albin:

Personally, I like to stay away from all things nChain or CSW.

In general, I see it like this:

Case a): CSW and nchain is a scammer with his scam company: Easy, I don't want anything to do with that.
Case b): CSW is affiliated with or (part of) Satoshi and nchain isn't a scam: Cool, do whatever you like. However, you clearly made sure with all your actions as much as possible to be seen by everyone as a scammer (to hide your true identity or get plausible deniability, or whatever). I will respect that and thus will also act exactly ike for Case a) above ... Which after all is all you asked for.



Now, that he uses BU to build something else is outside of my influence, though. Same with what other members think, of course. But I do think it is prudent to stay clear.

Finally, @satoshis_sockpuppet brings up a very important point: nChain would have needed to signal S2X-disagreement by yesterday. That didn't happen, which is yet another piece of evidence for Case a) above.

 

[Christoph Bergmann]

What I don't like is that we did not see any proof of development activity by nChain.

On the other side I look forward to see people I trust - Solex and theZerg - cooperating with nChain, because this will us get closer to an answer to the question if nChain is a real company developing a real solution, or if they are a Potemkin village simulating development activity to get money from investors.

 

[freetrader]

@satoshis_sockpuppet

Pure speculation here, but maybe the lead time necessary to roll out a totally new implementation is prohibitive in having an influence or effect on how the current drama plays out?

What happened to Prometheus ?

 

[bluemoon]

Personally, I like to stay away from all things nChain or CSW.

I am not a BU member so perhaps it is not for me to say, but I would trust Solex and theZerg to make their own judgments in dealing with CSW.

I do not know CSW and have not met him. While his links to Satoshi are a matter of curiosity, they are irrelevant to dealing with him. What really matters are the quality of his ideas and any support he can offer or synergy he can bring.

Is he a scammer? I don't know. He is a maverick; making claims and threats which turn out to be hollow or empty will not help his credibility. Yet provided those who deal with him exercise some caution and retain independence of judgment and action I see no great harm and possibly some good resulting.

There are many actors out there with misunderstandings, impure motives and conflicts of interest, but the real scammers and manipulators are Blockstream Core and their backers and fellow-travellers.

 

[adamstgbit]

see here: https://www.reddit.com/r/btc/comments/6ofaiu/after_exploring_uahf_details_below_bitcoin/

classic is going to join the bitcash movement!

a very interesting quote from that is

include malleability fixes
...
It is just a different way to create a specific signature in a transaction. It is the minimum invasive change because it is also optional. It is great because it allows you to protect your transactions to be replayed on a different chain at the same time.

without understanding too much of this, i must say... BU NEEDS to get onboard with this change, and do the same thing with its "special bitcash client".

 

[AdrianX]

I will attend the meeting. I understand theZerg won't be there in person I expect Peter R, solex and Peter Tschipper.

I haven't met Peter T (a key BU developer) so that'll make for an interesting dynamic

The meeting is with "nChain"? not specifically CWR and I'm not sure he will be attending give nChain is based in the UK, and nTrust based in Vancouver.

 

[adamstgbit]

lockin is expected to be official within about 3.33hours

 

[Peter R]

I read through the Bitcoin Unlimited critique paper by Ren Zhang and Bart Preneel in more detail this afternoon. It's actually a well written paper and, if framed differently, supports a lot of BU's ideas.

For example, the strategies they identify and study in Section 3 and 4 where an opportunistic miner can get more than his fair share of the block rewards (and one reason they say BU is "not incentive compatible" [1]) all depend on the other miners having different block size limits. We know this already and do not consider it a weakness. If miners really want to have different block size limits they can just modify the code and recompile (the point is they don't want to have different block size limits).

They then show that in the absence of an official limit a Nash equilibrium exists where all miners set the same de facto block size limit. This is of course in line with our thinking and forms the basis of the idea that the devs don't need to hold the miners' hands. Tools like BUIP055 are designed to help miners synchronize changes to the de facto block size limit.

The authors then introduce a new idea in Section 5: the idea that there is a "maximum profitable block size" where any given miner becomes unprofitable. They go on to construct a simple model and use that model to argue that the hash power majority will create very large blocks in order to drive inefficient miners out of business. They say:

"When all miners are profit-driven, it is rational to deliberately create larger blocks to force weak miners to leave the business, so that the remaining miner can get larger share of the mining rewards."

I think their proof of this is the weakest part of the paper (actually I don't think they proved anything in this regard). Inefficient miners are driven out of business when their cost per hash is no longer competitive, for the reasons Nicola Dimitri explained in Arnhem. Intuitively, I would expect the "cost" of dealing with larger blocks to be small compared to the costs per hash, and so I don't think this strategy would be practical.

But I don't see how this strategy would work in theory either. If there were no block size limit at all, not even a de facto one, and let's assume that the cost of dealing with larger blocks were significant, under what conditions could a miner increase his profits by producing large spam blocks?

I've invited one of the authors here to explain this in more detail -- hopefully he joins us.

[1] On a related topic, I think the idea that a miner's revenue share needs to be perfectly proportional his hash power or else Bitcoin is "not incentive compatible" is misguided. Miners are driven more by profit than revenue and so their cost structures IMO are much more important than little tricks they may or may not be able to do to earn an extra 0.2% here and there. How can you be worried about a miner deploying a strategy to increase his revenue by 1% and not be worried that the least efficient miners have cost structures several hundred of percent more than the most efficient.

 

[adamstgbit]

They say:

"When all miners are profit-driven, it is rational to deliberately create larger blocks to force weak miners to leave the business, so that the remaining miner can get larger share of the mining rewards."

they'd end up forcing every single non-minning node off the network before they get to the "weak miners"....
what's the point of getting a larger share of half dead network?

 

[Peter R]

@adamstgbit: Good point!

Another important part of BU is that nodes signal a block size limit too and this helps establish what the greater community thinks is a reasonable size, and so miners would be unlikely to cross that limit for the same reasons they are hesitant to cross the 1 MB limit today.

But even if we ignore that and just imagine a network with only mining nodes, I still don't understand the conditions under which a miner could benefit by producing large blocks of spam.

 

[awemany]

Now that SegWit is locked in, I guess it is time for its proponents to deliver...

... the decentralized LN without hubs and spokes.

I think SegWit will be underwhelming, but what do I know... In any case, looks like the miners gave Core the opportunity to deliver on that front. Optimistically, this will be the final, closing chapter of Core's influence, as I think they'll have a very hard time to make good on all their PR promises. "Be careful what you wish for, you might actually get it."

Given that this is a very late variant of the infamous HK consensus, they can't complain that they haven't enough time to prepare their LN awesomeness. As that is supposed to be ready to go now, with turn-key activation.

But I am not an optimist anymore, and the effectiveness of their propaganda to twist basically everything 180deg has been thoroughly proven.

 

[awemany]

Oh I also want to make a prediction: The next real bubble starts around the time when the 2MB HF is going to activate, if it is going to activate. Likely in november. Not now. I can see up to $5K until November (depending on likelihood of HF), but I think only the HF to bigger blocks happening will actually trigger the next frenzy.

 

[satoshis_sockpuppet]

what's the point of getting a larger share of half dead network?

The good thing about game theory is, that you can "simplify" your problem to any point you want to. Too be fair, Peter R's (still great) talk about Segwit has a similar problem, the real world isn't a game theory laboratory. And empirically, miners have shown to work for and not against the network overall.

I guess you could create a game theoretical paper, that Bitmain shouldn't sell their miners (and instead mine themselves with every ASIC they produce) as well as the direct opposite without logical mistakes, just by tweaking your premises.

Btw, the price for most consensus in a single sentence goes to the inventor of Bitcoin minus inflation control:

a rushed hard-fork doesnt have consensus but maybe something related can find consensus if people try to reach consensus

 

[awemany]

@satoshis_sockpuppet : LOL. Skimming his comment as I expected the usual, I didn't even see that he used consensus three times in one sentence. (archived: https://archive.fo/ASIIE)

He also certainly seems to like the word 'collaborate' - and once again, it is in there.

Looks like Blockstream is all about agreement, collaboration, warmth, interaction, togetherness, happiness, consensus, closeness and so forth.

 

[Peter R]

Here is Ren Zhang's response to my comments above regarding the BU critique paper (unfortunately, he wants to keep the discussion on Reddit):

Thanks for the invitation. I think it is better if we keep our discussion on Reddit, which is easier for people holding different opinions to follow.

I really appreciate that you read the paper so thoroughly. I feel like the paper fulfills its mission and touches the "targeted" audience. I'm glad we agree that certain amount of centralization is necessary at current stage. Therefore the key question is how we can introduce the least amount centralization to protect the decentralized nature of the system. In that sense, our paper indicates that BU might end up deviating from its goal.

Come back to your feedback on the paper.

The purpose of this paper is not to predict the future, but to point out several attack vectors opened by BU. These attacks are similar to the selfish mining attack, which, also, might not happen immediately, but still considered one of the most important attacks in Bitcoin mining protocol. We believe protocol modifications should avoid opening new attack vectors, rather than lowering the threshold of attacks.

I understand your point that within certain incentive model (yet to be formally defined), miners don't want to have different block size limits. However a protocol design should consider all incentive models. As I haven't seen any persuasive analysis of miners' social choice of EBs under all incentive models, from my perspective, it is still early to say chain-splitting attack is "not a weakness".

We proved in the "block size increasing game" that the consensus on EB requires a delicate condition, which is very fragile in reality. You refuted this result with two arguments: first, "cost of large blocks" should be small when comparing with "cost per hash"; second, our paper does not mention how big block miners can drive weak miners out of the business.

About the first argument, the condition might not hold in future. I agree that intuitively, the variation of (computational) "cost per hash" is higher than that of "cost of large blocks" for the moment. However, in theory the hashing cost has a fixed upper bound, whereas the latter does not: we don't need to explicitly bound the hashing cost, but we do need to manually bound the cost of large blocks by having a de facto block size limit (32MB currently). In other words, the latter can be a lot bigger than the former.

About the second argument, a simple scenario is when the network is filled with spam transactions of low fee and few real transactions with high fee, miners with slow connection would either be forced to mine empty blocks and give up the transaction fees or buy (expensive) bandwidth to download all transactions and huge blocks to filter the spams and real transactions already mined. These options lead to higher cost and lower profit for the weak miners.

In fact, if BU truly believes that miners' profitability is not affected by blocks of arbitrary sizes, why having the EB mechanism? Why don't have "no block size limit at all"? As I see it, BU is designed to protect the benefits of the majority, including slow miners and slow public nodes. However, the current BU design might fail this purpose as the effective block size is largely decided by the big miners, and I believe there is an inconsistency to rely on big miners' good will to protect the small miners and public nodes.

Two small notes:

1. The analysis on BU in the paper was based on the release in March 2017, thus it would be an interesting task to analyze whether BUIP55 changes the ecosystem. I think it strengthens the system in a limited incentive model.

2. We tried to analyze the equilibrium when there is no block size limit, however we didn't manage to find the proper tool to deal with this setting. We have some preliminary results that it is bad, but we find it hard to evaluate “how bad”. It would be an interesting topic for future research.​

 

[satoshis_sockpuppet]

@Peter R

I'm glad we agree that certain amount of centralization is necessary at current stage.

Am I misreading something or didn't you just paraphrase what they think is right?
Personally I heavily disagree with the sentiment of that sentence. The current stage can already
be "free and unbound" for the protocol.

but still considered one of the most important attacks in Bitcoin mining protocol.

Selfish mining also, as every game theoretical work, doesn't take a miners interest in a healthy network into consideration.

I understand your point that within certain incentive model (yet to be formally defined), miners don't want to have different block size limits. However a protocol design should consider all incentive models.

That is impossible.

However, in theory the hashing cost has a fixed upper bound,

How so?

the latter can be a lot bigger than the former.

Theoretical possible, very unlikely given the real world data.

These options lead to higher cost and lower profit for the weak miners.

If you don't invest into your infrastructure you might have a lower profit in the long term.
Where is the problem?
Why don't we force Amazon to run on Rasperry Pi's to have a level playing field for every small bookshop in the world?

Why don't have "no block size limit at all"?

Fine with me.

and I believe there is an inconsistency to rely on big miners' good will to protect the small miners and public nodes.

Every miner wants to mine coins they can sell, they can't ignore the rest of the network, if they don't want to mine just for themselves.

The other way around, how much should we lower the blocksize limit to protect "small miners and public nodes"?

And why on earth are miners following the current blocksize limit of 1 MB if they are not interested in the rest of the network? If miners behaved the way, they are modelled in these scenarios, we wouldn't have any BS related discussions.


It's understandable, that game theorists like to tear up Bitcoin, but so far they are living in a different galaxy. The miners do as Satoshi instinctivly foresaw. Economics is complex and not easy modelled. People fail to build mathematical models for much simpler economical environments. Honestly I think we could resolve the debate by using common sense.

As PeterR already said, all these ideas have one big problem: Who sets the rules.
They all want to protect decentralization by centralizing the ruleset. And even if you think, that "you need a little centralization now", I'd like to see a fucking concrete example, how in god's name that is supposed to happen. No academical abstraction. A concrete way, to determine what the rules are today.

It will come down to: Github repository X.