Subject: File No. SR-NYSEArca-2017-06 From: Matt Corallo Sep. 11, 2017 I am Matt Corallo, a long-time developer of Bitcoin (around the 10th publicly recorded individual to contribute to the Bitcoin codebase), an expert on Bitcoin's operation, vocal Bitcoin advocate, and strong proponent of the availability of a Bitcoin Exchange-Traded Product (ETP). I have very grave concerns with the proposed rules for the maintaining of Bitcoin deposits and the lack of consumer protection in the event of Bitcoin Network rule changes in the current filings. As described in the S-1 filing for the "Bitcoin Investment Trust" (BIT), a "permanent fork" of Bitcoin may occur when two groups of users disagree as to the rules which define the system (its "consensus rules"). More specifically, such a "permanent fork" is likely to occur when one group of users wish to make a change to Bitcoin's consensus rules, while another group does not. This leads to two cryptocurrencies, and may lead to significant ambiguity around which should be referred to as "Bitcoin". The latest S-1 filing by the BIT, allows the BIT to, in the event of a permanent fork, "in consultation with the Index Provider, select a Bitcoin Network"; ie they will be allowed to select any cryptocurrency resulting from a permanent fork which they will term Bitcoin, with no clear restrictions. This creates a gaping divergence of interest between the Sponsor and the investors in the proposed ETP. Digital Currency Group ("DCG"), as the sole owner of the Sponsor, in conjunction with TradeBlock (the "Index Provider", in which DCG is an investor) would be enabled to, through such a selection, shift significant value towards one cryptocurrency over another. As an investor in numerous Bitcoin startups, DCG further has a strong incentive to encourage rule changes and adoption of cryptocurrencies which benefit their portfolio companies as well as their own operations, possibly over rule changes which benefit the investors in the proposed ETP. Further, in the currently-proposed rule changes, DCG is not explicitly barred from trading on the value of different cryptocurrencies prior to the announcement of the BIT's decision as to which fork will receive the future attention of the proposed Bitcoin ETP, and its investors' capital. Finally, it is important to note that, in the event of a permanent fork, there is likely to be significant market confusion as investors, businesses, and users decide which cryptocurrency they will term "Bitcoin". During this time period, the BIT is not restricted from selecting a cryptocurrency immediately (as it did on July 28th with respect to the Bitcoin Cash fork two days later ), nor restricted to selecting the cryptocurrency which the majority of the Bitcoin community terms "Bitcoin". In such a scenario, the BIT could cause significant longer-term market confusion, effectively misrepresenting itself to consumers, all while complying with its currently-proposed rules and filings. These scenarios are possibly best illustrated by the case of the Ethereum/Ethereum Classic fork, which the BIT S-1 lists as a prime example of such a "permanent fork". DCG invested heavily on one side of the fork, almost entirely at odds with the remainder of the Ethereum userbase, businesses, and exchanges. While the vast majority of market participants in Ethereum shifted their value to the new Ethereum Network, DCG promoted and invested in Ethereum Classic. If DCG had, at that time, owned the Sponsor of an Ethereum ETP under the proposed rules for the BIT ETP, they would be free to, and perfectly justified under the S-1 in, declaring the ETP to hold only Ethereum Classic, potentially to their own gain, and to significant market confusion. Recently, DCG and some of its portfolio companies have been strongly promoting "Segwit2x" (a proposed rule change to the Bitcoin Network). While it is still months off, the Bitcoin community is already split in whether it should be adopted, very likely leading to such a "permanent fork" and a debate over which cryptocurrency should be termed "Bitcoin" and which should adopt a new name. It is still very much an open question which cryptocurrency exchanges will adopt the BTC ticker symbol for, and whether significant market confusion will result. As a final note, the latest BIT S-1 claims that "as a practical matter, a modification to the source code only becomes part of the Bitcoin Network if accepted by participants collectively having a majority of the processing power on the Bitcoin Network". This may be somewhat misleading as it conflicts with the previous S-1 statements that the BIT is allowed to select a cryptocurrency which results from a permanent fork freely. Additionally, were it to be the case that the BIT simply followed the majority of processing power on the Bitcoin Network, it would likely lead to additional confusion as a significant majority of processing power on the Bitcoin network shifts back and forth between different forks as profitability of mining on each changes. As noted in several other comments provided in regards to SR-NYSEArca-2017-06, the adoption of rule changes to allow the listing of a Bitcoin ETP would be very much in line with the SEC's mission, and to the significant benefit of US consumers. However, additional rules must be put in place to protect investors in the event of a permanent fork of the Bitcoin network such as the one DCG and its portfolio companies is advocating for now, rules I believe to be rather straightforward and simple to write. Matt  While the Bitcoin Cash fork appeared highly unlikely to take the name "Bitcoin" with any large part of the community at the time, several prominent community members had, and have since, indicated that they would refer to Bitcoin Cash simply as "Bitcoin" if certain conditions are met. http://www.prnewswire.com/news-releases/grayscale-investments-llc-statement-regarding-bitcoin-investment-trust-and-bitcoin-cash-300496137.html
A perspective from the Bitcoin Cash and Bitcoin Unlimited developer who discovered CVE-2018–17144. That is about the time that Matt Corallo wanted to shave off of block validation with his pull request in 2016 to Bitcoin Core. 600µs is a lot less than what is saved with more efficient block propagation, like XThin, Compact Blocks, or now Graphene over typical links, especially those that are of similar low-end quality in network speed like Raspberry Pis are in compute speed. An optimization that was not in the focus by Core until XThin from Bitcoin Unlimited came onto the scene and kicked the Core team into gear on this issue. Furthermore, 600 microseconds is an order of magnitude or more below the variance between node validation speeds from a Raspberry Pi to a more high-end miner node and thus wholly in the range that the network already deals with. This 600 microsecond optimization now resulted in CVE-2018–17144. Certainly the most catastrophic bug in recent years, and certainly one of the most catastrophic bugs in Bitcoin ever. This bug was initially suspected to potentially cause inflation, was reported because it led to reliable crashes and confirmed by closer analysis… to be actually allowing inflation! I have consistently and repeatedly criticized hubris and arrogance in the most prominent Core developers, and done so since 2013, when the bullshitting around the 1MB block size limit started. Here we have an optimization that talks about avoiding “duplicate” validation like validation is nothing to worry about, an afterthought in Bitcoin almost. And a change that is quickly found to be good in peer reviewed, ACKed in Core-speak, in a rubber-stamp-like manner by Core developers such as Gregory Maxwell. Developers which I fully respect for their intelligence and knowledge by the way, but still, well, dislike as much for their overblown egos and underhanded discussion style as well as having done all they can to handicap Bitcoin with the 1MB limit. I also have to be honest, this change creates an unavoidable element of suspicion in me. For anyone who knows what went down and what the code paths do, it is just unavoidable to have this thought here. I like to qualify that this is not what I assert nor think is happening, but definitely crosses my mind as a potentiality! Because what is better to destroy the value of Bitcoin in the public’s eye than a silent inflation bug? What is better than creating code paths that look harmless for themselves but combined with some other, seemingly harmless rework in other areas of the code, result in utter catastrophe? And it looks like CVE-2018–17144 would eventually have become exactly this. The only thing that saved Core is their effective client diversity between revisions and someone actually noticing that there is a problem. After two years of this bug sitting around idle and exploitable. Client diversity that has been much criticized on the Bitcoin Cash side of things, but it obviously shows its advantages now. Reading the title of the original PR: “Remove duplicatable duplicate-input check from CheckTransaction” , as well as the message therein: “Benchmark results indicate this saves about 0.5–0.7ms during CheckBlock.” almost reads like it could be a sick joke being played on us all now. I always feared that someone from the bankster circles, someone injected into the Bitcoin development circles with the sole goal of wreaking unsalvageable havoc, would do exactly what happened. Injecting a silent inflation bug. Because that is what would destroy one of the very core advantages that Bitcoin has over the current status quo. That of transparency and a verifiable money supply. And, even though as a Bitcoin/BCHer, I do not see true long term prospects in Bitcoin/BTC anymore, calling the whole foundation of crypto into question just like that would have been equally disastrous to “our” variant of Bitcoin. Now, again, I am definitely not saying this is the case with PR 9049 for sure. I actually think the explanation of a young, cocky Core developer, a new “master of the universe” wreaking havoc by sheer arrogance and hubris, is the more likely explanation. People in general, but I don’t even exclude myself here, tend to believe in the competence of others if they appear just self-assured enough. This is part of the problem with attitude and psychological dynamics in this space. It creates a dangerous aura of ‘these guys know what they are doing’. I myself have done some minor work on sensitive areas in the Bitcoin Unlimited implementation. And I am working on some more “consensus critical” code for BCH now (see below). And, yes, I sometimes do lose some sleep over what could go wrong. I know I make mistakes. I have done so. I will. We all do. But I have yet to see anything resembling an admission of being imperfect by the developer in question, or any other prominent Core developer for that matter. The folks in question know exactly who I mean. There must be more reasonable folks in Core, but they are rather silent. Much worse even: In the discussion on github that follows this PR, user freetrader (a well known anonymous but still respected member of the Bitcoin Cash community who helped to create the Bitcoin Cash initial fork) asks the very valid question: Which is answered in the, all-too-typical for Core, smug manner by Matt Corallo, notably the original author of the bug who has all reason to be a bit more careful and respectful: The bug was disclosed in an absolutely responsible manner. As even the full disclosure on bitcoincore.org’s own pages notices, it went to a set of trustworthy people by the person who found the bug and did so in an encrypted PGP message only. This leaves the question why Core recklessly endangered the security of Bitcoin Cash as well endangering the myriad of altcoins that are out there and still susceptible with this premature and hasty publication. The back references from altcoins merging the change trickling into PR #14247 are a glimpse into this process. Now, Matt talks about “running out of time” in the above reply. But what time is that exactly? If you think hard about this, this can only be a distrust in any of the informed parties that they’ll leak this secret prematurely and thus catch Bitcoin Core with their pants down, or as a worse assumption, be actually exploited by one of the informed parties against BTC. Bitcoin Unlimited was ferociously attacked, presumably by deranged BTC supporters from the wider ‘community’, when it had a bug. And it seems a bit like Core members assumed a payback by deranged BCH supporters in kind here (I am not doubting those supporters exist), given the hints in the original disclosure that this bug has actually been discovered by someone aligned with the Bitcoin Cash side of things. But not only that, Core seems to have assumed that members on the BCH side of things who have been informed are deranged or at least irresponsible enough to leak this info to the wrong parties! I like to applaud deadalnix and the ABC team for what I was thinking the Core team should have done here as well: Bury the fix in a bit more and unrelated refactoring code so as to fix it but also to buy some more time for an upgrade. Maybe Core wasn’t creative enough to see a way to hide the problem, but then they also had no reason to blare it out like they did here. This was very irresponsible, and, and this should reach any altcoin impacted by this, this is definitely solely Bitcoin Core’s responsibility. No one else said anything in public before Core published their PR. It should also be noted by the Core team that this creates a strong disincentive to keep them in the loop with initial disclosure for anyone finding a bug. Cory Fields has talked about the risks and dangers with regards to sitting on the knowledge of a 0-day on Bitcoin Cash, and this bug discussed herein is one that was worth at least 10x more in potential damage and thus also shorting value and angry deranged people (a.k.a. “31337 crypto trading bros”) capable of violence. If a party behaves this irresponsibly, it shouldn’t be surprised if it degrades itself to a lower position in the food chain with regards to vulnerability disclosures. I am not saying I won’t inform next time I might stumble upon something, but this is not a good way to create the necessary trust. The Discovery and Disclosure Sitting in my little van by the sea on Monday, I was working on getting the new CHECKDATASIG/-VERIFY opcodes that are about to activate for Bitcoin (Cash) in November implemented on the Bitcoin Unlimited client. I have been looking at a potentially neat use case for those and am motivated to get this done. Around noon, I noticed that there is a lot of divergence in the way that signature operations counting was done in ABC vs. how it was done in Bitcoin Unlimited (BU). I agreed earlier with the BU team that I would go and port most of the CDS/-V stuff over from ABC, but I felt overwhelmed. My thoughts were that: Ok, this is doable, but this needs a lot more analysis and also many more eyeballs for review. And will take a lot longer. Sigh. While doing so, I stumbled upon this comment in the ABC code base: Check for duplicate inputs — note that this check is slow so we skip it in CheckBlock My initial reaction was a slight “Eh, WTF is going on with that comment?”. And then I looked up uses of CheckRegularTransaction in ABC, which is the renamed variant of CheckTransaction in Core (but I didn’t know at that time). I dug through the code to try to understand the logic. I noticed that block validation skips this test as it is assumed to have already happen during mempool ingress. My next thought was a bit of a sinking feeling and a “Uh-oh, I really hope the folks from ABC have thought about the difference between the mempool and block transmission and that those are distinct ways into the system. There might be a problem here!”. And then I went and thought about a way to test this. I patched an ABC node to not relay transactions even when asked and connected one unpatched and one patched node together in -regtest mode and created a transaction with a duplicate input (which the above test was skipping). Wham! assert(), Aborted. Next thought was along the lines: “Oh fuck, this doesn’t look good, gotta notify deadalnix and the crew what is lurking in ABC, this doesn’t look good at all. [email protected]#%!!”. Being aware of the danger that this could maybe be further exploited towards an actual inflation and chain-splitting bug (but I didn’t further check the specifics of this, as a node crash bug with assert() failure was already enough to be worried about), I quickly and somewhat inaccurately noted to myself (and timestamped): BitcoinABC does not check for duplicate inputs when processing a block, only when inserting a transaction into the mempool. This is dangerous as blocks can be generated with duplicate transactions and then sent through e.g. compact block missing transactions and avoid hitting the mempool, creating money out of thin air. awemany [Footnote: I timestamped this message in the BU slack, adding an innocuous situational lie of ‘Ooops, wrong channel’ to it. I also tried timestamping my findings on on my usual go-to site originstamp.org but they only submit timestamps every 24h due to the fees on Bitcoin being too high to do more often… I guess I should maybe get into the habit of doing timestamping transactions myself..] Opening up a disclosure email to deadalnix, I started to have a thought of: “Ok, actually, where is this stuff coming from, when and where did they introduce it into the code, might we be lucky and this is not in a release yet?” And then I noticed that this stuff was coming from Core. Already having written a disclosure report, I rechecked whether Core was vulnerable as well. And, once again: Wham! assert(), Aborted. I started to get shivers up my spine. Uh oh! Core has a crash bug, potentially worse. Stuff in the code since 2016. NOT good. NOT good at all. I like to say here that I actually had a feeling of this is bad, not this is good because of Core vs. Cash or something like that. I (unfortunately) still own a (for my poor soul significant) amount of BTC and for that reason and others do not like having bugs in Core either. Being a responsible citizen in this space, I then wrote the encrypted disclosure email to Wladimir, sickpig and some others, attaching a variant of the ABC and the Core patch to exploit this problem to my disclosure. I also put in a BCH address for a bounty payment to myself into that email (disclosed as proof below), as I feel this should be something worth a little performance bonus 🙂 No money has been received at the time of this writing yet. If you want to change this, you can send me BCH here: bitcoincash:qr5yuq3q40u7mxwqz6xvamkfj8tg45wyus7fhqzug5 (1NBKDco2EctDXvBv6r4hqJRPWfgX9jFpqs) I chose the handle beardnboobies as this is the first thing that came into my mind when I thought about this very discovery here. I thought: Ok, I am slowly becoming a pale nerd working on just code, with beard and manboobies. Oh well. I have noticed that this handle was — for whatever reason- taken out of the release notes that are checked into the main development branch of Bitcoin Core and is only available in the release branch / tag, being replaced with anonymous contributor on the main branch. I wonder: Do you Core guys feel this is too unprofessional to have this pseudonym appear in the main branch? Have some humor please! 🙂 By the way, a plea: I urge everyone in BCH as well as BTC (as well as impacted altcoins), to take a fine-toothed comb through the code with the goal of looking for similar issues! More specifically, I faintly remember (though might be wrong) from discussions back with Core devs on reddit in 2016 and before, that the idea that there’s a lot of “duplicate validation” between mempool and block validation was kind of en vogue back then. Potentially more code is vulnerable because it assumes that mempool validation can stand in for block validation. I suspect more, though maybe not as grave bugs, in this area. Reactions After I submitted it, I felt relief and then I started to watch the space from the back. A weird situation. Only then I also fully realized what Core contributor Cory Fields described with a bit of a different angle and on a smaller scale, the weirdness of having found a bug that you know is worth millions at least, massively impacting a $100 billion currency. The fact that I could have gone and rented hash power and shorted BTC and exploited this. But also the fact that I did not! Wladimir eventually wrote me an email that they’re preparing releases (and at that time or around it they published the PR), so I responded expressing my astonishment of the quite public handling of this serious issue. What I was amazed by in general was the long time it took for the bug to blow up to its full proportions, with the process seemingly even not over now. One thing is certainly others digging into this and realizing the full severity of this — as it turns out, yes it CAN be used to double-spend and inflate on BTC after all! — but also the time it takes from the initial PR being public, seemingly not noticed at all and the first media article being written. And then I noticed the usual spin. The “stupid BCashers can’t code and are irresponsible and what not” angle that is all too often repeated then by seemingly cerebrally insufficient Core supporters. I quote the below to gloat maybe. But also to show the world WHAT kind of bullshit the Bitcoin Cash side of things is facing here in a constant barrage. This is just from a few of the more prominent Core supporters and devs. There is, of course, a lot more folks foaming “btrash, bcash” at the mouth on reddit and twitter. Tone Vays and Jimmy Song Here we have Tone Vays, who likes to pose with the undercurrent of violence by wielding weapons on Twitter and apparently also on Youtube, discussing this bug with Jimmy Song in an unwillingly hilarious Youtube video: Luke-Jr I like to say some words about this tweet of Luke-Jr, committing the sin of bearing false witness about us irresponsible “BCashers”… I suspect Luke-Jr has been left in the dark about the background of this disclosure as well, not belonging to the innermost circles either. Careful observers might have noticed even more of this dynamic happening with other people. And note again: I have done everything that is necessary to make this a responsible disclosure. The initial, unobfuscated public disclosure happened by Bitcoin Core on their github! This is exactly the opposite situation compared to what Luke-Jr is describing. This is despicable. From:Luke-Jr Closing remarks Apart from pointing out the insane spin of some Core supporters in the preceding part, I simply want to take the opportunity now to urge caution for everyone here. Bugs lurk everywhere. Everyone is imperfect. Myself included, of course. I started to like Jihan Wu’s credo of “Don’t play hatred, don’t wish competing coins ill. Just wish and try to make BCH better” (from twitter) and see BCH and BTC in fierce but still civil competition. Civil competition obviously meaning no violence, including no violence like attacking each other’s nodes. I like to reiterate that, despite the gloating and strong words you might find in this article, I did everything to play fair. I also agree in general with Cory Fields from Core that it is not very easy to find the necessary disclosure addresses and information. He’s right about the lack of easily accessible GPG keys both on the BCH as well as — I like to add- on the BTC side of things. I didn’t find a non-retracted key of Pieter Wuille in time. I also like to note that a few things went finally completely out of the window here with this bug, for example Core’s idea of ‘the code being law’. If the code is law, does that mean that you have to accept inflation now? Or is it actually the Core devs steering the ship? Is an element of reasonableness entering the space? And yes, I sincerely believe, despite the current price ratio that BCH has a much brighter future than BTC, by being fundamentalist on the principles that matter and came along with the original white paper while not being fundamental on things that were created post-hoc — like the 1MB (now 4MW) limit in the Bitcoin Core implementation. As I also don’t think extended inflation is crucial for BTC’s operation. But anyone is free to buy or sell as they want. Let’s continue competing. Let’s civilly inform each other of bugs. May the best chain win. Finally, I like to thank Andrea Suisani, Andrew Stone and Peter Rizun for their review of this article and valuable input.
I must have listened hundreds of hours to bitcoin podcasts this year and wanted to share some of my favourite ones. Hopefully it will be helpful for someone to decide with the allocation of their precious time, so here are my recommendations, in no particular order. Blockdigest - a bi-weekly podcast, with focus on current events in the space. Most of the knowledgeable and ethical people around; no ads, no sponsors, no bs. The downside is that the format is a bit hard to digest (heh, get it?), as the videos are quite long (2-3h), covering many topics in depth, sometimes relapsing into rants and namecalling. But this comes with their "grassroots" approach (they featured u/nopara73, Wasabi wallet creator, many times, as well as other privacy oriented topics), and I have learned a lot from these guys and girls over time, and Janine deserves a special shout out for her journalistic ethics and vigour, continuing to call out many faulty practices in her work field. Twitter YouTube channel Tales From The Crypt - "what's up you freaks, it's your boy Marty Bent!". I like the relaxed, fun, but inquisitive style of the host, having beers/whisky with his guests, making them feel comfortable while grilling them with good questions. The selection of guests is great, too (Matt Corallo, Nic Carter, Hasufly, Jack Mallers, Pierre Rochard etc etc)! The host also has a "Weekly Recap" series as part of the podcast, as well as a daily (!) newsletter with recap of the daily stuff from the bitcoin space. Twitter Libsyn Anchor.fm iTunes WhatBitcoinDid - Peter (the host) attracted the wrath of bitcoiners by interviewing Craig "Faketoshi" Wright earlier this year without being able to challenge him enough on the technical side. But he seems to be driven by genuine curiosity, desire to learn and an open mind, which became evident with the progression of his podcast, the guest selection and the kind of discussions that have been had on his show. I like his approach to actually travel to his guests to interview them, so thumbs up for the effort. It was fun to observe him starting from a point of "zero knowledge" and advance to a full-blown bitcoin maximalist (well, almost!) by gaining understanding of how bitcoin works. One of my favourite episodes are the one with Tuur Demeester and Nic Carter. Guests like Adam Back, Giacomo Zucco, but also non-bitcoin guests like Hester Pierce (SEC commissioner), Grin's/Mimblewible dev Michael Gordner etc. Twitter Website Noded - Bitcoin maximalism to the.. maximum. It might surprise you though that the views are actually quite balanced and not at all without critical, adversarial thoughts on bitcoin. The CVE-2018–17144 bug (inflation bug in the Bitcoin Core software) got extensive, critical coverage (a whole episode w/ John Newbery as a guest) and the views and questions of the hosts are much more nuanced and critical than the term "maximalist" might suggest. Guest list is comprised of devs like Rusty Russel, Christian Decker, Matt Corallo and "hardcore" bitcoiners like Murad Mahmudov. People with knowledge, low time preference, skin in the game and deeply rooted in the bitcoin space. Twitter Website Soundcloud Stephan Livera Podcast - another "grassroots" podcast, mainly focused on people from the developer and building space. Incredible work ethic of Stephan, suddenly coming out of nowhere and then bringing out a podcast almost every day, although it seems to have slowed down a lot recently. Guests like Justin Moon (creator of the "BUIDL bootcamp"), Rene Pickhardt (Lightning dev/buildeeducator), Samourai wallet dev etc. Twitter Website Tone Vays - probably no description necessary. Tone has been in the space for many years now, not afraid to call a bear market when everyone is a bull (and vice versa). Impressive dedication to shill his ref links in the beginning of each video, but we allow it for all the dedication to his youtube channel over the years. Not a podcast to go for technical information on bitcoin, but if you're into readings of those candles, those magic nines and things like that, it's a good podcast with some entertainment value and a good track record of staying scam-free. On that note, also check out Tone's CryptoScam series, where he analyzes various altcoins with guests like Peter Todd, StopAndDecrypt, Paul Storzc etc. Twitter YouTube Cryptoconomy- a guy with a pleasant voice reads out (and comments on) some of the most important articles in the bitcoin space (by Nick Szabo, f.ex). If you don't like reading long articles, this might be the podcast for you. Twitter Website
What is up with all these Bitcoin devs who think that their job includes HARD-CODING CERTAIN VALUES THAT ARE SUPPOSED TO BE USER-CONFIGURABLE (eg: "seed servers")?
Recently, the developer of SegWit2x / BTC1, Jeff Garzik, caused some controversy by hard-coding the "seed servers" which Bitcoin uses to first start hunting for "peers". Worse than that: apparently one of the "seeds" is a company he started, variously named Chainalysis / Skry / Bloq - which apparently specializes in de-anonymizing Bitcoin transactions and performing KYC/AML - and which also has apparently entered into agreements with Interpol. Seriously, WTF??? This is what "Bitcoin devs" still consider to be part of their "job" - hard-coding parameters like this, which affect everyone else on the network - and which could easily be "exposed" to be made user-configurable - instead of being baked into the source code and requiring a friggin' recompile to change??? This recent event has refocused attention on the fact all these past years, most of these seed servers in "the" existing (legacy) client running on most of the network have _also been hard-coded - to domains under the control of "devs associated with Blockstream".
I don't like the list of seed servers in Bitcoin Core Pieter Wuille - does not support BIP148 - works for Blockstream Matt Corallo - does not support BIP148 - works for Blockstream Luke Dashjr - supports BIP148 - works for Blockstream Christian Decker - supports BIP148 - works for Blockstream Jonas Schnelli - supports BIP148 Peter Todd - supports BIP148 - worked for Samson Mow who works for Blockstream
...and the key thing with that is being able to control what nodes a node connects to can be a very powerful tool to attack new nodes, as it lets you prevent a node from learning about the valid chain with the most work.
4 out of 5 people running the bitcoin networks seed servers are directly associated with Blockstream! I don't even believe that Blockstream is actually plotting an evil, forceful takeover of bitcoin using the seed servers. However it beautifully counteracts Adam's "decentralization is everything" arguments. What is most troublesome to me, is that this simple information is not allowed to appear on r\bitcoin at all.
https://np.reddit.com/btc/comments/6n8vqc/the_corporate_takeover_of_bitcoin_illustrated_in/ Seriously? Bitcoin is almost 9 years old - and most people are still running clients which use hard-coded values (which require an inconvenient recompile to reconfigure) for the "seed servers"?? Maybe this is, in some sense, part of the reason why people like BlueMatt and Luke-Jr and Pieter Wiulle think they can lord it over us and tell everyone else what to do? ...because they have quietly (and unfairly / incompetently) hard-coded their own friggin' server domain names directly into everyone else's client code, as our "seed servers"? Is the low level of "quality" we - as a community - have become accustomed to from our devs? Do other clients (Bitcoin Classic, Bitcoin Unlimited and Bitcoin ABC) also gratuitously hard-code their "seed servers" like this? Here's a post from a year ago regarding "seed servers" in Classic:
How come "classic" uses the same alert keys/DNS seeds as Core?
https://np.reddit.com/btc/comments/44atsp/how_come_classic_uses_the_same_alert_keysdns/ Meanwhile, here's the main question: Why are any "serious" Bitcoin clients still "gratuitously" hard-coding any values like this? Why has our "ecosystem" / "community" not naturally evolved to the point where we have some public "wiki" pages listing all the "good" (community-recognized, popular) seed servers - and every user configures their own client software by choosing who they want from this list? (Maybe because we've been distracted by bullshit for these past few years, fighting with these very same devs because they've refused provide any support for users who want bigger blocks?) What would users have to do if (God forbid) something were to happen to the servers of those 4-5 seed servers which are currently hard-coded into nearly everyone's clients? In that situation (assuming some "new" seed servers quickly appeared) people would be have two options:
Edit their C++ source code and download/install a (trusted, verified) C++ compiler (if they don't already have one), and recompile the friggin' code; or
Wait until new binaries got posted online - and download them (and verify them).
Seriously? This unnecessary "centralization point" (or major inconvenience / bottleneck) has been sitting in our code this entire time - while these supposedly knowledgeable devs keep beating us over their head with their mantra of "decentralization" - which they have actually been doing so little to maximize?
Psycho-Socio-Economic Side Bar Serious (but delicate/senstive) question: How many of these "devs" have developed (possibly unconscious?) behaviors in life where they try to make users dependent on them? "Vendor lock-in" is a thing - a very bad thing, which certain Bitcoin devs have exhibited a tendency to inflict on users - in many cases due to rather obvious (psychological, social, and/or economic) reasons. We should gently (but firmly) reject these tendencies whenever any dev exhibits them.
Our community should expect and demand an accessible, user-friendly interface for all user-configurable parameters - to maximize decentralization and autonomy
In "command-line" versions of the client program, these kind of parameters should be:
in a separate config file - using some ultra-simple, standard format such as YAML or JSON
also configurable via options (eg, --seed-server) upon invocation on the command-line
In GUI versions version of the client program (using some popular cross-platform standard such as Qt, HTML, etc.) these kind of parameters should be exposed as user-configurable options.
Yes, these user-configurable values for things like "seed servers" (or "max blocksize") could come pre-configured to "sensible defaults - so that the software will work "out of the box" (immediately upon downloading and installing) - with no initial configuration required by the user. Yes: Even the blocksize has always been user-configurable - but most users don't know this, because most devs have been hiding this fact from us. Three recent posts by u/ForkiusMaximus explained how Adjustable-Blocksize-Cap (ABC) Bitcoin clients shatter this illusion:
Adjustable-blocksize-cap (ABC) clients give miners exactly zero additional power. BU, Classic, and other ABC clients are really just an argument in code form, shattering the illusion that devs are part of the governance structure.
https://np.reddit.com/btc/comments/602vsy/clearing_up_some_widespread_confusions_about_bu/ Note about Bitcoin ABC vs Bitcoin Unlimited: There is a specific new Bitcoin client called Bitcoin ABC, which functions similar to Bitcoin Unlimited - with the important difference that Bitcoin ABC is _guaranteed to hard-fork to bigger blocks on August 1_. (Please correct me if I'm wrong about this. Documentation for the behavior of these various hard-forks is currently still rather disorganized :-) All serious devs should be expected to provide code which does not require a "recompile" to change these "initial, sensible" default parameters. I mean - come on. Even back in the 80s people had "*.INI" files on DOS and Windows. Nearly all users understand and know how to set user-configurable values - for decades. How many people are familiar with using a program which has a "Preferences" screen? (Sometimes you may have to close and re-open the program in order for your new preferences to take effect.) This is really basic, basic functionality which nearly all software provides via a GUI (and or config file and/or command-line options). And nearly all devs have been offering this kind of functionality - in either command-line parameters, config files, and/or graphic user interfaces (GUIs). Except most Bitcoin devs. The state of "software development" for Bitcoin clients seems really messed up in certain ways like this. As users, we need to start demanding simple, standard features in our client software - such as accessible, user-friendly configurability of parameter values - without the massive inconvenience of a recompile. What is a "Bitcoin client"? After nearly 9 years in operation, our community should by now have a basic concept or definition of what a "Bitcoin client" is / does - probably something along the lines of:
A Bitcoin client is a device for reading (and optionally appending to) the immutable Bitcoin Blockchain.
Based on that general concept / definition, a program which does all of the above and also gratuitously "hard-codes" a bunch of domain names for "seed servers" is not quite the same thing as a "a Bitcoin client". Such an "overspecialized" client actually provides merely a subset of the full functionality of a true "Bitcoin client", eg:
An "overspecialized" client only enables connecting to certain "seed servers" upon startup (in accordance with the "gratuitous opinion" of the dev who (mis)translated the community's conceptual specifications to C++ code)
An "overspecialized" client only enables mining blocks less that a certain size (in accordance with the "gratuitous opinion" of the dev who (mis)translated the community's conceptual specifications to C++ code)
One of the main problems with nearly all Bitcoin clients developed so far is that they are gratuitously opinionated: they "gratuitously" hard-code particular values (eg, "max blocksize", "seed servers") which are not part of the whitepaper, and not part of the generally accepted definition of a "Bitcoin client". This failure on the part of devs to provide Bitcoin clients which behave in accordance with the community's specification of "Bitcoin clients" is seriously damaging Bitcoin - and needs to be fixed as soon as possible. Right now is a good opportunity - with so many new Bitcoin clients popping up, as the community prepares to fork. All devs working on various Bitcoin client software offerings need to wake up and realize that there is about to be a major battle to find out which Bitcoin client software offering performs "best" (in the user-interface sense - and ultimately in the economic sense) at:
reading (and optionally appending to) the immutable Bitcoin Blockchain
The Bitcoin client software offerings which can optimally (and most simply and securely :-) "satisfy" the above specification (and not merely some gratuitously overspecialized "subset" of it) will have the most success.
Yes, Bitcoin was always supposed to be gold 2.0: digital gold that you could use like cash, so you could spend it anywhere without needing banks and gold notes to make it useful. So why is Core trying to turn it back into gold 1.0? (112 points, 85 comments)
In October 2010 Satoshi proposed a hard fork block size upgrade. This proposed upgrade was a fundamental factor in many people's decision to invest, myself included. BCH implemented this upgrade. BTC did not. (74 points, 41 comments)
what do the following have in common: Australia, Canada, USA, Hong Kong, Jamaica, Liberia, Namibia, New Zealand, Singapore, Taiwan, Caribbean Netherlands, East Timor, Ecuador, El Salvador, the Federated States of Micronesia, the Marshall Islands, Palau, Zimbabwe (47 points, 20 comments)
BCH is victim to one of the biggest manipulation campaigns in social media: Any mention of BCH triggered users instantly to spam "BCASH".. until BSV which is a BCH fork and almost identical to it pre-November fork popped out of nowhere and suddenly social media is spammed with pro-BSV posts. (131 points, 138 comments)
LocalBitcoins just banned cash. It really only goes to show everything in the BTC ecosystem is compromised. (122 points, 42 comments)
The new narrative of the shills who moved to promoting bsv: Bitcoin was meant to be government-friendly (33 points, 138 comments)
PSA: The economical model of the Lightning Network is unsound. The LN will support different coins which will be interconnected and since the LN tokens will be transacted instead of the base coins backing them up their value will be eroded over time. (14 points, 8 comments)
94 points: ThomasZander's comment in "Not a huge @rogerkver fan and never really used $BCH. But he wiped up the floor with @ToneVays in Malta, and even if you happen to despise BCH, it’s foolish and shortsighted not to take these criticisms seriously. $BTC is very expensive and very slow."
87 points: tjonak's comment in A Reminder Why You Shouldn’t Use Google.
86 points: money78's comment in Tone Vays: "So I will admit, I did terrible in the Malta Debate vs @rogerkver [...]"
83 points: discoltk's comment in "Not a huge @rogerkver fan and never really used $BCH. But he wiped up the floor with @ToneVays in Malta, and even if you happen to despise BCH, it’s foolish and shortsighted not to take these criticisms seriously. $BTC is very expensive and very slow."
79 points: jessquit's comment in Ways to trigger a Shitcoin influencer Part 1: Remind them that’s it’s very likely they got paid to shill fake Bitcoin to Noobs
There are hundreds of developers who contribute to Bitcoin Core. Over 50 of them have 10+ commits to Bitcoin Core.
Blockstream employs 7 of these developers, including Pieter Wuille, Luke Dashjr, Greg Maxwell, Jorge Timon, Patrick Strateman, Warren Togami and Mark Friedenbach.
By number of commits, the developers Blockstream employs are ranked #2, #8, #13, #14, #19, #35, and #50, respectively.
Another company called ChainCode Labs employs 3 of the top 50 developers, including Alex Morcos, Suhas Daftuar, and Matt Corallo (formerly employed by Blockstream).
By number of commits, the developers ChainCode employs are ranked #5, #11 and #12, respectively.
As for SegWit, it is a multi-faceted gold-mine of an update with many, many benefits to scaling, security and efficiency:
It fixes the substantial transaction malleability problem once and for all.
It improves the efficiency of signature-hashing so it scales linearly rather than quadratically.
It 1.7x's the # of single-signature transactions per block and 4x's the # of multi-signature transactions per block.
It enables second-layer scaling solutions like Lightning.
It upgrades pay-to-script-hash transactions from 160-bit hashes to 256-bit hashes.
It makes it safer for hardware wallets to sign transactions by explicitly hashing input values.
It reduces the growth of the system's most burdensome resource: unspent transaction outputs, which are ideally kept in memory.
It introduces versioning for the scripting language to allow for more easy upgradeability.
The trust in the BU development team has faded   . (It's more legit if it looks as if it has sources. You know what I'm talking about... the bugs that have been found, the fact that it can't keep up with Core's commits, the fact that Core developers aren't jumping ship to it, the fact that it looks less active even compared to Classic - which has a smaller "market share").
The trust in the reasons for which some miners were supporting BU has faded  . I'm guessing that we were all hoping that they hate censorship and manipulation, just like we do, but for Jihan for example - the reasons might be different. I first became suspicious of it when he sharedMR_hehe's post, saying this:
If 2nd layer protocols become a reality, many bitcoin transactions will go through 2nd layer networks and not via miners. Miners won't receive transaction fees for them. The mining community obviously feel unhappy about this.
The covert form of ASICBOOST (where they don't use the version field, the form that was only recently publicly discovered) would only show up as a higher than usual number of empty blocks or blocks with reordered or missing transactions (depending on how the attacker implemented it; it's not necessarily both).
IMO, the long term objectives should be:
remove as many of the forms of manipulation as possible (for example censorship from /bitcoin, centralized exchanges, DOS attacks, and so on)
hard fork at some point in the future away from the current repository, hopefully to one that is distributed (updates wouldn't come from a central location - GitHub - and they could be voted on) and add a governance system to Bitcoin, where we can make decisions like paying developers (as DASH does it, or BOScoin in the future)
instantly confirmed transactions (businesses need that)
move to something akin to POS, and the capability of hundreds of thousands of transactions... per second
make running nodes either very light on computing resources or paid somehow
keep convincing businesses to accept cryptocurrencies as a method of payment, because that's how you completely eliminate banks and central banks from the equation
etc. Note that without utility for people and businesses, Bitcoin is just a complex and very effective pyramid scheme. No wonder you're only allowed to post "BUY BUY BUY HOLD!!" in /bitcoin. Also note that DASH is already doing some of the stuff above. Maybe we should just do a Bitcoin genesis block with DASH's source code lol. There's little financial interest in my recommendation, as I've already sold most of my Bitcoins for ETH. I'm sure many others from /btc have done the same. But I still want most cryptocurrencies to succeed, not just the ones I'm "invested" in. I want banks to fail. EDIT: looking at the comments, some people want hard fork SegWit, others want BU, others want soft fork FlexTrans, others want extension blocks... Really, we can't pull in so many different directions. We'll just move slowly somewhere in between, and in the tech word you remain behind when that happens.
If BTC1x prevails it will prove that the only way to achieve "consensus" in bitcoin is to make false agreements
If you think about it, it makes perfect sense. If person A and B want different things but want to come to an agreement, then one way to do it is for A to pretend he will give B what he wants and then later retract. so here are some bullet points to think about
it is claimed the majority of bitcoin users want small blocks which will lead to higher fees because they deeply understand bitcoin and understand how the larger bandwidth requirements of block propagation will geographically centralize bitcoin miners because of latency (if you ignore that there are relay networks)
This implies that the supposed centralization of bitcoin miners combined with a larger blockchain from larger blocks (which will result in less people running nodes in theory) outweigh the ways in which small blocks increase centralization and that people are okay with that for some reason.
it demonstrates that even though hard forks and soft forks are both equally powerful (Vitalik once described how you could alter the inflation rate and increase coins past 21 million with a soft fork) , that for some reason exchanges are required to call Bitcoin the one that upgrades through soft forks instead. Notice how coinbase could have said the names could have been S1x and S2x which would have been neutral?
By core developer Matt Corallo's own reasoning when he wrote a letter to the SEC to try to deny the winklevoss ETF... one of his reasons was that the ETF would allow the winklevoss to call an upgraded block size "bitcoin" and this would artificially boost the price and value of that blockchain due to branding and/or confusion. By that logic, coinbase is effectivelly helping to manipulate the bias of the bitcoin blockchain to the one that upgrades through equally powerful soft forks and is run by deplorable core developers. That is probably why the other sub seems so happy despite that they did say they could override this based on the majority choosing the other side
And a final thing to notice is that some of the most vocal supporters of increasing the blocksize are those who actually use bitcoin (for instance bitpay, roger ver... even Erik Vorhees). Many of the core supporters and core themselves have admitted to not even using bitcoin, but simply holding it.
if holding bitcoin and onlly holding is really the best use case for bitcoin and it has the largest segment of support... why does core seem afraid of cryptographically signed voting where you sign with coins?
Once again my attempt to summarize and explain the weekly bitcoin developer meeting in layman's terms. Link to last weeks summarization Disclaimer Please bare in mind I'm not a developer and I'd have problems coding "hello world!", so some things might be incorrect or plain wrong. Like any other write-up it likely contains personal biases, although I try to stay as neutral as I can. There are no decisions being made in these meetings, so if I say "everyone agrees" this means everyone present in the meeting, that's not consensus, but since a fair amount of devs are present it's a good representation. The dev IRC and mailinglist are for bitcoin development purposes. If you have not contributed actual code to a bitcoin-implementation, this is probably not the place you want to reach out to. There are many places to discuss things that the developers read, including this sub-reddit. link to this week logslink to meeting minutes Main topics discussed this week where: Mempool limiting: chain limits Low-S change CLTV & CSV review Creation of bitcoin discuss mailing list off-topic but important notice This issue has made most JS bitcoin software vulnerable to generating incorrect public keys. "This is an ecosystem threat with the potential to cause millions of dollars in losses that needs higher visibility; though it's not a bitcoin core / bitcoin network issue. Common, critical, JS code is broken that may cause the generation of incorrect pubkeys (among other issues). Anyone who cares for a JS implementation should read that PR." Mempool limiting: chain limits
(c/p from last week) Chain in this context means connected transactions. When you send a transaction that depends on another transaction that has yet to be confirmed we talk about a chain of transactions. Miners ideally take the whole chain into account instead of just every single transaction (although that's not widely implemented afaik). So while a single transaction might not have a sufficient fee, a depending transaction could have a high enough fee to make it worthwhile to mine both. This is commonly known as child-pays-for-parent. Since you can make these chains very big it's possible to clog up the mempool this way. The first unconfirmed transaction is called the ancestor and the transactions depending on it the descendants. The total amount of transactions is reffered to as "packages".
since last week
As said in "Chain limits" last week Morcos did write a proposal about lowering the default limits for transaction-chains. 2 use cases came up which are currently in use or happened before: As example: someone buys bitcoin from a website and can spend those bitcoin in the marketplace of the same website without waiting for confirmation in order to improve the bitcoin user-experience. This leaves a sequential transaction chain. They don't need to chain more than 5 transactions deep for this, and it falls within the proposed limits. What's not within the proposed limits is the chain of +/- 100 transactions a company had during the spam-attacks. These where simply increased activities by end-users while not enough UTXO's where available (3 to be precise)(UTXO: unspent transaction output, an output that can be used as input for a new transaction). Notably this is with the best practices of using confirmed transactions first. Ways this can be solved from the company's end is to have more UTXO's available before hand, bundling transactions (which requires delaying customer's request) or using replace-by-fee to add payees (which saves blockchain space, is cheaper in fees and gets transactions through quicker, but is not widely deployed by miners atm). Bare in mind these proposals are for default values for the memorypool, not in any way hard limits.
Sense of urgency. Quoting sipa: "my mempool is 2.5G... we better get some solution!" Current attack analysis assumes child-pays-for-parent mining, it should probably be done again without. Higher limits on number of transactions increase attack-vectors. Proposed number of transactions gets some push-back, total size limit not. Mixing default values (for example having a 50% of a 10/10 limit and 50% of a 100/100 limit) wastes bandwidth while there are too many factors that limit utility of long chains as well. 25 transaction limit ought to be enough for everyone (for now).
This is in regards to the recent malleability attack. Which is caused by a value 'S' in the ECDSA signature which can be 2 values, a high and low value and still be valid. Resulting in different transaction id's. more info A solution for this is to require nodes to have the "low-s" encoding for signatures. Downside is that it will block most transactions made by sufficiently out of date software (+/- pre-march 2014) This does not replace the need for BIP62, it only eliminates the cheap DOS attack.
95% of transactions already confirm to this, and more fixes have been applied since. BlueMatt has a node which several people are running that auto-malleates to low-s transactions. Questions whether we release it ASAP or wait for the next release and get it to a couple of miners in the meantime (possibly with auto-lowS-malleating)
CLTV: checkLockTimeVerify CSV: checkSequenceVerify Both new time-related OP-codes. Been discussed heavily last week.
Concerns whether CSV will be ready enough for release later this month. There's no clarity on how things look when all 3 time related pull-requests are merged. There's a number of people still reviewing the pull-requests. Uncertainty and confusion about whether the semantics are final or not (in regards to using bits from nSequence). nSequence are 4 bytes intended for sequencing time-locked transactions, but this never got used. Now these bytes are being repurposed for a mixture of things. Currently the plan is: " bits 0..15 are the relative locktime, bit 30 determines units (0: height, 1: time w/ 512s granularity), and bit 31 toggles BIP 68 (0: on, 1: off). bits 16..29 are masked off and can take any value."
Clarification from maaku regarding nSequence for BIP68. (after the meeting he explained he was waiting for opinions, but not enough people seemed to know the issue at hand) Continue review of pull requests 6312, 6564 and 6566 Creation of bitcoin discuss mailing list
The bitcoin-dev mailing list is intented for technical discussions only. There's things that don't belong there but need to be discussed anyway. Now this is done in bitcoin-dev, but the volume of this is getting too big. There's recently also an influx of really inappropriate posts, level kindergarden.
No clarity about who are the moderators. Next week there'll be a bitcoin-discuss list created. Decisions are needed as to who'll become the moderators for that and bitcoin-dev. Decisions are needed as to what will be the list and moderation policies.
The bitcoin-discuss list will be created as well as a simple website listing all the lists and corresponding policies. A meeting is scheduled on monday to discuss the moderation and policies of said lists. Participants morcos Alex Morcos gmaxwell Gregory Maxwell wumpus Wladimir J. van der Laan sipa Pieter Wuille BlueMatt Matt Corallo btcdrak btcdrak petertodd Peter Todd warren Warren Togami phantomcircuit Patrick Strateman dstadulis Daniel Stadulis GreenIsMyPepper Joseph Poon bsm117532 Bob McElrath
Hi all, I was listening to the Trace Mayer podcast and he was talking about the "HODLERs of last resort". You can listen here: https://www.bitcoin.kn/2018/03/the-bitcoin-hodler-of-last-resort/ I think it's relevant here in BTCP as well. I know things are down and we didn't get our exchange listings yet and coinmarketcap is not showing our market cap and maybe there's some problems on the dev team? But, I wanted to take the time to explain why I'm a hodler of last resort for BTCP. First off, blockchains don't die easy so even if all the devs for BTCP quit and this board dies off, as long as there is a way to sell BTCP and miners keep mining it, BTCP is going exactly no where. I mean Auroracoin and Bitconnect are still alive for crying out loud. The price may decline, maybe even to less than $1, but it's going to be around and it will always have the possibility of coming back to favor. I got into ZCL originally because I saw the potential in BTCP and none of that has changed. In fact, certain aspects of the value prop are even stronger than I would have thought when I first entered my position. I think the biggest thing we have going for us is our community. There's a lot of people here and I don't think we're going to let this thing die easy. Importantly, Bitcoin Private HAS A USE CASE and it's something that Bitcoin doesn't do well at the current time. It's also quite possible that Bitcoin doesn't ever adopt privacy features and even it does, it could take 5 years or more before it's implemented. Even Matt Corallo said he sees confidential transactions a ways out for Bitcoin as the research into how to implement it is still ongoing and they're not even close to consensus. You can also bet there will be a major fight about the best way to implement it just like there was for scaling. So, while things may have not gone our way price-wise, the opportunity for this coin is still exactly the same as it was before the fork. So, all in all nothing has changed and the team has paid $600k to exchanges to be listed already. Do you think the exchanges want to return that money? I don't. Bitcoin private will be listed on larger exchanges, it will be traded, it will be mined. The (mostly volunteer) devs will implement segwit. More stuff will happen. So, I'm a hodler of last resort. Who's with me?
Bitcoin dev IRC meeting in layman's terms (2015-11-12)
Once again my attempt to summarize and explain the weekly bitcoin developer meeting in layman's terms. Link to last weeks summarization Note that I crosspost this to Voat, bitcoin.com and the bitcoin-discuss mailing list every week. I can't control what's being talking about in the meeting, if certain things come up I might not be able to post here because of "guidelines". Disclaimer Please bear in mind I'm not a developer and I'd have problems coding "hello world!", so some things might be incorrect or plain wrong. Like any other write-up it likely contains personal biases, although I try to stay as neutral as I can. There are no decisions being made in these meetings, so if I say "everyone agrees" this means everyone present in the meeting, that's not consensus, but since a fair amount of devs are present it's a good representation. The dev IRC and mailinglist are for bitcoin development purposes. If you have not contributed actual code to a bitcoin-implementation, this is probably not the place you want to reach out to. There are many places to discuss things that the developers read, including this sub-reddit. link to this week logsMeeting minutes by meetbot Main topics discussed where: transaction priority for 0.12 Opt-in replace-by-fee Versionbits Chain limits transaction priority for 0.12
Each transaction is assigned a priority, determined by the age, size, and number of inputs. Which currently makes some transactions free. This currently has a large amount of code, which makes it harder to maintain, and is not that optimal since you can't expect miners to include 0-fee transactions.
Most people seem fine with removing priority in the mempool, but people should be notified ahead of time this is coming. sdaftuar proposed a staggered approach, setting the default value for priority to 0, and remove it entirely in the next release. petertodd notes there will be a natural staggered process since not everyone will upgrade to 0.12 instantly and some implementations might not remove priority at all. Most wallet-software outside of bitcoin-core don't implement priority calculations. As fee estimation becomes more important and many wallet providers use the bitcoin-core fee estimation, improvements on that are welcome. Luke-Jr doesn't agree with removing priority, particularly with changing the mining code to use the priority a transaction has when it enters the mempool. Sipa has the idea to add a small fraction of bitcoin days destroyed divided by the average UTXO age to the fee, so that non-spam-attack transactions are viewed as if they have a larger fee. While most agree with the proposal to remove the current priority, there's still much debate on whether it needs to be replaced for 0.13, and if so, how.
Currently when a node sees a transaction that spends the same output it ignores it. With replace-by-fee it replaces the current transaction in the mempool if it has a higher fee. This allows for things like spending "stuck" transactions, adding more recipients to a transaction in order to prevent chaining, etc. Since there are people that accept 0-confirmation transactions and this would make it extremely easy to double spend them, this is made opt-in. The sender can choose to opt-in to replace-by-fee by changing an input in the nSequence field.
Peter Todd wrote some tools to use replace-by-fee. link It would be nice to have opt-in per output instead of the whole transaction, however that would be very hard to implement and would have some privacy concerns. Luke-Jr would like to see an option to toggle between first-seen-safe/full RBF and neveopt-in/always. Since there are possibly some objections with the "always" toggle it should be a separate pull-request.
review and merge nSequence-based Full-RBF opt-in Peter Todd will write a mail to the list to explain how it works and how people can not accept opt-in transactions. Versionbits
BIP 9 Currently softforks have been done by the isSuperMajority mechanism, meaning when 95% of the last X blocks has a version number higher than Y the fork is deployed. A new way of doing this is currently being worked on and that uses all bits of the version number, appropriately being called versionbits. So instead of a fork happening when the version is larger than (for example) 00000000011 (3), a fork happens when (for example) the 3rd bit is up (so 00100000011). This way softforks can be deployed simultaneous and independent of each other.
There are 2 different implementations. One from Codeshark and one from Rusty jtimon thinks both implementations are more complicated than they need to be. There needs to be a minor revision namely a starting time for proposals. In general we'd like to get this in soon, but existing softforks need to complete first.
CodeShark adds a starting time to versionbits. Chain limits
Chain in this context means connected transactions. When you send a transaction that depends on another transaction that has yet to be confirmed we talk about a chain of transactions. Miners ideally take the whole chain into account instead of just every single transaction (although that's not widely implemented afaik). So while a single transaction might not have a sufficient fee, a depending transaction could have a high enough fee to make it worthwhile to mine both. This is commonly known as child-pays-for-parent. Since you can make these chains very big it's possible to clog up the mempool this way. With the recent malleability attacks, anyone who made transactions going multiple layers deep would've already encountered huge problems doing this (beautifully explained in let's talk bitcoin #258 from 13:50 onwards) Proposal and github link.
Wumpus doesn't feel comfortable with merging it because there's some controversy from companies who exceed the limits (or could be/want to). jgarzik does feel comfortable with it, and many think it should be merged as it's easy to revert if needed. There's little choice as it's not safe from attacks without limits. We should communicate the replace-by-fee sendmany alternative to long chains (adding new recipients on existing non-confirmed transactions), although it won't show up in users wallet yet and block-explorers probably aren't ready to display it correctly. Emphasis on the fact it's a change in default values, not a consensus change, however default values have a lot of power. The final limits are 25 transactions and 101kb total size for both ancestor and descendant packages.
jgarzik will merge the pull-request. Morcos will mail the list once it's merged. Participants
BlueMatt Matt Corallo petertodd Peter Todd morcos Alex Morcos jgarzik Jeff Garzik gmaxwell Gregory Maxwell wumpus Wladimir J. van der Laan Luke-Jr Luke Dashjr jtimon Jorge Timón btcdrak btcdrak phantomcircuit Patrick Strateman sipa Pieter Wuille CodeShark Eric Lombrozo sdaftuar Suhas Daftuar jg_taxi jg_taxi gavinandresen Gavin Andresen cfields Cory Fields bsm1175321 Bob McElrath
19:53 sipa new topic? 19:53 wumpus any other topics? 19:53 petertodd 19:53 jgarzik did we cover jonas while I was in the taxi? 19:54 sdaftuar ? 19:54 jtimon ? 19:54 CodeShark not sure I want to know 19:54 jgarzik proposal for new GUI maintainer 19:54 CodeShark sounds kinky, though 19:54 petertodd CodeShark: GUI's are pretty kinky 19:56 BlueMatt ok, end meeting? 19:56 btcdrak if we can remember the command this week :-) 19:56 wumpus #meetingend 19:56 gmaxwell #destroymeeting 19:56 wumpus #endmeeting 19:56 Luke-Jr #endmeeting 19:56 lightningbot Meeting ended Thu Nov 12 19:56:42 2015 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 19:56 BlueMatt #magicmeetbotincantation 19:57 petertodd #DoWhatIMean
Bitcoin dev IRC meeting in layman's terms (2015-10-22)
Once again my attempt to summarize and explain the weekly bitcoin developer meeting in layman's terms. Link to last weeks summarization Disclaimer Please bear in mind I'm not a developer and I'd have problems coding "hello world!", so some things might be incorrect or plain wrong. Like any other write-up it likely contains personal biases, although I try to stay as neutral as I can. There are no decisions being made in these meetings, so if I say "everyone agrees" this means everyone present in the meeting, that's not consensus, but since a fair amount of devs are present it's a good representation. The dev IRC and mailinglist are for bitcoin development purposes. If you have not contributed actual code to a bitcoin-implementation, this is probably not the place you want to reach out to. There are many places to discuss things that the developers read, including this sub-reddit. link to this week logsMeeting minutes by meetbot Main topics discussed where: Mempool Memory Usage LevelDB replacement Median Past locktime & CLTV Short topics/notes BIP 9 Versionbits PR #6816 is ready for implementation and needs more reviews. A 3 month moderation period on the bitcoin-dev mailinglist has started, as well as a new list bitcoin-discuss. more details: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-Octobe011591.html "bitcoin.org had incorrect release notes for 0.11.1. It's corrected now. They had posted the release notes for the initial RC and not updated them. Process wise it would be good to watch out for that in the future." Mempool Memory Usage
When a transaction is relayed across the network it is held by the nodes in memory, until it gets into a block. All these transactions that sit in memory are called the memorypool or mempool for short. Like we could see during the spam-attack if there's a big back-log of transactions that couldn't make it in the blockchain this mempool can get pretty big resulting in nodes crashing. To stop this from happening devs created a mechanism to reject and/or remove transactions from the mempool. This mempool limiting got merged this week. Also relevant: There is an already existing limit on the database cache size called "dbCache". The default value for that is 100MB.
Testing shows there's a discrepancy between the configured mempool limit and the actual memory usage. This is caused by the amount of UTXO data when processing transactions. This data is only flushed after a block is processed (so temporarily exceeding the cache limit set in dbCache). There are 2 "obvious" solutions for this:
Always enforce the UTXO cache limit, just like the mempool limit is always enforced. Downside for that is if you misconfigure your mempool limit an attack can blow away your UTXO cache, which significantly slows down validation and propagation.
Take the UTXO cache into account when limiting the mempool. Downside for that is that you could construct transactions which require way more cache space and thereby more easily kick out other transactions.
A more optimal solution would be to give priority in the cache to things in the mempool. Ways to achieve that are to kick UTXO's from transaction that are evicted from the mempool out of the cache and from transactions that never made it into the mempool. Something TheBlueMatt is working on
Continue to research and optimize. LevelDB replacement
LevelDB is the database system currently used in bitcoin. Since this is not being maintained for some time devs are looking for replacements.
jgarzik worked on a patch for SQLite Some people express concerns whether the performance will be good enough with SQLite, but there are no benchmark results yet.
Do research into other options Do lots of benchmarks and report results Median Past locktime & CLTV
When a block is created miners include a timestamp. This timestamp has to be between the median of the previous 11 blocks and the network-adjusted time +2 hours. So this timestamp can vary a decent amount from the real time. With the introduction of lock-time transactions, that are only valid after a certain time, miners are incentivised to lie about the time in order to include time-locked transactions (and their fees) that wouldn't otherwise be valid. BIP 113 enables the usage of GetMedianTimePast (the median of the previous 11 blocks) from the prior block in lock-time transactions to combat this behaviour. Users can compensate for this by adding 1 hour (6 blocks) to their lock times. CLTV stands for CheckLockTimeVerify, BIP65 Commonly reffered to as: How you thought nLockTime worked before you actually tried to use it.
CLTV is ready to be merged (and has been merged at time of writing) Questions of whether to add median past locktime as mempool only or as softfork Overall questions as to what to include in the CLTV deployment, what to include as mem-pool only and what as softfork. Median past locktime violates current 'standard' behavior, so we would prefer to have that violation dead in the network before the median past locktime softfork moves forward.
review BIP-113: Mempool-only median time-past as endpoint for lock-time calculations review the CLTV backports (done and merged at time of writing) Backport median past locktime to 0.10 and 0.11 Participants btcdrak btcdrak sipa Pieter Wuille gmaxwell Gregory Maxwell BlueMatt Matt Corallo morcos Alex Morcos petertodd Peter Todd CodeShark Eric Lombrozo jgarzik Jeff Garzik maaku Mark Friedenbach kanzure Bryan Bishop jcorgan Johnathan Corgan Luke-Jr Luke Dashjr jonasschnelli Jonas Schnelli sdaftuar Suhas Daftuar
Q: What is your relationship with Blockstream now? Are you in a Cold War? Your evaluation on BS was pretty high “If this amazing team offers you a job, you should take it,” tweeted Gavin Andresen, Chief Scientist, Bitcoin Foundation.” But now, what’s your opinion on BS? A: I think everybody at Blockstream wants Bitcoin to succeed, and I respect and appreciate great work being done for Bitcoin by people at Blockstream. We strongly disagree on priorities and timing; I think the risks of increasing the block size limit right away are very small. I see evidence of people and businesses getting frustrated by the limit and choosing to use something else (like Ethereum or a private blockchain); it is impossible to know for certain how dangerous that is for Bitcoin, but I believe it is more danger than the very small risk of simply increasing or eliminating the block size limit.
Q: 1) Why insist on hard fork at only 75%? You once explained that it is possible to be controlled by 5% if we set the threshold at 95%. I agree, but there should be some balance here. 75% means a high risk in splitting, isn’t it too aggressive? Is it better if we set it to 90%? A: 1)The experience of the last two consensus changes is that miners very quickly switch once consensus reaches 75% -- the last soft fork went from 75% support to well over 95% support in less than one week. So I’m very confident that miners will all upgrade once the 75% threshold is reached, and BIP109 gives them 28 days to do so. No miner wants to create blocks that will not be accepted by the network. Q: 2) How to solve the potentially very large blocks problem Classic roadmap may cause, and furthur causing the centralization of nodes in the future? A: 2)Andreas Antonopoulos gave a great talk recently about how people repeatedly predicted that the Internet would fail to scale. Smart engineers proved them wrong again and again, and are still busy proving them wrong today (which is why I enjoy streaming video over my internet connection just about every night). I began my career working on 3D graphics software, and saw how quickly we went from being able to draw very simple scenes to today’s technology that is able to render hundreds of millions of triangles per second. Processing financial transactions is much easier than simulating reality. Bitcoin can easily scale to handle thousands of transactions per second, even on existing computers and internet connections, and even without the software optimizations that are already planned. Q: 3) Why do you not support the proposal of RBF by Satoshi, and even plan to remove it in Classic completely? A: 3) Replace-by-fee should be supported by most of the wallets people are using before it is supported by the network. Implementing replace-by-fee is very hard for a wallet, especially multi-signature and hardware wallets that might not be connected to the network all of the time. When lots of wallet developers start saying that replace-by-fee is a great idea, then supporting it at the network level makes sense. Not before. Q: 4) . Your opinion on soft fork SegWit, sidechain, lighnting network. Are you for or against, please give brief reasons. Thanks. A: 4) The best way to be successful is to let people try lots of different things. Many of them won’t be successful, but that is not a problem as long as some of them are successful. I think segregated witness is a great idea. It would be a little bit simpler as a hard fork instead of a soft fork (it would be better to put the merkle root for the witness data into the merkle root in the block header instead of putting it inside a transaction), but overall the design is good. I think sidechains are a good idea, but the main problem is finding a good way to keep them secure. I think the best uses of sidechains will be to publish “write-only” public information involving bitcoin. For example, I would like to see a Bitcoin exchange experiment with putting all bids and asks and trades on a sidechain that they secure themselves, so their customers can verify that their orders are being carried out faithfully and nobody at the exchanges is “front-running” them. Q: 5) Can you share your latest opinion on Brainwallet? It is hard for new users to use long and complex secure passphrase, but is it a good tool if it solves this problem? A: 5) We are very, very bad at creating long and complex passphrases that are random enough to be secure. And we are very good at forgetting things. We are much better at keeping physical items secure, so I am much more excited about hardware wallets and paper wallets than I am about brain wallets. I don’t trust myself to keep any bitcoin in a brain wallet, and do not recommend them for anybody else, either.
Q: Gavin, do you have bitcoins now? What is your major job in MIT? Has FBI ever investigated on you? When do you think SHA256 might be outdated, it seems like it has been a bit unsafe? A: Yes, a majority of my own person wealth is still in bitcoins -- more than a financial advisor would say is wise. My job at MIT is to make Bitcoin better, in whatever way I think best. That is the same major job I had at the Bitcoin Foundation. Sometimes I think the best way to make Bitcoin better is to write some code, sometimes to write a blog post about what I see happening in the Bitcoin world, and sometimes to travel and speak to people. The FBI (or any other law enforcement agency) has never investigated me, as far as I know. The closest thing to an investigation was an afternoon I spent at the Securities and Exchange Commission in Washington, DC. They were interested in how I and the other Bitcoin developers created the software and how much control we have over whether or not people choose to run the software that we create. “Safe or unsafe” is not the way to think about cryptographic algorithms like SHA256. They do not suddenly go from being 100% secure for everything to completely insecure for everything. I think SHA256 will be safe enough to use in the all ways that Bitcoin is using it for at least ten years, and will be good enough to be used as the proof-of-work algorithm forever. It is much more likely that ECDSA, the signature algorithm Bitcoin is using today, will start to become less safe in the next ten or twenty years, but developer are already working on replacements (like Schnorr signatures).
Q: It’s a pleasure to meet you. I only have one question. Which company are you serving? or where do you get your salary? A: The Media Lab at MIT (Massachusetts Institute of Technology) pays my salary; I don’t receive regular payments from anybody else. I have received small amounts of stock options in exchange for being a techical advisor to several Bitcoin companies (Coinbase, BitPay, Bloq, Xapo, Digital Currency Group, CoinLab, TruCoin, Chain) which might be worth money some day if one or more of those companies do very well. I make it very clear to these companies that my priority is to make Bitcoin better, and my goal in being an advisor to them is to learn more about the problems they face as they try to bring Bitcoin to more of their customers. And I am sometimes (once or twice a year) paid to speak at events.
Q: Would you mind share your opinion on lightning network? Is it complicated to implement? Does it need hard fork? A: Lightning does not need a hard fork. It is not too hard to implement at the Bitcoin protocol level, but it is much more complicated to create a wallet capable of handling Lightning network payments properly. I think Lightning is very exciting for new kinds of payments (like machine-to-machine payments that might happen hundreds of times per minute), but I am skeptical that it will be used for the kinds of payments that are common on the Bitcoin network today, because they will be more complicated both for wallet software and for people to understand.
Q: 1) There has been a lot of conferences related to blocksize limit. The two took place in HongKong in Decemeber of 2015 and Feberary of 2016 are the most important ones. Despite much opposition, it is undeniable that these two meetings basically determines the current status of Bitcoin. However, as the one of the original founders of Bitcoin, why did you choose to not attend these meetings? If you have ever attended and opposed gmax’s Core roadmap (SegWit Priority) in one of the meetings, we may be in a better situation now, and the 2M hard fork might have already begun. Can you explain your absence in the two meetings? Do you think the results of both meetings are orchestrated by blockstream? A: 1) I attended the first scaling conference in Montreal in September of 2015, and had hoped that a compromise had been reached. A few weeks after that conference, it was clear to me that whatever compromise had been reached was not going to happen, so it seemed pointless to travel all the way to Hong Kong in December for more discussion when all of the issues had been discussed repeatedly since February of 2015. The February 2016 Hong Kong meeting I could not attend because I was invited only a short time before it happened and I had already planned a vacation with my family and grandparents. I think all of those conferences were orchestrated mainly by people who do not think raising the block size limit is a high priority, and who want to see what problems happen as we run into the limit. Q: 2) We have already known that gmax tries to limit the block size so as to get investment for his company. However, it is obvious that overthrowing Core is hard in the short term. What if Core continues to dominate the development of Bitcoin? Is it possible that blockstream core will never raise the blocksize limit because of their company interests? A: 2) I don’t think investment for his company is Greg’s motivation-- I think he honestly believes that a solution like lightning is better technically. He may be right, but I think it would be better if he considered that he might also be wrong, and allowed other solutions to be tried at the same time. Blockstream is a funny company, with very strong-willed people that have different opinions. It is possible they will never come to an agreement on how to raise the blocksize limit.
Q: I would like to ask your opinion on the current situation. It’s been two years, but a simple 2MB hard fork could not even be done. In Bitcoin land, two years are incredibly long. Isn’t this enough to believe this whole thing is a conspiracy? A: I don’t think it is a conspiracy, I think it is an honest difference of opinion on what is most important to do first, and a difference in opinion on risks and benefits of doing different things. Q: How can a multi-billion network with millions of users and investors be choked by a handful of people? How can this be called decentrilized and open-source software anymore? It is so hard to get a simple 2MB hard fork, but SegWig and Lighting Network with thousands of lines of code change can be pushed through so fast. Is this normal? It is what you do to define if you are a good man, not what you say. A: I still believe good engineers will work around whatever unnecessary barriers are put in their way-- but it might take longer, and the results will not be as elegant as I would prefer. The risk is that people will not be patient and will switch to something else; the recent rapid rise in developer interest and price of Ethereum should be a warning. Q: The problem now is that everybody knows Classic is better, however, Core team has controlled the mining pools using their powers and polical approaches. This made them controll the vast majority of the hashpower, no matter what others propose. In addition, Chinese miners have little communication with the community, and do not care about the developement of the system. Very few of them knows what is going on in the Bitcoin land. They almost handed over their own power to the mining pool, so as long as Core controls the pools, Core controls the whole Bitcoin, no matter how good your Classic is. Under this circumstance, what is your plan? A: Encourage alternatives to Core. If they work better (if they are faster or do more) then Core will either be replaced or will have to become better itself. I am happy to see innovations happening in projects like Bitcoin Unlimited, for example. And just this week I see that Matt Corallo will be working on bringing an optmized protocol for relaying blocks into Core; perhaps that was the plan all along, or perhaps the “extreme thin blocks” work in Bitcoin Unlimited is making that a higher priority. In any case, competition is healthy. Q: From this scaling debate, do you think there is a huge problem with Bitcoin development? Does there exsit development centrilization? Does this situation need improvment? For example, estabilish a fund from Bitcoin as a fundation. It can be used for hiring developers and maintainers, so that we can solve the development issue once and for all. A: I think the Core project spends too much time thinking about small probability technical risks (like “rogue miners” who create hard-to-validate blocks or try to send invalid blocks to SPV wallets) and not enough time thinking about much larger non-technical risks. And I think the Core project suffers from the common open source software problem of “developers developing for developers.” The projects that get worked on are the technically interesting projects-- exciting new features (like the lightning network), and not improving the basic old features (like improving network performance or doing more code review and testing). I think the situation is improving, with businesses investing more in development (but perhaps not in the Core project, because the culture of that project has become much less focused on short-term business needs and more on long-term exciting new features). I am skeptical that crowd-funding software development can work well; if I look at other successful open source software projects, they are usually funded by companies, not individuals.
You are one of the most-repected person in Bitcoin world, I won’t miss the chance to ask some questions. First of all, I am a Classic supporter. I strongly believe that on-chain transcations should not be restrained artificially. Even if there are transcations that are willing to go through Lighting Network in the future, it should be because of a free market, not because of artificial restrication. Here are some of my questions: Q: 1) For the past two years, you’ve been proposing to Core to scale Bitcoin. In the early days of the discussion, Core devs did agree that the blocksize should be raised. What do you think is the major reason for Core to stall scaling. Does there exist conflict of interest between Blockstream and scaling? A: 1) There might be unconscious bias, but I think there is just a difference of opinion on priorities and timing. Q: 2) One of the reason for the Chinese to refuse Classic is that Classic dev team is not technically capable enough for future Bitcoin development. I also noticed that Classic does have a less frequent code release compared to Core. In your opinion, is there any solution to these problems? Have you ever thought to invite capable Chinese programers to join Classic dev team? A: 2) The great thing about open source software is if you don’t think the development team is good enough (or if you think they are working on the wrong things) you can take the software and hire a better team to improve it. Classic is a simple 2MB patch on top of Core, so it is intentional that there are not a lot of releases of Classic. The priority for Classic right now is to do things that make working on Classic better for developers than working on Core, with the goal of attracting more developers. You can expect to see some results in the next month or two. I invite capable programmers from anywhere, including China, to help any of the teams working on open source Bitcoin software, whether that is Classic or Core or Unlimited or bitcore or btcd or ckpool or p2pool or bitcoinj. Q: 3) Another reason for some of the Chinese not supporting Classic is that bigger blocks are more vulnerable to spam attacks. (However, I do think that smaller blocks are more vlunerable to spam attack, because smaller amount of money is needed to choke the blockchain.) What’s our opinion on this? A: 3) The best response to a transaction spam attack is for the network to reject transactions that pay too little fees but to simply absorb any “spam” that is paying as much fees as regular transactions. The goal for a transaction spammer is to disrupt the network; if there is room for extra transactions in blocks, then the network can just accept the spam (“thank you for the extra fees!”) and continue as if nothing out of the ordinary happened. Nothing annoys a spammer more than a network that just absorbs the extra transactions with no harmful effects. Q: 4) According to your understanding on lighting network and sidechains,if most Bitcoin transactions goes throught lighting network or sidechains, it possible that the fees paid on the these network cannot reach the main-chain miners, which leaves miners starving. If yes, how much percent do you think will be given to miners. A: 4) I don’t know, it will depend on how often lightning network channels are opened and closed, and that depends on how people choose to use lightning. Moving transactions off the main chain and on to the lightning network should mean less fees for miners, more for lightning network hubs. Hopefully it will also mean lower fees for users, which will make Bitcoin more popular, drive up the price, and make up for the lower transaction fees paid to miners. Q: 5) The concept of lighting network and sidechains have been out of one or two years already, when do you think they will be fully deployed. A: 5) Sidechains are already “fully deployed” (unless you mean the version of sidechains that doesn’t rely on some trusted gateways to move bitcoin on and off the sidechain, which won’t be fully deployed for at least a couple of years). I haven’t seen any reports of how successful they have been. I think Lightning will take longer than people estimate. Seven months ago Adam Back said that the lightning network might be ready “as soon as six months from now” … but I would be surprised if there was a robust, ready-for-everybody-to-use lightning-capable wallet before 2018. Q: 6)Regarding the hard fork, Core team has assumed that it will cause a chain-split. (Chinese miners are very intimitated by this assumption, I think this is the major reason why most of the Chinese mining pools are not switching to Classic). Do you think Bitcoin will have a chain-split? A: 6) No, there will not be a chain split. I have not talked to a single mining pool operator, miner, exchange, or major bitcoin business who would be willing to mine a minority branch of the chain or accept bitcoins from a minority branch of the main chain. Q: 7) From your point of view, do you think there is more Classic supporters or Core supporters in the U.S.? A: 7) All of the online opinion pools that have been done show that a majority of people worldwide support raising the block size limit.
Q: Which is more in line with the Satoshi’s original roadmap, Bitcoin Classic or Bitcoin Core? How to make mining pools support and adopt Bitcoin Classic? A: Bitcoin Classic is more in line with Satoshi’s original roadmap. We can’t make the mining pools do anything they don’t want to do, but they are run by smart people who will do what they think is best for their businesses and Bitcoin.
Q: Do you have any solution for mining centralization? What do you think about the hard fork of changing mining algorithms? A: I have a lot of thoughts on mining centralization; it would probably take ten or twenty pages to write them all down. I am much less worried about mining centralization than most of the other developers, because Satoshi designed Bitcoin so miners make the most profit when they do what is best for Bitcoin. I have also seen how quickly mining pools come and go; people were worried that the DeepBit mining pool would become too big, then it was GHash.io… And if a centralized mining pool does become too big and does something bad, the simplest solution is for businesses or people to get together and create or fund a competitor. Some of the big Bitcoin exchanges have been seriously considering doing exactly that to support raising the block size limit, and that is exactly the way the system is supposed to work-- if you don’t like what the miners are doing, then compete with them! I think changing the mining algorithm is a complicated solution to a simple problem, and is not necessary.
Q: Last time you came to China, you said you want to "make a different". I know that in USA the opposition political party often hold this concept, in order to prevent the other party being totally dominant. Bitcoin is born with a deep "make a different" nature inside. But in Chinese culture, it is often interpreted as split “just for the sake of splitting”, can you speak your mind on what is your meaning of "make a different"? A: I started my career in Silicon Valley, where there is a lot of competition but also a lot of cooperation. The most successful companies find a way to be different than their competitors; it is not a coincidence that perhaps the most successful company in the world (Apple Computer) had the slogan “think different.” As Bitcoin gets bigger (and I think we all agree we want Bitcoin to get bigger!) it is natural for it to split and specialize; we have already seen that happening, with lots of choices for different wallets, different exchanges, different mining chips, different mining pool software.
Q: 1) The development of XT and Classic confirmed my thoughts that it is nearly impossible to use a new version of bitcoin to replace the current bitcoin Core controlled by Blockstream. I think we will have to live with the power of Blockstream for a sufficient long time. It means we will see the deployment of SegWit and Lighting network. If it really comes to that point, what will you do? Will you also leave like Mike Hearn? A: 1) With the development of Blockchain, bitcoin will grow bigger and bigger without any doubts, And also there will be more and more companies related to the bitcoin network. When it comes to money, there will be a lot of fights between these companies. Is it possible to form some kind of committee to avoid harmful fights between these companies and also the situation that a single company controlling the direction of the bitcoin development? Is there any one doing this kind of job right now? Q: 2) My final question would be, do you really think it is possible that we can have a decentralized currency? Learning from the history, it seems like every thing will become centralized as long as it involves human. Do you have any picture for a decentralized currency or even a society? Thanks. A: 2) I think you might be surprised at what most people are running a year or three from now. Perhaps it will be a future version of Bitcoin Core, but I think there is a very good chance another project will be more successful. I remember when “everybody” was running Internet Explorer or Firefox, and people thought Google was crazy to think that Chrome would ever be a popular web browser. It took four years for Chrome to become the most popular web browser. In any case, I plan on working on Bitcoin related projects for at least another few years. Eventually it will become boring or I will decide I need to take a couple of years of and think about what I want to do next. As for fights between companies: there are always fights between companies, in every technology. There are organizations like the IETF (Internet Engineering Task Force) that try to create committees so engineers at companies can spend more time cooperating and less time fighting; I’m told by people who participate in IETF meetings that they are usually helpful and create useful standards more often than not. Finally, yes, I do think we can have a “decentralized-enough” currency. A currency that might be controlled at particular times by a small set of people or companies, but that gives everybody else the ability to take control if those people or businesses misbehave.
Hi Gavin, I have some questions: Q: 1) I noticed there are some new names added to the classic team list. Most people here only know you and Jeff. Can you briefly introduce some others to the Chinese community? A: 1) Tom Zander has been acting as lead developer, and is an experienced C++ developer who worked previously on the Qt and Debian open source projects. Pedro Pinheiro is on loan from Blockchain.info, and has mostly worked on continuous integration and testing for Classic. Jon Rumion joined recently, and has been working on things that will make life for developers more pleasant (I don’t want to be more specific, I don’t want to announce things before they are finished in case they don’t work out). Jeff has been very busy starting up Bloq, so he hasn’t been very active with Classic recently. I’ve also been very busy traveling (Barbados, Idaho, London and a very quick trip to Beijing) so haven’t been writing much code recently. Q: 2) if bitcoin classic succeeded (>75% threshold), what role would you play in the team after the 2MB upgrade finished, as a leader, a code contributor, a consultant, or something else? A: 2)Contributor and consultant-- I am trying not to be leader of any software project right now, I want to leave that to other people who are better at managing and scheduling and recruiting and all of the other things that need to be done to lead a software project. Q: 3) if bitcoin classic end up failed to achieve mainstream adoption (<75% 2018), will you continue the endeavor of encouraging on-chain scaling and garden-style growth of bitcoin? A: 3) Yes. If BIP109 does not happen, I will still be pushing to get a good on-chain solution to happen as soon as possible. Q: 4) Have you encountered any threat in your life, because people would think you obviously have many bitcoins, like what happened to Hal Finney (RIP), or because some people have different ideas about what bitcoin's future should be? A: 4) No, I don’t think I have received any death threats. It upsets me that other people have. Somebody did threaten to release my and my wife’s social security numbers and other identity information if I did not pay them some bitcoins a couple of years ago. I didn’t pay, they did release our information, and that has been a little inconvenient at times. Q: 5) Roger Ver (Bitcoin Jesus) said bitcoin would worth thousands of dollars. Do you have similar thoughts? If not, what is your opinion on bitcoin price in future? A: 5) I learned long ago to give up trying to predict the price of stocks, currencies, or Bitcoin. I think the price of Bitcoin will be higher in ten years, but I might be wrong. Q: 6) You've been to China. What's your impression about the country, people, and the culture here? Thank you! A: 6) I had a very quick trip to Beijing a few weeks ago-- not nearly long enough to get a good impression of the country or the culture. I had just enough time to walk around a little bit one morning, past the Forbidden City and walk around Tianmen Square. There are a LOT of people in China, I think the line to go into the Chairman Mao Memorial Hall was the longest I have ever seen! Beijing reminded me a little bit of London, with an interesting mix of the very old with the very new. The next time I am in China I hope I can spend at least a few weeks and see much more of the country; I like to be in a place long enough so that I really can start to understand the people and cultures.
Q: Dear Gavin, How could I contact you, we have an excellent team and good plans. please confirm your linkedin. A: Best contact for me is [email protected] : but I get lots of email, please excuse me if your messages get lost in the flood. 15. satoshi Q: Gavin, you've been both core and classic code contributor. Are there any major differences between the two teams, concerning code testing (quality control) and the release process of new versions? A: Testing and release processes are the same; a release candidate is created and tested, and once sufficiently tested, a final release is created, cryptographically signed by several developers, and then made available for download. The development process for Classic will be a little bit different, with a ‘develop’ branch where code will be pulled more quickly and then either fixed or reverted based on how testing goes. The goal is to create a more developer-friendly process, with pull requests either accepted or rejected fairly quickly.
I am a bitcoin enthusiast and a coin holder. I thank you for your great contribution to bitcoin. Please allow me to state some of my views before asking:
I'm on board with classic
I support the vision to make bitcoin a powerful currency that could compete with Visa
I support segwit, so I'll endorse whichever version of bitcoin implementation that upgrades to segwit, regardless of block size.
I disagree with those who argue bitcoin main blockchain should be a settlement network with small blocks. My view is that on the main chain btc should function properly as a currency, as well as a network for settlement.
I'm against the deployment of LN on top of small block sized blockchain. Rather, it should be built on a chain with bigger blocks.
I also won’t agree with the deployment of many sidechains on top of small size block chain. Rather, those sidechains should be on chain with bigger blocks.
With that said, below are my questions: Q: 1) If bitcoin is developed following core's vision, and after the 2020 halving which cuts block reward down to 6.125BTC, do you think the block transaction fee at that time will exceed 3BTC? A: 1) If the block limit is not raised, then no, I don’t think transaction fees will be that high. Q: 2) If bitcoin is developed following classic's vision, and after the 2020 halving which cuts block reward down to 6.125BTC, do you think the block transaction fee at that time will exceed 3BTC? A: 2) Yes, the vision is lots of transactions, each paying a very small fee, adding up to a big total for the miners. Q: 3) If bitcoin is developed following core's vision, do you think POW would fail in future, because the mining industry might be accounted too low value compared with that of the bitcoin total market, so that big miners could threaten btc market and gain profit by shorting? *The questioner further explained his concern. Currently, its about ~1.1 billion CNY worth of mining facilities protecting ~42 billion CNY worth (6.5 Billion USD) of bitcoin market. The ratio is ~3%. If bitcoin market cap continues to grow and we adopt layered development plan, the mining portion may decrease, pushing the ratio go even down to <1%, meaning we are using very small money protecting an huge expensive system. For example, in 2020 if bitcoin market cap is ~100 billion CNY, someone may attempt to spend ~1 billion CNY bribe/manipulate miners to attack the network, thus making a great fortune by shorting bitcoin and destroying the ecosystem. A: 3) Very good question, I have asked that myself. I have asked people if they know if there have been other cases where people destroyed a company or a market to make money by shorting it -- as far as I know, that does not happen. Maybe because it is impossible to take a large short position and remain anonymous, so even if you were successful, you would be arrested for doing whatever you did to destroy the company or market (e.g. blow up a factory to destroy a company, or double-spend fraud to try to destroy Bitcoin). Q: 4) If bitcoin is developed following classic's vision, will the blocks become too big that kill decentralization? A: 4) No, if you look at how many transactions the typical Internet connection can support, and how many transactions even a smart phone can validate per second, we can support many more transactions today with the hardware and network connections we have now. And hardware and network connections are getting faster all the time. Q: 5) In theory, even if we scale bitcoin with just LN and sidechains, the main chain still needs blocks with size over 100M, in order to process the trading volume matching Visa's network. So does core have any on-chain scaling plan other than 2MB? Or Core does not plan to evolve bitcoin into something capable of challenging visa? A: 5) Some of the Core developer talk about a “flexcap” solution to the block size limit, but there is no specific proposal. I think it would be best to eliminate the limit all together. That sounds crazy, but the most successful Internet protocols have no hard upper limits (there is no hard limit to how large a web page may be, for example), and no protocol limit is true to Satoshi’s original design. Q: 6) If (the majority of) hash rate managed to switch to Classic in 2018, will the bitcoin community witness the deployment of LN in two years (~2018)? A: 6) The bottleneck with Lightning Network will be wallet support, not support down at the Bitcoin protocol level. So I don’t think the deployment schedule of LN will be affected much whether Classic is adopted or not. Q: 7) If (majority) hash rate upgraded to blocks with segwit features in 2017 as specified in core's roadmap, would classic propose plans to work on top of that (blocks with segwit)? Or insist developing simplified segwit blocks as described in classic's roadmap? A: 7) Classic will follow majority hash rate. It doesn’t make sense to do anything else. Q: 8) If most hash rate is still on core's side before 2018, will you be disappointed with bitcoin, and announce that bitcoin has failed like what Mike did, and sell all your stashed coins at some acceptable price? A: 8) No-- I have said that I think if the block size limit takes longer to resolve, that is bad for Bitcoin in the short term, but smart engineers will work around whatever road blocks you put in front of them. I see Bitcoin as a long-term project. Q: 9) If we have most hash rate switched to classic's side before 2018, what do you think will be the fate of Blockstream company? A: 9) I think Blockstream might lose some employees, but otherwise I don’t think it will matter much. They are still producing interesting technology that might become a successful business. Q: 10) If we have most hash rate still on core's side before 2018, what do you think will be the fate of Blockstream company? A: 10) I don’t think Blockstream’s fate depends on whether or not BIP109 is adopted. It depends much more on whether or not they find customers willing to pay for the technology that they are developing. Q: 11) If we have most hash rate still on core's side before 2018, what do you think will be the fate of companies that support classic, such as Coinbse, bitpay, and Blockchain.info? A: 11) We have already seen companies like Kraken support alternative currencies (Kraken supports Litecoin and Ether); if there is no on-chain scaling solution accepted by the network, I think we will see more companies “hedging their bets” by supporting other currencies that have a simpler road map for supporting more transactions. Q: 12) If we have most hash rate switched to classic's side before 2018, will that hinder the development of sidechain tech? What will happen to companies like Rockroot(Rootstock?) ? A: 12) No, I think the best use of sidechains is for things that might be too risky for the main network (like Rootstock) or are narrowly focused on a small number of Bitcoin users. I don’t think hash rate supporting Classic will have any effect on that. Q: 13) Between the two versions of bitcoin client, which one is more conducive to mining industry, classic or core? A: 13) I have been working to make Classic better for the mining industry, but right now they are almost identical so it would be dishonest to say one is significantly better than the other.
Q: Gavin, can you describe what was in your mind when you first learned bitcoin? A: I was skeptical that it could actually work! I had to read everything I could about it, and then read the source code before I started to think that maybe it could actually be successful and was not a scam.
Audio interview transcription — WBD074. Note: the following is a transcription of my interview with Matt Corallo from Chaincode Labs. I use Rev.com from translations and they remove ums, errs and half sentences. I have reviewed the transcription but if you find any mistakes, please feel free to email me.You can listen to the original recording here. Square Crypto Hires Matt Corallo to Boost Bitcoin Development. Read full article. Leigh Cuen. August 20, 2019, 11:00 AM. Square Crypto, the division of the publicly traded payments company that ... By CCN: Matt Corallo, also known as “The Blue Matt,” has blocked Blockstream CSO Samson Mow on Twitter. Mow, according to Corallo, represents a toxic element of the Bitcoin community. Gavin Andresen once called Mow and Gregory Maxwell “toxic trolls.” Best decision I’ve ever made. I’m honestly pretty embarrassed to have helped ... View Matt Corallo’s profile on LinkedIn, the world's largest professional community. Matt has 2 jobs listed on their profile. See the complete profile on LinkedIn and discover Matt’s ... In this episode, I talk with Bitcoin Core developer, Matt Corallo. We discuss what makes Bitcoin work, covering topics such as the Lightning Network, fungibility and inflation. We also talk about issues important to Matt such as BetterHash and adoption. LISTEN TO THE FULL EPISODE HERE AND ACCESS LINKS TO THE SHOW NOTES https://www ...
Fungibility Overview by Adam Back and Matt Corallo (Scaling Bitcoin Milan 2016)
This feature is not available right now. Please try again later. MCC 2019: Matt Corallo - Mining: No Good, The Bad, and The Ugly ... MCC 2019: Justin Moon - The Next Generation of Bitcoin Developers by Magical Crypto Friends. 12:21. MCC 2019: Creating Bitcoin ... How to Tell If You're a Bitcoin Wizard - Matt Corallo - Duration: 6:21. CoinDesk 1,474 views. 6:21. Meditations of Marcus Aurelius - SUMMARIZED - (22 Stoic Principles to Live by) - Duration: 31:14 ... In the mean time, Bitcoin has been slowly shedding its anarchistic and anti-establishment origins and finding places where it can provide legitimate value within the current financial world. In ... Matt Corallo presents a special presentation on Blockchain technologies. Slides of the presentation here: http://goo.gl/hwtTYc