Forkology 301: The Three Tiers of Investor Control over Bitcoin
DanielKrawisz's article Who Controls Bitcoin is a must-read for anyone wanting to understand how Bitcoin is governed. This post builds on Krawisz's point - that investors hold all the cards - by describing in more detail how Bitcoin investors can exercise their control over Bitcoin through a tiered or layered structure of increasing directness and radicalness. Tier 1: Expression of Intent Investors simply make it known, in a credible way, that they support some change (say a bigger blocksize cap), meaning they intend to buy more BTC if the change is made in good time, and sell BTC if it is not. Then there are three ways the ecosystem can react: (i) Core Capitulates: The Core dev team is pressured to up the blocksize cap in Core and does so in a way that satisfies investors. (ii) Competing Implementations Arise: If Core refuses or raises the cap too slowly, other implementations like BitcoinXT spring up and miners - enticed by the additional gains through a higher BTC price - adopt it. (iii) Bitcoin Unlimited Renders the Previous Two Moot: Bitcoin Unlimited is another implementation in development that attempts to dispense with centralized blocksize planning entirely by allowing each user to set their own blocksize cap through a pulldown menu. Set the cap too low and your node might fail to track consensus as larger blocks get into the chain; set it too high and you might waste resources dealing with blocks that will end up orphaned. Users can also set a block depth after which they will accept a block higher than their set limit only if the block gets deep enough in the chain. This mechanism constitutes a kind of built in fork-tolerant logic. Instead of a preset group of developers opining over the "correct" blocksize cap or an ivory-tower scheme of centrally planned "Flexcaps," the blocksize limit is an emergent property of each individual node and miner's cost/benefit analysis and priorities for their own situation, much like the price of graphite. The concept of consensus becomes more fluid, with nodes sometimes objecting to bigger blocks by refusing to relay them, thereby assuming a risk of temporarily falling out of consensus. Somewhat like the English language, consensus on the rules is emergent rather than consensus rules being handed down from Core dev. Instead of "Concur with Core or go pound sand," Bitcoin Unlimited's consensus on blocksize is an aggregate product of each node and miner positioning themselves favorably in the market due to their own calculations of the trade-offs for their unique circumstances. The result is expected to be a soft blocksize limit that grows dynamically as market forces (orphan rates and other incentives), transaction demand, and technology levels change, in a way that maximizes investor satisfaction and therefore BTC price and miner revenue. Miners will up the size of the blocks they mine as transaction demand grows, and as long as they do so conservatively other miners and nodes (all interested in seeing the BTC price rise) will approvingly build on and propagate these blocks. Blocks over the soft limit will be discouraged by most nodes (by definition of the term "soft limit"), but if they manage to get several blocks deep into the chain most nodes will accept them. Miners a take a risk (orphan risk) in producing these slightly oversized blocks, edging forward carefully when they believe nodes will respond approvingly because investors and users are demanding it. If Bitcoin Unlimited catches on, Core and XT's centralized blocksize plans become relics. Investors announce their intent, ideally through a prediction market or futures market but cruder measures would also have an effect, and miners react (conservatively!) through adjusting blocksize cap (and chain depth at which they'll give in and accept an oversized block) through the pulldown menu to rake in those juicy profits. Nodes also have a voice in what they help propagate, with an interest to aid bigger blocks because of their stake in the BTC price as business owners, holders, etc. Tier 2: Fork Arbitrage on Exchanges This case is more radical, but it is only required if a change is too controversial for something like XT's 75% threshold to be relied upon. Here, several weeks/months before the fork is to occur, Bitcoin exchanges prepare futures contracts for, say, coins in Core and coins in XT, and let investors effectively sell their coins in Core to buy more coins in XT, or vice versa. For example if you have 10 BTC, you would of course have 10 Core bitcoins and 10 XT bitcoins after the fork if you took no action, but if you choose to participate in the arbitrage you might sell your 10 future Core bitcoins and use them to increase your future XT bitcoin count to 15 or 20 BTC. Why would it ever be only 15 BTC? This would be the case where you entered the arbitraging late and Core bitcoin futures had already fallen to half the price of XT bitcoin futures, meaning your 10 Core BTC only buys you 5 XT BTC. [For more technical details, see Meni Rosenfeld's How I learned to stop worrying and love the fork, though he doesn't address the futures contract innovation, which further streamlines the process by giving a very strong indication of the winner before the fork even happens.] In almost all conceivable cases a definitive winner emerges (and if not, no other method is going to do any better at determining the winner), and the other fork either dies or becomes a niche alt-protocol coin (not really an "altcoin," since it shares Bitcoin's ledger). The niche coin would likely only arise and persist if there truly were a key tradeoff being made, as some small block adherents argue. In any case, hodler purchasing power is completely preserved by default if they choose not to bet in the "forkbitrage" process, even in the event of a persistent split. This forkbitrage process represents a more direct expression of investor will than in Tier 1. (Also, it may be possible that this process starting up would kick off Tier 1 effects that would allow the more radical measure of forbitrage to be halted early, with the exchanges returning investors' bets.) Tier 3: Spinoff with New Hashing Algorithm This is the most radical, because it is only required in the scenario where "miners go insane" and do something ridiculous like upping the block reward or refusing to implement obvious necessary changes like blocksize cap increases, despite investor support, and where the miners would threaten to 51% attack the investors' chosen fork in the above forkbitrage process. Of course this can only be a short term threat, since the fork winning the Tier 2 forkbitrage process would soon have far more hashpower thanks to far greater market cap, but short term matters when you could be 51% attacked. Here the Bitcoin ledger is copied over to the investors' chosen protocol, so that all holders have the same number of coins (and same percentage of all outstanding coins) in the "new" coin, say a larger blocksize cap coin. The World Wide Ledger is preserved, which is all that should matter to investors, and the "old" Bitcoin is again sold off to nothing or goes niche. Hodler purchasing power is preserved, of course. This is the very purest expression of investor will. Miners can be called a kind of investor, but with some complications. Spinoffs allow investors to circumvent even the miners - a radical measure for outlandish scenarios. Tier 1 lets investors deal with attempted developer control, Tier 2 lets investors deal with controversy, and Tier 3 lets investors deal with pervasive miner irrationality. This is how investors rule the roost. Previous Forkology posts and discussions: Forkology 101 Forkology 201 (guest post by Peter__R)
cruzbit: A simple decentralized peer-to-peer ledger implementation. Currently ~100 GH/s nethash.
Hello everyone, I'm a long time bitcoin fan/user. For years I thought about rewriting bitcoin to be as simple as possible. There is a fair amount of complexity to the canonical bitcoin implementation that didn't strike me as strictly necessary. It makes understanding and working with the protocol difficult. I had some time recently, so I finally decided to implement what I thought was the simplest version of bitcoin that could exist. cruzbit is what I ended up with. Project: https://github.com/cruzbit/cruzbit In addition to simplicity, I wanted everything I used to be standard. I wanted an average developer to be able to run cruzbit and immediately start working with the protocol and talking to their client. Highlights:
Newer crypto: Ed25519 and SHA3
Simplified transaction format: No inputs/outputs. No scripts.
No UTXO: Account-model, but as far as I can tell, a novel simpler approach to it. No serial per-account nonce.
No fixed block size limit: A variation of BIP 101 is implemented.
Reference implementation is in Go. Completely new code base.
Web/dev-friendly peer protocol: secure WebSockets and JSON for all protocol messages and primitives.
No premining or any of that funny business. The memo field of the coinbase transaction of the genesis block is timestamped with the bitcoin blockchain's tip block hash at the time of its creation. The client currently has built-in support for mining with Nvidia ALL GPUs (now has CUDA and OpenCL support.) The network has been up for just over a month. Any/all feedback is much appreciated. Would love to have some new miners join us. Take it easy! Third-party block explorer: https://cruzbase.com/ Third-party site with tons of links+info and binaries (but we suggest building yourself, it's easy!): https://cruzb.it/ Currently listed on the qTrade exchange: https://qtrade.io/market/CRUZ_BTC
A Beginners Guide to Bitcoin, Blockchain & Cryptocurrency
As cryptocurrency, and blockchain technology become more abundant throughout our society, it’s important to understand the inner workings of this technology, especially if you plan to use cryptocurrency as an investment vehicle. If you’re new to the crypto-sphere, learning about Bitcoin makes it much easier to understand other cryptocurrencies as many other altcoins' technologies are borrowed directly from Bitcoin. Bitcoin is one of those things that you look into only to discover you have more questions than answers, and right as you’re starting to wrap your head around the technology; you discover the fact that Bitcoin has six other variants (forks), the amount of politics at hand, or that there are over a thousand different cryptocurrencies just as complex if not even more complex than Bitcoin. We are currently in the infancy of blockchain technology and the effects of this technology will be as profound as the internet. This isn’t something that’s just going to fade away into history as you may have been led to believe. I believe this is something that will become an integral part of our society, eventually embedded within our technology. If you’re a crypto-newbie, be glad that you're relatively early to the industry. I hope this post will put you on the fast-track to understanding Bitcoin, blockchain, and how a large percentage of cryptocurrencies work.
Altcoin: Short for alternative coin. There are over 1,000 different cryptocurrencies. You’re probably most familiar with Bitcoin. Anything that isn’t Bitcoin is generally referred to as an altcoin. HODL: Misspelling of hold. Dank meme accidentally started by this dude. Hodlers are much more interested in long term gains rather than playing the risky game of trying to time the market. TO THE MOON: When a cryptocurrency’s price rapidly increases. A major price spike of over 1,000% can look like it’s blasting off to the moon. Just be sure you’re wearing your seatbelt when it comes crashing down. FUD: Fear. Uncertainty. Doubt. FOMO: Fear of missing out. Bull Run: Financial term used to describe a rising market. Bear Run: Financial term used to describe a falling market.
What Is Bitcoin?
Bitcoin (BTC) is a decentralized digital currency that uses cryptography to secure and ensure validity of transactions within the network. Hence the term crypto-currency. Decentralization is a key aspect of Bitcoin. There is no CEO of Bitcoin or central authoritative government in control of the currency. The currency is ran and operated by the people, for the people. One of the main development teams behind Bitcoin is blockstream. Bitcoin is a product of blockchain technology. Blockchain is what allows for the security and decentralization of Bitcoin. To understand Bitcoin and other cryptocurrencies, you must understand to some degree, blockchain. This can get extremely technical the further down the rabbit hole you go, and because this is technically a beginners guide, I’m going to try and simplify to the best of my ability and provide resources for further technical reading.
A Brief History
Bitcoin was created by Satoshi Nakamoto. The identity of Nakamoto is unknown. The idea of Bitcoin was first introduced in 2008 when Nakamoto released the Bitcoin white paper - Bitcoin: A Peer-to-Peer Electronic Cash System. Later, in January 2009, Nakamoto announced the Bitcoin software and the Bitcoin network officially began. I should also mention that the smallest unit of a Bitcoin is called a Satoshi. 1 BTC = 100,000,000 Satoshis. When purchasing Bitcoin, you don’t actually need to purchase an entire coin. Bitcoin is divisible, so you can purchase any amount greater than 1 Satoshi (0.00000001 BTC).
What Is Blockchain?
Blockchain is a distributed ledger, a distributed collection of accounts. What is being accounted for depends on the use-case of the blockchain itself. In the case of Bitcoin, what is being accounted for is financial transactions. The first block in a blockchain is referred to as the genesis block. A block is an aggregate of data. Blocks are also discovered through a process known as mining (more on this later). Each block is cryptographically signed by the previous block in the chain and visualizing this would look something akin to a chain of blocks, hence the term, blockchain. For more information regarding blockchain I’ve provided more resouces below:
Bitcoin mining is one solution to the double spend problem. Bitcoin mining is how transactions are placed into blocks and added onto the blockchain. This is done to ensure proof of work, where computational power is staked in order to solve what is essentially a puzzle. If you solve the puzzle correctly, you are rewarded Bitcoin in the form of transaction fees, and the predetermined block reward. The Bitcoin given during a block reward is also the only way new Bitcoin can be introduced into the economy. With a halving event occurring roughly every 4 years, it is estimated that the last Bitcoin block will be mined in the year 2,140. (See What is Block Reward below for more info). Mining is one of those aspects of Bitcoin that can get extremely technical and more complicated the further down the rabbit hole you go. An entire website could be created (and many have) dedicated solely to information regarding Bitcoin mining. The small paragraph above is meant to briefly expose you to the function of mining and the role it plays within the ecosystem. It doesn’t even scratch the surface regarding the topic.
How do you Purchase Bitcoin?
The most popular way to purchase Bitcoin through is through an online exchange where you trade fiat (your national currency) for Bitcoin. Popular exchanges include:
There’s tons of different exchanges. Just make sure you find one that supports your national currency.
Bitcoin and cryptocurrencies are EXTREMELY volatile. Swings of 30% or more within a few days is not unheard of. Understand that there is always inherent risks with any investment. Cryptocurrencies especially. Only invest what you’re willing to lose.
Transaction & Network Fees
Transacting on the Bitcoin network is not free. Every purchase or transfer of Bitcoin will cost X amount of BTC depending on how congested the network is. These fees are given to miners as apart of the block reward. Late 2017 when Bitcoin got up to $20,000USD, the average network fee was ~$50. Currently, at the time of writing this, the average network fee is $1.46. This data is available in real-time on BitInfoCharts.
In this new era of money, there is no central bank or government you can go to in need of assistance. This means the responsibility of your money falls 100% into your hands. That being said, the security regarding your cryptocurrency should be impeccable. The anonymity provided by cryptocurrencies alone makes you a valuable target to hackers and scammers. Below I’ve detailed out best practices regarding securing your cryptocurrency.
Two-Factor Authentication (2FA)
Two-factor authentication is a second way of authenticating your identity upon signing in to an account. Most cryptocurrency related software/websites will offer or require some form of 2FA. Upon creation of any crypto-related account find the Security section and enable 2FA.
The most basic form of 2FA which you are probably most familiar with. This form of authentication sends a text message to your smartphone with a special code that will allow access to your account upon entry. Note that this is not the safest form of 2FA as you may still be vulnerable to what is known as a SIM swap attack. SIM swapping is a social engineering method in which an attacker will call up your phone carrier, impersonating you, in attempt to re-activate your SIM card on his/her device. Once the attacker has access to your SIM card he/she now has access to your text messages which can then be used to access your online accounts. You can prevent this by using an authenticator such as Google Authenticator.
The use of an authenticator is the safest form of 2FA. An authenticator is installed on a seperate device and enabling it requires you input an ever changing six digit code in order to access your account. I recommend using Google Authenticator. If a website has the option to enable an authenticator, it will give you a QR code and secret key. Use Google Authenticator to scan the QR code. The secret key consists of a random string of numbers and letters. Write this down on a seperate sheet of paper and do not store it on a digital device. Once Google Authenticator has been enabled, every time you sign into your account, you will have to input a six-digit code that looks similar to this. If you happen to lose or damage the device you have Google Authenticator installed on, you will be locked out of your account UNLESS you have access to the secret key (which you should have written down).
A wallet is what you store Bitcoin and cryptocurrency on. I’ll provide resources on the different type of wallets later but I want to emphasize the use of a hardware wallet (aka cold storage). Hardware wallets are the safest way of storing cryptocurrency because it allows for your crypto to be kept offline in a physical device. After purchasing crypto via an exchange, I recommend transferring it to cold storage. The most popular hardware wallets include the Ledger Nano S, and Trezor. Hardware wallets come with a special key so that if it gets lost or damaged, you can recover your crypto. I recommend keeping your recovery key as well as any other sensitive information in a safety deposit box. I know this all may seem a bit manic, but it is important you take the necessary security precautions in order to ensure the safety & longevity of your cryptocurrency.
Technical Aspects of Bitcoin
Address: What you send Bitcoin to.
Wallet: Where you store your Bitcoin
Max Supply: 21 million
Block Time: ~10 minutes
Block Size: 1-2 MB
Block Reward: BTC reward received from mining.
What is a Bitcoin Address?
A Bitcoin address is what you send Bitcoin to. If you want to receive Bitcoin you’d give someone your Bitcoin address. Think of a Bitcoin address as an email address for money.
What is a Bitcoin Wallet?
As the title implies, a Bitcoin wallet is anything that can store Bitcoin. There are many different types of wallets including paper wallets, software wallets and hardware wallets. It is generally advised NOT to keep cryptocurrency on an exchange, as exchanges are prone to hacks (see Mt. Gox hack). My preferred method of storing cryptocurrency is using a hardware wallet such as the Ledger Nano S or Trezor. These allow you to keep your crypto offline in physical form and as a result, much more safe from hacks. Paper wallets also allow for this but have less functionality in my opinion. After I make crypto purchases, I transfer it to my Ledger Nano S and keep that in a safe at home. Hardware wallets also come with a special key so that if it gets lost or damaged, you can recover your crypto. I recommend keeping your recovery key in a safety deposit box.
What is Bitcoins Max Supply?
The max supply of Bitcoin is 21 million. The only way new Bitcoins can be introduced into the economy are through block rewards which are given after successfully mining a block (more on this later).
What is Bitcoins Block Time?
The average time in which blocks are created is called block time. For Bitcoin, the block time is ~10 minutes, meaning, 10 minutes is the minimum amount of time it will take for a Bitcoin transaction to be processed. Note that transactions on the Bitcoin network can take much longer depending on how congested the network is. Having to wait a few hours or even a few days in some instances for a transaction to clear is not unheard of. Other cryptocurrencies will have different block times. For example, Ethereum has a block time of ~15 seconds. For more information on how block time works, Prabath Siriwardena has a good block post on this subject which can be found here.
What is Bitcoins Block Size?
There is a limit to how large blocks can be. In the early days of Bitcoin, the block size was 36MB, but in 2010 this was reduced to 1 MB in order to prevent distributed denial of service attacks (DDoS), spam, and other malicious use on the blockchain. Nowadays, blocks are routinely in excess of 1MB, with the largest to date being somewhere around 2.1 MB. There is much debate amongst the community on whether or not to increase Bitcoin’s block size limit to account for ever-increasing network demand. A larger block size would allow for more transactions to be processed. The con argument to this is that decentralization would be at risk as mining would become more centralized. As a result of this debate, on August 1, 2017, Bitcoin underwent a hard-fork and Bitcoin Cash was created which has a block size limit of 8 MB. Note that these are two completely different blockchains and sending Bitcoin to a Bitcoin Cash wallet (or vice versa) will result in a failed transaction. Update: As of May 15th, 2018 Bitcoin Cash underwent another hard fork and the block size has increased to 32 MB. On the topic of Bitcoin vs Bitcoin Cash and which cryptocurrency is better, I’ll let you do your own research and make that decision for yourself. It is good to know that this is a debated topic within the community and example of the politics that manifest within the space. Now if you see community members arguing about this topic, you’ll at least have a bit of background to the issue.
What is Block Reward?
Block reward is the BTC you receive after discovering a block. Blocks are discovered through a process called mining. The only way new BTC can be added to the economy is through block rewards and the block reward is halved every 210,000 blocks (approximately every 4 years). Halving events are done to limit the supply of Bitcoin. At the inception of Bitcoin, the block reward was 50BTC. At the time of writing this, the block reward is 12.5BTC. Halving events will continue to occur until the amount of new Bitcoin introduced into the economy becomes less than 1 Satoshi. This is expected to happen around the year 2,140. All 21 million Bitcoins will have been mined. Once all Bitcoins have been mined, the block reward will only consist of transaction fees.
Any computer that connects to the Bitcoin network is called a node. Nodes that fully verify all of the rules of Bitcoin are called full nodes.
In other words, full nodes are what verify the Bitcoin blockchain and they play a crucial role in maintaining the decentralized network. Full nodes store the entirety of the blockchain and validate transactions. Anyone can participate in the Bitcoin network and run a full node. Bitcoin.org has information on how to set up a full node. Running a full node also gives you wallet capabilities and the ability to query the blockchain. For more information on Bitcoin nodes, see Andreas Antonopoulos’s Q&A on the role of nodes.
What is a Fork?
A fork is a divergence in a blockchain. Since Bitcoin is a peer-to-peer network, there’s an overall set of rules (protocol) in which participants within the network must abide by. These rules are put in place to form network consensus. Forks occur when implementations must be made to the blockchain or if there is disagreement amongst the network on how consensus should be achieved.
Soft Fork vs Hard Fork
The difference between soft and hard forks lies in compatibility. Soft forks are backwards compatible, hard forks are not. Think of soft forks as software upgrades to the blockchain, whereas hard forks are a software upgrade that warrant a completely new blockchain. During a soft fork, miners and nodes upgrade their software to support new consensus rules. Nodes that do not upgrade will still accept the new blockchain. Examples of Bitcoin soft forks include:
A hard fork can be thought of as the creation of a new blockchain that X percentage of the community decides to migrate too. During a hard fork, miners and nodes upgrade their software to support new consensus rules, Nodes that do not upgrade are invalid and cannot accept the new blockchain. Examples of Bitcoin hard forks include:
Note that these are completely different blockchains and independent from the Bitcoin blockchain. If you try to send Bitcoin to one of these blockchains, the transaction will fail.
A Case For Bitcoin in a World of Centralization
Our current financial system is centralized, which means the ledger(s) that operate within this centralized system are subjugated to control, manipulation, fraud, and many other negative aspects that come with this system. There are also pros that come with a centralized system, such as the ability to swiftly make decisions. However, at some point, the cons outweigh the pros, and change is needed. What makes Bitcoin so special as opposed to our current financial system is that Bitcoin allows for the decentralized transfer of money. Not one person owns the Bitcoin network, everybody does. Not one person controls Bitcoin, everybody does. A decentralized system in theory removes much of the baggage that comes with a centralized system. Not to say the Bitcoin network doesn’t have its problems (wink wink it does), and there’s much debate amongst the community as to how to go about solving these issues. But even tiny steps are significant steps in the world of blockchain, and I believe Bitcoin will ultimately help to democratize our financial system, whether or not you believe it is here to stay for good.
Well that was a lot of words… Anyways I hope this guide was beneficial, especially to you crypto newbies out there. You may have come into this realm not expecting there to be an abundance of information to learn about. I know I didn’t. Bitcoin is only the tip of the iceberg, but now that you have a fundamental understanding of Bitcoin, learning about other cryptocurrencies such as Litecoin, and Ethereum will come more naturally. Feel free to ask questions below! I’m sure either the community or myself would be happy to answer your questions. Thanks for reading!
dcrd: Several steps towards multipeer downloads completed: an optimization to use in-memory block index and a new 1337 chain view. Maintenance: improved test coverage, upgrading dependency management system and preparing for the upcoming Go 1.11 release. dcrwallet: A big change introducing optional privacy-preserving SPV sync mode was merged. In this mode dcrwallet does not download the full blockchain but only gets the "filters", uses them to determine which blocks it needs and fetches them from random nodes on the network. This has on-disk footprint of 300-400 MB and sync time of minutes, compared to ~3.4 GB and sync time of hours for full sync (these are rough estimates).
jy-p: the server side of SPV (in dcrd) was deployed in v1.2.0, the client side of SPV (in dcrwallet) is in our next release, v1.3.0. Still some minor bugs in SPV that are being worked out. There will be an update to add the latest features from BIP 157/158 in the next few months. SPV will be optional in v1.3.0, but it will become the default after we get a proper header commitment for it (#general)
Decrediton: besides regular bugfixes and design improvements, several components are being developed in parallel like SPV mode, Politeia integration and Trezor support. Politeia: testing started on mainnet, thanks to everyone who is participating. A lot of testing, bugfixing and polishing is happening in preparation for full mainnet launch. There are also a few missing features to be added before launch, e.g. capacity to edit a proposal and versioning for that, discussion to remain open once voting starts. Decrediton integration is moving forward, check out this video for a demo and this meta issue for the full checklist. Trezor: Decrediton integration of initial Trezor support is in progress and there is a demo. Android: app design version 2.0 completed. dcrdata: development of several chart visualizations was completed and is awaiting deployment. Specifically, voting agendas and historic charts are merged while ticket pool visualization is in testing. atomicswap: @glendc is seeking reviews of his Ethereum support pull request. Dev activity stats for July: 252 active PRs, 220 master commits, 34,754 added and 12,847 deleted lines spread across 6 repositories. Contributions came from 6-10 developers per repository. (chart)
Hashrate: the month started at 40.5 and ended at 51.6 PH/s, with a low of 33.3 and a new all time high of 68.4 PH/s. F2Pool is leading with 40-45%, followed by the new BeePool at 15-25% and coinmine.pl at 18-23%. Staking: 30-day average ticket price is 92.6 DCR (-2.1). The price started the month at 94.6 and quickly retreated to month's low of 85 until 1,860 tickets were bought within a single period (versus target 720). This pushed the pool of tickets to 41,970 (2.5% above target), which in turn caused 10 price increases in a row to the month's high of 100.4. This was the highest ticket price seen on the new ticket price algorithm which has been in effect since Jul 2017. Second half of the month there was unusually low volatility between 92 and 94 DCR per ticket. Locked DCR held between 3.75 and 3.87 million or 46.6-48.0% of supply (+0.1% from previous peak). Nodes: there are 212 public listening and 216 normal nodes per dcred.eu. Version distribution: 67% on v1.2.0 (+10%), 24% on v1.1.2 (-1%), 7% on v1.1.0 (-7%). Node count data is not perfect but we can see the steady trend of upgrading to v1.2.0. This version of dcrd is notable for serving compact filters. The increased count of such full nodes allows the developers to test SPV client mode in preparations for the upcoming v1.3.0 release.
Obelisk posted three updates in July. For the most recent daily updates join their Discord. New miner from iBeLink: DSM7T hashes Blake256 at 7 TH/s or Blake2b at 3.5 TH/s, consumes 2,100 W and costs $3,800, shipping Aug 5-10. There were also speculations about the mysterious Pangolin Whatsminer DCR with the speed of 44 TH/s at 2,200 W and the cost of $3,888, shipping November. If you know more about it please share with us in #pow-mining channel.
emiliomann: stakebrasil is one of the pools with the lowest number of missed and expired tickets. It was one of the first and has a smaller percentage than the most recent ones who haven’t had the time to do so. (...) The Brazilian pool should be the one with the more servers spread around the world: 6 to decrease the latency. This is to explain to you why the [pool fee] rate of 5% (currently around 0.06 DCR) on the reward is also one of the highest. girino: 8 voting wallets now. I just finished setting up a new one yesterday. All of them in different datacenters, 3 in europe, 3 in north america, 1 in brazil and one in asia. We also have 3 more servers, 1 for the front end, one for "stats" and one for dcrdata. (#general)
On the mining side, Luxor started a new set of pool servers inside mainland China, while zpool has enabled Decred mining. StatX announced Decred integration into their live dashboard and public chat. Decred was added to Satowallet with BTC and ETH trading pairs. Caution: do your best to understand the security model before using any wallet software.
Marina Silva is the first presidential candidate in Brazil using blockchain to keep all their electoral donations transparent and traceable. VotoLegal uses Decred technology, awesome use case! (reddit)
We continue to see institutional interest in DCR. Large block buyers love the concept of staking as a way to earn additional income and appreciate the stakeholder rights it affords them. Likening a DCR investment to an activist shareholdebondholder gives these institutions some comfort while dipping their toes into a burgeoning new asset class.
Targeted advertising reports released for June and July. As usual, reach @timhebel for full versions.
Big news in June: Facebook reversed their policy on banning crypto ads. ICO ads are still banned, but we should be OK. My team filled out the appeal today, so we should hopefully hear something within a few days. (u/timhebel on reddit)
After couple weeks Facebook finally responded to the appeal and the next step is to verify the domain name via DNS. A pack of Stakey Telegram stickers is now available. Have fun!
Meetup in Berlin, Germany hosted by BlueYard Capital. @jz_bz and @lftherios discussed open source incentivization, the value of governance and their respective projects @decredproject and @oscoin. See @issedjur's feedback here. (photos: 1, 2, 3)
O'Reilly Open Source Convention in Portland, USA. @raedah's talk was "Decentralizing decision-making on the blockchain". Read his report here and see on the photos how the Big Stakey was entertaining the public. (photos: 1, 2, 3)
oregonisaac: many open source devs at OSCON were VERY interested in Politeia and it was probably the #1 hook that resulted in lots of long conversations about what makes Decred unique from the ground up. (#politeia)
Blockchain Meetup in Faro, Portugal. Marco Peereboom gave a talk "Decred 101" and answered questions.
Meetup in Lisbon, Portugal on Aug 2. @moo31337 and @mm will be presenting on Decred with talk "Decred 101 - Governance with skin in the game". Co-hosted by The Block Cafe. Free entrance.
Meetup in Taipei, Taiwan on Aug 5. @morphymore will give a short intro on Decred.
OKEx Global Meetup Tour in Ho Chi Minh City, Vietnam on Aug 9. @joshuam will introduce Decred and on-chain governance and take part in a panel discussion.
Twitter: Ari Paul debates "There can be only one" aka "highlander argument". Reddit and Forum: how ticket pool size influences average vote time; roadmap concerns; why ticket price was volatile; ideas for using Reddit chat for dcrtrader and alternative chat systems; insette's write-up on Andrew Stone's GROUP proposal for miner-validated tokenization that is superior to current OP_RETURN-based schemes; James Liu's paper to extend atomic swaps to financial derivatives; what happens when all DCR are mined, tail emission and incentives for miners. Chats: why tickets don't have 100% chance to vote; ideas for more straightforward marketing; long-running chat about world economy and failure modes; @brandon's thoughts on tokenizing everything, ICOs, securities, sidechains and more; challenges of staking with Trezor; ideas how to use CryptoSteel wallet with Decred; why exchange can't stake your coins, how staking can increase security, why the function to export seed from wallet is bad idea and why dcrwallet doesn't ever store the seed; ticket voting math; discussion about how GitHub workflow forces to depend on modern web browser and possible alternatives; funding marketing and education in developing markets, vetting contractors based on deliverables, "Decred contractor clearance", continued in #governance. #dex channel continues to attract thinkers and host chats about influence of exchanges, regulation, HFT, lot sizes, liquidity, on-chain vs off-chain swaps, to name a few topics. #governance also keeps growing and hosting high quality conversations.
In July DCR was trading in USD 56-76 and BTC 0.0072-0.0109 range. A recovery started after a volume boost of up to $10.5 m on Fex around Jul 13, but once Bitcoin headed towards USD ~8,000 DCR declined along with most altcoins. WalletInvestor posted a prediction on dcrtrader. Decred was noticed in top 10 mineable coins on coinmarketcap.com.
One million PCs in China were infected via browser plugins to mine Decred, Siacoin and Digibyte. In a Unchained podcast episode David Vorick shared why ASICs are better than GPUs even if they tend toward mining centralization and also described Obelisk's new Launchpad service. (missed in June issue) Sia project moved to GitLab. The stated reasons are to avoid the risk of depending on centralized service, to avoid vendor lock-in, better continuous integration and testing, better access control and the general direction to support decentralized and open source projects. Luxor explained why PPS pools are better. @nic__carter published slides from his talk "An Overview of Governance in Blockchains" from Zcon0. This article arguing the importance of governance systems dates back to 2007. Bancor wallet was hacked. This reminds us about the fake feeling of decentralizaion, that custody of funds is dangerous and that smart contracts must have minimum complexity and be verifiable. Circle announced official Poloniex mobile apps for iOS and Android. On Jul 27 Circle announced delisting of 9 coins from Poloniex that led to a loss of 23-81% of their value same day. Sad reminder about how much a project can depend on a single centralized exchange. DCR supply and market cap is now correct on onchainfx.com and finally, on coinmarketcap.com. Thanks to @sumiflow, @jz and others doing the tedious work to reach out the various websites.
About This Issue
So most of you guys know my last data digging through the rBtc and rBitcoin subreddits (the BTCSRs from here on) showing nicely how nullc decided to increase use of the term 'Bitcoin's creator' in place of 'Satoshi' in recent times and thereby confirming drwasho's intuitive suspicion. Now, given the success of this investigation, I was wondering whether I could generalize this approach to dig through user histories to try to find more such interesting terms. I see this is mostly a fun exercise that might show further suspicious or even just interesting or funny things about us. So here's my method: I use the BTCSRs and the same date range (2009 - Oct 31st 2016) as above. The general method is to look at bigram (pairs of word) statistics for a certain user vs. the rest of the BTCSR data. To count bigrams, I take a comment, remove quoted text from comments, replace the characters ',;.!?' with spaces and then split the lowercased result by using the python string.split(..) method and then count pairs of adjacent such tokenized words. The analysis turns out to be somewhat sensitive to the tokenization used; I think the basic approach is fine but if someone has a great I idea on how to improve this, I am all ears. I first count bigrams of the whole BTCSR. I then take a user (from a random selection of users that just came to mind and while looking through the last submissions here on rBtc) and count the bigram frequency distribution for that user and all his comments. I then look for those bigrams that fulfil the following two criterions:
the pair appears at least a hundred times in the whole corpus
at least 10% of all occurences are due to the user's account in question
I then sort the resulting set of terms according to maximum ratio user_frequency / total_frequency (highest first) and print it (up to the first 20). For those wondering why the numbers for Greg don't exactly match his 'Bitcoin's creator' example, it should be noted that the number of terms are slightly different to my last analysis. Among other things, this is due to:
that fact that I count occurrences in comments here, not number of comments that a term appears in
my tokenization as described above might yield slightly different sets of terms as the regexeps I used in my earlier submission.
I think the results below are interesting and I can certainly see my own pet peeves reflected in this analysis, as well as some common talking points by others :-) It also nicely exposes the 'Bitcoin' creator' thing again. But decide for yourself. If you want your name added to this list, just reply and ask. So here we go: Terms of interest by nullc, term, user count, total count, fraction:
bitcoin's creator 133 200 0.67 block relay 100 350 0.29 fast block 47 183 0.26 the system's 66 270 0.24 bip 109 37 152 0.24 elements alpha 32 162 0.20 doubly so 20 102 0.20 competing systems 20 103 0.19 majority hashpower 23 120 0.19 round trip 36 189 0.19 signature validation 29 153 0.19 is untrue 44 235 0.19 lite clients 30 170 0.18 p2p protocol 38 219 0.17 a specification 27 159 0.17 security properties 16 103 0.16 the bloom 23 150 0.15 not validating 19 124 0.15 consensus changes 17 111 0.15 utxo bloat 15 100 0.15
by myself awemany:
utxo commitments 50 166 0.30 the 32mb 32 125 0.26 32mb limit 22 108 0.20 tunnel vision 20 102 0.20 on blocksize 43 261 0.16 note also 24 148 0.16 different jurisdictions 16 107 0.15 of greg 14 103 0.14 gavin's proposal 38 285 0.13 with n 14 105 0.13 per node 19 146 0.13 emphasis mine 16 123 0.13 payment hubs 17 140 0.12 block transmission 12 106 0.11 group think 16 144 0.11 blocksize cap 65 592 0.11 physical limits 11 102 0.11 crippling the 18 168 0.11 on bct 18 169 0.11 hard cap 59 554 0.11
bloom filtering 24 126 0.19
the queues 82 100 0.82 the "fee 213 315 0.68 relay nodes 243 409 0.59 "fee market" 307 580 0.53 000 | 74 144 0.51 the 21inc 56 115 0.49 total hashpower 73 161 0.45 the cartel 204 476 0.43 branch will 50 119 0.42 traffic will 42 102 0.41 overlay network 41 103 0.40 clients who 114 291 0.39 that clients 41 110 0.37 block n 42 114 0.37 speculative trading 53 154 0.34 bit shares 53 155 0.34 ditto for 43 129 0.33 the bip66 34 116 0.29 gambling game 30 104 0.29 ln payment 37 131 0.28
broadband connection 43 108 0.40 txs per 28 105 0.27 txs that 42 161 0.26 throwaway accounts 39 154 0.25 tx data 26 105 0.25 core contributors 43 179 0.24 txs to 38 164 0.23 bitcoin main 32 147 0.22 cryptocurrency market 26 139 0.19 5 percent 34 182 0.19 digital scarcity 39 214 0.18 bandwidth growth 19 106 0.18 real account 24 134 0.18 8 gb 44 247 0.18 transactional currency 35 198 0.18 on trusted 30 172 0.17 the sc 26 153 0.17 of txs 46 273 0.17 limit needs 18 108 0.17 shorter block 28 169 0.17
fake coins 12 100 0.12
claimed i 22 102 0.22 vast number 19 114 0.17 refund transaction 25 162 0.15 risk more 33 234 0.14 watching only 17 124 0.14 actual fact 14 103 0.14 in cs 13 100 0.13 and jon 13 101 0.13 blockstream core 99 797 0.12 heaps of 21 171 0.12 no-one will 15 124 0.12 no-one is 32 272 0.12 quite certain 18 157 0.11 blockchain security 16 141 0.11 i've followed 14 124 0.11 decentralised network 16 144 0.11 and though 28 257 0.11 in earnest 14 129 0.11 0 https://bitcointalk 17 162 0.10 no-one can 19 184 0.10
php topic=68655 65 136 0.48 b/c they 53 130 0.41 b/c the 37 101 0.37 b/c it 39 129 0.30 b/c of 68 225 0.30 the sc 45 153 0.29 https://bitco in/forum/threads/gold-collapsing-bitcoin-up 56 198 0.28 75% discount 18 104 0.17 profit company 25 145 0.17 the ppl 19 114 0.17 the mainchain 42 266 0.16 the gfc 20 166 0.12 on bct 19 169 0.11 ppl who 20 192 0.10 most ppl 12 116 0.10 small blockists 18 175 0.10 of ppl 17 170 0.10
cap increase 86 209 0.41 urgency to 40 120 0.33 that wright 67 359 0.19 cap increases 18 102 0.18 support both 38 234 0.16 the urgency 27 180 0.15 wright is 115 826 0.14 reasonable doubt 59 459 0.13 he supposedly 14 110 0.13 block cap 23 186 0.12 people believing 12 109 0.11 into irrelevance 11 100 0.11 to bolster 17 169 0.10
missing transactions 24 103 0.23
active developers 29 101 0.29 try localbitcoins 91 446 0.20 white list 22 112 0.20 mission of 26 142 0.18 rate limit 29 173 0.17 try electrum 24 150 0.16 $0 03 31 194 0.16 rate limited 19 124 0.15 the mission 35 243 0.14 try circle 28 203 0.14 favor a 14 105 0.13 reuse an 13 108 0.12 around $0 22 186 0.12 42 million 13 110 0.12 lite clients 20 170 0.12 fiat exchanges 16 139 0.12 don't decide 15 134 0.11 $0 04 17 160 0.11
No results found for gavinandresen, pwuille, raisethelimit, digitsu, Egon_1, ThomasZander, deadalnix, randy-lawnmole, Windowly, BeijingBitcoins, Helvetian616, BiggerBlocksPlease, 8btccom, saddit42, jessquit, KillerHurds, thestringpuller, MeTheImaginaryWizard, Leithm, steb2k, Matthew-Davey, s1ckpig, thezerg, redlightsaber.
My draft for a new /r/btc FAQ explaining the split from /r/Bitcoin to new users
If /btc is going to actually compete with /Bitcoin, it needs to be just as friendly and informative to new users, especially given its position as the “non default” or “breakaway” sub. The current /btc sticky saying "Welcome to the Wiki" doesn't even have any content in it and I feel this is a bit of a wasted opportunity to create an informative resource that new users will see by default and everyone else can link to instead of retyping things over and over about the history and difference between the subs. Here's what I've written as a starting point. I've done my best to keep it as concise and relevant as possible but in all honesty it is a complicated issue and a short but effective explanation is basically impossible. I hope the community can expand/improve on it further. Quick bit about me I got into Bitcoin in October 2013, when /Bitcoin had around 40k subscribers if I remember correctly, so by now I've actually personally experienced a large portion of Bitcoin's history - including the events preceding and since the creation of this sub. I have been an active and popular poster on /Bitcoin for almost all of that time, until the split and my subsequent banning. With the recent censorship fiasco, I'm finding I have to reiterate the same points over and over again to explain to newer users what happened with the /Bitcoin vs /btc split, questions about hard forks, what is likely to happen in the future and so on. So I put a couple of hours into writing this post to save myself the trouble in future.
There is a TL:DR; at the bottom, but it is exactly that. If you skip straight to the TL:DR; then don’t expect sympathy when you post questions that have already been covered in the lengthy and detailed main post.
New to Bitcoin?
I am totally new to Bitcoin. What is it? How does it work? Can/should I mine any? Where can I buy some? How do I get more information? All of these questions are actually really well covered in the /Bitcoin FAQ. Check it out in a new tab here. Once you've got a bit of a handle on the technology as a whole, come back here for the rest of the story.
What's the difference between /btc and /Bitcoin? What happened to create two such strongly opposed communities? Why can't I discuss /btc in /Bitcoin? Historically, the /Bitcoin subreddit was the largest and most active forum for discussing Bitcoin. As Bitcoin grew close to a cap in the number of transactions it could process, known as the 1MB block size limit, the community had differing opinions on the best way to proceed. Note that this upcoming issue was anticipated well ahead of time, with Satoshi's chosen successor to lead the project Gavin Andresen posting about it in mid 2015. Originally, there was quite a broad spread of opinions - some people favoured raising the blocksize to various extents, some people favoured implementing a variety of second layer solutions to Bitcoin, probably most people thought both could be a good idea in one form or another. This topic was unbelievably popular at the time, taking up almost every spot on the front page of /Bitcoin for weeks on end. Unfortunately, the head moderator of /Bitcoin - theymos - felt strongly enough about the issue to use his influence to manipulate the debate. His support was for the proposal of existing software (called Bitcoin Core) NOT to raise the blocksize limit past 1MB and instead rely totally on second layer solutions - especially one called Segregated Witness (or SegWit). With some incredibly convoluted logic, he decided that any different implementations of Bitcoin that could potentially raise the limit were effectively equivalent to separate cryptocurrencies like Litecoin or Ethereum and thus the block size limit or implement other scaling solutions were off-topic and ban-worthy. At the time the most popular alternative was called Bitcoin XT and was supported by experienced developers Gavin Andresen and Mike Hearn, who have since bothleft Bitcoin Core development in frustration at their marginalisation. Theymos claimed that for Bitcoin XT or any other software implementation to be relevant to /Bitcoin required "consensus", which was never well defined, despite it being seemingly impossible for everyone to agree on the merits of a new project if no one was allowed to discuss it in the first place. Anyone who didn't toe the line of his vaguely defined moderation policy was temporarily or permanently banned. There was also manipulation of the community using the following tactics - which can still be seen today:
Default thread sorting changed to "controversial" in selected threads instead of "best" like nearly every other subreddit
Comment/upvote scores hidden by default (combined with the previous point this prevented theymos and other unpopular mods like StarMaged and BashCo from ending up at the bottom of every thread they posted in)
The implementation of a custom CSS sheet that disguises long threads of [removed] comments. This was especially effective at the time as the censorship was obvious since threads were becoming wastelands of hundreds of deleted comments, similar to other Reddit throw downs like GamerGate
This created enormous uproar among users, as even many of those in favour of Bitcoin Core thought it was authoritarian to actively suppress this crucial debate. theymos would receive hundreds of downvotes whenever he posted: for example here where he gets -749 for threatening to ban prominent Bitcoin business Coinbase from the subreddit. In an extraordinary turn of events, Theymos posted a thread which received only 26% upvotes in a sample size of thousands announcing that he did not care if even 90% of users disagreed with his policy, he would not change his opinion or his moderation policy to facilitate the discussion the community wanted to have. His suggested alternative was instead for those users, however many there were, to leave. Here are Theymos' exact words, as he describes how he intends to continue moderating Bitcoin according to his own personal rules rather than the demands of the vast majority of users, who according to him clearly don't have any "real arguments" or "any brains".
Do not violate our rules just because you disagree with them. This will get you banned from /Bitcoin , and evading this ban will get you (and maybe your IP) banned from Reddit entirely. If 90% of /Bitcoin users find these policies to be intolerable, then I want these 90% of /Bitcoin users to leave. Both /Bitcoin and these people will be happier for it. I do not want these people to make threads breaking the rules, demanding change, asking for upvotes, making personal attacks against moderators, etc. Without some real argument, you're not going to convince anyone with any brains -- you're just wasting your time and ours. The temporary rules against blocksize and moderation discussion are in part designed to encourage people who should leave /Bitcoin to actually do so so that /Bitcoin can get back to the business of discussing Bitcoin news in peace.
/btc was therefore born in an environment not of voluntary departure but of forced exile. This forced migration caused two very unfortunate occurrences:
It polarised the debate around Bitcoin scaling. Previously, there was a lot of civil discussion about compromise and people with suggestions from all along the spectrum were working to find the best solution. That was no longer possible when a moderation policy would actively suppress anyone with opinions too different from Theymos. Instead it forced everyone into a "with us or against us" situation, which is why the /btc subreddit has been pushed so far in favour of the idea of a network hard fork (discussed below).
It has distracted Bitcoin from its mission of becoming a useful, global, neutral currency into a war of information. New users often find /Bitcoin and assume it to be the authoritative source of information, only to later discover that a lot of important information or debate has been invisibly removed from their view.
Since then, like any entrenched conflict, things have degenerated somewhat on both sides to name calling and strawman arguments. However, /btc remains committed to permitting free and open debate on all topics and allowing user downvotes to manage any "trolling" (as /Bitcoin used to) instead of automatic shadow-banning or heavy-handed moderator comment deletion (as /Bitcoin does now). Many users in /Bitcoin deny that censorship exists at all (it is difficult to see when anyone pointing out the censorship has their comment automatically hidden by the automoderator) or justify it as necessary removal of "trolls", which at this point now includes thousands upon thousands of current and often long-standing Bitcoin users and community members. Ongoing censorship is still rampant, partially documented in this post by John Blocke For another detailed account of this historical sequence of events, see singularity87 s posts here and here. /btc has a public moderator log as demonstration of its commitment to transparency and the limited use of moderation. /Bitcoin does not. Why is so much of the discussion in /btc about the censorship in /Bitcoin? Isn't a better solution to create a better community rather than constantly complaining? There are two answers to this question.
Over time, as /btc grows, conversation will gradually start to incorporate more information about the Bitcoin ecosystem, technology, price etc. Users are encouraged to aid this process by submitting links to relevant articles and up/downvoting on the /new and /rising tab as appropriate. However, /btc was founded effectively as a refuge for confused and angry users banned from /Bitcoin and it still needs to serve that function so at least some discussion of the censorship will probably always persist (unless there is a sudden change of moderation policy in /Bitcoin).
The single largest issue in Bitcoin right now is the current cap on the number of transactions the network can process, known as the blocksize limit. Due to the censorship in /Bitcoin, open debate of the merits of different methods of addressing this problem is impossible. As a result, the censorship of /Bitcoin (historically the most active and important Bitcoin community forum) has become by proxy the single most important topic in Bitcoin, since only by returning to open discussion would there be any hope of reaching agreement on the solution to the block size limit itself. As a topic of such central importance, there is naturally going to be a lot of threads about this until a solution is found. This is simply how Bitcoin works, that at any one time there is one key issue under discussion for lengthy periods of time (previous examples of community "hot topics" include the demise of the original Bitcoin exchange Mt Gox, the rise to a 51% majority hash rate of mining pool GHash.io and the supposed "unveiling" of Bitcoin's anonymous creator Satoshi Nakamoto).
Bitcoin Network Hard Forks
What is a hard fork? What happens if Bitcoin hard forks? A network hard fork is when a new block of transactions is published under a new set of rules that only some of the network will accept. In this case, Bitcoin diverges from a single blockchain history of transactions to two separate blockchains of the current state of the network. With any luck, the economic incentive for all users to converge quickly brings everyone together on one side of the fork, but this is not guaranteed especially since there is not a lot of historical precedent for such an event. A hard fork is necessary to raise the block size limit above its 1MB cap. Why is /btc generally in favour of a hard fork and /Bitcoin generally against? According to a lot of users on /Bitcoin - a hard fork can be characterised as an “attack” on the network. The confusion and bad press surrounding a hard fork would likely damage Bitcoin’s price and/or reputation (especially in the short term). They point to the ongoing turmoil with Ethereum as an example of the dangers of a hard fork. Most of /Bitcoin sees the stance of /btc as actively reckless, that pushing for a hard fork creates the following problems:
The possibility of an irrevocable community divergence, as has happened in Ethereum (discussed below)
The chance of introducing new code bugs by forcing a network update without totally comprehensive software developer review
The possibility of reducing decentralisation in the network as higher hardware requirements puts greater strain on network nodes and miners
According to a lot of users on /btc - a hard fork is necessary despite these risks. Most of /btc sees the stance of /Bitcoin as passively reckless, that continuing to limit Bitcoin’s blocksize while remaining inactive creates the following problems:
Transaction fees are continuously rising as transactions compete for the limited space in each block
Confirmation times for any given transaction are also increasing, especially ones without a rapidly escalating fee attached
Fee and confirmation times is making BItcoin hostile to new users, who are confused by their difficulties with this “revolutionary” new technology
Restricting Bitcoin’s growth increases the likelihood it will be overtaken by another unrestricted cryptocurrency
Passively validating the stance of /Bitcoin to continue censoring the debate about this important issue
Bitcoiners are encouraged to examine all of the information and reach their own conclusion. However, it is important to remember that Bitcoin is anopen-source projectfounded on the ideal offree market competition (between any/all software projects, currencies, monetary policies, miners, ideas etc.). In one sense, /btc vs /Bitcoin is just another extension of this, although Bitcoiners are also encouraged to keep abreast of the top posts and links on both subreddits. Only those afraid of the truth need to cut off opposing information. What do Bitcoin developers, businesses, users, miners, nodes etc. think? Developers There are developers on both sides of the debate, although it is a common argument in /Bitcoin to claim that the majority supports Bitcoin Core. This is true in the sense that Bitcoin Core is the current default and has 421 listed code contributors but misleading because not only are many of those contributors authors of a single tiny change and nothing else but also many major figures like Gavin Andresen, Mike Hearn and Jeff Garzik have left the project while still being counted as historical contributors. Businesses including exchanges etc. A definite vote of confidence is not available from the vast majority of Bitcoin businesses, and wouldn't be binding in any case. The smart decision for most businesses is to support both chains in the event of a fork until the network resolves the issue (which may only be a day or two). Users Exact user sentiment is impossible to determine, especially given the censorship on /Bitcoin. Miners and Nodes Coin.dance hosts some excellent graphical representations of the current opinion on the network. Node Support Information Miner Support Information What do I do if the network hard forks?* Do we end up with two Bitcoins? Firstly, in the event of a hard fork there is no need to panic. All Bitcoins are copied to both chains in the case of a split, so any Bitcoins you have are safe. HOWEVER, in the event of a fork there will be some period of confusion where it is important to be very careful about how/why you spend your Bitcoins. Hopefully (and most likely) this would not last long - everyone in Bitcoin is motivated to converge into agreement for everyone's benefit as soon as possible - but it's impossible to say for sure. There isn't a lot of historical data about cryptocurrency hard forks, but one example is alternative cryptocurrency Ethereum that forked into two coins after the events of the DAO and currently exists as two separate chains, ETH (Ethereum) and ETC (Ethereum Classic). The Ethereum fork is not a good analogy for Bitcoin because its network difficulty target adjusts every single block, so a massive drop in hash rate does not significantly impede its functioning. Bitcoin’s difficult target adjusts only every 2100 blocks - which under usual circumstances takes two weeks but in the event of a hard fork could be a month or more for the smaller chain. It is almost inconceivable that a minority of miners would willingly spend millions of dollars over a month or more purely on principle to maintain a chain that was less secure and processed transactions far slower than the majority chain - even assuming the Bitcoins on this handicapped chain didn't suffer a market crash to close to worthless. Secondly, a hard fork is less likely to be a traumatic event than it is often portrayed in /Bitcoin:
The Bitcoin Core and /Bitcoin stated policy is to avoid a hard fork at all costs. So there is no risk of a hard fork on that side.
The Bitcoin XT/Classic/Unlimited and /btc side is prepared for a hard fork if necessary, but it will only come to pass if a clear majority of miners (and presumably users, although that's harder to determine) are already signalling that they would be onboard. There is no exact threshold value, but no miner is going to risk publishing a block larger than 1MB until they are very confident the network will follow them.
What Happens Now
How do I check on the current status of opinion? Coin.dance hosts some excellent graphical representations of the current opinion on the network. Node Support Information Miner Support Information Users are also welcome to engage in anecdotal speculation about community opinion based on their impression of the commentary and activity in /btc and /Bitcoin. Haven't past attempts to raise the blocksize failed? There is no time limit or statute of limitations on the number of attempts the community can make to increase the block size and scale Bitcoin. Almost any innovation in the history of mankind required several attempts to get working and this is no different. The initial attempt called Bitcoin XT never got enough support for a fork because key developer Mike Hearn left out of frustration at trying to talk around all the censorship and community blockading. The second major attempt called Bitcoin Classic gained massive community momentum until it was suddenly halted by the drastic implementation of censorship by Theymos described above. The most popular attempt at the moment is called Bitcoin Unlimited. /btc is neutral and welcoming to any and all projects that want to find a solution to scaling Bitcoin - either on-or off-chain. However, many users are suspicious of Bitcoin Core's approach that involves only SegWit, developed by a private corporation called Blockstream and that has already broken its previous promises in a document known as the Hong Kong Agreement to give the network a block size limit raise client along with Segregated Witness (only the latter was delivered) . What if the stalemate is irreconcilable and nothing ever happens? Increasing transaction fees and confirmation times are constantly increasing the pressure to find a scaling solution - leading some to believe that further adoption of Bitcoin Unlimited or a successor scaling client will eventually occur. Bitcoin Core's proposed addition of SegWit is struggling to gain significant support and as it is already the default client (and not censored in /Bitcoin) it is unlikely to suddenly grow any further. If the stalemate is truly irreconcilable, eventually users frustrated by the cost, time and difficulty of Bitcoin will begin migrating to alternative cryptocurrencies. This is obviously not a desirable outcome for long standing Bitcoin supporters and holders, but cannot be ignored as the inevitable free market resort if Bitcoin remains deadlocked for long enough.
Bitcoin is at its transaction capacity and needs to scale to onboard more users
The community was discussing different ways to do this until the biased head moderator of /BitcoinTheymos got involved
Theymos, started an authoritarian censorship rampage which culminated in telling 90% of /Bitcoin users to leave. /btc is where they went. Here is the thread where it all started. Note the 26% upvoted on the original post, the hundreds of upvotes of community outcry in the comments and the graveyard of [removed] posts further down the chain. Highly recommended reading in its entirety.
To this day, /Bitcoin bans all discussion of alternative scaling proposals and /btc
Bitcoin is about freedom, and can’t function effectively with either an artificially restricted transaction cap or a main community forum that is so heavily manipulated. This subreddit is the search for solutions to both problems as well as general Bitcoin discussion.
Debate continues in /btc, and generally doesn't continue in /Bitcoin - although posts referencing /btc or Bitcoin Unlimited regularly sneak past the moderators because it is such a crucial topic
Eventually one side or the other breaks, enough miners/nodes/users get on one side and Bitcoin starts scaling. This may or may not involve a hard fork.
If not, fees and average confirmation times continue to rise until users migrate en masse to an altcoin. This is not an imminent danger, as can be seen by the BTC marketcap dominance at its historical levels of 80+% but could change at any time
IRC Log from Ravencoin Open Developer Meeting - Sept 21, 2018
[14:04] Topics for the chat today: 1. Bitcoin double spend bug. 2. Max reorg depth changes. [14:04] I think that will take most of the hour. We'll then open it up for questions. [14:05] == blondfrogs changed the topic of #ravencoin-dev to: Topics for the chat today: 1. Bitcoin double spend bug. 2. Max reorg depth changes. [14:05] == wolfsokta changed the topic of #ravencoin-dev to: Bitcoin Bug/Max Reorg [14:05] Hi! I'm Forest... Forest Gump, do you want a ravencoin? [14:05] Hi all [14:05] == blondfrogs changed the topic of #ravencoin-dev to: Topics for the chat today: 1. Bitcoin double spend bug. 2. Max reorg depth changes. [14:05] Topic fight [14:05] as far as i know the double spending bug could inflate the bitcoin supply right? [14:05] like make more bitcoin that possible [14:05] than [14:06] is this correct? [14:06] it's more that the danger is crashing all the nodes [14:07] 1. Raven is also affected by the bitcoin bug. Which is what we want to discus. [14:08] blondfrogs can you tell us what you're planning to address the bug? [14:08] So, we have updated our codebase to have the bitcoin bug fix. This is going to be implemented in 220.127.116.11. We are currently making binaries and should have an annoucment by end of day today to the community. We are urging the community to update their wallets to 18.104.22.168 [14:09] ... [14:10] BTC patched it though. Wouldnt the "same" patch work for RVN? [14:10] Spot on! [14:10] No, it would not since we forked a while back. [14:10] Exactly. We patched it in the same way but we still need to get our wallets that contain the fix out so the community can upgrade [14:10] is there a todo somewhere to add auto-update functionality to the wallet? [14:11] So, we need to get the word out to get people to update. [14:11] YES [14:12] How does the patch affect future LN implementation? [14:12] Any changes that were made to bitcoin to get LN to integrate would need to be merged into Raven. [14:12] Any risks? [14:13] Fair comment. [14:13] We would love any developers that are interested in doing that work to jump in. [14:13] The fix is just changing a 'false' to 'true' to tell the node to scan for dup tx in the block. [14:14] So the auto update feature implementation is being discussed through OS stores, as a second option for wallet download ... @lsji07 [14:14] The comment in the Bitcoin code said it was slow to scan the transactions. So it will be a bit slower. [14:14] slower is better than being vulnerable [14:16] Agreed [14:16] lets talk about the maxreorg depth, people in the discord have been asking "why isnt it lower" what do you guys think [14:16] once we finish with the first one we will russk [14:16] k [14:16] no russk [14:16] lol [14:17] I saw it went back to 60. [14:17] 22.214.171.124 will be built and uploaded today. [14:18] Once the binaries are ready, Ill get it out to all of the social sites, exchanges, and pool operators [14:18] We changed the voting date for 126.96.36.199 [14:19] So it will not interfere with 2.1 release. [14:19] We would prefer that 2.0.4 and 188.8.131.52 assets do not activate as they're not 100% compatible with 2.1 assets. [14:19] == Zaaaab [[email protected]/web/cgi-irc/kiwiirc.com/ip.184.108.40.206] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] [14:20] We also need the communities help to get people to upgrade to 220.127.116.11 [14:20] The protocol layer for assets changed just a bit. [14:20] Unique assets can be 31 chars instead of 30 [14:20] We saved a byte on asset creation by not encoding the IPFS length twide. [14:20] We saved a byte on asset creation by not encoding the IPFS length twice. [14:21] ipfs will be implemented natively later right? [14:21] YEs [14:21] I hope so. [14:21] awesome [14:21] So vulnerabilty patch first, then the asset layer. Same 31/10 date though for starting asset activation on 2.1 [14:21] It makes sense for us to integrate with IPFS when messaging is available. [14:22] Yes lsji07 [14:22] Until then, the IPFS hashes will be embedded and we'll "pin" the files so they stay around. [14:22] == HansSchmidt [[email protected]/web/cgi-irc/kiwiirc.com/ip.18.104.22.168] has joined #ravencoin-dev [14:22] == Hans_Schmidt [[email protected]/web/cgi-irc/kiwiirc.com/ip.22.214.171.124] has left #ravencoin-dev  [14:22] == corby_ [[email protected]/web/freenode/ip.126.96.36.199] has joined #ravencoin-dev [14:23] do you guys have anyone working on RSK yet? [14:23] hi [14:23] sup [14:23] Any other questions about 188.8.131.52? [14:23] @russk Thats a great question for the open QA at the end :) [14:23] K, let's cover the Max Re-Org depth changes. [14:24] No, but it can be implemented with RVN the same way as Bitcoin - as a side chain. [14:24] Tron posted an article that discusses the options that were discussed. [14:24] https://medium.com/@tronblack/ravencoin-building-the-immune-system-23d077b65f71 [14:24] Hope you all had a chance to read through it. [14:25] im still voting for the lake of fire method [14:25] I think the lake of fire was my favorite too. [14:25] Agreed [14:25] I'm with ya russk [14:25] I have sourced the lake part. [14:25] We found a burning pit in Utah, but no lake. [14:25] aw [14:26] Must try harder. [14:26] The code has moved to 60 blocks. [14:26] The reason for 55 was to have "buffer" [14:26] https://en.wikipedia.org/wiki/Darvaza_gas_crater [14:26] I would love to hear thoughts about the solution being proposed. [14:26] Buffer isn't needed if we get all the >= and the counts right. [14:27] Or questions/suggestions. [14:27] Exchanges don't go by time, but by confirmations. Confirmations are the block count, so if it can't re-org at 60, then 60 should be a safe level. [14:27] Plus 60 is easier to explain to people than 55 because the timing is in line with bitcoin. [14:27] It might be lower, but we opted for a more conservative number. [14:27] The downside risk is a chain split on an honest/honest split. [14:28] With years of data, we could look at all the chain splits and determine the probability of a long split. [14:29] For instance, a network cable between China and the rest of the world is cut, and then comes back on line later. [14:29] I think the code decision is sound. The only way a chain split would occur is splitting the hardware links around the world. Wartime scenario? [14:29] say if 50% of nodes upgrade to the new maxreorg client and someone tries to reorg the chain there will be a big split right? [14:30] Yes. [14:30] == Raven-Fam|21005 [[email protected]/web/cgi-irc/kiwiirc.com/ip.184.108.40.206] has joined #ravencoin-dev [14:30] Most exchanges today give access to bitcoin funds long before 6 confirmations, so you wouldn't expect exchanges to require 60 confirms either, correct? [14:30] Although that risk exists primarily between now and early Nov. After that, we hope 90%+ will be on the asset aware software. [14:31] which is why you all need to upgrade your wallets and vote for the correct chain and tell your friends. [14:31] got it, 2.1 will be the actual client for the hardfork, correct? [14:31] The exchanges are welcome to take on additional risk. The risk decreases as the hashpower goes up. [14:31] 2.1 is the planned version number. [14:32] also, say if i am still on 2.0.3-4 will i still be able to use assets after the hardfork? [14:32] how incompatible are the clients [14:32] At that point 2.0.3-4 clients would be on a different fork I believe. [14:34] any node with version < 2.1 will fork when assets are active. [14:34] Assets activate when 90% of the blocks are mined with 2.1+ [14:34] We'll work hard to ensure exchanges and pools have updated to 220.127.116.11 first and then to 2.1 when it's available. [14:34] awesome [14:35] But we want the community to help get the word out as well. Raven needs you! [14:35] We need a raven with a US Army hat guy to get people to update. [14:35] lol [14:36] Ill ping Pathfinder and get him on it. [14:36] Only you can help assure upgrades [14:36] Any other questions/comments/suggestions on Max Re-Org? [14:37] So just to be clear- the max reorg is included in 18.104.22.168 of not? [14:37] No, it is not. [14:37] Only the bitcoin bug fix is in 22.214.171.124 [14:38] Okay, open Q&A then! [14:38] Russk go! [14:38] lol [14:39] when are you guys going to implement native bech32? [14:39] Is there time to talk about asset_name token burning? There has been a proposal for RPC commands to let an asset_token owner burn them in order to clean out unwanted asset names and reduce UTXO. That appears to be easy and relatively uncontroversial. [14:39] also anyone working on RSK yet [14:40] Bech 32 was deprecated. [14:40] Honestly don't know much about it. [14:41] is the block size going to increase to 2mb when we fork? [14:41] russk tell me more. [14:41] I thought it was the new btc address format... [14:41] it is [14:41] it allows native segwit addresses [14:41] https://github.com/bitcoin/bips/blob/mastebip-0173.mediawiki [14:41] Ravencoin forked in the middle of implementation of segwit, it's planned to be added with Segwit. [14:41] Raven is already 2mb [14:41] really? [14:42] i thought it was 1mb [14:42] It's part of the vote coming up on Oct 31 [14:42] ah ok [14:42] It's in there, but BIP9 has to activate first. [14:42] Yes. We've also tested that it is possible to fill a 2MB block [14:42] Or rather BIP9 voting will activate RIP2 which will increase the block size. [14:43] https://i.imgflip.com/2igmj7.jpg [14:43] do you guys have a timeframe of when segwit is being fully added? [14:43] I want you. Nice one. [14:44] and for when they have done it, you can use https://i.imgflip.com/2igmml.jpg [14:44] lol [14:44] Wow, we have a meme master in the community! [14:44] @HansSchmidt any new code would be appreciated, if you have the ability to code the rpc called please submit an PR to the repo [14:44] I can't even open Photoshop that fast [14:45] We are talking about adding anti-spam features into the wallet. [14:45] Basically, if somebody sends an asset to an address that has been already used it could be an unwanted asset. [14:45] == vap0r-XMR [[email protected]/web/cgi-irc/kiwiirc.com/ip.126.96.36.199] has joined #ravencoin-dev [14:46] One more meme from the master: ttps://i.imgflip.com/2igmtd.jpg [14:46] https://i.imgflip.com/2igmtd.jpg [14:46] == Raven-Fam|1781 [[email protected]/web/freenode/ip.188.8.131.52] has joined #ravencoin-dev [14:46] Understood. I'll look at it, but I'm more python than C [14:47] == SweetAndLow [~[email protected]] has joined #ravencoin-dev [14:47] Perfect [14:47] That would still be great Hans. [14:47] im looking into implementing RSK [14:48] @HansSchmidt You don't need C [14:48] it doesnt look crazy hard, just some java stuff [14:48] == Zaaaab [[email protected]/web/cgi-irc/kiwiirc.com/ip.184.108.40.206] has joined #ravencoin-dev [14:48] c++ [14:48] more like c-- [14:49] == Raven-Fam|21005 [[email protected]/web/cgi-irc/kiwiirc.com/ip.220.127.116.11] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] [14:49] when ravencoin client coded in assembly [14:49] == Zaaaab [[email protected]/web/cgi-irc/kiwiirc.com/ip.18.104.22.168] has quit [Client Quit] [14:49] I was referring to @blondfrog new RPCs [14:49] == Zaaaab [[email protected]/web/cgi-irc/kiwiirc.com/ip.22.214.171.124] has joined #ravencoin-dev [14:49] I'd like to help with RSK [14:49] We would love you to help! [14:50] if you know java you can probably do it @vap0r [14:50] https://github.com/rsksmart [14:50] fork rskj and bitcoinj [14:50] Thanks [14:51] RSK would be extremely useful for bond-like implementations [14:51] assets would probably mess RSK up tho [14:51] Im off now thanks for the hard work guys! [14:52] It might be a fun merge for sure. [14:52] Thanks for joining! [14:52] == AlsoSushi [[email protected]/web/cgi-irc/kiwiirc.com/ip.126.96.36.199] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] [14:52] the bitcoinj client doesnt look crazy hard to port over to ravencoin [14:52] == lsji07 [~[email protected]] has quit [Quit: AndroIRC - Android IRC Client ( http://www.androirc.com )] [14:52] you would just need to change the diff algo to DGW and make an x16r java implementation [14:53] It shouldn't be too hard. [14:53] Which channel can I disclose a vulnerability? [14:53] is it the bitcoin double spend vulnerability? [14:53] or something new [14:53] DM Chatturga on discord. [14:53] == dudeman [[email protected]/web/cgi-irc/kiwiirc.com/ip.188.8.131.52] has joined #ravencoin-dev [14:53] No, on Testnet [14:53] ahh ok yea dm chatturga [14:54] Either way, you can send it to me and I can make surfe it gets where it needs to go. [14:54] sure* [14:54] Do you have a suggested fix? [14:54] Not currently, need more time [14:55] Just give Chatturga a ping, and we can talk about it [14:55] Thank you vap0r! [14:55] i am extremely curious to see what this vulnerability is [14:55] Does not impact supply [14:56] assets related? [14:56] On second thought vap0r just share it here if you don't mind. [14:56] this is testnet so its meant to be bug tested [14:57] If it's a testnet only bug then please feel free to share. [14:58] We're now on pins and needles vap0r. [14:58] :) [14:59] Any other questions while we wait? [14:59] Or another meme? ;) [15:00] Do you all like these open developer meetings? [15:00] == Mixed [[email protected]/web/freenode/ip.184.108.40.206] has joined #ravencoin-dev [15:00] yea they are nice [15:00] no [15:00] lol [15:00] hahaha!!! to bad blondy [15:00] if they were on discord it would be nicer [15:01] == vap0r-XMR [[email protected]/web/cgi-irc/kiwiirc.com/ip.220.127.116.11] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] [15:01] lol [15:01] there he goes [15:01] Vap0r left... [15:01] +1 on Discord [15:01] Is anyone using testnet6 yet? I built develop2 branch to get 2.0.6 to play with, but had to modify it back to testnet5 in order to be useful. Even on testnet5 there has been only one person sometimes cpu mining. [15:01] Is anyone using testnet6 yet? I built develop2 branch to get 2.0.6 to play with, but had to modify it back to testnet5 in order to be useful. Even on testnet5 there has been only one person sometimes cpu mining. [15:01] Is anyone using testnet6 yet? I built develop2 branch to get 2.0.6 to play with, but had to modify it back to testnet5 in order to be useful. [15:01] We're setting up seed nodes for testnet6. [15:02] Seed nodes are being updated. [15:02] wierd echo... [15:02] Love that you're pulling the code Hans! [15:02] im not on testnetv6 yet, i could compile the binaries and then we could play around @hans [15:02] We expect testnet6 consensus rules to be the final ones. [15:03] when are we getting testnetv20? [15:03] lol [15:03] We're working on it russk [15:03] cant wait [15:04] how can I find the seed nodes? they're added into the code updates? [15:04] == Spyder [[email protected]/web/freenode/ip.18.104.22.168] has quit [Quit: Page closed] [15:04] We're done, thanks everybody. [15:04] russk -- 14 mistakes from now. [15:04] Roshii is done. :) [15:04] Did I see a request for one more meme? [15:04] https://i.imgflip.com/2igof3.jpg [15:04] one last question, when moon? [15:04] == Zaaaab [[email protected]/web/cgi-irc/kiwiirc.com/ip.22.214.171.124] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] [15:05] lol @chatt [15:05] == Mixed [[email protected]/web/freenode/ip.126.96.36.199] has quit [Ping timeout: 256 seconds] [15:05] == Sat_Roshii [[email protected]/web/freenode/ip.188.8.131.52] has quit [Quit: Page closed] [15:05] Seed nodes are behind 3 DNS entries [15:05] Thanks all. Tron out. [15:05] == Tron_ [[email protected]/web/freenode/ip.184.108.40.206] has quit [Quit: Page closed] [15:05] Peace [15:06] == blondfrogs [[email protected]/web/freenode/ip.220.127.116.11] has quit [Quit: Page closed] [15:06] == Raven-Fam|1781 [[email protected]/web/freenode/ip.18.104.22.168] has quit [Quit: Page closed] [15:06] Peace [15:06] == HansSchmidt [[email protected]/web/cgi-irc/kiwiirc.com/ip.22.214.171.124] has left #ravencoin-dev  [15:06] 3 domains Ravencoin.org, Ravencoin.com, bitactivate.com [15:06] 4 dns entries per domain so a total of 12 nodes. [15:07] Alright, everybody left me. Thanks all for joining this week! [15:07] I'll never let go, Wolf [15:07] I think we'll try discord two weeks from now. [15:07] good shit guys, keep up the good work [15:08] Thank you all! We have the best community! [15:08] And definitely the best Memes! [15:08] == Zaaaab [[email protected]/web/cgi-irc/kiwiirc.com/ip.126.96.36.199] has joined #ravencoin-dev [15:09] Have a great weekend.
Since this is a pressing and prevalent issue, I thought maybe condensing the essential arguments into one mega thread is better than rehashing everything in new threads all the time. I chose a FAQ format for this so a certain statement can be answered. I don't want to re-post everything here so where appropriate I'm just going to use links. Disclaimer: This is biased towards big blocks (BIP 101 in particular) but still tries to mention the risks, worries and fears. I think this is fair because all other major bitcoin discussion places severely censor and discourage big block discussion.
What is the block size limit?
The block size limit was introduced by Satoshi back in 2010-07-15 as an anti-DoS measure (though this was not stated in the commit message, more info here). Ever since, it has never been touched because historically there was no need and raising the block size limit requires a hard fork. The block size directly limits the number of transactions in a block. Therefore, the capacity of Bitcoin is directly limited by the block size limit.
Why does a raise require a hard fork?
Because larger blocks are seen as invalid by old nodes, a block size increase would fork these nodes off the network. Therefore it is a hard fork. However, it is possible to downsize the block limit with a soft fork since smaller blocks would still be seen as valid from old nodes. It is considerably easier to roll out a soft fork. Therefore, it makes sense to roll out a more ambitious hard fork limit and downsize as needed with soft forks if problems arise.
What is the deal with soft and hard forks anyways?
It is the Chicken and Egg problem applied to future growth of Bitcoin. If companies do not see how Bitcoin can scale long term, they don't invest which in turn slows down adoption and development. See here and here.
Does an increase in block size limit mean that blocks immediately get larger to the point of the new block size limit?
No, blocks are as large as there is demand for transactions on the network. But one can assume that if the limit is lifted, more users and businesses will want to use the blockchain. This means that blocks will get bigger, but they will not automatically jump to the size of the block size limit. Increased usage of the blockchain also means increased adoption, investment and also price appreciation.
Which are the block size increase proposals?
See here. It should be noted that BIP 101 is the only proposal which has been implemented and is ready to go.
What is the long term vision of BIP 101?
BIP 101 tries to be as close to hardware limitations regarding bandwidth as possible so that nodes can continue running at normal home-user grade internet connections to keep the decentralized aspect of Bitcoin alive. It is believed that it is hard to increase the block size limit, so a long term increase is beneficial to planning and investment in the Bitcoin network. Go to this article for further reading and understand what is meant by "designing for success". BIP 101 vs actual transaction growth visualized: http://imgur.com/QoTEOO2 Note that the actual growth in BIP 101 is piece-wise linear and does not grow in steps as suggested in the picture.
What is up with the moderation and censorship on bitcoin.org, bitcointalk.org and /bitcoin?
Proponents of a more conservative approach fear that a block size increase proposal that does not have "developeexpert consensus" should not be implemented via a majority hard fork. Therefore, discussion about the full node clients which implement BIP 101 is not allowed. Since the same individuals have major influence of all the three bitcoin websites (most notably theymos), discussion of Bitcoin XT is censored and/or discouraged on these websites.
Who governs or controls Bitcoin Core anyways? Who governs Bitcoin XT? What is Bitcoin governance?
Bitcoin Core is governed by a consensus mechanism. How it actually works is not clear. It seems that any major developer can "veto" a change. However, there is one head maintainer who pushes releases and otherwise organizes the development effort. It should be noted that the majority of the main contributors to Bitcoin Core are Blockstream employees. BitcoinXT follows a benevolent dictator model (as Bitcoin used to follow when Satoshi and later Gavin Andresen were the lead maintainers). It is a widespread believe that Bitcoin can be separated into protocol and full node development. This means that there can be multiple implementations of Bitcoin that all follow the same protocol and overall consensus mechanism. More reading here. By having multiple implementations of Bitcoin, single Bitcoin implementations can be run following a benevolent dictator model while protocol development would follow an overall consensus model (which is enforced by Bitcoin's fundamental design through full nodes and miners' hash power). It is still unclear how protocol changes should actually be governed in such a model. Bitcoin governance is a research topic and evolving.
What are the arguments against a significant block size increase and against BIP 101 in particular?
The main arguments against a significant increase are related to decentralization and therefore robustness against commercial interests and government regulation and intervention. More here (warning: biased Wiki article). Another main argument is that Bitcoin needs a fee market established by a low block size limit to support miners long term. There is significant evidence and game theory to doubt this claim, as can be seen here. Finally, block propagation and verification times increase with an increased block size. This in turn increases the orphan rate of miners which means reduced profit. Some believe that this is a disadvantage to small miners because they are not as well connected to other big miners. Also, there is currently a large miner centralization in China. Since most of these miners are behind the Great Firewall of China, their bandwidth to the rest of the world is limited. There is a fear that larger block propagation times favor Chinese miners as long as they have a mining majority. However, there are solutions in development that can drastically reduce block propagation times so this problem will be less of an issue long term.
What is up with the fee market and what is the Lightning Network (LN)?
Major Bitcoin Core developers believe that a fee market established by a low block size is needed for future security of the bitcoin network. While many believe fundamentally this is true, there is major dispute if a fee market needs to be forced by a low block size. One of the main LN developers thinks such a fee market through low block size is needed (read here). The Lightning Network is a non-bandwidth scaling solution. It uses payment channels that can be opened and closed using Bitcoin transactions that are settled on the blockchain. By routing transactions through many of these payment channels, in theory it is possible to support a lot more transactions while a user only needs very few payment channels and therefore rarely has to use (settle on) the actual blockchain. More info here.
How does LN and other non-bandwidth scaling solutions relate to Bitcoin Core and its long term scaling vision?
Bitcoin Core is headed towards a future where block sizes are kept low so that a fee market is established long term that secures miner incentives. The main scaling solution propagated by Core is LN and other solutions that only sometimes settle transactions on the main Bitcoin blockchain. Essentially, Bitcoin becomes a settlement layer for solutions that are built on top of Bitcoin's core technology. Many believe that long term this might be inevitable. But forcing this off-chain development already today seems counterproductive to Bitcoin's much needed growth and adoption phase before such solutions can thrive. It should also be noted that no major non-bandwidth scaling solution (such as LN) has been tested or even implemented. It is not even clear if such off-chain solutions are needed long term scaling solutions as it might be possible to scale Bitcoin itself to handle all needed transaction volumes. Some believe that the focus on a forced fee market by major Bitcoin Core developers represents a conflict of interest since their employer is interested in pushing off-chain scaling solutions such as LN (more reading here).
Are there solutions in development that show the block sizes as proposed via BIP 101 are viable and block propagation times in particular are low enough?
Block size: It's economics & user preparation & moral hazard | Jeff Garzik | Dec 16 2015
Jeff Garzik on Dec 16 2015: All, Following the guiding WP principle of Assume Good Faith, I've been trying to boil down the essence of the message following Scaling Bitcoin. There are key bitcoin issues that remain outstanding and pressing, that are* orthogonal to LN & SW*. I create multiple proposals and try multiple angles because of a few, notable systemic economic and analysis issues - multiple tries at solving the same problems. Why do I do what I do -- Why not try to reboot... just list those problems? Definitions: FE - "Fee Event", the condition where main chain MSG_BLOCK is 95+% to hard limit for 7 or more days in row, "blocks generally full" This can also be induced by a miner squeeze (collective soft limit reduction). Service - a view of bitcoin as a decentralized, faceless, multi-celled, amorphous automaton cloud, that provides services in exchange for payment Users - total [current | future] set of economic actors that pay money to the Service, and receive value (figuratively or literally) in return Block Size - This is short hand for MAX_BLOCK_SIZE, the hard limit that requires, today, a hard fork to increase (excl. extension blocks etc.) Guiding Principle: Keep the Service alive, secure, decentralized, and censorship resistant for as many Users as possible. Observations on block size (shorthand for MAX_BLOCK_SIZE as noted above): This is economically modeled as a supply limited resource over time. On average, 1M capacity is available every 10 minutes, with variance. Observations on Users, block size and modern bidding process: A supermajority of hashpower currently evaluates for block inclusion based, first-pass, on tx-fee/KB. Good. The Service is therefore responsive to the free market and some classes of DoS. Good. Recent mempool changes float relay fee, making the Service more responsive to fast moving markets and DoS's. Good progress. Service provided to Users can be modeled at the bandwidth resource level as bidding for position in a virtual priority queue, where up-to-1M bursts are cleared every 10 min (on avg etc.). Not a perfectly fixed supply, definitionally, but constrained within a fixed range. Observations on the state of today's fee market: On average, blocks are not full. Economically, this means that fees trend towards zero, due to theoretically unlimited supply at <1M levels. Of course, fees are not zero. The network relay anti-flood limits serve as an average lower limit for most transactions (excl direct-to-miner). Wallet software also introduces fee variance in interesting ways. All this fee activity is range-bound on the low end. Let the current set of Users + transaction fee market behavior be TFM (today's fee market). Let the post-Fee-Event set of Users + transaction fee market behavior be FFM (future fee market). *Key observation: A Bitcoin Fee Event (see def. at top) is an Economic Change Event.* An Economic Change Event is a period of market chaos, where large changes to prices and sets of economic actors occurs over a short time period. A Fee Event is a notable Economic Change Event, where a realistic projection forsees higher fee/KB on average, pricing some economic actors (bitcoin projects and businesses) out of the system. *It is a major change to how current Users experience and pay for the Service*, state change from TFM to FFM. The game theory bidding behavior is different for a mostly-empty resource versus a usually-full resource. Prices are different. Profitable business models are different. Users (the set of economic actors on the network) are different. Observation: Contentious hard fork is an Economic Change Event. Similarly, a fork that partitions economic actors for an extended period or permanently is also an Economic Change Event, shuffling prices and economic actors as the Service dynamically readjusts on both sides of the partition, and Users-A and Users-B populations change their behavior. Short-Term Problem #1: No-action on block size increase leads to an Economic Change Event. Failure to increase block size is not obviously-conservative, it is a conscious choice, electing for one economic state and set of actors and prices over another. Choosing FFM over TFM. It is rational to reason that maintaining TFM is more conservative than enduring an Economic Change Event from TFM to FFM. *It is rational to reason that maintaining similar prices and economic actors is less disruptive.* Failure to increase block size will lead to a Fee Event sooner rather than later. Failure to plan ahead for a Fee Event will lead to greater market chaos and User pain. Short-Term Problem #2: Some Developers wish to accelerate the Fee Event, and a veto can accomplish that. In the current developer dynamics, 1-2 key developers can and very likely would veto any block size increase. Thus a veto (e.g. no-action) can lead to a Fee Event, which leads to pricing actors out of the system. A block size veto wields outsize economic power, because it can accelerate ECE. *This is an extreme moral hazard: A few Bitcoin Core committers can veto increase and thereby reshape bitcoin economics, price some businesses out of the system. It is less of a moral hazard to keep the current economics [by raising block size] and not exercise such power.* Short-Term Problem #3: User communication and preparation The current trajectory of no-block-size-increase can lead to short time market chaos, actor chaos, businesses no longer viable. In a $6.6B economy, it is criminal to let the Service undergo an ECE without warning users loudly, months in advance: "Dear users, ECE has accelerated potential due to developers preferring a transition from TFM to FFM." As stated, *it is a conscious choice to change bitcoin economics and User experience* if block size is not advanced with a healthy buffer above actual average traffic levels. Raising block size today, at TFM, produces a smaller fee market delta. Further, wallet software User experience is very, very poor in a hyper-competitive fee market. (This can and will be improved; that's just the state of things today) Short-Term Problem #4: UseDev disconnect: Large mass of users wishes to push Fee Event into future Almost all bitcoin businesses, exchanges and miners have stated they want a block size increase. See the many media articles, BIP 101 letter, and wiki e.g. https://en.bitcoin.it/wiki/Block_size_limit_controversy#Entities_positions The current apparent-veto on block size increase runs contra to the desires of many Users. (note language: "many", not claiming "all") *It is a valid and rational economic choice to subsidize the system with lower fees in the beginning*. Many miners, for example, openly state they prefer long term system growth over maximizing tiny amounts of current day income. Vetoing a block size increase has the effect of eliminating that economic choice as an option. It is difficult to measure Users; projecting beyond "businesses and miners" is near impossible. Without exaggeration, I have never seen this much disconnect between user wishes and dev outcomes in 20+ years of open source. Short-Term Problem #5: Higher Service prices can negatively impact system security Bitcoin depends on a virtuous cycle of users boosting and maintaining bitcoin's network effect, incentivizing miners, increasing security. Higher prices that reduce bitcoin's user count and network effect can have the opposite impact. (Obviously this is a dynamic system, users and miners react to higher prices... including actions that then reduce the price) Short-Term Problem #6: Post-Fee-Event market reboot problem + general lack of planning Game it out: Blocks are now full (FFM). Block size kept at 1M. How full is too full - who and what dictates when 1M should be increased? The same question remains, yet now economic governance issues are compounded: In FFM, the fees are very tightly bound to the upper bound of the block size. In TFM, fees are much less sensitive to the upper bound of block size. Changing block size, when blocks are full, has a more dramatic effect on the market - suddenly new supply is magically brought online, and a minor Economic Change Event occurs. More generally, the post-Fee-Event next step has not been agreed upon. Is it flexcap? This key "step #2" is just barely at whiteboard stage. Short-Term Problem #7: Fee Event timing is unpredictable. As block size free space gets tighter - that is the trend - and block size remains at 1M, Users are ever more likely to hit an Economic Change Event. It could happen in the next 2-6 months. Today, Users and wallets are not prepared. It is also understandably a very touchy subject to say "your business or use case might get priced out of bitcoin" But it is even worse to let worse let Users run into a Fee Event without informing the market that the block size will remain at 1M. Markets function best with maximum knowledge - when they are informed well in advance of market shifting news and events, giving economic actors time to prepare. Short-Term Problem #8: Very little testing, data, effort put into blocks-mostly-full economics We only know for certain that blocks-mostly-not-full works. We do not know that changing to blocks-mostly-full works. Changing to a new economic system includes boatloads of risk. Very little data has been forthcoming from any party on what FFM might look like, f...[message truncated here by reddit bot]... original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-Decembe011973.html
It is a misconception to believe miners have the vote on what BIP will be adopted if BIP 101, 100 or something else entirely. The users & service providers, exchanges, wallet services, lending platforms and so on have equally as powerful vote if not more powerful because they have the userbase and have as much interest and incentive in the direction of bitcoin as the miners do. Even if BIP 101 hits mining majority if the majority of these services and users do not upgrade to it, it is defacto the wrong chain to be on regardless of if it has more hashing power and this is equally true for the totally insane BIP 100 proposal. The difference is you can quickly visualise what version the miners are running, where as there is no mechanism for visualising what version users and service providers are running. It would be very useful to have some recognised platform to show the versions service providers are running.
Can we the users (and the industry players, exchanges, wallets etc) force the switch to BitcoinXT even if the miners don't agree?
We, the users are actually the parties that give Bitcoin it's value by treating it as a valuable unit of exchange in our commerce and investing. If enough of the users and the wallet providers and the exchanges support BIP 101 are we still held hostage by the miners? Or can we make a decision for them? I've seen very few people supporting small blocks, either on the forums or reddit (even on the old reddit they get voted down). And it seems the industry heavy weights are coalescing more and more around BIP 101. Hopefully the miners see the light -- but what if they don't? Perhaps the condition that 75% of the blocks mined support BitcoinXT is not that helpful of a condition. An economic majority might be much more important.
Smaller companies should come forward with their perspective on BIP101
Some of the largest companies in the Bitcoin ecosystem have now put their neck out and declared that they will work to be compatible with BIP 101 by December 2015, as you can see here. Smaller companies shouldn't be afraid to put forward their view as well. Consensus means consensus across the whole ecosystem, ie. merchants, miners, exchanges, remittance companies etc. Making your position clear is the only way we can reach that consensus, so that the whole thing can go forward smoothly one way or the other (fork or no fork, BIP 101 or any other).
A Cosmopolitan Coin / The Benefits of a Quiet Coin
We periodically get asked if NYAN is dead, merely because we are often quiet. We are not dead. But it's true we don't often have crises. On the technical front, our planned NYAN3 hardfork "sometime", hopefully coded by the end of this year, isn't really needed, but it will be nice to have. It will correct the difficulty function being lousy as its primary purpose, bump up the hard cap per BIP 101 to take care of that, and add an OP_DATA so we can easily build forums and such on the Nyanchain. We'll eventually formalize a specification for that, but that is a quick early version of it. On the financial front, we've held steady against BTC basically. Not a great level, but holding a reasonable floor I think. Decent for me not having money to put into it and not actively marketing in any significant or systematic way yet. I've been thinking lately that we might eventually make an effort to expand into the Chinese market, but at this point that will clearly have to wait until they resolve the BTC regulation, at which point I'm presuming alts will be covered too. I'm expecting that a regulated Chinese exchange will be formed or allowed to resume operations within a few months or so. On the community front, we've got our core group. And that's the most important thing. The people are central in cryptocurrency. I believe they are far more important than merely good technicals or financials. Paycoin once had good financials. And there are plenty of basically technically good cryptocurrencies that have failed. I believe we have a very strong group, and we'll build on that over the years. But all that adds up to not a lot of updates. We have a lot more time on our hands compared to the coins doing rapid development upstream. This gives us the luxury both of focusing on everything else we need to do, goofing around, and learning from other coins. I think it makes sense for us to have a core goal as a cryptocurrency community to be well-educated on other cryptocurrencies. This is an endless task, given the massive field. But it should give us a lot of valuable insight along with endless entertainment. define: cosmopolitan:
familiar with and at ease in many different countries and cultures.
As a community, we already have this. Of course we all use BTC as well, but beyond that, I think all of us have other coins we like as well, and that's a great thing. We learn from each other and are therefore aware of a far broader range of approaches and outcomes than our own particular experience. As we grow and expand, Nekonauts should be seen as the friendly ambassadors of cryptocurrency among all the cryptocurrencies. I think building alliances and standards will be a key part of making cryptocurrency into a strong institution for the future. We believe that we all do better when we all do better. There are far more areas where we can work together productively than there are useful or valuable means of trying to attack other coins, even if we wanted to. At most, for a Paycoin, we denounce it and move on. But most cryptocurrencies, I think, even if flawed and not suitable for our own purposes, have at least something to teach us. For example, after doing the write-up on Ethereum and thinking about it more, I've gone from overall vaguely skeptical of the coin to, well, I guess vaguely skeptical of the coin. To be sure, I've gained a far greater appreciation for their accomplishments. And I think it's a codebase worth working with. But I'm not sure the D'OH (The DAO bailout) fork was the right move. So I can see a value in ETC along with ETH. But I think even that seems overpriced for just playing around with the smart contract system, so if I were really going to play with it, I'd launch a Nythereum coin, starting ownership from NYAN. So even though I'm not going to be buying the coin, I see value in being able to work with both development teams potentially in the future. Just as I hope we can ultimately contribute to DOGE, LTC, and BTC technically. If nothing else, we should be able to provide some useful documentation and tutorials to complement what exists. Ultimately of course, I'd like to build /nyancoins into a crossroads for cryptocurrency, where the best leaders of the best coins meet to discuss grand strategy and philosophy and to make shitposts. In the meantime, we'll go where they are. I go to /buttcoin because the best critics are there, in particular jstolfi. It's widely read and gets open discussion. I expect it will grow, but there's plenty of room for additional subreddits alongside it, in particular because its tone can occasionally be off-putting. And of course, there are the multitude of coin-specific subreddits. I, of course, love /dogecoin for its community and CSS. And I know we have readers of a lot of the other major ones here as well. Personally, I can't stand reading the Bitcoin ones anymore. The whole 1MB thing is just too disappointing for me. But I'm going to keep learning more about what's out there, as there are so many great developments along with incompetent crooks and everything in between. Sometimes no news is good news.
BIP status updates & BIP 2 activation | Luke Dashjr | Nov 30 2016
Luke Dashjr on Nov 30 2016: To conclude discussion on BIP 2, I have opened a pull request to implement it and mark it active. Note this implies activation and implementation of BIP 123 as well: https://github.com/bitcoin/bips/pull/478 I plan to merge this on December 14th. If there are any hard objections to this change, please bring it up on the bitcoin-dev mailing list before then. Further reviews of the implementation are welcome in the meantime. Please refrain from requesting further changes to the BIPs themselves unless it is a blockeshow-stopper or trivial (not changing the meaning). In the process of implementing BIP 2, I came across a number of BIPs which managed to get into the repository without a proper license. Authors of any of these BIPs should open a pull request adding the necessary Copyright section and License header(s). (If there are other contributors to the document in the BIP git logs, I will try to reach out to them to get permission. If you have accepted contributions from anyone not documented in git as an Author, please mention this in the PR explicitly.) These BIPs need a license: 001 BIP Purpose and Guidelines 010 Multi-Sig Transaction Distribution 011 M-of-N Standard Transactions 012 OP_EVAL 013 Address Format for pay-to-script-hash 014 Protocol Version and User Agent 015 Aliases 016 Pay to Script Hash 021 URI Scheme 030 Duplicate transactions 031 Pong message 032 Hierarchical Deterministic Wallets 033 Stratized Nodes 034 Block v2, Height in Coinbase 035 mempool message 039 Mnemonic code for generating deterministic keys 043 Purpose Field for Deterministic Wallets 044 Multi-Account Hierarchy for Deterministic Wallets 045 Structure for Deterministic P2SH Multisignature Wallets 047 Reusable Payment Codes for Hierarchical Deterministic Wallets 061 Reject P2P message 062 Dealing with malleability 064 getutxo message 066 Strict DER signatures 067 Deterministic Pay-to-script-hash multi-signature addresses through
public key sorting
068 Relative lock-time using consensus-enforced sequence numbers 070 Payment Protocol 071 Payment Protocol MIME types 072 bitcoin: uri extensions for Payment Protocol 073 Use "Accept" header for response type negotiation with Payment Request
075 Out of Band Address Exchange using Payment Protocol Encryption 101 Increase maximum block size 102 Block size increase to 2MB 103 Block size following technological growth 106 Dynamically Controlled Bitcoin Block Size Max Cap 120 Proof of Payment 121 Proof of Payment URI scheme 123 BIP Classification Thanks, Luke original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-Novembe013331.html
The debate is not "SHOULD THE BLOCKSIZE BE 1MB VERSUS 1.7MB?". The debate is: "WHO SHOULD DECIDE THE BLOCKSIZE?" (1) Should an obsolete temporary anti-spam hack freeze blocks at 1MB? (2) Should a centralized dev team soft-fork the blocksize to 1.7MB? (3) OR SHOULD THE MARKET DECIDE THE BLOCKSIZE? (354 points, 116 comments)
"Notice how anyone who has even remotely supported on-chain scaling has been censored, hounded, DDoS'd, attacked, slandered & removed from any area of Core influence. Community, business, Hearn, Gavin, Jeff, XT, Classic, Coinbase, Unlimited, ViaBTC, Ver, Jihan, Bitcoin.com, btc" ~ u/randy-lawnmole (176 points, 114 comments)
"You have to understand that Core and their supporters eg Theymos WANT a hardfork to be as messy as possible. This entire time they've been doing their utmost to work AGAINST consensus, and it will continue until they are simply removed from the community like the cancer they are." ~ u/singularity87 (170 points, 28 comments)
3 excellent articles highlighting some of the major problems with SegWit: (1) "Core Segwit – Thinking of upgrading? You need to read this!" by WallStreetTechnologist (2) "SegWit is not great" by Deadalnix (3) "How Software Gets Bloated: From Telephony to Bitcoin" by Emin Gün Sirer (146 points, 59 comments)
Now that BU is overtaking SW, r\bitcoin is in meltdown. The 2nd top post over there (sorted by "worst first" ie "controversial") is full of the most ignorant, confused, brainwashed comments ever seen on r\bitcoin - starting with the erroneous title: "The problem with forking and creating two coins." (142 points, 57 comments)
enough with the blockstream core propaganda : changing the blocksize IS the MORE CAUTIOUS and SAFER approach . if it was done sooner , we would have avoived entirely these unprecedented clycles of network clogging that have caused much frustrations in a lot of actors (173 points, 15 comments)
Dear Theymos, you divided the Bitcoin community. Not Roger, not Gavin, not Mike. It was you. And dear Blockstream and Core team, you helped, not calling out the abhorrent censorship, the unforgivable manipulation, unbecoming of supposed cypherpunks. Or of any decent, civil persons. (566 points, 87 comments)
So, Alice is causing a problem. Alice is then trying to sell you a solution for that problem. Alice now tell that if you are not buying into her solution, you are the cause of the problem. Replace Alice with Greg & Adam.. (139 points, 28 comments)
SegWit+limited on-chain scaling: brought to you by the people that couldn't believe Bitcoin was actually a sound concept. (92 points, 47 comments)
Reality check: today's minor bug caused the bitcoin.com pool to miss out on a $12000 block reward, and was fixed within hours. Core's 1MB blocksize limit has cost the users of bitcoin >$100k per day for the past several months. (270 points, 173 comments)
Top post on /bitcoin about high transaction fees. 709 comments. Every time you click "load more comments," there is nothing there. How many posts are being censored? The manipulation of free discussion by /bitcoin moderators needs to end yesterday. (229 points, 91 comments)
Fantasy land: Thinking that a hard fork will be disastrous to the price, yet thinking that a future average fee of > $1 and average wait times of > 1 day won't be disastrous to the price. (209 points, 70 comments)
"Segwit is a permanent solution to refuse any blocksize increase in the future and move the txs and fees to the LN hubs. The chinese miners are not as stupid as the blockstream core devaluators want them to be." shock_the_stream (150 points, 83 comments)
In response to the "unbiased" ELI5 of Core vs BU and this gem: "Core values trustlessness and decentralization above all. Bitcoin Unlimited values low fees for on-chain transactions above all else." (130 points, 45 comments)
Core's own reasoning doesn't add up: If segwit requires 95% of last 2016 blocks to activate, and their fear of using a hardfork instead of a softfork is "splitting the network", then how does a hardfork with a 95% trigger even come close to potentially splitting the network? (96 points, 130 comments)
I'm more concerned that bitcoin can't change than whether or not we scale in the near future by SF or HF (26 points, 9 comments)
"The best available research right now suggested an upper bound of 4MB. This figure was considering only a subset of concerns, in particular it ignored economic impacts, long term sustainability, and impacts on synchronization time.." nullc (20 points, 4 comments)
At any point in time mining pools could have increased the block reward through forking and yet they haven't. Why? Because it is obvious that the community wouldn't like that and correspondingly the price would plummet (14 points, 14 comments)
Dear Theymos, you divided the Bitcoin community. Not Roger, not Gavin, not Mike. It was you. And dear Blockstream and Core team, you helped, not calling out the abhorrent censorship, the unforgivable manipulation, unbecoming of supposed cypherpunks. Or of any decent, civil persons. by parban333 (566 points, 87 comments)
The debate is not "SHOULD THE BLOCKSIZE BE 1MB VERSUS 1.7MB?". The debate is: "WHO SHOULD DECIDE THE BLOCKSIZE?" (1) Should an obsolete temporary anti-spam hack freeze blocks at 1MB? (2) Should a centralized dev team soft-fork the blocksize to 1.7MB? (3) OR SHOULD THE MARKET DECIDE THE BLOCKSIZE? by ydtm (354 points, 116 comments)
151 points: nicebtc's comment in "One miner loses $12k from BU bug, some Core devs scream. Users pay millions in excessive tx fees over the last year "meh, not a priority"
123 points: 1DrK44np3gMKuvcGeFVv's comment in "One miner loses $12k from BU bug, some Core devs scream. Users pay millions in excessive tx fees over the last year "meh, not a priority"
117 points: cryptovessel's comment in nullc disputes that Satoshi Nakamoto left Gavin in control of Bitcoin, asks for citation, then disappears after such citation is clearly provided. greg maxwell is blatantly a toxic troll and an enemy of Satoshi's Bitcoin.
117 points: seweso's comment in Roger Ver banned for doxing after posting the same thread Prohashing was banned for.
113 points: BitcoinIsTehFuture's comment in Dear Theymos, you divided the Bitcoin community. Not Roger, not Gavin, not Mike. It was you. And dear Blockstream and Core team, you helped, not calling out the abhorrent censorship, the unforgivable manipulation, unbecoming of supposed cypherpunks. Or of any decent, civil persons.
106 points: MagmaHindenburg's comment in bitcoin.com loses 13.2BTC trying to fork the network: Untested and buggy BU creates an oversized block, Many BU node banned, the HF fails • /Bitcoin
98 points: lon102guy's comment in bitcoin.com loses 13.2BTC trying to fork the network: Untested and buggy BU creates an oversized block, Many BU node banned, the HF fails • /Bitcoin
Earlier today, popular Bitcoin exchange Bitstamp announced how they will be implementing BIP 101 in a few days. As you would come to expect, it was only a matter of time until Theymos issued a comment on how Bitstamp will be removed from all Bitcoin references, including Reddit and the Bitcoin Wiki. Leading bitcoin startups including BitPay, Blockchain.info, Circle, KnCMiner, Bitnet, Xapo and BitGo have come to a consensus to implement Gavin Andresen’s BIP 101, and to expand the current block size to 8 megabytes, after a long discussion with core developers, miners and the companies’ technical teams. Brian Armstrong, CEO of record-funded Bitcoin wallet service and exchange Coinbase, plans a code update to allow for bigger blocks in the second week of December, and has indicated he prefers BIP (Bitcoin Improvement Proposal) 101.This makes Coinbase the latest Bitcoin industry heavyweight to endorse the proposal as adopted by alternative Bitcoin implementation Bitcoin XT, although the company ... There is a related issue, which is Bitcoin-XT, which grew out of several developer's frustrations with the process. That proposes to alter the blocksize according to BIP 101 once more than 75% of the blocks are created by Bitcoin-XT nodes. But that's not something within the BIP process. Earlier today, popular Bitcoin exchange Bitstamp announced how they will be implementing BIP 101 in a few days. As you would come to expect, it was only a matter of time until Theymos issued a comment on how Bitstamp will be removed from all Bitcoin references, including Reddit and the Bitcoin Wiki. Also read: Greek Banks Asked To Pay Bitcoin Ransom. Bitstamp To Be Banned From Bitcoin Resource ...
Bitcoin 101 - Calling All APIs - Coding Live Price Data ...
Crypto 101 Kraken Bitcoin Exchange; 20 videos; 4,873 views; Last updated on Jun 19, 2020; Learn the basics of cryptocurrency with our Crypto 101 series Play all Share. Loading... Save. Sign in to ... one nine tool in one combo for 12,18,24 bip 44 bip49, bip84 wallets and checks first five address and creates xpub and xprv to upload direct one of the awesome hacks every made for more details ... In this episode, I talk to Flood, an independent Bitcoin trader. We discuss the key things a newcomer to trading needs to know from which exchanges to use, trading strategies, leverage, finding ... petit délire de Guides. Uncensor the World: Michael W. Dean & Derrick Slopey Talk BipCoin, Dot-Bip, More - YMB Podcast E152 - Duration: 48:37. World Crypto Network 230 views 20 videos Play all Crypto 101 Kraken Bitcoin Exchange; 80 Trillion Dollar Bitcoin Exit Plan - Duration: 22:12. Mineable 429,426 views. 22:12. Killing a ...