Square Crypto Hires Matt Corallo to Boost Bitcoin Development

r/Bitcoin recap - November 2019

Hi Bitcoiners!
I’m back with the 35th monthly Bitcoin news recap.
For those unfamiliar, each day I pick out the most popularelevant/interesting stories in Bitcoin and save them. At the end of the month I release them in one batch, to give you a quick (but not necessarily the best) overview of what happened in bitcoin over the past month.
You can see recaps of the previous months on Bitcoinsnippets.com
A recap of Bitcoin in November 2019
Adoption
Development
Mining
Business
Education
Regulation & Politics
Archeology (Financial Incumbents)
Fun & Other
submitted by SamWouters to Bitcoin [link] [comments]

Will a high tx fee actually *increase* the expected confirmation time?

Suppose you are bitcoin miner (of any fork), with command of less than (say) 5% of the total hashpower, and you receive a transaction from a user that pays $50 of fee. Is it in your interest to forward that tx to other miners?
Until Jan/2017 or so, the answer should have been "no". If other miners got (or will soon get) that tx by some other path, sending it again would be a pointless waste of bandwidth. So suppose that no one else will get it by other means. If you hold onto that tx and keep adding it to your candidate blocks, when you finally solve a block you will collect those $50. On the other hand, if you forward it to other miners, there is at least a 95% chance that some other miner will collect those $50.
Since Jan/2017 the question became more complicated, because Matt Corallo's improved block propagation protocol (FIBRE) will transmit a block very fast if the receiving miner has already seen all transactions contained in it. Any transactions that he has not yet seen must be transmitted at that time; and the receiver cannot use or forward the block until all those "unseen" transactions have arrived.
So, if you hold that transaction with $50 fee, and the other miners will not get it by some other means, when you finally solve a block you will have to send that transaction with it. Your block will take a bit longer to propagate to other miners. Then there is an increased chance that another miner will solve his block and forward it to everybody, while yours is still propagating. Then your block may be orphaned and you will lose the reward that you would otherwise have collected.
The key parameter is the extra delay D that would be added to the propagation time of your block, if a single transaction in it was not seen by anyone else and had to be transmitted with the block. I don't know how much D can be. Let me guess that 1 extra unseen tx adds D = 6 milliseconds to the propagation time. The probability that some other miner will solve his block in those 6 milliseconds is 600/0.006 = 1/100'000. The block reward, at the current price, is about $50'000. Therefore, the expected loss for holding a transaction, if no one else will receive it by other means, is $0.50.
It follows that, if the extra delay D is 6 ms and the price is $3800, you should not forward to other miners any transaction that pays more than $0.50 of fee. On average, you will earn more if you hold that transaction, and keep putting it into your candidate blocks, until you solve one.
Makes sense?
EDIT: By the way There is reason to suspect that the "full but non-mining" relays may not be doing their job.
submitted by jstolfi to btc [link] [comments]

Six Hundred Microseconds.

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.
submitted by Cobi-communities to u/Cobi-communities [link] [comments]

Mining is how you vote for rule changes. Greg's comments on BU revealed he has no idea how Bitcoin works. He thought "honest" meant "plays by Core rules." [But] there is no "honesty" involved. There is only the assumption that the majority of miners are INTELLIGENTLY PROFIT-SEEKING. - ForkiusMaximus

The title of this post is a compressed summary combining some important quotes from several recent comments by u/ForkiusMaximus, which I thought were worth highlighting here in a post of their own.
His comments remind us that Bitcoin was already brilliantly designed by Satoshi so that the majority of "honest" "intelligently profit-seeking" miners will always be economically incentivized to use their hashpower to vote for the rule changes which will maximize their (and everyone else's) Bitcoin profits - and they will always do this regardless of any censorship or centralized dev teams.
Meanwhile, Core/Blockstream (and their supporters) totally fail to understand this subtle but vital point: they think that devs somehow control Bitcoin, by forcing people to run certain code... or moderators somehow control Bitcoin, by censoring certain forums... or now non-mining nodes can somehow control Bitcoin by suggesting a futile and pointless "user-activated soft-fork" (UASF) - ie a fork not supported by actual mining hashpower.
This all shows that Core/Blockstream (and their supporters) have a fundamental misunderstanding of the most important aspect of Bitcoin - the fact that:
This is why the 21 million coin cap will never get increased.
And this is why blocksizes will always continue to moderately increase.
Not because some dev team made it "hard" to modify these settings in the code.
And not because some moderator censored some discussion about some alternative clients.
The reason Bitcoin works is simply because the vast majority of miners are "honest" "intelligently profit-seeking".
This is why mining support for Core/Blockstream's centrally-planned blocksize has dropped to 2/3 of network hashpower (despite their big team of "experts" and all their censorship and fiat funding).
And this is why 1/3 of mining hashpower has already started voting for some form of market-driven blocksizes...
... not because BU or Classic suddenly "gave" them this power (after all, they always had this power themselves)...
... but simply because the vast majority of miners are "honest" "intelligently profit-seeking", and they know that bigger blocks will bring higher profits.
So, miners have always been able to use their hashpower (and even modify the Bitcoin client source code if they wanted) in order to vote for rule changes which would support bigger blocksizes and higher Bitcoin profits for everyone - with or without any help from BU, Classic, etc. - and there is nothing that any dev team (or any censored forum) can do to prevent miners from doing this.
So it is inevitable that miners will use their hashpower to vote for bigger blocksizes, because this means much higher Bitcoin profits for them (and also bigger Bitcoin profits for the rest of us :-)... simply because (as Satoshi clearly did understand, but most Core/Blockstream devs clearly do not understand):

The vast majority of miners are "honest" "intelligently profit-seeking".

The original comments by u/ForkiusMaximus providing an explanation of these important (but often subtle) concepts are shown below - with some text bolded & italicized for empahsis.
https://np.reddit.com/btc/comments/5z3hv5/bloomberg_antpool_will_switch_entire_pool_to/dev7drt/?context=3
We don't have to trust [miners] to be "honest" as Satoshi unfortunately worded it.
Replace the term honest with "intelligently profit-seeking."
Bitcoin assumes miners are intelligently profit-seeking, meaning that they have a decent enough read on what the ecosystem wants that they can and will make any necessary changes to please the ecosystem and thus boost their own bottom line.
Greg's recent comments on BU totally discredited him, as he revealed himself to have no friggin' idea how Bitcoin works.
He actually thought "honest" meant something like "plays by Core rules." That's a completely broken understanding of Bitcoin, and implies centralization.
It's the kind of misconception I'd expect from a run-of-the-mill nobody on a forum, not from the mighty leader of Core/BS. I'm kinda pissed I wasted mental clock ticks trying to debate this guy without realizing he has not just a flawed understanding, but zero understanding of how Bitcoin works at all. And of course all his supporters parrot his nonsense view of how Bitcoin supposedly works.
https://np.reddit.com/btc/comments/5yxreu/classic_fearmongering_example_by_bitcoin_core/dev0x5d/?context=3
Mining control is the key invention of Bitcoin. It's how it doesn't just devolve into yet another failed subjective monetary scheme. If you don't like it, you should figure out another scheme. Perhaps proof of stake is more your thing?
Also, it's pretty amazing that you think just because BU makes it more convenient for miners to do what they always could do, that that somehow dooms Bitcoin. If that dooms it, it was already a dead man walking.
How do you propose to stop miners from altering their own blocksize settings?
If you have no answer, you have no grounds to attack BU without falling into the category of being a Bitcoin skeptic.
https://np.reddit.com/btc/comments/5zoywt/the_largest_problem_of_bitcoin_is_that_most/df0jutk/
It's actually fairly subtle: mining IS how you vote for rule changes, BUT miners have every incentive to vote with the market, so they DON'T have any meaningful ability to push rules on the community (even under BU).
There is no trust or "honesty" involved, as Satoshi unfortunately worded it. There is only the underlying assumption that makes Bitcoin work: the assumption that the vast majority of miners are INTELLIGENTLY PROFIT-SEEKING.
The only way this system can break is if the majority of miners seek something other than profit (say a government took the major mining pools over and somehow hashers couldn't switch away in time), or the miners misjudge what the market wants (due to a failure of market communication).
However, in this case and on these timescales it is obvious the current crop of miners are generally profit-seeking. And if they are misjudging the market, we have a remedy: we can resolve that through fork futures trading on the exchanges.
Note that this is just moving the decision from the first kind of investors (miners) to the general investing public. Miners are a first-line proxy for investors in general. If they fail to reflect investor will, investors are free to take it to the market by forking and trading the two sides of the fork (preferably as futures so as to avoid scrambling to upgrade urgently).
Also important would be to maximize freedom of discussion so that market communication is not distorted. Finally, the whole idea of the UASF people, that we would poll the ecosystem somehow to prove the economic majority wants some change, already means that merely showing this proof to the miners should convince them, as they are intelligently profit-seeking. But that obviates the need for a UASF in the first place (!).
https://np.reddit.com/btc/comments/5yyotu/if_blockstream_core_offchain_solutions_are_any/deu0hpn/
I used to think they don't understand markets, but in fact they are stuck at an even more basic level than that.
I took a spin through the wreckage of /Bitcoin today for the first time in weeks. It was pleasantly surprising to see how with the ramping up of miner support for BU, the Core arguments have been reduced to obvious fundamental misunderstandings of Bitcoin that are now trivial to rebut.
In a word, they haven't actually grasped the concept of incentives.
This goes all the way to the top, not just the supporters but the key Core devs themselves. They don't understand markets, yes, but it's not like they are even close. They lack the understanding of even the fundamental building blocks of markets.
When you think about it, governance by incentives is pretty subtle. Even if one reads the whitepaper and goes, "Oh yeah I see, miners would be motivated not to kill the golden goose in that situation," it is quite another matter to fully internalize the fact that the only reason Bitcoin is a thing at all is because of the assumption that miners are not idiots. Or more accurately, that miners as a group will never have a gross failure to correctly apprehend the wishes of the market.
This is the source of all the weird claims about miners controlling or not controlling Bitcoin.
Core and Blockstream dev Matt Corallo thinks that if miners were allowed to (not mentioning how they could be disallowed to), they would mine extra coins for all the "extra profits." Again this goes beyond failing to understand markets, all the way down to failing to understand or take seriously incentives as a concept at all. I'm not blaming him, he's a coder; I blame those who take his commentary on non-coding matters seriously, merely by dint of his coding skill.
A constant refrain from Core supporters as BU gain hashpower is that "miners don't control Bitcoin." This is actually correct: miners don't control Bitcoin, they won't act against the economic majority. But not because they can't. They certainly can, just like oncoming traffic can swerve toward you on the freeway. But they don't, because that would destroy them as well.
Thus is the subtlety of governance by incentives. Miners have control, but they won't use it to do anything that displeases the ecosystem, on balance. Or they might, but in that case Bitcoin is a failed concept as its fundamental assumption is then proven to be broken.
Many or most anti-BU arguments unwittingly take that form: they start with the premise that Bitcoin is broken [i.e., miners are idiots or that they grossly fail to read the market] and reason from there to conclude that BU is broken. Examples include the median EB attack, the various big block attacks, and the bizarre claim that BU has a "new security model" because it "lets miners do something they couldn't before" (ironically implying Core has snuck in a new security model where they try to restrain miners by making it inconvenient for them to change a blocksize setting).
Hence we see that it isn't merely a matter of Core and Blockstream people having initially dismissed Bitcoin and then later seeing the light when the price rises forced them to look deeper. They in fact still haven't seen the light. They never fully understood the basic dynamic that makes Bitcoin tick, let alone understanding higher level concepts like markets. This is why they so easily fall into the central planning mindset, seeing Bitcoin as a fragile little thing that must be defended by their wise paternalistic guidance.
The Core devs have replaced the fundamental assumption in the whitepaper, that most miners are honest (I prefer "most miners are not idiots" as it is harder to misinterpret), with the fundamental assumption that the right set of people (or the right repository governance structure) is in charge of the "reference implementation."
This manifests as a kind of envy toward the miners and comes with all the other curious trappings of the Core worldview: the code is the spec, hard forks are dangerous, Core = Bitcoin, anything that deviates from Core diktats is an "altcoin," it doesn't count as censorship to delete discussion of alternative clients as they are "off topic," nodes > miners, anything that makes it a bit easier for miners to do something Core doesn't like is an "attack" on Bitcoin, centralized control by Core is necessary to preserve decentralization, UASF is a viable idea, Segwit has consensus among "the Bitcoin experts," and so on.
https://np.reddit.com/btc/comments/5yvtrn/new_atl_alltime_low_for_bitcoin_core_client/detpkdj/
Estimated Core hashrate down below 2/3 already.
Core has lost supermajority status, even with all the historical inertia, miner conservatism, and crackerjack programmers they are reported to have on their side. Even with the "consensus" of "the experts."
Even with two years of mindbendingly extreme censorship in their favor on the two biggest Bitcoin discussion forums.
https://np.reddit.com/btc/comments/5yvuw7/while_nobody_was_paying_attention/detqbnd/?context=3
The Core devs have directly created this situation by keeping the blocksize cap locked down long after it became controversial. The logic of how users make needed changes to the protocol, as mentioned in the whitepaper, requires that users be able to easily adjust any settings that are controversial, so as to be able to "vote with their CPU" power in a smooth manner.
Core tries to leverage their waning "reference implementation" status to rig the vote by deliberately leaving the now maximally controversial blocksize limit hard-coded, forcing the user to venture out into relatively new dev team offerings if they want to cast a vote. This is exactly how you create the conditions for a contentious split. They have brought this upon themselves entirely.
https://np.reddit.com/btc/comments/5z6w2u/bitcoin_on_linux_should_be_a_virtual_package/dewjwlh/
Adam implies BU is pre-alpha, yet it is winning in the only arena where people actually put their money where their mouths are.
How pathetic does it make Core that they are losing to a pre-alpha client?
submitted by ydtm to btc [link] [comments]

21 months ago, Gavin Andresen published "A Scalability Roadmap", including sections called: "Increasing transaction volume", "Bigger Block Road Map", and "The Future Looks Bright". *This* was the Bitcoin we signed up for. It's time for us to take Bitcoin back from the strangle-hold of Blockstream.

A Scalability Roadmap
06 October 2014
by Gavin Andresen
https://web.archive.org/web/20150129023502/http://blog.bitcoinfoundation.org/a-scalability-roadmap
Increasing transaction volume
I expect the initial block download problem to be mostly solved in the next relase or three of Bitcoin Core. The next scaling problem that needs to be tackled is the hardcoded 1-megabyte block size limit that means the network can suppor[t] only approximately 7-transactions-per-second.
Any change to the core consensus code means risk, so why risk it? Why not just keep Bitcoin Core the way it is, and live with seven transactions per second? “If it ain’t broke, don’t fix it.”
Back in 2010, after Bitcoin was mentioned on Slashdot for the first time and bitcoin prices started rising, Satoshi rolled out several quick-fix solutions to various denial-of-service attacks. One of those fixes was to drop the maximum block size from infinite to one megabyte (the practical limit before the change was 32 megabytes– the maximum size of a message in the p2p protocol). The intent has always been to raise that limit when transaction volume justified larger blocks.
“Argument from Authority” is a logical fallacy, so “Because Satoshi Said So” isn’t a valid reason. However, staying true to the original vision of Bitcoin is very important. That vision is what inspires people to invest their time, energy, and wealth in this new, risky technology.
I think the maximum block size must be increased for the same reason the limit of 21 million coins must NEVER be increased: because people were told that the system would scale up to handle lots of transactions, just as they were told that there will only ever be 21 million bitcoins.
We aren’t at a crisis point yet; the number of transactions per day has been flat for the last year (except for a spike during the price bubble around the beginning of the year). It is possible there are an increasing number of “off-blockchain” transactions happening, but I don’t think that is what is going on, because USD to BTC exchange volume shows the same pattern of transaction volume over the last year. The general pattern for both price and transaction volume has been periods of relative stability, followed by bubbles of interest that drive both price and transaction volume rapidly up. Then a crash down to a new level, lower than the peak but higher than the previous stable level.
My best guess is that we’ll run into the 1 megabyte block size limit during the next price bubble, and that is one of the reasons I’ve been spending time working on implementing floating transaction fees for Bitcoin Core. Most users would rather pay a few cents more in transaction fees rather than waiting hours or days (or never!) for their transactions to confirm because the network is running into the hard-coded blocksize limit.
Bigger Block Road Map
Matt Corallo has already implemented the first step to supporting larger blocks – faster relaying, to minimize the risk that a bigger block takes longer to propagate across the network than a smaller block. See the blog post I wrote in August for details.
There is already consensus that something needs to change to support more than seven transactions per second. Agreeing on exactly how to accomplish that goal is where people start to disagree – there are lots of possible solutions. Here is my current favorite:
Roll out a hard fork that increases the maximum block size, and implements a rule to increase that size over time, very similar to the rule that decreases the block reward over time.
Choose the initial maximum size so that a “Bitcoin hobbyist” can easily participate as a full node on the network. By “Bitcoin hobbyist” I mean somebody with a current, reasonably fast computer and Internet connection, running an up-to-date version of Bitcoin Core and willing to dedicate half their CPU power and bandwidth to Bitcoin.
And choose the increase to match the rate of growth of bandwidth over time: 50% per year for the last twenty years. Note that this is less than the approximately 60% per year growth in CPU power; bandwidth will be the limiting factor for transaction volume for the foreseeable future.
I believe this is the “simplest thing that could possibly work.” It is simple to implement correctly and is very close to the rules operating on the network today. Imposing a maximum size that is in the reach of any ordinary person with a pretty good computer and an average broadband internet connection eliminates barriers to entry that might result in centralization of the network.
Once the network allows larger-than-1-megabyte blocks, further network optimizations will be necessary. This is where Invertible Bloom Lookup Tables or (perhaps) other data synchronization algorithms will shine.
The Future Looks Bright
So some future Bitcoin enthusiast or professional sysadmin would download and run software that did the following to get up and running quickly:
  1. Connect to peers, just as is done today.
  2. Download headers for the best chain from its peers (tens of megabytes; will take at most a few minutes)
  3. Download enough full blocks to handle and reasonable blockchain re-organization (a few hundred should be plenty, which will take perhaps an hour).
  4. Ask a peer for the UTXO set, and check it against the commitment made in the blockchain.
From this point on, it is a fully-validating node. If disk space is scarce, it can delete old blocks from disk.
How far does this lead?
There is a clear path to scaling up the network to handle several thousand transactions per second (“Visa scale”). Getting there won’t be trivial, because writing solid, secure code takes time and because getting consensus is hard. Fortunately technological progress marches on, and Nielsen’s Law of Internet Bandwidth and Moore’s Law make scaling up easier as time passes.
The map gets fuzzy if we start thinking about how to scale faster than the 50%-per-increase-in-bandwidth-per-year of Nielsen’s Law. Some complicated scheme to avoid broadcasting every transaction to every node is probably possible to implement and make secure enough.
But 50% per year growth is really good. According to my rough back-of-the-envelope calculations, my above-average home Internet connection and above-average home computer could easily support 5,000 transactions per second today.
That works out to 400 million transactions per day. Pretty good; every person in the US could make one Bitcoin transaction per day and I’d still be able to keep up.
After 12 years of bandwidth growth that becomes 56 billion transactions per day on my home network connection — enough for every single person in the world to make five or six bitcoin transactions every single day. It is hard to imagine that not being enough; according the the Boston Federal Reserve, the average US consumer makes just over two payments per day.
So even if everybody in the world switched entirely from cash to Bitcoin in twenty years, broadcasting every transaction to every fully-validating node won’t be a problem.
submitted by ydtm to btc [link] [comments]

The Origins of the Blocksize Debate

On May 4, 2015, Gavin Andresen wrote on his blog:
I was planning to submit a pull request to the 0.11 release of Bitcoin Core that will allow miners to create blocks bigger than one megabyte, starting a little less than a year from now. But this process of peer review turned up a technical issue that needs to get addressed, and I don’t think it can be fixed in time for the first 0.11 release.
I will be writing a series of blog posts, each addressing one argument against raising the maximum block size, or against scheduling a raise right now... please send me an email ([email protected]) if I am missing any arguments
In other words, Gavin proposed a hard fork via a series of blog posts, bypassing all developer communication channels altogether and asking for personal, private emails from anyone interested in discussing the proposal further.
On May 5 (1 day after Gavin submitted his first blog post), Mike Hearn published The capacity cliff on his Medium page. 2 days later, he posted Crash landing. In these posts, he argued:
A common argument for letting Bitcoin blocks fill up is that the outcome won’t be so bad: just a market for fees... this is wrong. I don’t believe fees will become high and stable if Bitcoin runs out of capacity. Instead, I believe Bitcoin will crash.
...a permanent backlog would start to build up... as the backlog grows, nodes will start running out of memory and dying... as Core will accept any transaction that’s valid without any limit a node crash is eventually inevitable.
He also, in the latter article, explained that he disagreed with Satoshi's vision for how Bitcoin would mature[1][2]:
Neither me nor Gavin believe a fee market will work as a substitute for the inflation subsidy.
Gavin continued to publish the series of blog posts he had announced while Hearn made these predictions. [1][2][3][4][5][6][7]
Matt Corallo brought Gavin's proposal up on the bitcoin-dev mailing list after a few days. He wrote:
Recently there has been a flurry of posts by Gavin at http://gavinandresen.svbtle.com/ which advocate strongly for increasing the maximum block size. However, there hasnt been any discussion on this mailing list in several years as far as I can tell...
So, at the risk of starting a flamewar, I'll provide a little bait to get some responses and hope the discussion opens up into an honest comparison of the tradeoffs here. Certainly a consensus in this kind of technical community should be a basic requirement for any serious commitment to blocksize increase.
Personally, I'm rather strongly against any commitment to a block size increase in the near future. Long-term incentive compatibility requires that there be some fee pressure, and that blocks be relatively consistently full or very nearly full. What we see today are transactions enjoying next-block confirmations with nearly zero pressure to include any fee at all (though many do because it makes wallet code simpler).
This allows the well-funded Bitcoin ecosystem to continue building systems which rely on transactions moving quickly into blocks while pretending these systems scale. Thus, instead of working on technologies which bring Bitcoin's trustlessness to systems which scale beyond a blockchain's necessarily slow and (compared to updating numbers in a database) expensive settlement, the ecosystem as a whole continues to focus on building centralized platforms and advocate for changes to Bitcoin which allow them to maintain the status quo
Shortly thereafter, Corallo explained further:
The point of the hard block size limit is exactly because giving miners free rule to do anything they like with their blocks would allow them to do any number of crazy attacks. The incentives for miners to pick block sizes are no where near compatible with what allows the network to continue to run in a decentralized manner.
Tier Nolan considered possible extensions and modifications that might improve Gavin's proposal and argued that soft caps could be used to mitigate against the dangers of a blocksize increase. Tom Harding voiced support for Gavin's proposal
Peter Todd mentioned that a limited blocksize provides the benefit of protecting against the "perverse incentives" behind potential block withholding attacks.
Slush didn't have a strong opinion one way or the other, and neither did Eric Lombrozo, though Eric was interested in developing hard-fork best practices and wanted to:
explore all the complexities involved with deployment of hard forks. Let’s not just do a one-off ad-hoc thing.
Matt Whitlock voiced his opinion:
I'm not so much opposed to a block size increase as I am opposed to a hard fork... I strongly fear that the hard fork itself will become an excuse to change other aspects of the system in ways that will have unintended and possibly disastrous consequences.
Bryan Bishop strongly opposed Gavin's proposal, and offered a philosophical perspective on the matter:
there has been significant public discussion... about why increasing the max block size is kicking the can down the road while possibly compromising blockchain security. There were many excellent objections that were raised that, sadly, I see are not referenced at all in the recent media blitz. Frankly I can't help but feel that if contributions, like those from #bitcoin-wizards, have been ignored in lieu of technical analysis, and the absence of discussion on this mailing list, that I feel perhaps there are other subtle and extremely important technical details that are completely absent from this--and other-- proposals.
Secured decentralization is the most important and most interesting property of bitcoin. Everything else is rather trivial and could be achieved millions of times more efficiently with conventional technology. Our technical work should be informed by the technical nature of the system we have constructed.
There's no doubt in my mind that bitcoin will always see the most extreme campaigns and the most extreme misunderstandings... for development purposes we must hold ourselves to extremely high standards before proposing changes, especially to the public, that have the potential to be unsafe and economically unsafe.
There are many potential technical solutions for aggregating millions (trillions?) of transactions into tiny bundles. As a small proof-of-concept, imagine two parties sending transactions back and forth 100 million times. Instead of recording every transaction, you could record the start state and the end state, and end up with two transactions or less. That's a 100 million fold, without modifying max block size and without potentially compromising secured decentralization.
The MIT group should listen up and get to work figuring out how to measure decentralization and its security.. Getting this measurement right would be really beneficial because we would have a more academic and technical understanding to work with.
Gregory Maxwell echoed and extended that perspective:
When Bitcoin is changed fundamentally, via a hard fork, to have different properties, the change can create winners or losers...
There are non-trivial number of people who hold extremes on any of these general belief patterns; Even among the core developers there is not a consensus on Bitcoin's optimal role in society and the commercial marketplace.
there is a at least a two fold concern on this particular ("Long term Mining incentives") front:
One is that the long-held argument is that security of the Bitcoin system in the long term depends on fee income funding autonomous, anonymous, decentralized miners profitably applying enough hash-power to make reorganizations infeasible.
For fees to achieve this purpose, there seemingly must be an effective scarcity of capacity.
The second is that when subsidy has fallen well below fees, the incentive to move the blockchain forward goes away. An optimal rational miner would be best off forking off the current best block in order to capture its fees, rather than moving the blockchain forward...
tools like the Lightning network proposal could well allow us to hit a greater spectrum of demands at once--including secure zero-confirmation (something that larger blocksizes reduce if anything), which is important for many applications. With the right technology I believe we can have our cake and eat it too, but there needs to be a reason to build it; the security and decentralization level of Bitcoin imposes a hard upper limit on anything that can be based on it.
Another key point here is that the small bumps in blocksize which wouldn't clearly knock the system into a largely centralized mode--small constants--are small enough that they don't quantitatively change the operation of the system; they don't open up new applications that aren't possible today
the procedure I'd prefer would be something like this: if there is a standing backlog, we-the-community of users look to indicators to gauge if the network is losing decentralization and then double the hard limit with proper controls to allow smooth adjustment without fees going to zero (see the past proposals for automatic block size controls that let miners increase up to a hard maximum over the median if they mine at quadratically harder difficulty), and we don't increase if it appears it would be at a substantial increase in centralization risk. Hardfork changes should only be made if they're almost completely uncontroversial--where virtually everyone can look at the available data and say "yea, that isn't undermining my property rights or future use of Bitcoin; it's no big deal". Unfortunately, every indicator I can think of except fee totals has been going in the wrong direction almost monotonically along with the blockchain size increase since 2012 when we started hitting full blocks and responded by increasing the default soft target. This is frustrating
many people--myself included--have been working feverishly hard behind the scenes on Bitcoin Core to increase the scalability. This work isn't small-potatoes boring software engineering stuff; I mean even my personal contributions include things like inventing a wholly new generic algebraic optimization applicable to all EC signature schemes that increases performance by 4%, and that is before getting into the R&D stuff that hasn't really borne fruit yet, like fraud proofs. Today Bitcoin Core is easily >100 times faster to synchronize and relay than when I first got involved on the same hardware, but these improvements have been swallowed by the growth. The ironic thing is that our frantic efforts to keep ahead and not lose decentralization have both not been enough (by the best measures, full node usage is the lowest its been since 2011 even though the user base is huge now) and yet also so much that people could seriously talk about increasing the block size to something gigantic like 20MB. This sounds less reasonable when you realize that even at 1MB we'd likely have a smoking hole in the ground if not for existing enormous efforts to make scaling not come at a loss of decentralization.
Peter Todd also summarized some academic findings on the subject:
In short, without either a fixed blocksize or fixed fee per transaction Bitcoin will will not survive as there is no viable way to pay for PoW security. The latter option - fixed fee per transaction - is non-trivial to implement in a way that's actually meaningful - it's easy to give miners "kickbacks" - leaving us with a fixed blocksize.
Even a relatively small increase to 20MB will greatly reduce the number of people who can participate fully in Bitcoin, creating an environment where the next increase requires the consent of an even smaller portion of the Bitcoin ecosystem. Where does that stop? What's the proposed mechanism that'll create an incentive and social consensus to not just 'kick the can down the road'(3) and further centralize but actually scale up Bitcoin the hard way?
Some developers (e.g. Aaron Voisine) voiced support for Gavin's proposal which repeated Mike Hearn's "crash landing" arguments.
Pieter Wuille said:
I am - in general - in favor of increasing the size blocks...
Controversial hard forks. I hope the mailing list here today already proves it is a controversial issue. Independent of personal opinions pro or against, I don't think we can do a hard fork that is controversial in nature. Either the result is effectively a fork, and pre-existing coins can be spent once on both sides (effectively failing Bitcoin's primary purpose), or the result is one side forced to upgrade to something they dislike - effectively giving a power to developers they should never have. Quoting someone: "I did not sign up to be part of a central banker's committee".
The reason for increasing is "need". If "we need more space in blocks" is the reason to do an upgrade, it won't stop after 20 MB. There is nothing fundamental possible with 20 MB blocks that isn't with 1 MB blocks.
Misrepresentation of the trade-offs. You can argue all you want that none of the effects of larger blocks are particularly damaging, so everything is fine. They will damage something (see below for details), and we should analyze these effects, and be honest about them, and present them as a trade-off made we choose to make to scale the system better. If you just ask people if they want more transactions, of course you'll hear yes. If you ask people if they want to pay less taxes, I'm sure the vast majority will agree as well.
Miner centralization. There is currently, as far as I know, no technology that can relay and validate 20 MB blocks across the planet, in a manner fast enough to avoid very significant costs to mining. There is work in progress on this (including Gavin's IBLT-based relay, or Greg's block network coding), but I don't think we should be basing the future of the economics of the system on undemonstrated ideas. Without those (or even with), the result may be that miners self-limit the size of their blocks to propagate faster, but if this happens, larger, better-connected, and more centrally-located groups of miners gain a competitive advantage by being able to produce larger blocks. I would like to point out that there is nothing evil about this - a simple feedback to determine an optimal block size for an individual miner will result in larger blocks for better connected hash power. If we do not want miners to have this ability, "we" (as in: those using full nodes) should demand limitations that prevent it. One such limitation is a block size limit (whatever it is).
Ability to use a full node.
Skewed incentives for improvements... without actual pressure to work on these, I doubt much will change. Increasing the size of blocks now will simply make it cheap enough to continue business as usual for a while - while forcing a massive cost increase (and not just a monetary one) on the entire ecosystem.
Fees and long-term incentives.
I don't think 1 MB is optimal. Block size is a compromise between scalability of transactions and verifiability of the system. A system with 10 transactions per day that is verifiable by a pocket calculator is not useful, as it would only serve a few large bank's settlements. A system which can deal with every coffee bought on the planet, but requires a Google-scale data center to verify is also not useful, as it would be trivially out-competed by a VISA-like design. The usefulness needs in a balance, and there is no optimal choice for everyone. We can choose where that balance lies, but we must accept that this is done as a trade-off, and that that trade-off will have costs such as hardware costs, decreasing anonymity, less independence, smaller target audience for people able to fully validate, ...
Choose wisely.
Mike Hearn responded:
this list is not a good place for making progress or reaching decisions.
if Bitcoin continues on its current growth trends it will run out of capacity, almost certainly by some time next year. What we need to see right now is leadership and a plan, that fits in the available time window.
I no longer believe this community can reach consensus on anything protocol related.
When the money supply eventually dwindles I doubt it will be fee pressure that funds mining
What I don't see from you yet is a specific and credible plan that fits within the next 12 months and which allows Bitcoin to keep growing.
Peter Todd then pointed out that, contrary to Mike's claims, developer consensus had been achieved within Core plenty of times recently. Btc-drak asked Mike to "explain where the 12 months timeframe comes from?"
Jorge Timón wrote an incredibly prescient reply to Mike:
We've successfully reached consensus for several softfork proposals already. I agree with others that hardfork need to be uncontroversial and there should be consensus about them. If you have other ideas for the criteria for hardfork deployment all I'm ears. I just hope that by "What we need to see right now is leadership" you don't mean something like "when Gaving and Mike agree it's enough to deploy a hardfork" when you go from vague to concrete.
Oh, so your answer to "bitcoin will eventually need to live on fees and we would like to know more about how it will look like then" it's "no bitcoin long term it's broken long term but that's far away in the future so let's just worry about the present". I agree that it's hard to predict that future, but having some competition for block space would actually help us get more data on a similar situation to be able to predict that future better. What you want to avoid at all cost (the block size actually being used), I see as the best opportunity we have to look into the future.
this is my plan: we wait 12 months... and start having full blocks and people having to wait 2 blocks for their transactions to be confirmed some times. That would be the beginning of a true "fee market", something that Gavin used to say was his #1 priority not so long ago (which seems contradictory with his current efforts to avoid that from happening). Having a true fee market seems clearly an advantage. What are supposedly disastrous negative parts of this plan that make an alternative plan (ie: increasing the block size) so necessary and obvious. I think the advocates of the size increase are failing to explain the disadvantages of maintaining the current size. It feels like the explanation are missing because it should be somehow obvious how the sky will burn if we don't increase the block size soon. But, well, it is not obvious to me, so please elaborate on why having a fee market (instead of just an price estimator for a market that doesn't even really exist) would be a disaster.
Some suspected Gavin/Mike were trying to rush the hard fork for personal reasons.
Mike Hearn's response was to demand a "leader" who could unilaterally steer the Bitcoin project and make decisions unchecked:
No. What I meant is that someone (theoretically Wladimir) needs to make a clear decision. If that decision is "Bitcoin Core will wait and watch the fireworks when blocks get full", that would be showing leadership
I will write more on the topic of what will happen if we hit the block size limit... I don't believe we will get any useful data out of such an event. I've seen distributed systems run out of capacity before. What will happen instead is technological failure followed by rapid user abandonment...
we need to hear something like that from Wladimir, or whoever has the final say around here.
Jorge Timón responded:
it is true that "universally uncontroversial" (which is what I think the requirement should be for hard forks) is a vague qualifier that's not formally defined anywhere. I guess we should only consider rational arguments. You cannot just nack something without further explanation. If his explanation was "I will change my mind after we increase block size", I guess the community should say "then we will just ignore your nack because it makes no sense". In the same way, when people use fallacies (purposely or not) we must expose that and say "this fallacy doesn't count as an argument". But yeah, it would probably be good to define better what constitutes a "sensible objection" or something. That doesn't seem simple though.
it seems that some people would like to see that happening before the subsidies are low (not necessarily null), while other people are fine waiting for that but don't want to ever be close to the scale limits anytime soon. I would also like to know for how long we need to prioritize short term adoption in this way. As others have said, if the answer is "forever, adoption is always the most important thing" then we will end up with an improved version of Visa. But yeah, this is progress, I'll wait for your more detailed description of the tragedies that will follow hitting the block limits, assuming for now that it will happen in 12 months. My previous answer to the nervous "we will hit the block limits in 12 months if we don't do anything" was "not sure about 12 months, but whatever, great, I'm waiting for that to observe how fees get affected". But it should have been a question "what's wrong with hitting the block limits in 12 months?"
Mike Hearn again asserted the need for a leader:
There must be a single decision maker for any given codebase.
Bryan Bishop attempted to explain why this did not make sense with git architecture.
Finally, Gavin announced his intent to merge the patch into Bitcoin XT to bypass the peer review he had received on the bitcoin-dev mailing list.
submitted by sound8bits to Bitcoin [link] [comments]

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
submitted by specialenmity to btc [link] [comments]

HODLERs of Last resort

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?
submitted by cpgilliard78 to BitcoinPrivate [link] [comments]

The Origins of the (Modern) Blocksize Debate

On May 4, 2015, Gavin Andresen wrote on his blog:
I was planning to submit a pull request to the 0.11 release of Bitcoin Core that will allow miners to create blocks bigger than one megabyte, starting a little less than a year from now. But this process of peer review turned up a technical issue that needs to get addressed, and I don’t think it can be fixed in time for the first 0.11 release.
I will be writing a series of blog posts, each addressing one argument against raising the maximum block size, or against scheduling a raise right now... please send me an email ([email protected]) if I am missing any arguments
In other words, Gavin proposed a hard fork via a series of blog posts, bypassing all developer communication channels altogether and asking for personal, private emails from anyone interested in discussing the proposal further.
On May 5 (1 day after Gavin submitted his first blog post), Mike Hearn published The capacity cliff on his Medium page. 2 days later, he posted Crash landing. In these posts, he argued:
A common argument for letting Bitcoin blocks fill up is that the outcome won’t be so bad: just a market for fees... this is wrong. I don’t believe fees will become high and stable if Bitcoin runs out of capacity. Instead, I believe Bitcoin will crash.
...a permanent backlog would start to build up... as the backlog grows, nodes will start running out of memory and dying... as Core will accept any transaction that’s valid without any limit a node crash is eventually inevitable.
He also, in the latter article, explained that he disagreed with Satoshi's vision for how Bitcoin would mature[1][2]:
Neither me nor Gavin believe a fee market will work as a substitute for the inflation subsidy.
Gavin continued to publish the series of blog posts he had announced while Hearn made these predictions. [1][2][3][4][5][6][7]
Matt Corallo brought Gavin's proposal up on the bitcoin-dev mailing list after a few days. He wrote:
Recently there has been a flurry of posts by Gavin at http://gavinandresen.svbtle.com/ which advocate strongly for increasing the maximum block size. However, there hasnt been any discussion on this mailing list in several years as far as I can tell...
So, at the risk of starting a flamewar, I'll provide a little bait to get some responses and hope the discussion opens up into an honest comparison of the tradeoffs here. Certainly a consensus in this kind of technical community should be a basic requirement for any serious commitment to blocksize increase.
Personally, I'm rather strongly against any commitment to a block size increase in the near future. Long-term incentive compatibility requires that there be some fee pressure, and that blocks be relatively consistently full or very nearly full. What we see today are transactions enjoying next-block confirmations with nearly zero pressure to include any fee at all (though many do because it makes wallet code simpler).
This allows the well-funded Bitcoin ecosystem to continue building systems which rely on transactions moving quickly into blocks while pretending these systems scale. Thus, instead of working on technologies which bring Bitcoin's trustlessness to systems which scale beyond a blockchain's necessarily slow and (compared to updating numbers in a database) expensive settlement, the ecosystem as a whole continues to focus on building centralized platforms and advocate for changes to Bitcoin which allow them to maintain the status quo
Shortly thereafter, Corallo explained further:
The point of the hard block size limit is exactly because giving miners free rule to do anything they like with their blocks would allow them to do any number of crazy attacks. The incentives for miners to pick block sizes are no where near compatible with what allows the network to continue to run in a decentralized manner.
Tier Nolan considered possible extensions and modifications that might improve Gavin's proposal and argued that soft caps could be used to mitigate against the dangers of a blocksize increase. Tom Harding voiced support for Gavin's proposal
Peter Todd mentioned that a limited blocksize provides the benefit of protecting against the "perverse incentives" behind potential block withholding attacks.
Slush didn't have a strong opinion one way or the other, and neither did Eric Lombrozo, though Eric was interested in developing hard-fork best practices and wanted to:
explore all the complexities involved with deployment of hard forks. Let’s not just do a one-off ad-hoc thing.
Matt Whitlock voiced his opinion:
I'm not so much opposed to a block size increase as I am opposed to a hard fork... I strongly fear that the hard fork itself will become an excuse to change other aspects of the system in ways that will have unintended and possibly disastrous consequences.
Bryan Bishop strongly opposed Gavin's proposal, and offered a philosophical perspective on the matter:
there has been significant public discussion... about why increasing the max block size is kicking the can down the road while possibly compromising blockchain security. There were many excellent objections that were raised that, sadly, I see are not referenced at all in the recent media blitz. Frankly I can't help but feel that if contributions, like those from #bitcoin-wizards, have been ignored in lieu of technical analysis, and the absence of discussion on this mailing list, that I feel perhaps there are other subtle and extremely important technical details that are completely absent from this--and other-- proposals.
Secured decentralization is the most important and most interesting property of bitcoin. Everything else is rather trivial and could be achieved millions of times more efficiently with conventional technology. Our technical work should be informed by the technical nature of the system we have constructed.
There's no doubt in my mind that bitcoin will always see the most extreme campaigns and the most extreme misunderstandings... for development purposes we must hold ourselves to extremely high standards before proposing changes, especially to the public, that have the potential to be unsafe and economically unsafe.
There are many potential technical solutions for aggregating millions (trillions?) of transactions into tiny bundles. As a small proof-of-concept, imagine two parties sending transactions back and forth 100 million times. Instead of recording every transaction, you could record the start state and the end state, and end up with two transactions or less. That's a 100 million fold, without modifying max block size and without potentially compromising secured decentralization.
The MIT group should listen up and get to work figuring out how to measure decentralization and its security.. Getting this measurement right would be really beneficial because we would have a more academic and technical understanding to work with.
Gregory Maxwell echoed and extended that perspective:
When Bitcoin is changed fundamentally, via a hard fork, to have different properties, the change can create winners or losers...
There are non-trivial number of people who hold extremes on any of these general belief patterns; Even among the core developers there is not a consensus on Bitcoin's optimal role in society and the commercial marketplace.
there is a at least a two fold concern on this particular ("Long term Mining incentives") front:
One is that the long-held argument is that security of the Bitcoin system in the long term depends on fee income funding autonomous, anonymous, decentralized miners profitably applying enough hash-power to make reorganizations infeasible.
For fees to achieve this purpose, there seemingly must be an effective scarcity of capacity.
The second is that when subsidy has fallen well below fees, the incentive to move the blockchain forward goes away. An optimal rational miner would be best off forking off the current best block in order to capture its fees, rather than moving the blockchain forward...
tools like the Lightning network proposal could well allow us to hit a greater spectrum of demands at once--including secure zero-confirmation (something that larger blocksizes reduce if anything), which is important for many applications. With the right technology I believe we can have our cake and eat it too, but there needs to be a reason to build it; the security and decentralization level of Bitcoin imposes a hard upper limit on anything that can be based on it.
Another key point here is that the small bumps in blocksize which wouldn't clearly knock the system into a largely centralized mode--small constants--are small enough that they don't quantitatively change the operation of the system; they don't open up new applications that aren't possible today
the procedure I'd prefer would be something like this: if there is a standing backlog, we-the-community of users look to indicators to gauge if the network is losing decentralization and then double the hard limit with proper controls to allow smooth adjustment without fees going to zero (see the past proposals for automatic block size controls that let miners increase up to a hard maximum over the median if they mine at quadratically harder difficulty), and we don't increase if it appears it would be at a substantial increase in centralization risk. Hardfork changes should only be made if they're almost completely uncontroversial--where virtually everyone can look at the available data and say "yea, that isn't undermining my property rights or future use of Bitcoin; it's no big deal". Unfortunately, every indicator I can think of except fee totals has been going in the wrong direction almost monotonically along with the blockchain size increase since 2012 when we started hitting full blocks and responded by increasing the default soft target. This is frustrating
many people--myself included--have been working feverishly hard behind the scenes on Bitcoin Core to increase the scalability. This work isn't small-potatoes boring software engineering stuff; I mean even my personal contributions include things like inventing a wholly new generic algebraic optimization applicable to all EC signature schemes that increases performance by 4%, and that is before getting into the R&D stuff that hasn't really borne fruit yet, like fraud proofs. Today Bitcoin Core is easily >100 times faster to synchronize and relay than when I first got involved on the same hardware, but these improvements have been swallowed by the growth. The ironic thing is that our frantic efforts to keep ahead and not lose decentralization have both not been enough (by the best measures, full node usage is the lowest its been since 2011 even though the user base is huge now) and yet also so much that people could seriously talk about increasing the block size to something gigantic like 20MB. This sounds less reasonable when you realize that even at 1MB we'd likely have a smoking hole in the ground if not for existing enormous efforts to make scaling not come at a loss of decentralization.
Peter Todd also summarized some academic findings on the subject:
In short, without either a fixed blocksize or fixed fee per transaction Bitcoin will will not survive as there is no viable way to pay for PoW security. The latter option - fixed fee per transaction - is non-trivial to implement in a way that's actually meaningful - it's easy to give miners "kickbacks" - leaving us with a fixed blocksize.
Even a relatively small increase to 20MB will greatly reduce the number of people who can participate fully in Bitcoin, creating an environment where the next increase requires the consent of an even smaller portion of the Bitcoin ecosystem. Where does that stop? What's the proposed mechanism that'll create an incentive and social consensus to not just 'kick the can down the road'(3) and further centralize but actually scale up Bitcoin the hard way?
Some developers (e.g. Aaron Voisine) voiced support for Gavin's proposal which repeated Mike Hearn's "crash landing" arguments.
Pieter Wuille said:
I am - in general - in favor of increasing the size blocks...
Controversial hard forks. I hope the mailing list here today already proves it is a controversial issue. Independent of personal opinions pro or against, I don't think we can do a hard fork that is controversial in nature. Either the result is effectively a fork, and pre-existing coins can be spent once on both sides (effectively failing Bitcoin's primary purpose), or the result is one side forced to upgrade to something they dislike - effectively giving a power to developers they should never have. Quoting someone: "I did not sign up to be part of a central banker's committee".
The reason for increasing is "need". If "we need more space in blocks" is the reason to do an upgrade, it won't stop after 20 MB. There is nothing fundamental possible with 20 MB blocks that isn't with 1 MB blocks.
Misrepresentation of the trade-offs. You can argue all you want that none of the effects of larger blocks are particularly damaging, so everything is fine. They will damage something (see below for details), and we should analyze these effects, and be honest about them, and present them as a trade-off made we choose to make to scale the system better. If you just ask people if they want more transactions, of course you'll hear yes. If you ask people if they want to pay less taxes, I'm sure the vast majority will agree as well.
Miner centralization. There is currently, as far as I know, no technology that can relay and validate 20 MB blocks across the planet, in a manner fast enough to avoid very significant costs to mining. There is work in progress on this (including Gavin's IBLT-based relay, or Greg's block network coding), but I don't think we should be basing the future of the economics of the system on undemonstrated ideas. Without those (or even with), the result may be that miners self-limit the size of their blocks to propagate faster, but if this happens, larger, better-connected, and more centrally-located groups of miners gain a competitive advantage by being able to produce larger blocks. I would like to point out that there is nothing evil about this - a simple feedback to determine an optimal block size for an individual miner will result in larger blocks for better connected hash power. If we do not want miners to have this ability, "we" (as in: those using full nodes) should demand limitations that prevent it. One such limitation is a block size limit (whatever it is).
Ability to use a full node.
Skewed incentives for improvements... without actual pressure to work on these, I doubt much will change. Increasing the size of blocks now will simply make it cheap enough to continue business as usual for a while - while forcing a massive cost increase (and not just a monetary one) on the entire ecosystem.
Fees and long-term incentives.
I don't think 1 MB is optimal. Block size is a compromise between scalability of transactions and verifiability of the system. A system with 10 transactions per day that is verifiable by a pocket calculator is not useful, as it would only serve a few large bank's settlements. A system which can deal with every coffee bought on the planet, but requires a Google-scale data center to verify is also not useful, as it would be trivially out-competed by a VISA-like design. The usefulness needs in a balance, and there is no optimal choice for everyone. We can choose where that balance lies, but we must accept that this is done as a trade-off, and that that trade-off will have costs such as hardware costs, decreasing anonymity, less independence, smaller target audience for people able to fully validate, ...
Choose wisely.
Mike Hearn responded:
this list is not a good place for making progress or reaching decisions.
if Bitcoin continues on its current growth trends it will run out of capacity, almost certainly by some time next year. What we need to see right now is leadership and a plan, that fits in the available time window.
I no longer believe this community can reach consensus on anything protocol related.
When the money supply eventually dwindles I doubt it will be fee pressure that funds mining
What I don't see from you yet is a specific and credible plan that fits within the next 12 months and which allows Bitcoin to keep growing.
Peter Todd then pointed out that, contrary to Mike's claims, developer consensus had been achieved within Core plenty of times recently. Btc-drak asked Mike to "explain where the 12 months timeframe comes from?"
Jorge Timón wrote an incredibly prescient reply to Mike:
We've successfully reached consensus for several softfork proposals already. I agree with others that hardfork need to be uncontroversial and there should be consensus about them. If you have other ideas for the criteria for hardfork deployment all I'm ears. I just hope that by "What we need to see right now is leadership" you don't mean something like "when Gaving and Mike agree it's enough to deploy a hardfork" when you go from vague to concrete.
Oh, so your answer to "bitcoin will eventually need to live on fees and we would like to know more about how it will look like then" it's "no bitcoin long term it's broken long term but that's far away in the future so let's just worry about the present". I agree that it's hard to predict that future, but having some competition for block space would actually help us get more data on a similar situation to be able to predict that future better. What you want to avoid at all cost (the block size actually being used), I see as the best opportunity we have to look into the future.
this is my plan: we wait 12 months... and start having full blocks and people having to wait 2 blocks for their transactions to be confirmed some times. That would be the beginning of a true "fee market", something that Gavin used to say was his #1 priority not so long ago (which seems contradictory with his current efforts to avoid that from happening). Having a true fee market seems clearly an advantage. What are supposedly disastrous negative parts of this plan that make an alternative plan (ie: increasing the block size) so necessary and obvious. I think the advocates of the size increase are failing to explain the disadvantages of maintaining the current size. It feels like the explanation are missing because it should be somehow obvious how the sky will burn if we don't increase the block size soon. But, well, it is not obvious to me, so please elaborate on why having a fee market (instead of just an price estimator for a market that doesn't even really exist) would be a disaster.
Some suspected Gavin/Mike were trying to rush the hard fork for personal reasons.
Mike Hearn's response was to demand a "leader" who could unilaterally steer the Bitcoin project and make decisions unchecked:
No. What I meant is that someone (theoretically Wladimir) needs to make a clear decision. If that decision is "Bitcoin Core will wait and watch the fireworks when blocks get full", that would be showing leadership
I will write more on the topic of what will happen if we hit the block size limit... I don't believe we will get any useful data out of such an event. I've seen distributed systems run out of capacity before. What will happen instead is technological failure followed by rapid user abandonment...
we need to hear something like that from Wladimir, or whoever has the final say around here.
Jorge Timón responded:
it is true that "universally uncontroversial" (which is what I think the requirement should be for hard forks) is a vague qualifier that's not formally defined anywhere. I guess we should only consider rational arguments. You cannot just nack something without further explanation. If his explanation was "I will change my mind after we increase block size", I guess the community should say "then we will just ignore your nack because it makes no sense". In the same way, when people use fallacies (purposely or not) we must expose that and say "this fallacy doesn't count as an argument". But yeah, it would probably be good to define better what constitutes a "sensible objection" or something. That doesn't seem simple though.
it seems that some people would like to see that happening before the subsidies are low (not necessarily null), while other people are fine waiting for that but don't want to ever be close to the scale limits anytime soon. I would also like to know for how long we need to prioritize short term adoption in this way. As others have said, if the answer is "forever, adoption is always the most important thing" then we will end up with an improved version of Visa. But yeah, this is progress, I'll wait for your more detailed description of the tragedies that will follow hitting the block limits, assuming for now that it will happen in 12 months. My previous answer to the nervous "we will hit the block limits in 12 months if we don't do anything" was "not sure about 12 months, but whatever, great, I'm waiting for that to observe how fees get affected". But it should have been a question "what's wrong with hitting the block limits in 12 months?"
Mike Hearn again asserted the need for a leader:
There must be a single decision maker for any given codebase.
Bryan Bishop attempted to explain why this did not make sense with git architecture.
Finally, Gavin announced his intent to merge the patch into Bitcoin XT to bypass the peer review he had received on the bitcoin-dev mailing list.
submitted by sound8bits to sound8bits [link] [comments]

Full English Transcript of Gavin's AMA on 8BTC, April 21st. (Part 1)

Part 2
Part 3
Raw transcript on Google Docs (English+Chinese): https://docs.google.com/document/d/1p3DWMfeGHBL6pk4Hu0efgQWGsUAdFNK6zLHubn5chJo/edit?usp=sharing
Translators/Organizers: emusher, kcbitcoin, nextblast, pangcong, Red Li, WangXiaoMeng. (Ranked in alphabetical order)
1.crypto888
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.
2. Ma_Ya
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.
3. BiTeCui
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).
4. SanPangHenBang
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.
5.SaTuoXi
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.
6. pangcong
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.
7. HeiYanZhu
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.
8.jb9802
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.
9. btcc123
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.
10.KuHaiBian
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.
11. ChaLi
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.
12. bluestar
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.
13. satoshi
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.
14. Pussinboots
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.
16. tan90d
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:
  1. I'm on board with classic
  2. I support the vision to make bitcoin a powerful currency that could compete with Visa
  3. I support segwit, so I'll endorse whichever version of bitcoin implementation that upgrades to segwit, regardless of block size.
  4. 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.
  5. 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.
  6. 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.
17. Alfred
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.
submitted by kcbitcoin to btc [link] [comments]

Subreddit Stats: Bitcoin posts from 2018-10-09 to 2018-10-16 19:41 PDT

Period: 7.10 days
Submissions Comments
Total 765 10226
Rate (per day) 107.80 1494.28
Unique Redditors 596 3440
Combined Score 31658 33963

Top Submitters' Top Submissions

  1. 4526 points, 1 submission: Alexsayzz
    1. Anti-crypto propaganda... promoted by American Express (4526 points, 513 comments)
  2. 2391 points, 2 submissions: MoonMan_666
    1. Someone just paid $0.10 to move $194M (29,999 BTC). Think about how powerful that is for a second. (2369 points, 380 comments)
    2. Dev sends Bitcoin without using the web or the power grid (22 points, 4 comments)
  3. 2077 points, 1 submission: _Logicrypto
    1. When your boss thanks you for staying late at work but you were just watching the Bitcoin price and lost track of time (2077 points, 69 comments)
  4. 1496 points, 1 submission: bitbug42
    1. ⚡Lightning Network at the Senate - Counterargument to Roubini's speech that Bitcoin can never scale to serve the planet (1496 points, 186 comments)
  5. 1417 points, 1 submission: opencoins
    1. Why sell and pay capital gains, why not wait for mass adoption? That's my motto. (1417 points, 244 comments)
  6. 1174 points, 1 submission: awertheim
    1. Took a while but finally part of the picture club (had to wait on the web browser update!) (1174 points, 127 comments)
  7. 853 points, 1 submission: Hodl_it
    1. Feeling good? (853 points, 215 comments)
  8. 833 points, 1 submission: cointastical
    1. Bitcoin ATM operator gets the $62,500 that police confiscated back (833 points, 110 comments)
  9. 802 points, 2 submissions: JandyJammer
    1. Congratulations US senators for understanding crypto better than this guy (748 points, 125 comments)
    2. How is Bitmex the biggest exchange... total joke. I hope their competitors crush them. (54 points, 49 comments)
  10. 704 points, 1 submission: lesbiansareoverrated
    1. ...in case you missed the laura shill burn today (704 points, 100 comments)
  11. 512 points, 5 submissions: castorfromtheva
    1. Mycelium wallet will FINALLY get segwit! "This month" as stated by Mycelium developers on 9 October 2018. Glad to hear! I am excited. (312 points, 136 comments)
    2. Just saw it on their website: Ledger Nano S 20% off, directly from manufacturer! For six days, starting today. Just in case you consider getting a hardware wallet. (146 points, 84 comments)
    3. Newsflash: Bitfinex Unveils ‘Distributed Banking Solution,’ Resumes Fiat Deposits (44 points, 8 comments)
    4. Binance Uganda Launch 80% Ready As Users Can Now Sign Up: Deposits & Trading Coming Soon (8 points, 1 comment)
    5. Article: "Cryptos at a turning point", trustnodes.com (2 points, 0 comments)
  12. 510 points, 4 submissions: eddieweng
    1. Someone moved 12,220 BTC ($82M) in block 545,877 (393 points, 180 comments)
    2. Someone moved 22,200 BTC ($139M) in block 545,243 (90 points, 38 comments)
    3. CoinMarketBull – CoinMarketCap, but with a different metric (26 points, 4 comments)
    4. holdernews - trending stories on bitcointalk (1 point, 0 comments)
  13. 387 points, 1 submission: StoneHammers
    1. We are three months away from Bitcoins 10 year anniversary. (387 points, 39 comments)
  14. 366 points, 3 submissions: TrackCoinMarket-com
    1. Citizens of Venezuela have turned to Bitcoin and gold farming in online games to survive the country’s economic collapse. (365 points, 60 comments)
    2. Zambian Central Bank Declares Bitcoin Is Not Legal Tender (1 point, 7 comments)
    3. Bitcoin is Maturing, Crypto Growth Surprisingly Positive Reveals Study (0 points, 3 comments)
  15. 358 points, 1 submission: musicfan39
    1. Bitcoin all-time price graph (Aug 2010 – Oct 2018) (358 points, 84 comments)
  16. 311 points, 5 submissions: TheGreatMuffin
    1. Bitfinex' statement on fiat deposits/withdrawals (tldr: fiat and crypto withdrawals working, fiat deposits temporarily paused) (103 points, 52 comments)
    2. Bitfinex suspends all fiat deposits, “expects the situation to normalize within a week” (78 points, 62 comments)
    3. Fidelity gives a nod to OG cypherpunks (mentioning Adam Back, Nick Szabo, David Chaum) and bitcoin's precursors in their newest blog post (78 points, 0 comments)
    4. full video of the US Senate hearing on cryptocurrency: with P. Van Valkenburgh and N. Roubini as witnesses (starts at minute 16) (31 points, 5 comments)
    5. Interview with one of the creators of the Samourai wallet (21 points, 1 comment)
  17. 305 points, 1 submission: 6maud
    1. Jamie Dimon: Bitcoin is a scam. Also Jamie Dimon: Let's file 20 blockchain patents so we don't miss out on this blockchain thing. facepalm (305 points, 93 comments)
  18. 274 points, 2 submissions: undertheradar48
    1. $6.9 trillion of assets just got access to the world of crypto! (169 points, 24 comments)
    2. 1.65 Million people are attending over 5,000 Bitcoin meetups around the world. Organic interest/curiosity is real! (105 points, 41 comments)
  19. 265 points, 1 submission: NoGooderr
    1. Shorters, are you okay? (265 points, 123 comments)
  20. 253 points, 5 submissions: _smudger_
    1. Bakkt CEO: We're About To See A Cryptocurrency Revolution (130 points, 29 comments)
    2. Our team, launch and advocacy – Bakkt Blog – Medium (104 points, 33 comments)
    3. Coinbase's Adam White is joining Bakkt as its COO - The Block (16 points, 1 comment)
    4. The Bright Side of the 2018 Bitcoin Bear Market – Wes Carlson – Medium (2 points, 0 comments)
    5. Analysis: ErisX & Bakkt Are All in on the Battle for Institutional Cash (1 point, 0 comments)
  21. 247 points, 1 submission: Fly115
    1. It would be impossible for every Fidelity brokerage customer to own even one Bitcoin. This is why Bitcoins are worth thousands of dollars, while a dollar is only worth one dollar (and only until next year when when it's worth 97 cents). - Erik Voorhees (247 points, 129 comments)
  22. 237 points, 1 submission: manfromnantucket1984
    1. Bear markets are for building! 🐻⚡ While the price is doing what it does, we continue to build the #LightningNetwork at the #LightningHackdayNYC in New York on October 27th/28th 2018. Speakers like Christian Decker, Matt Corallo and Peter Todd will take you down the rabbit hole. (237 points, 15 comments)
  23. 232 points, 1 submission: TheMidnightMatinee
    1. Guys lets rally and show your support for an BTC ETF! Here's why! (232 points, 63 comments)
  24. 231 points, 2 submissions: installeris
    1. Fidelity just made it easier for hedge funds and other pros to invest in cryptocurrencies (169 points, 36 comments)
    2. Nouriel Roubini has always been talking sh*t about Bitcoin. And he's always wrong. (62 points, 29 comments)
  25. 226 points, 1 submission: lewtr
    1. An easter egg in the Bitcoin genesis block code (226 points, 40 comments)
  26. 218 points, 1 submission: Unusual_Mountain
    1. Bitcoin as a safe haven from monetary policy can help keep governments and banks honest. It doesn't have to replace them. (218 points, 85 comments)
  27. 214 points, 1 submission: Mobilenewsflash
    1. Roubini (214 points, 50 comments)
  28. 212 points, 1 submission: CardCollector1
    1. Getting Started with BTCPay Server - Free and Open Source Bitcoin and Lightning Network payment processor (212 points, 75 comments)
  29. 201 points, 1 submission: yonstonston
    1. Sorry guys, i bought BTC yesterday... (201 points, 72 comments)
  30. 161 points, 2 submissions: linzex
    1. A Bitcoin Lesson From A Yogi Master (93 points, 6 comments)
    2. ChangeNow Exchange Accused of $70,000 Theft (68 points, 8 comments)
  31. 159 points, 3 submissions: zappadoing
    1. greetings from holidays - I thought I won't have to read anything about bitcoin this time... (130 points, 12 comments)
    2. Telegram down! Lots of Bitcoin-Groups not accessible. We need something decentralized. (19 points, 26 comments)
    3. Colleges Are Baffled by Bitcoin Donations (10 points, 0 comments)
  32. 159 points, 1 submission: Crevative
    1. Zimbabwe spirals into economic chaos as fears of another round of hyperinflation begin to spark - another fiat currency fails! (159 points, 20 comments)
  33. 147 points, 1 submission: lexihayes99
    1. Just wanted to remind people of a simpler time :) (147 points, 196 comments)
  34. 146 points, 1 submission: Rare_Ad
    1. Bitcoin was a tool that was born of the economic crisis some 10 years ago, does that mean another big recession or banking collapse could catapult it forward? (146 points, 87 comments)
  35. 146 points, 1 submission: vmrey
    1. Buda, the largest crypto exchange by volume in Chile, is one of the first to incorporate Lightning network. (146 points, 14 comments)
  36. 145 points, 1 submission: wwwdata
    1. I own crypto but not Bitcoin. (145 points, 243 comments)
  37. 141 points, 9 submissions: expertbit
    1. This E-Bike Accepts Payments With Bitcoin's Lightning Network (51 points, 3 comments)
    2. Bitcoin [BTC] transfers will become a lot faster with Liquid Network, says Jimmy Song (37 points, 58 comments)
    3. Top Universities Are Now Investing in Cryptocurrency Funds (18 points, 0 comments)
    4. Indian Exchange Unocoin Could Launch Crypto ATMs (17 points, 0 comments)
    5. Bitcoin Price Stability -- A Bullish Or Bearish Sign? (15 points, 1 comment)
    6. Don’t Underestimate China’s Power In Bitcoin (2 points, 3 comments)
    7. Bitcoin Price Analysis: Bulls Defend Yearly Support Amidst Wall Street Slump (1 point, 0 comments)
    8. Bitcoin Network Comes To A Standstill In China (0 points, 2 comments)
    9. Bitcoin Price Jumps by $600 to Reach One-Month High Above $6.9k (0 points, 0 comments)
  38. 137 points, 1 submission: diditmakesound
    1. Everyone still buying right now (137 points, 30 comments)
  39. 135 points, 1 submission: gattacibus
    1. POLONIEX suspends Bitcoin withdrawals (135 points, 86 comments)
  40. 129 points, 3 submissions: nopara73
    1. Wasabi Wallet added OSX support. Please consider testing it. (55 points, 25 comments)
    2. Scoring Bitcoin Wallets (38 points, 25 comments)
    3. A Technical Overview of Wasabi Wallet, Future Ideas, Plans and Strategy (36 points, 1 comment)
  41. 123 points, 1 submission: Big_Bluefin
    1. Live from Fremont Street in Las Vegas (123 points, 20 comments)
  42. 121 points, 1 submission: agustinf
    1. Latin American Exchange Buda.com adds Lightning Network payments for all. (121 points, 17 comments)
  43. 118 points, 2 submissions: TheCrunk1
    1. Fidelity launches new company for trading, storing cryptocurrencies (98 points, 26 comments)
    2. Binance launches fiat-to-crypto exchange in Uganda (20 points, 7 comments)
  44. 112 points, 1 submission: Thinkmoreaboutit
    1. "Over the weekend I sent a bitcoin transaction to a relay 12.6km away with no cell network or internet connection. Here's a tweetstorm about how I used @gotenna and @SamouraiWallet to do it" [email protected] (112 points, 20 comments)
  45. 111 points, 1 submission: Jackieknows
    1. When it comes to your coins, keep it quiet. – Trezor Blog (111 points, 10 comments)
  46. 110 points, 1 submission: 100ravp
    1. Someone solved the 310.00 BTC challenge (110 points, 87 comments)
  47. 110 points, 1 submission: loulan
    1. There was an attempt (110 points, 78 comments)
  48. 106 points, 1 submission: king-only
    1. Breez, a Lightning Network mobile client, is now fully open sourced (106 points, 19 comments)
  49. 101 points, 2 submissions: HodlingToTheMoon
    1. Websites using Joomla (second most popular platform after Wordpress), can now be enabled with Bitcoin payments - In less than 5 min! (98 points, 5 comments)
    2. Got business on your mind? Here are 7 easy and genuine ideas to start a Bitcoin-centric e-commerce store! (3 points, 0 comments)
  50. 98 points, 1 submission: ubunt2
    1. Fidelity Starts Crypto Unit to Serve Wall Street Customers (98 points, 4 comments)
  51. 97 points, 1 submission: CosmicHemorroid
    1. Lightning Powered E-bike #Reckless (97 points, 22 comments)
  52. 96 points, 3 submissions: DesignerAccount
    1. Bitcoin is all grown up! (83 points, 6 comments)
    2. [Bitcoin OpSec - Keep your coins safe] Detailed breakdown of sophisticated scam (12 points, 6 comments)
    3. Infographic - How do UTXOs work? (1 point, 0 comments)
  53. 96 points, 1 submission: bowlingfries
    1. Bitcoin kiosk in Portland OR weed dispensary (96 points, 21 comments)
  54. 94 points, 1 submission: nassimmontreal
    1. #roubinilovescrypto (94 points, 37 comments)
  55. 92 points, 2 submissions: ella11price
    1. Selling goods and items for Bitcoin should be easy. I built a marketplace similar to eBay so people can sell anything for crypto. This video explains it. (91 points, 63 comments)
    2. The best ways to earn bitcoin and cryptocurrency. Includes how to spot a scam (1 point, 0 comments)
  56. 91 points, 1 submission: ytcoinartist
    1. The Golden Pineapple, a 3D combination puzzle for all ages and free to play. Be the first to solve the final level and win 1 BTC, courtesy of The Pineapple Fund. http://pineapplearcade.net/arcade-game/pineapple (91 points, 25 comments)
  57. 89 points, 1 submission: Rachsuchtig
    1. An BTC ATM at Austria/Salzburg Shopping Arena, totally surprised to see (89 points, 11 comments)
  58. 87 points, 2 submissions: Ishan1121
    1. Bitcoin proves once again its the best way to transfer money! $194 million transferred for 10 cents. (87 points, 18 comments)
    2. Discussion: So Bitcoin rises as fake news on Binance delisting Tether (USDT) goes viral...removing Tether completley will affect the market positively? THoughts? (0 points, 6 comments)
  59. 87 points, 1 submission: Blixx87
    1. I finally figured it out! We have been forming a Dorito Pattern and it’s on it’s way to the cheese dip. (87 points, 49 comments)
  60. 86 points, 8 submissions: EffigyBoy
    1. Venezuelans Play RuneScape To Make Small Profit In Bitcoin (31 points, 4 comments)
    2. CFTC Chair On Bitcoin Expansion: "We Are Seeing More Institutional Movement Into This Area" (26 points, 0 comments)
    3. The Indian Government is Considering to Launch Its Own Cryptocurrency to Avoid Citizens Using Bitcoin (13 points, 14 comments)
    4. The Congress Is Groping In The Dark To Handle Cryptocurrencies. Bitcoin has come into the mainstream. (6 points, 0 comments)
    5. After Stock Markets Plunge Cryptocurrency Whale Dumps over 22 100 BTC (5 points, 11 comments)
    6. Scientific Journal 'Chaos' Favors Bitcoin – As stable as Oil and Dollar Markets (2 points, 1 comment)
    7. The First Physical Cryptocurrency Store in The U.S. Launches on October 20 (2 points, 1 comment)
    8. Omniex and Gemini Struck A Partnership to Support Institutional Investors (1 point, 0 comments)
  61. 85 points, 2 submissions: jakesonwu
    1. Release - Eclair v0.2-beta7 - Compatible with Bitcoin Core 0.17.0 (75 points, 8 comments)
    2. Lord Keynes Would Be Proud (10 points, 1 comment)
  62. 84 points, 2 submissions: renepickhardt
    1. ECDSA is not that bad: two-party signing without Schnorr or BLS (by Stepan Snigirev) (53 points, 7 comments)
    2. Last week in Lightning Network: A weekly collection of lightning network (and related) news on Twitter (31 points, 6 comments)
  63. 83 points, 3 submissions: OldCarpet54
    1. [GIVEAWAY] Crypto Invest Summit – Wozniak, Gupta, Morehead (82 points, 1 comment)
    2. blockchain news: from SF Blockchain Week and XBlockchain (1 point, 0 comments)
    3. Buterin | SpankChain | Kambria: San Francisco Blockchain Week (0 points, 0 comments)
  64. 83 points, 1 submission: -elektro-pionir-
    1. AMA with Bitcoin engineer Jameson Lopp (83 points, 21 comments)
  65. 80 points, 3 submissions: ysangkok
    1. Bitcoin script discussion at Scaling Bitcoin: "Sporks are probabilistic soft-forks [...] where instead of [...] version bits if the blockhash has some [...] PoW below some threshold, it activates. [...] [E.g.] you have an expectation of 6 months to get your shit together. Doing it live." (28 points, 3 comments)
    2. Multi-Hop Locks for Secure, Privacy-Preserving and Interoperable Payment-Channel Networks (27 points, 8 comments)
    3. Scaling Bitcoin Kaizen - Scriptless scripts, adaptor signatures and their applications (25 points, 2 comments)
  66. 78 points, 3 submissions: mkuraja
    1. What's the difference between Lightning Network and Liquid Network? (57 points, 41 comments)
    2. Need some fresh, new FOMO in your life? Reenter, Trace Mayer. (15 points, 1 comment)
    3. This American tourist thought I'd see "Bitcoin Accepted Here" all over Tokyo, Japan but not one place found yet. (6 points, 17 comments)
  67. 77 points, 1 submission: Miladran
    1. Fidelity Says It Will Trade Bitcoin for Hedge Funds (77 points, 1 comment)
  68. 77 points, 1 submission: pandaman200
    1. Swiss Crypto Fund Obtains Country’s First Crypto Asset Management License (77 points, 4 comments)
  69. 75 points, 3 submissions: mickhick95
    1. I purchased a goTenna to broadcast my BTC transactions with TxTenna and Samourai Wallet. (44 points, 15 comments)
    2. I saw a Bitcoin ATM and I had to make a purchase. (28 points, 41 comments)
    3. 303-ish Days in the BTC Bear Market, This Sideways Motion Looks Like A Turn Around!!! (3 points, 16 comments)
  70. 75 points, 1 submission: hcarpach
    1. Venezuelan cryptocurrency miner: “we are police’s most wanted” (75 points, 21 comments)
  71. 73 points, 6 submissions: WorkCoin_Team
    1. “Bitcoin enables certain uses that are very unique. I think it offers possibilities that no other currency allows. For example the ability to spend a coin that only occurs when two separate parties agree to spend the coin; with a third party that couldn’t run away with the coin itself.” – Pieter Wui (66 points, 14 comments)
    2. Revolution of Bitcoin (5 points, 3 comments)
    3. A Funny Bitcoin Thought (2 points, 20 comments)
    4. Getting started with Bitcoin (0 points, 1 comment)
    5. Make your foundation strong (0 points, 0 comments)
    6. What are you not willing to compromise? (0 points, 6 comments)
  72. 73 points, 1 submission: ozdixon
    1. Bitcoin accepted at a absenth bar in Prague. (73 points, 11 comments)
  73. 72 points, 1 submission: Itasia
    1. What Are Atomic Swaps? Ultimate Guide (72 points, 16 comments)
  74. 71 points, 1 submission: MannyAndDrChurchShow
    1. I wonder if they would still honor this card.... (71 points, 9 comments)
  75. 68 points, 4 submissions: grittygatorr
    1. Liquid Network - the world’s first production Bitcoin sidechain has officially gone live (65 points, 100 comments)
    2. XDEX Advertises Commission-Free Bitcoin Trading in Brazil (2 points, 0 comments)
    3. Coinfloor to Cut on Staff and Reorganize Amid Volume Fluctuations in the Crypto Markets (1 point, 0 comments)
    4. Barclays Temporarily Suspends Work on Cryptocurrency Trading Project (0 points, 1 comment)
  76. 68 points, 1 submission: WouterGlorieux
    1. Introducing 'The Bitcoin Spellbook': an open-source REST API server for the back-end of (almost) any Bitcoin application. (Think of it as your own IfThisThenThat server but for Bitcoin) (68 points, 3 comments)
  77. 67 points, 1 submission: Vaultoro_official
    1. Leading up to the LightingNetwork Hackathon in NY, I thought I would post the talks we filmed at the Berlin lightningHackDay. Some amazing talks! (67 points, 1 comment)
  78. 65 points, 1 submission: Komodor123
    1. Do you speak more than one language? Then help spread Bitcoin around the world by translating Bitcoin.org! (65 points, 28 comments)
  79. 63 points, 1 submission: Sandiegosurf1
    1. Fidelity Launches Institutional Crypto Trading and Clearing. Let the institutional money flow! (63 points, 1 comment)
  80. 63 points, 1 submission: TearAnus-SoreAssRekt
    1. Buying PC Games With Bitcoin: Site Reviews (with some accepting Lightning!) (63 points, 7 comments)
  81. 62 points, 1 submission: CryptoCloaks
    1. We finally got our RaspiBlitz case to a level we love! Time for load testing to check thermals, final mods are almost done! (62 points, 10 comments)
  82. 61 points, 1 submission: sagiher
    1. #Liberte#CaribbeanBitcoin#ShoutOutToAllBitcoinDeveloperOutThere (61 points, 9 comments)

Top Commenters

  1. PragmaticParadox (465 points, 7 comments)
  2. ikarienator (462 points, 1 comment)
  3. Hanspanzer (434 points, 106 comments)
  4. Toyake (434 points, 71 comments)
  5. uglymelt (394 points, 3 comments)
  6. UsherTechs (377 points, 1 comment)
  7. isdudu (345 points, 4 comments)
  8. TyroneTheDriver (307 points, 1 comment)
  9. Rattlesnake_Mullet (296 points, 11 comments)
  10. andycam7 (282 points, 3 comments)
  11. dmdeemer (275 points, 1 comment)
  12. BTCkoning (266 points, 114 comments)
  13. CP70 (257 points, 7 comments)
  14. ascension8438 (239 points, 7 comments)
  15. Fly115 (226 points, 9 comments)
  16. haribo_2016 (220 points, 4 comments)
  17. dsmid (214 points, 1 comment)
  18. i_gotta_say (208 points, 87 comments)
  19. TheGreatMuffin (206 points, 56 comments)
  20. ebaley (198 points, 34 comments)
  21. bitsteiner (185 points, 86 comments)
  22. Redditridder (181 points, 5 comments)
  23. KupKhunKrap (173 points, 36 comments)
  24. 45sbvad (169 points, 3 comments)
  25. c3corvette (165 points, 2 comments)
  26. killerstorm (163 points, 8 comments)
  27. evilgrinz (158 points, 48 comments)
  28. chronic_nervosa (140 points, 1 comment)
  29. bigdaddysdick (136 points, 7 comments)
  30. castorfromtheva (129 points, 27 comments)
  31. Touchmyhandle (125 points, 12 comments)
  32. Euphoricsoul (122 points, 1 comment)
  33. WaterMac27 (122 points, 1 comment)
  34. DSXIII (118 points, 1 comment)
  35. RIMS_REAL_BIG (117 points, 24 comments)
  36. cryptogrip (112 points, 39 comments)
  37. WalterRyan (108 points, 10 comments)
  38. sudophant (107 points, 5 comments)
  39. NotSeeTroll (104 points, 37 comments)
  40. deadleg22 (104 points, 10 comments)
  41. shared_makes_it_real (103 points, 26 comments)
  42. alexiglesias007 (103 points, 7 comments)
  43. Buttoshi (102 points, 68 comments)
  44. flunderbossanova (102 points, 59 comments)
  45. lexihayes99 (101 points, 28 comments)
  46. mabezard (101 points, 2 comments)
  47. peniswithahoodie (98 points, 1 comment)
  48. beloboi (96 points, 65 comments)
  49. vovr (89 points, 3 comments)
  50. segells4soulsmogoblo (89 points, 1 comment)
  51. damchi (87 points, 21 comments)
  52. smadgerano (81 points, 14 comments)
  53. time_wasted504 (80 points, 34 comments)
  54. joeknowswhoiam (80 points, 16 comments)
  55. diydude2 (79 points, 26 comments)
  56. sQtWLgK (79 points, 17 comments)
  57. 989x4000 (78 points, 22 comments)
  58. sreaka (78 points, 16 comments)
  59. YoungScholar89 (78 points, 6 comments)
  60. Ellipso (76 points, 2 comments)
  61. HitsABlunt (76 points, 1 comment)
  62. almkglor (75 points, 39 comments)
  63. MrRGnome (75 points, 37 comments)
  64. Daddeus65 (75 points, 28 comments)
  65. whalecheetah (75 points, 25 comments)
  66. BCash_BeTrash (75 points, 23 comments)
  67. cipher-space (75 points, 19 comments)
  68. bnuttall (72 points, 2 comments)
  69. chrisrico (71 points, 26 comments)
  70. esdraelon (71 points, 8 comments)
  71. ale1ormont (71 points, 2 comments)
  72. igadjeed (70 points, 42 comments)
  73. Holographiks (70 points, 19 comments)
  74. frankieboy07 (70 points, 2 comments)
  75. snazzycoins (69 points, 12 comments)
  76. dmar198 (69 points, 11 comments)
  77. protoman86 (69 points, 7 comments)
  78. bitbug42 (68 points, 5 comments)
  79. CardCollector1 (66 points, 16 comments)
  80. hawks5999 (66 points, 7 comments)
  81. DefiantVerse (65 points, 12 comments)
  82. psionides (65 points, 8 comments)
  83. btc-forextrader (64 points, 37 comments)
  84. UniqueNewQuark (63 points, 5 comments)
  85. imaducksfan (63 points, 1 comment)
  86. bitusher (62 points, 23 comments)
  87. homad (62 points, 13 comments)
  88. torbitonsa (62 points, 7 comments)
  89. violencequalsbad (62 points, 7 comments)
  90. wwwdata (61 points, 20 comments)
  91. LadyRosedancer (61 points, 1 comment)
  92. Nunoyabiznes (60 points, 22 comments)
  93. pg3crypto (60 points, 13 comments)
  94. XxArmadaxX (60 points, 4 comments)
  95. awertheim (59 points, 27 comments)
  96. Ploxxx69 (59 points, 1 comment)
  97. TheGlassStone (59 points, 1 comment)
  98. moodytomatoes (58 points, 39 comments)
  99. Sneakybobo (58 points, 13 comments)
  100. UniqueCandy (58 points, 8 comments)

Top Submissions

  1. Anti-crypto propaganda... promoted by American Express by Alexsayzz (4526 points, 513 comments)
  2. Someone just paid $0.10 to move $194M (29,999 BTC). Think about how powerful that is for a second. by MoonMan_666 (2369 points, 380 comments)
  3. When your boss thanks you for staying late at work but you were just watching the Bitcoin price and lost track of time by _Logicrypto (2077 points, 69 comments)
  4. ⚡Lightning Network at the Senate - Counterargument to Roubini's speech that Bitcoin can never scale to serve the planet by bitbug42 (1496 points, 186 comments)
  5. Why sell and pay capital gains, why not wait for mass adoption? That's my motto. by opencoins (1417 points, 244 comments)
  6. Took a while but finally part of the picture club (had to wait on the web browser update!) by awertheim (1174 points, 127 comments)
  7. Feeling good? by Hodl_it (853 points, 215 comments)
  8. Bitcoin ATM operator gets the $62,500 that police confiscated back by cointastical (833 points, 110 comments)
  9. Congratulations US senators for understanding crypto better than this guy by JandyJammer (748 points, 125 comments)
  10. ...in case you missed the laura shill burn today by lesbiansareoverrated (704 points, 100 comments)

Top Comments

  1. 462 points: ikarienator's comment in Feeling good?
  2. 456 points: PragmaticParadox's comment in Anti-crypto propaganda... promoted by American Express
  3. 387 points: uglymelt's comment in ⚡Lightning Network at the Senate - Counterargument to Roubini's speech that Bitcoin can never scale to serve the planet
  4. 377 points: UsherTechs's comment in When your boss thanks you for staying late at work but you were just watching the Bitcoin price and lost track of time
  5. 342 points: isdudu's comment in Anti-crypto propaganda... promoted by American Express
  6. 307 points: TyroneTheDriver's comment in Anti-crypto propaganda... promoted by American Express
  7. 276 points: andycam7's comment in Why sell and pay capital gains, why not wait for mass adoption? That's my motto.
  8. 275 points: dmdeemer's comment in Someone just paid $0.10 to move $194M (29,999 BTC). Think about how powerful that is for a second.
  9. 268 points: Rattlesnake_Mullet's comment in Someone moved 12,220 BTC ($82M) in block 545,877
  10. 244 points: CP70's comment in Anti-crypto propaganda... promoted by American Express
Generated with BBoe's Subreddit Stats
submitted by subreddit_stats to subreddit_stats [link] [comments]

Matt Corallo - Better Hashing Through BetterHash State of Digital Assets: The State of Bitcoin Fungibility Overview by Adam Back and Matt Corallo (Scaling Bitcoin Milan 2016) MCC 2019: Bitcoin Protocol Development Panel Btc - YouTube

Matt Corallo image via CoinDesk/YouTube. Related Stories. Bitcoin’s Price is Up More Than $1K Since Bakkt Futures News; These Bitcoin Users Want DAI and DeFi – Here’s How They Plan to Get It In this episode, I talk with Bitcoin Core developer, Matt Corallo. We discuss how Bitcoin works, covering topics such as the Lightning Network, fungibility and inflation. We also talk about issues important to Matt such as BetterHash and adoption. 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 cofound @Blockstream. Early Bitcoin Core developer Matt Corallo started working on Bitcoin in 2011. At that time he still attended high school and lived in Germany near Frankfurt am Main. He was a cofounder of Blockstream before he started working on open source projects for Bitcoin at Chaincode Labs in New York. We discuss many different topics, ranging from his interest in Bitcoin at the beginning, to current Square Crypto, the division of the publicly traded payment company that focuses exclusively on bitcoin, has just hired one of the world’s most prolific bitcoin developers.. The co-founder of Chaincode Labs and the co-founder of Blockstream, Matt Corallo, was the author of notable efficiency improvements, such as the implementation of rust rays, which makes it easier for users to build and

[index] [4081] [22790] [27211] [11922] [19059] [19987] [30687] [8039] [25605] [8095]

Matt Corallo - Better Hashing Through BetterHash

Soona Amhaz of Volt Capital discuss the current state of Bitcoin with Matt Corallo of Square Crypto, Nic Carter of Castle Island Ventures, and Tadge Dryja of MIT. How to Tell If You're a Bitcoin Wizard - Matt Corallo - Duration: 6:21. CoinDesk 1,434 views. 6:21. BetterHash vs NiceHash vs HoneyMiner vs CudoMiner Profitability - Duration: 7:26. Many People believe that bitcoin price is going to $10,000, or even $100,000. What happens if it doesnt? Can it still survive. Katherine Wu moderates the panel about Bitcoin Protocol Development with Eric Lombrozo (Ciphrex), Matt Corallo (Chaincode Labs), John Newberry (Chaincode Labs), and Luke Dashjr at MCC 2019 on ... Matt Corallo - Better Hashing Through BetterHash by London Bitcoin Devs. 1:33:40. The Run of the Golden Bull by Running Bull. 1:50. How The Economic Machine Works by Ray Dalio

Flag Counter