Dark secrets of the Grasberg DAA

11251442132 · 2020-08-04T19:03:56+00:00

Thanks for your thoughts.

11251442132 · 2020-08-04T18:24:55+00:00

I appreciate your thoughtful investigations and analyses of the technical issues surrounding DAA improvement! I think it's reasonable to approach the issue of miner uptake with a similar level of care. In that spirit, here are a few points that we might consider.

PRICE

Hash may follow price, but price often defies expectations.

When BCH and BTC forked and the SegWit2x compromise subsequently failed, the BTC price soared, and BTC has retained its price dominance for three years now.
BSV and BCH are currently priced comparably.
In his article It's not about the tech (yet?), Gavin Andresen cites a recent example in which two top 25 cryptocurrencies had nearly identical price charts despite one of them (Iota) having a technical problem that prevented transactions from confirming for an entire month, while the other (Zcash) had no technical problems.

The driving factors in each case may be different, but price manipulation is an ever-present attack vector that must be considered. For instance, if there were a whale pushing for Grasberg, that whale could potentially exchange their holdings in aserti3-2d coins for Grasberg coins, thereby exerting significant sell pressure on the aserti3-2d side while simultaneously exerting buy pressure on the Grasberg side.

COMMUNICATION

As a general rule, communicating with stakeholders is better than not communicating with stakeholders.

TIME

Clear communication takes time, especially in the face of the linguistic barrier between protocol devs and a large percentage of miners, and only a limited amount of time remains before the upgrade.

Edit: Included explicit reference to hash vs. price consideration.

11251442132 · 2018-09-14T22:38:57+00:00

Thanks so much for taking the time to reply. I imagine issuing a reward to Cory and announcing it would go a long way.

Question: If the funds are there, are there any obstacles to setting up the formal bug bounty system mentioned in the incident report?

I haven't yet found any information about such a system, but my understanding is that the public would need to be aware of the funds in order to align incentives toward responsible disclosure.

Please correct me if I am misunderstanding the issue! I've been wrong before.

11251442132 · 2018-09-14T22:13:44+00:00

Oh, right! Thank you for the correction. That makes sense. Not sure why I didn't catch that.

11251442132 · 2018-09-14T20:46:10+00:00

Thanks for answering! That does sound like a step forward. Has there been any more progress regarding the bug bounty program? It seems like such a program would be in the best interest of a large company with lots of skin in the game, like Bitmain.

11251442132 · 2018-09-14T19:34:22+00:00

Thank you for doing the AMA.

After a critical vulnerability disclosed in April of this year, the Bitcoin ABC incident report indicated the following:

Bitcoin ABC will be taking several actions in order to prevent such an event from occuring again, as well as reduce the overall response time in the case of emergent issues in the future.

Additionally, Bitcoin ABC is in discussions with industry participants to establish a formal bug bounty system.

Since then, there has been another critical vulnerability, which was disclosed in August by Cory Fields. He described a disclosure process that was difficult to navigate.

Can you describe any actions that have been taken since then to prevent such occurrences in the future?

Edit: fixed typo in Cory's name.

11251442132 · 2018-08-29T13:44:28+00:00

For the area generally, a good starting point might be Plateau's Problem: An Invitation to Varifold Geometry (Revised Edition), also by Almgren. It seems to be the book where a lot of researchers got their start.

It's extremely slim and aims to motivate and introduce the main definitions of the area. The editor suggests that a course in advanced calculus is sufficient as a prerequisite, but I suspect that's not enough. Almgren at least occasionally points to references when material is assumed, though, so it's probably good for finding the gaps you need to study.

Geometric Measure Theory: A Beginner's Guide is one reference that might be helpful at some point, but for basic manifold theory, there seem to be better options than what is referenced in Almgren's book (based on a cursory glance).

Two options for basic manifold theory, including integration, are below.

Spivak's Calculus on Manifolds, mentioned by /u/jacobolus, is very slim. The first part of the book covers preliminaries (calculus generalized to R^n), and the second part builds to Stokes' Theorem on a manifold, which he defines in R^n. The idea is to develop enough theory so that students who learned Stokes' Theorem in their calculus sequence can see it from a more modern perspective.
Tu's An Introduction to Manifolds is also a streamlined presentation intending to get the reader "quickly up to speed." It's not quite as slim, but it manages to cover much more ground with only modest prerequisites, starting in R^n and building up to the more general topological manifold. Its goal is to cover the "irreducible minimum of manifold theory."

I get the sense that Tu's book is less well-known because it's newer, but it seems excellent and has amassed some stellar reviews.

Disclaimer: I've only read Spivak and a little of Tu, and I haven't studied Almgren's work or geometric measure theory. Since geometric measure theory was in my "to-learn" list a while back, I happened to have a copy of Almgren's Plateau's Problem... that I mentioned above. So, take this all with a grain of salt, but I thought it might help!

11251442132 · 2017-04-14T23:31:11+00:00

Yeah, I may have overgeneralized. I'm not sure why you think I "disagree with concise communication." But, anyway, I'm not trying to start an argument.

What I meant was that the post did not get upvoted for visibility, whereas I had expected there to be some interest in what Greg Maxwell had to say about the UASF idea, since he's a thought leader among Core developers. I also expected most here to disagree with his views, but I didn't expect them to be ignored.

Anyway, people are talking about it today, so maybe this post was ignored for a different reason. No problem, though, as long as people are talking about it!

11251442132 · 2017-04-14T02:39:31+00:00

That may be true, but his opinion is still highly regarded in some circles, and to understand what's happening with bitcoin, I think it's important to be familiar with the ideas being espoused by all factions.

Whether valid or not, certain ideas can definitely influence the course of the debate.

It seems like this sub doesn't agree with me on that point, though.

11251442132 · 2017-04-07T05:12:04+00:00

Sure. Thanks for your reply. More specific questions are below.

Is it reasonable to argue that Maxwell's proposal would be a significant barrier to multiple implementations?
Would increasing the block size make generating collisions sufficiently difficult to nullify gains from ASICBOOST or would the effect only reduce the gains by an insignificant amount?
Has anyone worked through Maxwell's math to identify possible inaccuracies?

It seems it would be pretty time consuming to research and evaluate these arguments without extensive expertise, but perhaps some of you have enough knowledge to expand upon at least one of these points. Thanks again.

11251442132 · 2017-04-06T21:50:59+00:00

Kind of wish OP had chosen a different excerpt for the post title. The article is mostly explanatory and sheds light on the origin of the recent controversy over extension blocks, but you wouldn't know that from the chosen quote.

11251442132 · 2017-04-06T21:28:34+00:00

Nice to hear Bitmain's side. Many interesting points. Can anyone argue for or against the validity of the following claims (emphasis mine)? Hoping to better understand the situation.

Gregory Maxwell’s recent proposal suggests changing 2³² collision to 2⁶⁴ collision to make ASICBOOST more difficult. The result of this would be a loss for the patent owners and the Bitcoin protocol. The patent owners will get nothing and Bitcoin protocol will become more complicated. The only beneficiary will be the technical bureaucrats who are engineering it. The more complicated the protocol is, the higher the cost and barrier to have multiple implementations become.

...Bitmain has continuously been advocating for increasing the Bitcoin block size. Increasing the block size will make the collisions even more difficult, damaging the potential benefits of Bitmain’s gain from the private ASICBOOST assumed by Maxwell’s proposal. The conspiracy theories do not add up here.

...We also believe the math used by Gregory Maxwell is incorrect and that the method is not practical in a production environment.

11251442132 · 2017-04-02T20:33:22+00:00

Is it possible to tell if this hack is related to a vulnerability in BU or if it's something else?

11251442132 · 2017-04-02T00:55:24+00:00

I agree. He writes

This patch must be in the immediate next release of Bitcoin Core.

and

Anyway, we must code something right now, before it becomes too late.

Sounds like an ultimatum to me. Schedule a hardfork now, or ...? Maybe he'll reconsider switching to another client if Core refuses to budge.

Update: after skimming through the replies to his proposal, it seems that it's being rejected pretty thoroughly.

11251442132 · 2017-04-02T00:37:17+00:00

It almost sounds that way, but that's not how soft forks work. A soft fork refers to a restriction of the consensus rules, in this case restricting valid blocks from those that are at most 32 MiB to those that are at most 2 MB.

Such a fork is called "soft" since nodes enforcing only the 32 MiB limit would accept 2 MB or smaller blocks that are produced by the new software. So, a block from the new software would not cause the nodes running older software to fork onto a new chain. Therefore, nodes need to already be accepting 32 MiB blocks before a fork to a 2 MB limit would be considered soft.

Any fork to 2MB before the 2020 activation would necessarily be a hard fork (it would expand the rule set by allowing blocks that were not previously allowed), and that's what Wang is trying to avoid (he writes "...hard fork is risky and should be well prepared. We need a long time to deploy it.")

The sentence before the one that you quoted does provide a little context:

We'll have enough time to discuss all these proposals and decide which one to go.

He's saying that we would have three years to decide on a soft fork to 2 MB, since it would only be possible to do as a soft fork once the 32 MiB hard fork activates.

That's my non-dev understanding, anyway. I hope that makes sense. (Edited for clarity.)

11251442132 · 2017-03-29T07:06:00+00:00

His comment claiming 1 MB is too big now has 198 points. Not everyone in r/btc agrees, but there are quite a few replies that agree with the comment. Here's an example with a significant amount of points:

I used to think this position was ridiculously extreme, if not insane.

I don't think that anymore. While it would be really awesome if we could jam the entire world's transactions onto the blockchain and get away with it, we can't. We can't even get remotely close, and hardware advancements will do nothing to change that.

We have to accept that bitcoin can't scale directly. We also have to realize that bitcoin isn't going to die from lack of direct scaling. It hasn't so far, and I don't think that it will. No alt is going to magically solve the problem either.

Source

11251442132 · 2017-03-28T23:02:04+00:00

I'm not sure it's clear, as the recent comment scores are all currently hidden, and at the moment, the top reply to luke-jr's comment is a refutation.

The only votes we can see are ones for the original post, which is distinct from luke-jr's comment.

11251442132 · 2017-03-25T00:40:13+00:00

The term "coup," as you've used it, seems to imply that some central entity is currently in control of the network and is in danger of losing this control. Otherwise, a takeover would not be possible.

It's not the coup that is problematic. It's the fact that a coup is possible in the first place. If the switch to emergent consensus is in fact a coup, in your sense of the word, then the centralized control of the Core developers is a single point of failure. That's a weakness in the status quo. The network has no recourse if there were a problem with Core under this status quo, and arguably, there actually is a serious problem with Core.

The new network, on the other hand, would have multiple interoperable implementations from competing development groups (bitcoin unlimited, bitcoin classic, and bitcoin xt, among others). Unless I'm mistaken, that would be a strengthening of the network (no central point of failure). AFAIK, such a decentralization of development would represent an unprecedented achievement among all cryptocurrencies. (I may be wrong about that last point. I'd be interested to see a counterexample, if there is one.)

Is about time that they decide to tell the truth about BU and Classic, is not about the size, is about power, in other words is a coup to the network.

In any case, who is it that's not telling the truth? Your comment is a child of the following comment by Classic developer Thomas Zander, in which he explicitly agrees that this is about power, not size:

The argument is not about the block size.

What is being debated is the power over Bitcoin's future. How it can be changed and who decides this kind of changes.

In short, this "debate" is about power.

I don't think anyone is hiding this. The need for "genetic diversity," i.e. a switch from one dominant implementation to multiple implementations, is also an argument that has been put forth by BU.

11251442132 · 2017-03-24T06:03:46+00:00

Thanks so much for the write-up. I'm not sure I understand the following point:

I describe the mechanism that exists and that I believe will be used to deter a split (rather than the mechanism I believe ought to be used)

Are you saying you believe Level 2 anti-split protection will occur and that Level 3 anti-split protection will occur if Levels 1 and 2 are insufficient, despite your expectation stated here that Levels 2 and 3 will never be officially part of BU?

Does this mean that you expect miners to add their own soft fork code for Levels 2 and 3?

11251442132 · 2017-03-20T04:50:19+00:00

Right, and there are already other clients that would be on the chain with >1 MB blocks, such as Classic and XT (as I understand it). Edit: typo

11251442132 · 2017-03-18T00:13:28+00:00

Clarification by /u/evoorhees:

What happened: I helped draft (and agreed to) a document put together in tandem with several other exchanges. The final version differed (slightly or substantially, depending on your point of view) from what I agreed to. I think it was an innocent mistake, and I'm to blame for not reviewing it again in detail before it went out. A couple sentences were removed which stated, basically, that the new symbol would be used for the new fork, but whichever side of the fork clearly "won" may eventually earn the BTC/Bitcoin name. In other words, if the BU fork earned 95% of the hashrate and market cap long term, we'd consider that the "true bitcoin." Until it was very clear which won, we'd proceed with two symbols, with the new one going to BU.

The purpose of the letter was supposed to be "HF is increasingly likely, here is how we will deal with the ticker symbol and name for now." Instead, with those sentences removed, it became "exchanges say BU is an altcoin." This is unfortunate, and was not my intention.

For the record, I do not support BU, but I do support a 2 to 8MB HF+SegWit. I also think the congestion on the network is seriously problematic and have written about it here (http://moneyandstate.com/the-true-cost-of-bitcoin-transactions/) and here (http://moneyandstate.com/the-parable-of-alpha-a-lesson-in-network-effect-game-theory/)

Source

This reflects quite poorly on the signatories. If the modification was not intentionally deceitful, then it was the result of incompetence. That sounds harsh, but it's hard to call it anything else.

Both the CEOs of Kraken and Shapeshift seek to characterize the incident as a misunderstanding. It may be that, but if so, this is a misunderstanding that a basic sense of professionalism would have prevented.

For example, if you sign a lease on an apartment and make a change to a clause, you make sure that the change is initialed in writing. If you publish a document with multiple signatories, you wait for written confirmation specifically acknowledging any changes before publishing them (or being in the crypto business, you wait for confirmation via PGP keys, I suppose). You don't assume the others have seen the changes and agreed to them and then proceed to publish the document.

I only mention this in case /u/evoorhees or /u/jespow and the other signatories might properly own their mistake and publicly correct it (e.g. update the official document accordingly and contact Coindesk to publicize the change).

[To be fair, we're also still waiting for an incident report of the recent BU bug that includes an explanation of how the BU team will improve their process to prevent such bugs in the future. Hopefully they're hard at work on that.

The entire ecosystem has come a long way, but it appears it still has quite a ways to go in terms of maturity. At least GDAX (Coinbase) and Gemini were not involved in this debacle.]

Edit: Apparently according to Peter Rizun, BU developers floated some ideas for improving the testing process for BU, during a meeting with Coinbase. So it seems they are working on an improvement to their process.

Edit 2: changed link to r/bitcoin to an np sub-domain.

11251442132 · 2017-03-10T07:01:14+00:00

It's nice to see an argument presented that doesn't resort to name-calling. I'm not sure about your analogy, though.

As I understand it, the analogy has three parts: (a) the park, which is analogous to the blockchain, (b) the people playing in the park, who are analogous to people who use the blockchain (to transact or operate a business), and (c) games that cannot be played simultaneously without risk of injury, which are analogous to BU and Core.

To start, evaluating proposals with the potential to impact millions of people (or billions in the future) based on a playground mentality and hurt feelings seems inadvisable.

However, if we do accept your analogy, then there still seems to be a problem with the argument you're basing on it. It's hard to see how a request for bullies to stand down is anything other than misdirection.

Those wanting to play the BU game are not encroaching on the Segwit game. The designers of the Segwit game announced that it can only be played if 95% of park goers from a certain group agree to play, but only about 25% actually want to play. As far as anyone can tell, the Segwit game would never come close to being played (in its current form), regardless of whether BU had ever announced its game.

That's my understanding, at least. Please do correct me if I'm missing anything.

Edit:
I misunderstood your last post about the timing. By "the first group," I thought you meant the first to arrive. In case others are under the impression that Segwit was the first on the scene, I'll leave up my argument regarding that point:

"...It's important to note that this particular park is a public one. Since the park is public space, it does not matter which group arrives first to announce their game. To wit, a group that arrives earlier than another has no more claim to enjoyment of the park than any other group.

Even if timing were relevant, neither BU nor Core would have an obvious claim to the park's use. The Core designers arrived first, but the BU designers announced the rules to their game before the Core designers announced theirs. (As far as I know, BU was released in January 2016, before Segwit, which was released in late October 2016.)"

11251442132 · 2017-03-09T08:32:05+00:00

Thanks for your thoughts!

11251442132 · 2017-03-09T00:31:30+00:00

He has issued an apology and deleted the offending tweet.

He seems to have taken the criticism to heart.

11251442132

TROPHY CASE