I want to put my money into Bitcoins but I have reservations.
I want to put my money into Bitcoins but I have reservations. Thanks to everyone who make sincere efforts to clarify the following doubts
How much energy will the Bitcoin network consume if BTC is valued at $100000?
How will the Bitcoin network sustain if all the Bitcoins have been mined?
We know that energy is a finite resource. Technologies that consume less energy for similar or better output get preference. That's what propagates the innovation in combustion engines. Bitcoin is far behind several of the available alternatives.
Bitcoin is unfit for everyday transactions. Because it is slow.
You can find studies that highlight the fact that the majority of Bitcoin mining is concentrated in few geographical regions.
I don't agree with the notion that Bitcoin is a store of value like gold. People do mention that there is an infinite amount of gold in the universe without even knowing that it will take a huge amount of energy to extract that gold and don't even think of bringing it back to earth. Gold is useful in several scientific applications.
Are there scientific studies to show that Bitcoin has improved the living standard of the poor of the world? Those are the ones who will suffer the undeserved consequence of global warming.
arriving at consensus AND distributing coins via burning Bitcoin instead of electricity/equipment to create permissionless, unfakeable, green, and trust minimized basis over every aspect of sidechain control.
creating Bitcoin peg from altcoin chain to mainchain (the hard direction) by allocating small percentage of Bitcoin intended for burning to reimbursing withdrawals, effectively making it a childchain/sidechain (no oracles or federated multisigs)
This is not an altcoin thread. I'm not making anything. The design discussed options for existing altcoins and new ways to built on top of Bitcoin inheriting some of its security guarantees. 2 parts: First, the design allows any altcoins to switch to securing themselves via Bitcoin instead of their own PoW or PoS with significant benefits to both altcoins and Bitcoin (and environment lol). Second, I explain how to create Bitcoin-pegged assets to turn altcoins into a Bitcoin sidechain equivalent. Let me know if this is of interest or if it exists, feel free to use or do anything with this, hopefully I can help.
how to create continuous sunk costs, permissionless entry, high cost of attacks?
how to do it without needing to build up a new source of hardware capital or energy costs?
how to peg another chain's token value w/o incentivized collusion risk of federation or oracles?
how to make sidechain use fully optional for all Bitcoin parties?
how to allow programmable Bitcoins w/ unlimited permissionless expressiveness w/o forcing mainchain into additional risks?
Solution to first few points:
Continuous Proof of Bitcoin Burn (CPoBB) to distribute supply control and sidechain consensus control to independent parties
Distributes an altcoin for permissionless access and sidechain-only sybil protection.
In case of sidechain block-producer censorship, Bitcoin's independent data availability makes sidechain nodes trivially aware
PoW altcoin switching to CPoBB would trade:
cost of capital and energy -> cost of burnt bitcoin
finality of their PoW -> finality of Bitcoin's PoW
impact on environment -> 0 impact on environment
unforgeable costliness of work -> unforgeable costliness of burn
contract logic can include conditions dependent on real Bitcoins as it's Bitcoin-aware
PoS altcoin switching to CPoBB would trade:
permissioned by coin holders entry -> permissionless entry by anyone with access to Bitcoin
no incentive to give up control or sell coins -> incentive to sell coins to cover the cost of burnt bitcoin
incentivized guaranteed centralization of control over time by staking -> PoW guarantees with same 0 environmental impact
nothing at stake -> recovering sunk costs at stake
contract logic can include conditions dependent on real Bitcoins as it's Bitcoin-aware
We already have a permissionless, compact, public, high-cost-backed finality base layer to build on top - Bitcoin! It will handle sorting, data availability, finality, and has something of value to use instead of capital or energy that's outside the sidechain - the Bitcoin coins. The sunk costs of PoW can be simulated by burning Bitcoin, similar to concept known as Proof of Burn where Bitcoin are sent to unspendable address. Unlike ICO's, no contributors can take out the Bitcoins and get rewards for free. Unlike PoS, entry into supply lies outside the alt-chain and thus doesn't depend on permission of alt-chain stake-coin holders. It's hard to find a more bandwidth or state size protective blockchain to use other than Bitcoin as well so altcoins can be Bitcoin-aware at little marginal difficulty - 10 years of history fully validates in under a day.
What are typical issues with Proof of Burn?
limited burn time window prevents permissionless entry in the future. how many years did it take for most heavily mined projects to become known and well reviewed? many. thus entry into control of supply that's vital to control of chain cannot be dependent on the earliest stage of the project. (counterparty)
"land grabs" - by having limited supply without continuous emission or inflation we encourage holding vs spending.
These issues can be fixed by having Proof of Burn be permanently accessible and continuous: Continuous Proof of Bitcoin Burn CPoBB
This should be required for any design for it to stay permissionless. Optional is constant fixed emission rate for altcoins not trying to be money if goal is to maximize accessibility. Since it's not depending on brand new PoW for security, they don't have to depend on massive early rewards giving disproportionate fraction of supply at earliest stage either. If 10 coins are created every block, after n blocks, at rate of 10 coins per block, % emission per block is = (100/n)%, an always decreasing number. Sidechain coin doesn't need to be scarce money, and could maximize distribution of control by encouraging further distribution. If no burners exist in a block, altcoin block reward is simply added to next block reward making emission predictable. Sidechain block content should be committed in burn transaction via a root of the merkle tree of its transactions. Sidechain state will depend on Bitcoin for finality and block time between commitment broadcasts. However, the throughput can be of any size per block, unlimited number of such sidechains can exist with their own rules and validation costs are handled only by nodes that choose to be aware of a specific sidechain by running its consensus compatible software. Important design decision is how can protocol determine the "true" side-block and how to distribute incentives. Simplest solution is to always :
Agree on the valid sidechain block matching the merkle root commitment for the largest amount of Bitcoin burnt, earliest inclusion in the bitcoin block as the tie breaker
Distribute block reward during the next side-block proportional to current amounts burnt
Bitcoin fee market serves as deterrent for spam submissions of blocks to validate
sidechain block reward is set always at 10 altcoins per block Bitcoin block contains the following content embedded and part of its transactions: tx11: burns 0.01 BTC & OP_RETURN tx56: burns 0.05 BTC & OP_RETURN ... <...root of valid sidechain block version 1> ... tx78: burns 1 BTC & OP_RETURN ... <...root of valid sidechain block version 2> ... tx124: burns 0.2 BTC & OP_RETURN ... <...root of INVALID sidechain block version 3> ...
Validity is deterministic by rules in client side node software (e.g. signature validation) so all nodes can independently see version 3 is invalid and thus burner of tx124 gets no reward allocated. The largest valid burn is from tx78 so version 2 is used for the blockchain in sidechain. The total valid burn is 1.06 BTC, so 10 altcoins to be distributed in the next block are 0.094, 0.472, 9.434 to owners of first 3 transactions, respectively. Censorship attack would require continuous costs in Bitcoin on the attacker and can be waited out. Censorship would also be limited to on-sidechain specific transactions as emission distribution to others CPoB contributors wouldn't be affected as blocks without matching coin distributions on sidechain wouldn't be valid. Additionally, sidechains can allow a limited number of sidechain transactions to happen via embedding transaction data inside Bitcoin transactions (e.g. OP_RETURN) as a way to use Bitcoin for data availability layer in case sidechain transactions are being censored on their network. Since all sidechain nodes are Bitcoin aware, it would be trivial to include. Sidechain blocks cannot be reverted without reverting Bitcoin blocks or hard forking the protocol used to derive sidechain state. If protocol is forked, the value of sidechain coins on each fork of sidechain state becomes important but Proof of Burn natively guarantees trust minimized and permissionless distribution of the coins, something inferior methods like obscure early distributions, trusted pre-mines, and trusted ICO's cannot do. More bitcoins being burnt is parallel to more hash rate entering PoW, with each miner or burner getting smaller amount of altcoins on average making it unprofitable to burn or mine and forcing some to exit. At equilibrium costs of equipment and electricity approaches value gained from selling coins just as at equilibrium costs of burnt coins approaches value of altcoins rewarded. In both cases it incentivizes further distribution to markets to cover the costs making burners and miners dependent on users via markets. In both cases it's also possible to mine without permission and mine at a loss temporarily to gain some altcoins without permission if you want to. Altcoins benefit by inheriting many of bitcoin security guarantees, bitcoin parties have to do nothing if they don't want to, but will see their coins grow more scarce through burning. The contributions to the fee market will contribute to higher Bitcoin miner rewards even after block reward is gone.
What is the ideal goal of the sidechains? Ideally to have a token that has the bi-directionally pegged value to Bitcoin and tradeable ~1:1 for Bitcoin that gives Bitcoin users an option of a different rule set without compromising the base chain nor forcing base chain participants to do anything different. Issues with value pegs:
federation based pegs allow collusion to steal bitcoins stored in multi-party controlled accounts
even if multisig participants are switched or weighted in some trust minimized manner, there's always incentive to collude and steal more
smart contract pegs (plasma, rollups) on base chain would require bitcoin nodes and miners to validate sidechain transactions and has to provide block content for availability (e.g. call data in rollups), making them not optional.
bitcoin nodes shouldn't be sidechain aware so impossible to peg the value
Let's get rid of the idea of needing Bitcoin collateral to back pegged coins 1:1 as that's never secure, independent, or scalable at same security level. As drive-chain design suggested the peg doesn't have to be fast, can take months, just needs to exist so other methods can be used to speed it up like atomic swaps by volunteers taking on the risk for a fee. In continuous proof of burn we have another source of Bitcoins, the burnt Bitcoins. Sidechain protocols can require some minor percentage (e.g. 20%) of burner tx value coins via another output to go to reimburse those withdrawing side-Bitcoins to Bitcoin chain until they are filled. If withdrawal queue is empty that % is burnt instead. Selection of who receives reimbursement is deterministic per burner. Percentage must be kept small as it's assumed it's possible to get up to that much discount on altcoin emissions. Let's use a really simple example case where each burner pays 20% of burner tx amount to cover withdrawal in exact order requested with no attempts at other matching, capped at half amount requested per payout. Example:
withdrawal queue: request1: 0.2 sBTC request2: 1.0 sBTC request3: 0.5 sBTC same block burners: tx burns 0.8 BTC, 0.1 BTC is sent to request1, 0.1 BTC is sent to request2 tx burns 0.4 BTC, 0.1 BTC is sent to request1 tx burns 0.08 BTC, 0.02 BTC is sent to request 1 tx burns 1.2 BTC, 0.1 BTC is sent to request1, 0.2 BTC is sent to request2 withdrawal queue: request1: filled with 0.32 BTC instead of 0.2 sBTC, removed from queue request2: partially-filled with 0.3 BTC out of 1.0 sBTC, 0.7 BTC remaining for next queue request3: still 0.5 sBTC
Withdrawal requests can either take long time to get to filled due to cap per burn or get overfilled as seen in "request1" example, hard to predict. Overfilling is not a big deal since we're not dealing with a finite source. The risk a user that chooses to use the sidechain pegged coin takes on is based on the rate at which they can expect to get paid based on value of altcoin emission that generally matches Bitcoin burn rate. If sidechain loses interest and nobody is burning enough bitcoin, the funds might be lost so the scale of risk has to be measured. If Bitcoins burnt per day is 0.5 BTC total and you hope to deposit or withdraw 5000 BTC, it might take a long time or never happen to withdraw it. But for amounts comparable or under 0.5 BTC/day average burnt with 5 side-BTC on sidechain outstanding total the risks are more reasonable. Deposits onto the sidechain are far easier - by burning Bitcoin in a separate known unspendable deposit address for that sidechain and sidechain protocol issuing matching amount of side-Bitcoin. Withdrawn bitcoins are treated as burnt bitcoins for sake of dividing block rewards as long as they followed the deterministic rules for their burn to count as valid and percentage used for withdrawals is kept small to avoid approaching free altcoin emissions by paying for your own withdrawals and ensuring significant unforgeable losses. Ideally more matching is used so large withdrawals don't completely block everyone else and small withdrawals don't completely block large withdrawals. Better methods should deterministically randomize assigned withdrawals via previous Bitcoin block hash, prioritized by request time (earliest arrivals should get paid earlier), and amount of peg outstanding vs burn amount (smaller burns should prioritize smaller outstanding balances). Fee market on bitcoin discourages doing withdrawals of too small amounts and encourages batching by burners. The second method is less reliable but already known that uses over-collateralized loans that create a oracle-pegged token that can be pegged to the bitcoin value. It was already used by its inventors in 2014 on bitshares (e.g. bitCNY, bitUSD, bitBTC) and similarly by MakerDAO in 2018. The upside is a trust minimized distribution of CPoB coins can be used to distribute trust over selection of price feed oracles far better than pre-mined single trusted party based distributions used in MakerDAO (100% pre-mined) and to a bit lesser degree on bitshares (~50% mined, ~50% premined before dpos). The downside is 2 fold: first the supply of BTC pegged coin would depend on people opening an equivalent of a leveraged long position on the altcoin/BTC pair, which is hard to convince people to do as seen by very poor liquidity of bitBTC in the past. Second downside is oracles can still collude to mess with price feeds, and while their influence might be limited via capped price changes per unit time and might compromise their continuous revenue stream from fees, the leverage benefits might outweight the losses. The use of continous proof of burn to peg withdrawals is superior method as it is simply a minor byproduct of "mining" for altcoins and doesn't depend on traders positions. At the moment I'm not aware of any market-pegged coins on trust minimized platforms or implemented in trust minimized way (e.g. premined mkr on premined eth = 2 sets of trusted third parties each of which with full control over the design). _______________________________________
Brief issues with current altchains options:
PoW: New PoW altcoins suffer high risk of attacks. Additional PoW chains require high energy and capital costs to create permissionless entry and trust minimized miners that are forever dependent on markets to hold them accountable. Using same algorithm or equipment as another chain or merge-mining puts you at a disadvantage by allowing some miners to attack and still cover sunk costs on another chain. Using a different algorithm/equipment requires building up the value of sunk costs to protect against attacks with significant energy and capital costs. Drive-chains also require miners to allow it by having to be sidechain aware and thus incur additional costs on them and validating nodes if the sidechain rewards are of value and importance.
PoS: PoS is permissioned (requires permission from internal party to use network or contribute to consensus on permitted scale), allows perpetual control without accountability to others, and incentivizes centralization of control over time. Without continuous source of sunk costs there's no reason to give up control. By having consensus entirely dependent on internal state network, unlike PoW but like private databases, cannot guarantee independent permissionless entry and thus cannot claim trust minimization. Has no built in distribution methods so depends on safe start (snapshot of trust minimized distributions or PoW period) followed by losing that on switch to PoS or starting off dependent on a single trusted party such as case in all significant pre-mines and ICO's.
Proof of Capacity: PoC is just shifting costs further to capital over PoW to achieve same guarantees.
PoW/PoS: Still require additional PoW chain creation. Strong dependence on PoS can render PoW irrelevant and thus inherit the worst properties of both protocols.
Tokens inherit all trust dependencies of parent blockchain and thus depend on the above.
Embedded consensus (counterparty, veriblock?, omni): Lacks mechanism for distribution, requires all tx data to be inside scarce Bitcoin block space so high cost to users instead of compensated miners. If you want to build a very expressive scripting language, might very hard & expensive to fit into Bitcoin tx vs CPoBB external content of unlimited size in a committed hash. Same as CPoBB is Bitcoin-aware so can respond to Bitcoin being sent but without source of Bitcoins like burning no way to do any trust minimized Bitcoin-pegs it can control fully.
Few extra notes from my talks with people:
fees must be high to be included in next block (and helps pay and bribe bitcoin miners), RBF use is encouraged to cancel late transactions
what if not enough burners, just passive nodes? you can burn smallest amount of bitcoin yourself when you have a transaction you want to go through
using commit hashes on bitcoin to lock altcoin state isn't new (e.g. kmd) but usually those rely on some federation or permissioned proof of stake mechanism with no real costs. this is combination of both.
this is not exactly like counterparty's embedded consensus as block data and transactions are outside Bitcoin, but consensus is derived with help of embedded on Bitcoin data.
deterministic randomness (e.g. via that block's hash) could be used to assign winning sidechain block weighted by amount burned to allow occasional blocks formed by others curbing success rate of censorship by highest burner
wants to transition away from using proof of burn via tunable proofs and native proof of work (whitepaper)
a dominant premine (trust maximized) relative to emission that defeats the purpose of distributing control over incentives (figure 3 in tokenpaper suggests premine still ~30%-70% by year 2050)
variable emission rate "adaptive mint and burn" makes supply unpredictable (and possibly gameable)
additional rewards that aren't trust minimized like "app mining" and "user incentives" possibly gameable with premine
election of a leader includes their own PoW to be elected even at start (5% cap), why lol?
blockstack also suggested use of randomness that depends on that block so Bitcoin miners that already spent energy mining that block can't just re-do it to get picked at no cost
if can burn bitcoins directly via op_return tx would help to use 1 less output and be provably prunable for utxo set (not sure if that's relayed as standard)
Main questions to you:
why not? (other than blocktime)
can this be done without an altcoin? (Not sure and don't think so w/o compromising unforgeable costliness and thus trust minimization. At least it's not using an altcoin that's clearly centralized.)
how to make it less detectable by Bitcoin miners? ( BMM could use some techniques described here: https://twitter.com/SomsenRuben/status/1210040270328254464 ) ( Perhaps since sidechain nodes receive proposed blocks independently and can figure out their hash, the commit message ( sidechain id + block commit + miner address) can be hashed one more time before its placed on Bitcoin, making miners unaware until after Bitcoin block is found that this is that sidechain's burn. Sidechain block producers would have to delay sidechain block propagation until after Bitcoin block is propagated, 10 minutes blocktime helps here. Hiding the fact that Bitcoin is burnt until after the fact is another possibly important matter. )
Should reward be split between all valid blocks or just winner gets all? (Blockstacks approach does not reward blocks marked by different from leader chaintip. That seems dangerous since sidechain tx sorting would be difficult to match and could take significant time to be compensated for perfectly valid work and coins burned. It doesn't seem as necessary in burning since we're not expending costs based on only one previous block version, the costs are independent of block assembly. Tradeoff is between making it easier for independent "mining" of sidechain and making it easier to validate for full nodes on sidechain)
A better anti-reorg algorithm using first-seen times to punish secret/dishonest mining
Bitcoin currently allows a malicious miner with at least 51% of the network hashrate to arbitrarily rewrite blockchain history. This means that transactions are reversible if they belong to a miner with a hashrate majority, and such transactions are subject to double-spend attempts. Bitcoin SV's miners have repeatedly threatened to perform this attack against exchanges using BCH by mining a secret, hidden chain which they only publish after they have withdrawn funds in a different currency from the exchange. It would be nice if we could prevent these secret mining re-org attacks. Yesterday, I came up with a new algorithm for making secret re-org attacks very expensive and difficult to pull off. This new algorithm is designed to avoid the permanent chainsplit vulnerabilities of ABC 0.18.5 while being more effective at punishing malicious behavior. The key to the new algorithm is to punish exactly the behavior that indicates malice. First, publishing a block after another block at the same height has arrived on the network suggests malice or poor performance, and the likelihood of malice increases as the delay increases. A good algorithm would penalize blocks in proportion to how much later they were published after the competing block. Second, building upon a block that was intentionally delayed is also a sign of malice. Therefore, a good algorithm would discount the work done by blocks based not only on their own delays, but the delays that were seen earlier in that chain as well. Since the actions at the start of the fork are more culpable (as they generate the split), we want to weight those blocks more heavily than later blocks. I wrote up an algorithm that implements these features. When comparing two chains, you look at the PoW done since the fork block, and divide that PoW by a penalty score. The penalty score for each chain is calculated as the sum of the penalty scores for each block. Each block's penalty score is equal to the apparent time delay of that block relative to its sibling or cousin, divided by 120 seconds, and further divided by the square of that block's height from the fork. This algorithm has some desirable properties:
It provides smooth performance. There are no corners or sharp changes in its incentive structure or penalty curve.
It converges over very long time scales. Eventually, if one chain has more hashrate than the other and that is sustained indefinitely, the chain with the most hashrate will win by causing the chain penalty score for the slower (less-PoW) chain to grow.
The long-term convergence means that variation in observed times early in the fork will not cause permanent chainsplits.
Long-term convergence means that nodes can follow the standard most-PoW rule during initial block download and get the same results unless an attack is underway, in which case the node will only temporarily disagree.
Over intermediate time scales (e.g. hours to weeks), the penalty given to secret-mining deep-reorg chains is very large and difficult to overcome even with a significant hashrate advantage. The penalty increases the longer the attack chain is kept secret. This makes attack attempts ineffective unless they are published within about 20 minutes of the attack starting.
Single-block orphan race behavior is identical to existing behavior unless one of the blocks has a delay of at least 120 seconds, in which case that chain would require a total of 3 blocks to win (or more) instead of just 2.
As the algorithm strongly punishes hidden chains, finalization becomes much safer as long as you prevent finalization from happening while there are known competitive alternate chains. However, this algorithm is still effective without finalization.
I wrote up this algorithm into a Python sim yesterday and have been playing around with it since. It seems to perform quite well. For example, if the attacker has 1.5x as much hashrate as the defenders (who had 100% of the hashrate before the fork), mine in secret for 20 minutes before publishing, and if finalization is enabled after 10 blocks when there's at least a 2x score advantage, then the attacker gets an orphan rate of 49.3% on their blocks and is only able to cause a >= 10 block reorg in 5.2% of cases, and none of those happen blindly, as the opposing chain shows up when most transactions have about 2 confirmations. If the attacker waits 1 hour before publishing, the attack is even less effective: 94% of their blocks are orphaned, 95.6% of their attempts fail, 94.3% of the attacks end with defenders successfully finalizing, and only 0.6% of attack attempts result in a >= 10 block reorg. The code for my algorithm and simulator can be found on my antiReorgSim Github repository. If you guys have time, I'd appreciate some review and feedback. To run it:
git clone https://github.com/jtoomim/antiReorgSim.git cd antiReorgSim python reorgsim.py # use pypy if you have it, as it's 30x faster
Thanks! Special thanks to Jonald Fyookball and Mark Lundeberg for reviewing early versions of the code and the ideas. I believe Jonald is working on a Medium post based on some of these concepts. Keep an eye out for it. Edit: I'm working on an interactive HTML visualization using Dash/Python! Here's a screenshot from a preliminary version in which convergence (or attacker victory, if you prefer) happens after 88.4 hours. In this scenario, the attacker wins because of the rule in Note 5. Edit 2: An alpha website version of the simulator is up! The code is all server-side for the simulation, so it might get overloaded if too many people hit it at the same time, but it might be fine. Feel free to play around with it! Note 1: This time delay is calculated by finding the best competing chain's last block with less work than this one and the first block with more work than this one and interpolating the time-first-seen between the two. The time at which the block was fully downloaded and verified is used as time-first-seen, not the time at which the header was received nor the block header's timestamp. Note 2: An empirical constant, intended to be similar to worst-case block propagation times. Note 3: A semi-empirical constant; this balances the effect of early blocks against late blocks. The motivation for squaring is that late blocks gain an advantage for two multiplicative reasons: First, there are more late blocks than early blocks. Second, the time deltas for late blocks are larger. Both of these factors are linear versus time, so canceling them out can be done by dividing by height squared. This way, the first block has about as much weight as the next 4 blocks; the first two blocks have as much weight as the next 9 blocks; and the first (n) blocks have about as much weight as the next (n+1)2 blocks. Any early advantage can be overcome eventually by a hashrate majority, so over very long time scales (e.g. hours to weeks), this rule is equivalent to the simple Satoshi most-PoW rule, as long as the hashrate on each chain is constant. However, over intermediate time scales, the advantage to the first seen blocks is large enough that the hashrate will likely not remain constant, and hashrate will likely switch over to whichever chain has the best score and looks the most honest. Note 4: The calculation doesn't actually use height, as that would be vulnerable to DAA manipulation. Instead, the calculation uses pseudoheight, which uses the PoW done and the fork block's difficulty to calculate what the height would be if all blocks had the fork block's difficulty. Note 5: If one chain has less PoW than the other, the shorter chain's penalty is calculated as if enough blocks had been mined at the last minute to make them equal in PoW, but these fictional blocks do not contribute to the actual PoW of that chain.
A perspective from the Bitcoin Cash and Bitcoin Unlimited developer who discovered CVE-2018–17144. That is about the time that Matt Corallo wanted to shave off of block validation with his pull request in 2016 to Bitcoin Core. 600µs is a lot less than what is saved with more efficient block propagation, like XThin, Compact Blocks, or now Graphene over typical links, especially those that are of similar low-end quality in network speed like Raspberry Pis are in compute speed. An optimization that was not in the focus by Core until XThin from Bitcoin Unlimited came onto the scene and kicked the Core team into gear on this issue. Furthermore, 600 microseconds is an order of magnitude or more below the variance between node validation speeds from a Raspberry Pi to a more high-end miner node and thus wholly in the range that the network already deals with. This 600 microsecond optimization now resulted in CVE-2018–17144. Certainly the most catastrophic bug in recent years, and certainly one of the most catastrophic bugs in Bitcoin ever. This bug was initially suspected to potentially cause inflation, was reported because it led to reliable crashes and confirmed by closer analysis… to be actually allowing inflation! I have consistently and repeatedly criticized hubris and arrogance in the most prominent Core developers, and done so since 2013, when the bullshitting around the 1MB block size limit started. Here we have an optimization that talks about avoiding “duplicate” validation like validation is nothing to worry about, an afterthought in Bitcoin almost. And a change that is quickly found to be good in peer reviewed, ACKed in Core-speak, in a rubber-stamp-like manner by Core developers such as Gregory Maxwell. Developers which I fully respect for their intelligence and knowledge by the way, but still, well, dislike as much for their overblown egos and underhanded discussion style as well as having done all they can to handicap Bitcoin with the 1MB limit. I also have to be honest, this change creates an unavoidable element of suspicion in me. For anyone who knows what went down and what the code paths do, it is just unavoidable to have this thought here. I like to qualify that this is not what I assert nor think is happening, but definitely crosses my mind as a potentiality! Because what is better to destroy the value of Bitcoin in the public’s eye than a silent inflation bug? What is better than creating code paths that look harmless for themselves but combined with some other, seemingly harmless rework in other areas of the code, result in utter catastrophe? And it looks like CVE-2018–17144 would eventually have become exactly this. The only thing that saved Core is their effective client diversity between revisions and someone actually noticing that there is a problem. After two years of this bug sitting around idle and exploitable. Client diversity that has been much criticized on the Bitcoin Cash side of things, but it obviously shows its advantages now. Reading the title of the original PR: “Remove duplicatable duplicate-input check from CheckTransaction” , as well as the message therein: “Benchmark results indicate this saves about 0.5–0.7ms during CheckBlock.” almost reads like it could be a sick joke being played on us all now. I always feared that someone from the bankster circles, someone injected into the Bitcoin development circles with the sole goal of wreaking unsalvageable havoc, would do exactly what happened. Injecting a silent inflation bug. Because that is what would destroy one of the very core advantages that Bitcoin has over the current status quo. That of transparency and a verifiable money supply. And, even though as a Bitcoin/BCHer, I do not see true long term prospects in Bitcoin/BTC anymore, calling the whole foundation of crypto into question just like that would have been equally disastrous to “our” variant of Bitcoin. Now, again, I am definitely not saying this is the case with PR 9049 for sure. I actually think the explanation of a young, cocky Core developer, a new “master of the universe” wreaking havoc by sheer arrogance and hubris, is the more likely explanation. People in general, but I don’t even exclude myself here, tend to believe in the competence of others if they appear just self-assured enough. This is part of the problem with attitude and psychological dynamics in this space. It creates a dangerous aura of ‘these guys know what they are doing’. I myself have done some minor work on sensitive areas in the Bitcoin Unlimited implementation. And I am working on some more “consensus critical” code for BCH now (see below). And, yes, I sometimes do lose some sleep over what could go wrong. I know I make mistakes. I have done so. I will. We all do. But I have yet to see anything resembling an admission of being imperfect by the developer in question, or any other prominent Core developer for that matter. The folks in question know exactly who I mean. There must be more reasonable folks in Core, but they are rather silent. Much worse even: In the discussion on github that follows this PR, user freetrader (a well known anonymous but still respected member of the Bitcoin Cash community who helped to create the Bitcoin Cash initial fork) asks the very valid question: Which is answered in the, all-too-typical for Core, smug manner by Matt Corallo, notably the original author of the bug who has all reason to be a bit more careful and respectful: The bug was disclosed in an absolutely responsible manner. As even the full disclosure on bitcoincore.org’s own pages notices, it went to a set of trustworthy people by the person who found the bug and did so in an encrypted PGP message only. This leaves the question why Core recklessly endangered the security of Bitcoin Cash as well endangering the myriad of altcoins that are out there and still susceptible with this premature and hasty publication. The back references from altcoins merging the change trickling into PR #14247 are a glimpse into this process. Now, Matt talks about “running out of time” in the above reply. But what time is that exactly? If you think hard about this, this can only be a distrust in any of the informed parties that they’ll leak this secret prematurely and thus catch Bitcoin Core with their pants down, or as a worse assumption, be actually exploited by one of the informed parties against BTC. Bitcoin Unlimited was ferociously attacked, presumably by deranged BTC supporters from the wider ‘community’, when it had a bug. And it seems a bit like Core members assumed a payback by deranged BCH supporters in kind here (I am not doubting those supporters exist), given the hints in the original disclosure that this bug has actually been discovered by someone aligned with the Bitcoin Cash side of things. But not only that, Core seems to have assumed that members on the BCH side of things who have been informed are deranged or at least irresponsible enough to leak this info to the wrong parties! I like to applaud deadalnix and the ABC team for what I was thinking the Core team should have done here as well: Bury the fix in a bit more and unrelated refactoring code so as to fix it but also to buy some more time for an upgrade. Maybe Core wasn’t creative enough to see a way to hide the problem, but then they also had no reason to blare it out like they did here. This was very irresponsible, and, and this should reach any altcoin impacted by this, this is definitely solely Bitcoin Core’s responsibility. No one else said anything in public before Core published their PR. It should also be noted by the Core team that this creates a strong disincentive to keep them in the loop with initial disclosure for anyone finding a bug. Cory Fields has talked about the risks and dangers with regards to sitting on the knowledge of a 0-day on Bitcoin Cash, and this bug discussed herein is one that was worth at least 10x more in potential damage and thus also shorting value and angry deranged people (a.k.a. “31337 crypto trading bros”) capable of violence. If a party behaves this irresponsibly, it shouldn’t be surprised if it degrades itself to a lower position in the food chain with regards to vulnerability disclosures. I am not saying I won’t inform next time I might stumble upon something, but this is not a good way to create the necessary trust. The Discovery and Disclosure Sitting in my little van by the sea on Monday, I was working on getting the new CHECKDATASIG/-VERIFY opcodes that are about to activate for Bitcoin (Cash) in November implemented on the Bitcoin Unlimited client. I have been looking at a potentially neat use case for those and am motivated to get this done. Around noon, I noticed that there is a lot of divergence in the way that signature operations counting was done in ABC vs. how it was done in Bitcoin Unlimited (BU). I agreed earlier with the BU team that I would go and port most of the CDS/-V stuff over from ABC, but I felt overwhelmed. My thoughts were that: Ok, this is doable, but this needs a lot more analysis and also many more eyeballs for review. And will take a lot longer. Sigh. While doing so, I stumbled upon this comment in the ABC code base: Check for duplicate inputs — note that this check is slow so we skip it in CheckBlock My initial reaction was a slight “Eh, WTF is going on with that comment?”. And then I looked up uses of CheckRegularTransaction in ABC, which is the renamed variant of CheckTransaction in Core (but I didn’t know at that time). I dug through the code to try to understand the logic. I noticed that block validation skips this test as it is assumed to have already happen during mempool ingress. My next thought was a bit of a sinking feeling and a “Uh-oh, I really hope the folks from ABC have thought about the difference between the mempool and block transmission and that those are distinct ways into the system. There might be a problem here!”. And then I went and thought about a way to test this. I patched an ABC node to not relay transactions even when asked and connected one unpatched and one patched node together in -regtest mode and created a transaction with a duplicate input (which the above test was skipping). Wham! assert(), Aborted. Next thought was along the lines: “Oh fuck, this doesn’t look good, gotta notify deadalnix and the crew what is lurking in ABC, this doesn’t look good at all. [email protected]#%!!”. Being aware of the danger that this could maybe be further exploited towards an actual inflation and chain-splitting bug (but I didn’t further check the specifics of this, as a node crash bug with assert() failure was already enough to be worried about), I quickly and somewhat inaccurately noted to myself (and timestamped): BitcoinABC does not check for duplicate inputs when processing a block, only when inserting a transaction into the mempool. This is dangerous as blocks can be generated with duplicate transactions and then sent through e.g. compact block missing transactions and avoid hitting the mempool, creating money out of thin air. awemany [Footnote: I timestamped this message in the BU slack, adding an innocuous situational lie of ‘Ooops, wrong channel’ to it. I also tried timestamping my findings on on my usual go-to site originstamp.org but they only submit timestamps every 24h due to the fees on Bitcoin being too high to do more often… I guess I should maybe get into the habit of doing timestamping transactions myself..] Opening up a disclosure email to deadalnix, I started to have a thought of: “Ok, actually, where is this stuff coming from, when and where did they introduce it into the code, might we be lucky and this is not in a release yet?” And then I noticed that this stuff was coming from Core. Already having written a disclosure report, I rechecked whether Core was vulnerable as well. And, once again: Wham! assert(), Aborted. I started to get shivers up my spine. Uh oh! Core has a crash bug, potentially worse. Stuff in the code since 2016. NOT good. NOT good at all. I like to say here that I actually had a feeling of this is bad, not this is good because of Core vs. Cash or something like that. I (unfortunately) still own a (for my poor soul significant) amount of BTC and for that reason and others do not like having bugs in Core either. Being a responsible citizen in this space, I then wrote the encrypted disclosure email to Wladimir, sickpig and some others, attaching a variant of the ABC and the Core patch to exploit this problem to my disclosure. I also put in a BCH address for a bounty payment to myself into that email (disclosed as proof below), as I feel this should be something worth a little performance bonus 🙂 No money has been received at the time of this writing yet. If you want to change this, you can send me BCH here: bitcoincash:qr5yuq3q40u7mxwqz6xvamkfj8tg45wyus7fhqzug5 (1NBKDco2EctDXvBv6r4hqJRPWfgX9jFpqs) I chose the handle beardnboobies as this is the first thing that came into my mind when I thought about this very discovery here. I thought: Ok, I am slowly becoming a pale nerd working on just code, with beard and manboobies. Oh well. I have noticed that this handle was — for whatever reason- taken out of the release notes that are checked into the main development branch of Bitcoin Core and is only available in the release branch / tag, being replaced with anonymous contributor on the main branch. I wonder: Do you Core guys feel this is too unprofessional to have this pseudonym appear in the main branch? Have some humor please! 🙂 By the way, a plea: I urge everyone in BCH as well as BTC (as well as impacted altcoins), to take a fine-toothed comb through the code with the goal of looking for similar issues! More specifically, I faintly remember (though might be wrong) from discussions back with Core devs on reddit in 2016 and before, that the idea that there’s a lot of “duplicate validation” between mempool and block validation was kind of en vogue back then. Potentially more code is vulnerable because it assumes that mempool validation can stand in for block validation. I suspect more, though maybe not as grave bugs, in this area. Reactions After I submitted it, I felt relief and then I started to watch the space from the back. A weird situation. Only then I also fully realized what Core contributor Cory Fields described with a bit of a different angle and on a smaller scale, the weirdness of having found a bug that you know is worth millions at least, massively impacting a $100 billion currency. The fact that I could have gone and rented hash power and shorted BTC and exploited this. But also the fact that I did not! Wladimir eventually wrote me an email that they’re preparing releases (and at that time or around it they published the PR), so I responded expressing my astonishment of the quite public handling of this serious issue. What I was amazed by in general was the long time it took for the bug to blow up to its full proportions, with the process seemingly even not over now. One thing is certainly others digging into this and realizing the full severity of this — as it turns out, yes it CAN be used to double-spend and inflate on BTC after all! — but also the time it takes from the initial PR being public, seemingly not noticed at all and the first media article being written. And then I noticed the usual spin. The “stupid BCashers can’t code and are irresponsible and what not” angle that is all too often repeated then by seemingly cerebrally insufficient Core supporters. I quote the below to gloat maybe. But also to show the world WHAT kind of bullshit the Bitcoin Cash side of things is facing here in a constant barrage. This is just from a few of the more prominent Core supporters and devs. There is, of course, a lot more folks foaming “btrash, bcash” at the mouth on reddit and twitter. Tone Vays and Jimmy Song Here we have Tone Vays, who likes to pose with the undercurrent of violence by wielding weapons on Twitter and apparently also on Youtube, discussing this bug with Jimmy Song in an unwillingly hilarious Youtube video: Luke-Jr I like to say some words about this tweet of Luke-Jr, committing the sin of bearing false witness about us irresponsible “BCashers”… I suspect Luke-Jr has been left in the dark about the background of this disclosure as well, not belonging to the innermost circles either. Careful observers might have noticed even more of this dynamic happening with other people. And note again: I have done everything that is necessary to make this a responsible disclosure. The initial, unobfuscated public disclosure happened by Bitcoin Core on their github! This is exactly the opposite situation compared to what Luke-Jr is describing. This is despicable. From:Luke-Jr Closing remarks Apart from pointing out the insane spin of some Core supporters in the preceding part, I simply want to take the opportunity now to urge caution for everyone here. Bugs lurk everywhere. Everyone is imperfect. Myself included, of course. I started to like Jihan Wu’s credo of “Don’t play hatred, don’t wish competing coins ill. Just wish and try to make BCH better” (from twitter) and see BCH and BTC in fierce but still civil competition. Civil competition obviously meaning no violence, including no violence like attacking each other’s nodes. I like to reiterate that, despite the gloating and strong words you might find in this article, I did everything to play fair. I also agree in general with Cory Fields from Core that it is not very easy to find the necessary disclosure addresses and information. He’s right about the lack of easily accessible GPG keys both on the BCH as well as — I like to add- on the BTC side of things. I didn’t find a non-retracted key of Pieter Wuille in time. I also like to note that a few things went finally completely out of the window here with this bug, for example Core’s idea of ‘the code being law’. If the code is law, does that mean that you have to accept inflation now? Or is it actually the Core devs steering the ship? Is an element of reasonableness entering the space? And yes, I sincerely believe, despite the current price ratio that BCH has a much brighter future than BTC, by being fundamentalist on the principles that matter and came along with the original white paper while not being fundamental on things that were created post-hoc — like the 1MB (now 4MW) limit in the Bitcoin Core implementation. As I also don’t think extended inflation is crucial for BTC’s operation. But anyone is free to buy or sell as they want. Let’s continue competing. Let’s civilly inform each other of bugs. May the best chain win. Finally, I like to thank Andrea Suisani, Andrew Stone and Peter Rizun for their review of this article and valuable input.
List of reasons why CTOR (pushed by Bitmain ABC) is bad
For those who don't know, CTOR is one of many possible artificial sorting methods that could be imposed on a set of transactions within a block. Any sorting algorithm is naturally slower than the act of constructing an unsorted list. Let that sink in for a while. That said, here is the list of reasons why I personally think CTOR has no place in the protocol of Bitcoin Cash.
CTOR makes block validation slower and is thus an anti-scaling solution. Making it a consensus rule puts every node under additional stress as they are forced to verify if the TXs are sorted correctly.
CTOR violates against the KISS principle, burdening the economic consensus protocol with unnecessary requirements to have a controversial shortcut in the node implementation (symptom of lazy programming).
With CTOR, valuable information about the causality of TXs goes lost forever. It is an attempt to erase part of the block chain and thus part of the history (which is the natural order of transactions).
CTOR enables Sybil attacks on miners go undetected and thus it makes 0-conf TXs less safe to accept. On the other hand, with natural/causal/FIFO ordering it is possible to easily detect if a particular miner is poorly connected to the network and could be under the Sybil attack.
CTOR is being advertised as a fix for something that is not broken in the first place --- the block propagation. During the stress test we saw how the network easily coped with 21 MB blocks. If the authors of CTOR were competent software engineers they would know the good old saying "If it's not broken, don't fix it!"
When using the natural ordering, the order of TXs in a block will increasingly differ between two independent miners as one of the miners becomes poorly connected to the network. A miner connected poorly to the network is more likely to fall a victim to a Sybil attack (if they already haven't). If we could detect this condition as early as possible it is possible to preemptively orphan discrepant blocks and thus thwart the double-spend attacks. A more safe and reliable network makes Bitcoin Cash more useful and thus increases its adoption. As a result, the price of BCH increases and miners will earn more. Thus, it is in the best interest of miners to cooperate and together provide better service to the users. CTOR is a step away from this direction and should be rejected.
An attempt at a fully comprehensive look at how to scale bitcoin. Lets bring Bitcoin out of Beta!
WARNING THIS IS GOING TO BE A REALLY REALLY LONG POST BUT PLEASE READ IT ALL. SCALING BITCOIN IS A COMPLEX ISSUE! HOPEFULLY HAVING ALL THE INFO IN ONE PLACE SHOULD BE USEFUL
Like many people in the community I've spent the past month or so looking deeply into the bitcoin scaling debate. I feel there has never been a fully comprehensive thread on how bitcoin could scale. The closest I have seen is gavinandresen's medium posts back in the summer describing the problem and a solution, and pre-emptively answering supposed problems with the solution. While these posts got to the core of the issue and spawned the debate we have been having, they were quite general and could have used more data in support. This is my research and proposal to scale bitcoin and bring the community back together.
There seems to me to be five main fundamental forces at play in finding a balanced solution;
Node Distribution Bandwidth has a relationship to node count and therefore 'node distribution'. This is because if bandwidth becomes too high then fewer people will be able to run a node. To a lesser extent bandwidth also effects 'mining decentralisation' as miners/pool owners also need to be able to run a node. I would argue that the centralisation pressures in relation to bandwidth are negligible though in comparison to the centralisation pressure caused by the usefulness of larger pools in reducing variance. The cost of a faster internet connection is negligible in comparison to the turnover of the pools. It is important to note the distinction between bandwidth required to propagate blocks quickly and the bandwidth required to propagate transactions. The bandwidth required to simply propagate transactions is still low today. New node time (i.e. the time it takes to start up a new node) also has a relationship with node distribution. i.e. If it takes too long to start a new node then fewer people will be willing to take the time and resources to start a new node. Storage Space also has a relationship with node distribution. If the blockchain takes up too much space on a computer then less people will be willing to store the whole blockchain. Any suitable solution should look to not decrease node distribution significantly. Mining Decentralisation Broadcast time (the time it takes to upload a block to a peer) has a relationship with mining centralisation pressures. This is because increasing broadcast time increases the propagation time, which increases the orphan rate. If the orphan rate it too high then individual miners will tend towards larger pools. Validation time (the time it to validate a block) has a relationship with mining centralisation pressures. This is because increasing validation time increases the propagation time, which increases the orphan rate. If the orphan rate it too high then individual miners will tend towards larger pools. Any suitable solution should look to not increase mining centralisation significantly. Network Utility Network Utility is one that I find is often overlooked, is not well understood but is equally as important. The network utility force acts as a kind of disclaimer to the other two forces. It has a balancing effect. Increasing the network utility will likely increase user adoption (The more useful something is, the more people will want to use it) and therefore decreasing network utility will likely decrease user adoption. User adoption has a relationship with node count. i.e. the more people, companies and organisations know about and use bitcoin, the more people, companies and organisations that will run nodes. For example we could reduce block size down to 10KB, which would reduce broadcast time and validation time significantly. This would also therefore reduce mining centralisation pressures significantly. What is very important to realise though is that network utility would also be significantly be reduced (fewer people able to use bitcoin) and therefore so would node distribution. Conversely, if we increased the block size (not the limit) right now to 10GB, the network utility would be very high as bitcoin would be able to process a large number of transactions but node distribution would be low and mining centralisation pressures would be high due to the larger resource requirements. Any suitable solution should look to increase network utility as time increases. Time Time is an important force because of how technology improves over time. Technology improves over time in a semi-predicable fashion (often exponential). As we move through time, the cost of resources required to run the bitcoin network (if the resource requirements remained static) will decrease. This means that we are able to increase resource requirements proportional to technological improvements/cost reductions without any increase in costs to the network. Technological improvements are not perfectly predictable though so it could be advantageous to allow some buffer room for when technological improvements do not keep up with predictions. This buffer should not be applied at the expense of the balance between the other forces though (i.e. make the buffer too big and network utility will be significantly decreased).
Adoption Increasing adoption means more people using the bitcoin/blockchain network. The more people use bitcoin the more utility it has, and the more utility Bitcoin has the more people will want to use it (network effect). The more people use bitcoin, the more people there that have an incentive to protect bitcoin. Any suitable solution should look to increase adoption as time increases.
The Solution Proposed by some of the bitcoin developers - The Lightning Network
The Lightning Network (LN) is an attempt at scaling the number of transactions that can happen between parties by not publishing any transaction onto the blockchain unless it is absolutely necessary. This is achieved by having people pool bitcoin together in a "Channel" and then these people can transact instantly within that channel. If any shenanigans happen between any of the parties, the channel can be closed and the transactions will be settled on the blockchain. The second part of their plan is limit the block size to turn bitcoin into a settlement network. The original block size limit of 1MB was originally put in place by Satoshi as an anti-DOS measure. It was to make sure a bad actor could not propagate a very large block that would crash nodes and increase the size of the blockchain unnecessarily. Certain developers now want to use this 1MB limit in a different way to make sure that resource requirements will stay low, block space always remains full, fees increase significantly and people use the lightning network as their main way of transacting rather than the blockchain. They also say that keeping the resource requirements very low will make sure that bitcoin remains decentralised. Problems with The Lightning Network The LN works relatively well (in theory) when the cost and time to publish a set of transactions to the network are kept low. Unfortunately, when the cost and time to publish a set of transactions on the blockchain become high, the LN's utility is diminished. The trust you get from a transaction on the LN comes only from the trustless nature of having transactions published to the bitcoin network. What this means is that if a transaction cannot be published on the bitcoin network then the LN transaction is not secured at all. As transactions fees rise on the bitcoin blockchain the LN utility is diminished. Lets take an example:
Cost of publishing a transaction to the bitcoin network = $20
LN transaction between Bob and Alice = $20.
Transaction between Bob and Alice has problem therefore we want to publish it to the blockchain.
Amount of funds left after transaction is published to the blockchain = $20 - $20 = $0.
This is also not a binary situation. If for example in this scenario, the cost to publish the transaction to blockchain was $10 then still only 50% of the transaction would be secure. It is unlikely anyone really call this a secure transaction. Will a user make a non-secured/poorly secured transaction on the LN when they could make the same transaction via an altcoin or non-cryptocurrency transaction and have it well secured? It's unlikely. What is much more likely to happen is that transaction that are not secured by bitcoin because of the cost to publish to the blockchain will simply overflow into altcoins or will simply not happen on any cryptocurrency network. The reality is though, that we don't know exactly what will happen because there is no precedent for it. Another problem outside of security is convenience. With a highly oversaturated block space (very large backlog of transactions) it could take months to have a transaction published to the blockchain. During this time your funds will simply be stuck. If you want to buy a coffee with a shop you don't have a channel open with, instead of simply paying with bitcoin directly, you would have to wait months to open a channel by publishing a transaction to the bitcoin blockchain. I think your coffee might be a little cold by then (and mouldy). I suggest reading this excellent post HERE for other rather significant problems with the LN when people are forced to use it. The LN is currently not complete and due to its high complexity it will take some time to have industry wide implementation. If it is implemented on top of a bitcoin-as-a-settlement-network economy it will likely have very little utility. Uses of The LN The LN is actually an extremely useful layer-2 technology when it is used with it's strengths. When the bitcoin blockchain is fast and cheap to transact on, the LN is also extremely useful. One of the major uses for the LN is for trust-based transactions. If you are transacting often between a set of parties you can truly trust then using LN makes absolute sense since the trustless model of bitcoin is not necessary. Then once you require your funds to be unlocked again it will only take a short time and small cost to open them up to the full bitcoin network again. Another excellent use of LN would be for layer-3 apps. For example a casino app: Anyone can by into the casino channel and play using real bitcoins instantly in the knowledge that is anything nefarious happens you can instantly settle and unlock your funds. Another example would be a computer game where you can use real bitcoin in game, the only difference is that you connect to the game's LN channel and can transact instantly and cheaply. Then whenever you want to unlock your funds you can settle on the blockchain and use your bitcoins normally again. LN is hugely more powerful, the more powerful bitcoin is. The people making the LN need to stick with its strengths rather than sell it as an all-in-one solution to bitcoin's scaling problem. It is just one piece of the puzzle.
Improving Network Efficiency
The more efficient the network, the more we can do with what we already have. There are a number of possible efficiency improvements to the network and each of them has a slightly different effect. Pruning Pruning allows the stored blockchain size to be reduced significantly by not storing old data. This has the effect of lowering the resource requirements of running a node. a 40GB unpruned blockchain would be reduced in size to 550MB. (It is important to note that a pruned node has lower utility to the network) Thin Blocks Thin blocks uses the fact that most of the nodes in the network already have a list of almost all the same transactions ready to be put into the blockchain before a block is found. If all nodes use the same/similar policy for which transactions to include in a block then you only need to broadcast a small amount of information across the network for all nodes to know which transactions have been included (as opposed to broadcasting a list of all transactions included in the block). Thin Blocks have the advantage of reducing propagation which lowers the mining centralisation pressure due to orphaned blocks. libsecp256k1libsecp256k1 allows a more efficient way of validating transactions. This means that propagation time is reduced which lowers the mining centralisation pressure due to orphaned blocks. It also means reduced time to bootstrap the blockchain for a new node. Serialised Broadcast Currently block transmission to peers happens in parallel to all connected peers. Obviously for block propagation this is a poor choice in comparison to serial transmission to each peer one by one. Using parallel transmission means that the more peers you have, the slower the propagation, whereas serial transmission does not suffer this problem. The problem that serial transmission does suffer from though is variance. If the order that you send blocks to peers in is random, then it means sometimes you will send blocks to a peer who has a slow/fast connection and/or is able to validate slowly/quickly. This would mean the average propagation time would increase with serialised transmission but depending on your luck you would sometimes have faster propagation and sometimes have slower propagation. As this will lower propagation time it will also lower the mining centralisation pressure due to orphaned blocks. (This is just a concept at the moment but I don't see why it couldn't be implemented). Serialised Broadcast Sorting This is a fix for the variance that would occur due to serialised broadcast. This sorts the order that you broadcast a block to each peer into; fastest upload + validation speed first and slowest upload speed and validation speed last. This not only decreases the variance to zero but also allows blocks to propagation to happen much faster. This also has the effect of lowering the mining centralisation pressure due to orphaned blocks. (This is just a concept at the moment but I don't see why it couldn't be implemented). Here is a table below that shows roughly what the effects these solutions should have.
New Node Time
(The "multiplier" shows how many times higher the block size could be relative to the specific function.)
The Factors in Finding a Balanced Solution
At the beginning of this post I detailed a relatively simple framework for finding a solution by describing what the problem is. There seems to me to be five main fundamental forces at play in finding a balanced solution; 'node distribution', 'mining decentralisation', 'network utility', 'time' and 'adoption'. The optimal solution needs to find a balance between all of these forces taking into account a buffer to offset our inability to predict the future with absolute accuracy. To find a suitable buffer we need to assign a set of red line values which certain values should not pass if we want to make sure bitcoin continues to function as well as today (at a minimum). For example, percentage of orphans should stay below a certain value. These values can only be a best estimate due to the complexity of bitcoin economics, although I have tried to provide as sound reasoning as possible. Propagation time It seems a fair limit for this would be roughly what we have now. Bitcoin is still functioning now. Could mining be more decentralised? Yes, of course, but it seems bitcoin is working fine right now and therefore our currently propagation time for blocks is a fairly conservative limit to set. Currently 1MB blocks take around 15 seconds to propagate more than 50% of the network. 15 second propagation time is what I will be using as a limit in the solution to create a buffer. Orphan Rate This is obviously a value that is a function of propagation time so the same reasoning should be used. I will use a 3% limit on orphan rate in the solution to create a buffer. Non-Pruned Node Storage Cost For this I am choosing a limit of $200 in the near-term and $600 in the long-term. I have chosen these values based on what I think is a reasonable (maximum) for a business or enthusiast to pay to run a full node. As the number of transactions increases as more people use bitcoin the number of people willing to pay a higher price to run a node will also increase although the percentage of people will decrease. These are of course best guess values as there is no way of knowing exactly what percentage of users are willing to pay what. Pruned Node Storage Cost For this I am choosing a limit of $3 in the near-term (next 5 years) and $9 in the long-term (Next 25 years). I have chosen these values based on what I think is a reasonable (maximum) for normal bitcoin user to pay. In fact this cost will more likely be zero as almost all users have an amount of storage free on their computers. Percentage of Downstream Bandwidth Used This is a best guess at what I think people who run nodes would be willing to use to be connected to the bitcoin network directly. I believe using 10% (maximum) of a users downstream bandwidth is the limit of what is reasonable for a full node (pruned and non-pruned). Most users would continue to access the blockchain via SPV wallets though. Downstream is generally a much more valuable resource to a user than upstream due to the nature of the internet usage. Percentage of Upstream Bandwidth Used This is a best guess at what I think people who run nodes would be willing to use to be connected to the bitcoin network directly. I believe using 25% (maximum) of a users downstream bandwidth is the limit of what is reasonable for a full node (pruned and non-pruned). Most users would continue to access the blockchain via SPV wallets though. Upstream is generally a much less valuable resource to a user than downstream due to the nature of the internet usage. Time to Bootstrap a New Node My limit for this value is at 5 days using 50% of downstream bandwidth in the near-term and 30 days in the long-term. This seems like a reasonable number to me for someone who wants to start running a full node. Currently opening a new bank account takes at least week until everything is set up and you have received your cards, so it seems to me people would be willing to wait this long to become connected. Again, this is a best guess on what people would be willing to do to access the blockchain in the future. Most users requiring less security will be able to use an SPV wallet. It is important to note that we only need enough nodes to make sure the blockchain is distributed across many places with many backups of the full blockchain. It is likely that a few thousand is a minimum for this. Increasing this amount to hundreds of thousands or millions of full nodes is not necessarily that much of an advantage to node distribution but could be a significant disadvantage to mining centralisation. This is because the more nodes you have in the network, the longer it takes to propagate >50% of it. Storage Cost Price Reduction Over Time Storage cost follows a linear logarithmic trend. Costs of HDD reducing by 10 times every 5 years, although this has slowed over the past few years. This can be attributed to the flooding in South East Asia and the transition to SSD technology. SSD technology also follows the linear logarithmic trend of costs reducing 10 times every 5 years, or roughly decreasing 37% per year. Average Upload and Download Bandwidth Increases Over Time Average upload and download bandwidth increases in a linear logarithmic trend. Both upload and download bandwidth follow the same trend of doubling roughly every two years, or increasing 40% per year. Price I was hesitant to include this one here but I feel it is unavoidable. Contrary to what people say (often when the price is trending downwards) bitcoin price is an extremely important metric in the long-term. Depending on bitcoin's price, bitcoin's is useful to; enthusiasts->some users->small companies->large companies->nations->the world, in roughly that order. The higher bitcoin's price is the more liquid the market will be and the more difficult it will be to move the price, therefore increasing bitcoin's utility. Bitcoin's price in the long-term is linked to adoption, which seems to happen in waves, as can be seen in the price bubbles over the years. If we are planning/aiming for bitcoin to at least become a currency with equal value to one of the worlds major currencies then we need to plan for a market cap and price that reflect that. I personally think there are two useful targets we should use to reflect our aims. The first, lower target is for bitcoin to have a market cap the size of a major national currency. This would put the market cap at around 2.1 trillion dollars or $100,000 per bitcoin. The second higher target is for bitcoin to become the world's major reserve currency. This would give bitcoin a market cap of around 21 trillion dollars and a value of $1,000,000 per bitcoin. A final, and much more difficult target is likely to be bitcoin as the only currency across the world, but I am not sure exactly how this could work so for now I don't think this is worth considering.
As price increases, so does the subsidy reward given out to miners who find blocks. This reward is semi-dynamic in that it remains static (in btc terms) until 210,000 blocks are found and then the subsidy is then cut in half. This continues to happen until all 21,000,000 bitcoins have been mined. If the value of each bitcoin increases faster than the btc denominated subsidy decreases then the USD denominated reward will be averagely increasing. Historically the bitcoin price has increased significantly faster than subsidy decreases. The btc denominated subsidy halves roughly every 4 years but the price of bitcoin has historically increased roughly 50 fold in the same time.
Bitcoin adoption should happen in a roughly s-curve dynamic like every other technology adoption. This means exponential adoption until the market saturation starts and adoption slows, then the finally is the market becomes fully saturated and adoption slowly stops (i.e. bitcoin is fully adopted). If we assume the top of this adoption s-curve has one of the market caps above (i.e. bitcoin is successful) then we can use this assumption to see how we can transition from a subsidy paid network to a transaction fee paid network. Adoption Adoption is the most difficult metric to determine. In fact it is impossible to determine accurately now, let alone in the future. It is also the one of the most important factors. There is no point in building software that no one is going to use after all. Equally, there is no point in achieving a large amount of adoption if bitcoin offers none of the original value propositions. Clearly there is a balance to be had. Some amount of bitcoin's original value proposition is worth losing in favour of adoption, and some amount of adoption is worth losing to keep bitcoin's original value proposition. A suitable solution should find a good balance between the two. It is clear though that any solution must have increased adoption as a basic requirement, otherwise it is not a solution at all.
One major factor related to adoption that I rarely see mentioned, is stability and predictability. This is relevant to both end users and businesses. End users rely on stability and predictability so that they do not have to constantly check if something has changed. When a person goes to get money from a cash machine or spend money in a shop, their experience is almost identical every single time. It is highly dependable. They don't need to keep up-to-date on how cash machines or shops work to make sure they are not defrauded. They know exactly what is going to happen without having to expend any effort. The more deviation from the standard experience a user experiences and the more often a user experiences a deviation, the less likely a user is going to want to continue to use that service. Users require predictability extending into the past. Businesses who's bottom line is often dependent on reliable services also require stability and predictability. Businesses require predictability that extends into the future so that they can plan. A business is less likely to use a service for which they do not know they can depend on in the future (or they know they cannot depend on). For bitcoin to achieve mass adoption it needs a long-term predictable and stable plan for people to rely on.
This proposal is one based on determining a best fit balance of every factor and a large enough buffer to allows for our inability to perfectly predict the future. No one can predict the future with absolutely certainty but it does not mean we cannot make educated guesses and plan for it.
The first part of the proposal is to spend 2016 implementing all available efficiency improvements (i.e the ones detailed above) and making sure the move to a scaled bitcoin happens as smoothly as possible. It seems we should set a target of implementing all of the above improvements within the first 6 months of 2016. These improvements should be implemented in the first hardfork of its kind, with full community wide consensus. A hardfork with this much consensus is the perfect time to test and learn from the hardforking mechanism. Thanks to Seg Wit, this would give us an effective 2 fold capacity increase and set us on our path to scalability.
The second part of the proposal is to target the release of a second hardfork to happen at the end of 2016. Inline with all the above factors this would start with a real block size limit increase to 2MB (effectively increasing the throughput to 4x compared to today thanks to Seg Wit) and a doubling of the block size limit every two years thereafter (with linear scaling in between). The scaling would end with an 8GB block size limit in the year 2039.
How does the Proposal fit inside the Limits
Propagation time If trends for average upload and bandwidth continue then propagation time for a block to reach >50% of the nodes in the network should never go above 1s. This is significantly quickly than propagation times we currently see. In a worst case scenario we can we wrong in the negative direction (i.e. bandwidth does not increase as quickly as predicted) by 15% absolute and 37.5% relative (i.e. bandwidth improves at a rate of 25% per year rather than the predicted 40%) and we would still only ever see propagation times similar to today and it would take 20 years before this would happen. Orphan Rate Using our best guess predictions the orphan rate would never go over 0.2%. In a worst case scenario where we are wrong in our bandwidth prediction in the negative direction by 37.5% relative, orphan rate would never go above 2.3% and it would take over 20 years to happen. Non-Pruned Node Storage Cost Using our best guess predictions the cost of storage for a non-pruned full node would never exceed $40 with blocks consistently 50% full and would in fact decrease significantly after reaching the peak cost. If blocks were consistently 100% full (which is highly unlikely) then the maximum cost of an un-pruned full node would never exceed $90. In a worst case scenario where we are wrong in our bandwidth prediction in the negative direction by 37.5% relative and we are wrong in our storage cost prediction by 20% relative (storage cost decreases in cost by 25% per year instead of the predicted 37% per year), we would see a max cost to run a node with 50% full blocks of $100 by 2022 and $300 by 2039. If blocks are always 100% full then this max cost rises to $230 by 2022 and $650 in 2039. It is important to note that for storage costs to be as high as this, bitcoin will have to be enormously successful, meaning many many more people will be incentivised to run a full node (businesses etc.) Pruned Node Storage Cost Using our best guess predictions the cost of storage for a pruned full node would never exceed $0.60 with blocks consistently 50% full. If blocks were consistently 100% full (which is highly unlikely) then the max cost of an un-pruned full node would never exceed $1.30. In a worst case scenario where we are wrong in our bandwidth prediction in the negative direction by 37.5% relative and we are wrong in our storage cost prediction by 20% relative (storage cost decreases in cost by 25% per year instead of the predicted 37% per year), we would see a max cost to run a node with 50% full blocks of $1.40 by 2022 and $5 by 2039. If blocks are always 100% full then this max cost rises to $3.20 by 2022 and $10 in 2039. It is important to note that at this amount of storage the cost would be effectively zero since users almost always have a large amount of free storage space on computers they already own. Percentage of Downstream Bandwidth Used Using our best guess predictions running a full node will never use more than 0.3% of a users download bandwidth (on average). In a worst case scenario we can we wrong in the negative direction by 37.5% relative in our bandwidth predictions and we would still only ever see a max download bandwidth use of 4% (average). Percentage of Upstream Bandwidth Used Using our best guess predictions running a full node will never use more than 1.6% of a users download bandwidth (on average). In a worst case scenario we can we wrong in the negative direction by 37.5% relative in our bandwidth predictions and we would only ever see a max download bandwidth use of 24% (average) and this would take over 20 years to occur. Time to Bootstrap a New Node Using our best guess predictions bootstrapping a new node onto the network should never take more than just over a day using 50% bandwidth. In a worst case scenario we can we wrong in the negative direction by 37.5% relative in our bandwidth predictions and it would take one and 1/4 days to bootstrap the blockchain using 50% of the download bandwidth. By 2039 it would take 16 days to bootstrap the entire blockchain when using 50% bandwidth. I think it is important to note that by this point it is very possible the bootstrapping the blockchain could very well be done by simply buying an SSD with blockchain already bootstrapped. 16 days would be a lot of time to download software but it does not necessarily mean a decrease in centralisation. As you will see in the next section, if bitcoin has reached this level of adoption, there may well be many parties will to spend 16 days downloading the blockchain. What if Things Turn Out Worse than the Worse Case? While it is likely that future trends in the technology required to scale bitcoin will continue relatively similar to the past, it is possible that the predictions are completely and utterly wrong. This plan takes this into account though by making sure the buffer is large enough to give us time to adjust our course. Even if no technological/cost improvements (near zero likelihood) are made to bandwidth and storage in the future this proposal still gives us years to adjust course.
What Does This Mean for Bitcoin?
Significantly Increased Adoption For comparison, Paypal handles around 285 transactions per second (tps), VISA handles around 2000tps and the total global non-cash transactions are around 12,400tps. Currently bitcoin is capable of handling a maximum of around 3.5 transactions every second which are published to the blockchain roughly every 10 minutes. With Seg Wit implemented via a hardfork, bitcoin will be capable or around 7tps. With this proposal bitcoin will be capable of handling more transactions than Paypal (assuming Paypal experiences growth of around 7% per year) in the year 2027. Bitcoin will overtake VISA's transaction capability by the year 2035 and at the end of the growth cycle in 2039 it will be able to handle close to 50% of the total global non-cash transactions. When you add on top second layer protocols( like the LN), sidechains, altcoins and off-chain transactions, there should be more than enough capacity for the whole world and every possible conceivable use for digital value transfer. Transitioning from a Subsidy to a Transaction Fee Model Currently mining is mostly incentivised by the subsidy that is given by the network (currently 25btc per block). If bitcoin is to widely successful it is likely that price increases will continue to outweigh btc denominated subsidy decreases for some time. This means that currently it is likely to be impossible to try to force the network into matching a significant portion of the subsidy with fees. The amount of fees being paid to miners has averagely increased over time and look like they will continue to do so. It is likely that the optimal time for fees to start seriously replacing the subsidy is when bitcoin adoption starts to slow. Unless you take a pessimistic view of bitcoin (thinking bitcoin is as big as it ever will be), it is reasonable to assume this will not happen for some time. With this proposal, using an average fee of just $0.05, total transaction fees per day would be:
Year 2020 = $90,720
Year 2025 = $483,840.00
Year 2030 = $2,903,040.00
Year 2035 = $15,482,880.00
Year 2041 = $123,863,040.00 (full 8GB Blocks)
Miners currently earn a total of around $2 million dollars per day in revenue, significantly less than the $124 million dollars in transaction fee revenue possible using this proposal. That also doesn't include the subsidy which would still play some role until the year 2140. This transaction fee revenue would be a yearly revenue of $45 billion for miners when transaction fees are only $0.05 on average.
Proposal Data You can use these two spreadsheets (1 - 2 ) to see the various metrics at play over time. The first spreadsheet shows the data using the predicted trends and the second spreadsheet shows the data with the worst case trends.
It's very clear we are on the edge/midst of a community (and possibly a network) split. This is a very dangerous situation for bitcoin. A huge divide has appeared in the community and opinions are becoming more and more entrenched on both sides. If we cannot come together and find a way forward it will be bad for everyone except bitcoin's competition and enemies. While this proposal is born from an attempt at finding a balance based on as many relevant factors as possible, it also fortunately happens to fall in between the two sides of the debate. Hopefully the community can see this proposal as a way of making a compromise, releasing the entrenchment and finding a way forward to scale bitcoin. I have no doubt that if we can do this, bitcoin will have enormous success in the years to come.
Technology improvements and their effects on the forces at play and the scalability of bitcoin.
This is a post about the potential technologies that can/are being done to bitcoin and their effects on how we can scale bitcoin.
Pruning Pruning allows the stored blockchain size to be reduced significantly by not storing old data. This has the effect of lowering the resource requirements of running a node. a 40GB unpruned blockchain would be reduced in size to 550MB. (It is important to note that a pruned node has lower utility to the network)
Thin Blocks Thin blocks uses the fact that most of the nodes in the network already have a list of almost all the same transactions ready to be put into the blockchain before a block is found. If all nodes use the same/similar policy for which transactions to include in a block then you only need to broadcast a small amount of information across the network for all nodes to know which transactions have been included (as opposed to broadcasting a list of all transactions included in the block). Thin Blocks have the advantage of reducing propagation which lowers the mining centralisation pressure due to orphaned blocks.
libsecp256k1 This allows a more efficient way of validating transactions. This means that propagation time is reduced which lowers the mining centralisation pressure due to orphaned blocks.
Serialised Broadcast Currently block transmission to peers happens in parallel to all connected peers. Obviously for block propagation this is a poor choice in comparison to serial transmission to each peer one by one. Using parallel transmission means that the more peers you have, the slower the propagation, whereas serial transmission does not suffer this problem. The problem that serial transmission does suffer from though is variance. If the order that you send blocks to peers in is random, then it means sometimes you will send blocks to a peer who has a slow/fast connection and/or is able to validate slowly/quickly. This would mean the average propagation time would increase with serialised transmission but depending on your luck you would sometimes have faster propagation and sometimes have slower propagation. As this will lower propagation time it will also lower the mining centralisation pressure due to orphaned blocks. (This is just a concept at the moment but I don't see why it couldn't be implemented).
Know-Your-Neighbour (Serialised broadcast sorting) This is a fix for the variance that would occur due to serialised broadcast. This sorts the order that you broadcast a block to each peer into; fastest upload + validation speed first and slowest upload speed and validation speed last. This not only decreases the variance to zero but also allows blocks to propagation to happen much faster. This also has the effect of lowering the mining centralisation pressure due to orphaned blocks. (This is just a concept at the moment but I don't see why it couldn't be implemented).
Here is a table below that shows roughly what the effects these solutions should have.
New Node Time
The "multiplier" shows how many times higher the block size could be relative to the specific function. e.g. if all of these solution are applied, you could increase blocks to 10 times their current size without bandwidth increasing beyond current levels. There seems to me to be four main fundamental forces at play; 'node distribution', 'mining decentralisation', 'network utility' and 'time'. Node Distribution Bandwidth has a relationship to node count and therefore 'node distribution'. This is because if bandwidth becomes too high then fewer people will be able to run a node. To a lesser extent bandwidth also effects 'mining decentralisation' as miners/pool owners also need to be able to run a node. I would argue that the centralisation pressures in relation to bandwidth are negligible though in comparison to the centralisation pressure caused by the usefulness of larger pools in reducing variance. The cost of a faster internet connection is negligible in comparison to the turnover of the pools. It is important to note the distinction between bandwidth required to propagate blocks quickly and the bandwidth required to propagate transactions. The bandwidth required to simply propagate transactions is still low today. New node time (i.e. the time it takes to start up a new node) also has a relationship with node distribution. i.e. If it takes too long to start a new node then fewer people will be willing to take the time and resources to start a new node. Storage Space also has a relationship with node distribution. If the blockchain takes up too much space on a computer then less people will be willing to store the whole blockchain. Mining Decentralisation Broadcast time (the time it takes to upload a block to a peer) has a relationship with mining centralisation pressures. This is because increasing broadcast time increases the propagation time, which increases the orphan rate. If the orphan rate it too high then individual miners will tend towards larger pools. Validation time (the time it to validate a block) has a relationship with mining centralisation pressures. This is because increasing validation time increases the propagation time, which increases the orphan rate. If the orphan rate it too high then individual miners will tend towards larger pools. Network Utility Network Utility is one that I find is often overlooked, is not well understood but is equally as important. The network utility force acts as a kind of disclaimer to the other two forces. It has a balancing effect. Increasing the network utility will likely increase user adoption (The more useful something is, the more people will want to use it) and therefore decreasing network utility will likely decrease user adoption. User adoption has a relationship with node count. i.e. the more people, companies and organisations know about and use bitcoin, the more people, companies and organisations that will run nodes. For example we could reduce block size down to 10KB, which would reduce broadcast time and validation time significantly. This would also therefore reduce mining centralisation pressures significantly. What is very important to realise though is that network utility would also be significantly be reduced (fewer people able to use bitcoin) and therefore so would node distribution. Conversely, if we increased the block size (not the limit) right now to 1GB, the network utility would be very high as bitcoin would be able to process a large number of transactions but node distribution would be low and mining centralisation pressures would be high due to the larger resource requirements. Time Time is an important force because of how technology improves over time. Technology improves over time in a semi-predicable fashion. As we move through time, the cost of resources required to run the bitcoin network(if the resource requirements remained static) will decrease. This means that we are able to increase resource requirements proportional to technological improvements/cost reductions without any increase in costs to the network. Technological improvements are not perfectly predictable though so it could be advantageous to allow some buffer room for when technological improvements do not keep up with predictions. This buffer should not be applied at the expense of the balance between the other forces though (i.e. make the buffer too big and network utility will be significantly decreased). We need to find a good balance between these four forces in bitcoin. I will soon make another post about a proposal that should keep all of these three forces balanced in a way that scales bitcoin on the blockchain and also still provides and incentives for off-chain, sidechain and second layer solutions. If we as a community can com together and find a solution to scale bitcoin, we have a real chance of changing the world. (if anyone feels I have made any mistakes or am missing anything, please let me know. I don't have knowledge of exactly how much of a speed boost to bootstrapping a new node using Seg Wit creates. I'd appreciate if someone could help me out there.). EDIT 1: Updated to a more accurate model of bandwidth when thin blocks are used. Edit 2: A relevant detail.
PSA: If you are running Bitcoin Core and you are not forwarding port 8333 (peering only 8 connections) then younare not running a full node.
To quote Gavin Andresen:
Most ordinary folks should NOT be running a full node. We need full nodes that are always on, have more than 8 connections (if you have only 8 then you are part of the problem, not part of the solution), and have a high-bandwidth connection to the Internet. So: if you've got an extra virtual machine with enough memory in a data center, then yes, please, run a full node.
Edit: according to nullc and pwuille, by running Bitcoin Core (or XT) you help reinforce the rules of the network by verifying transactions even if you do not help network propagation as you would if you opened the ports. So you do add value to the network (and specifically yourself because trustless). Also, it is probably poor advice to abdicate control of your node to a data center.
I sent 0.1415164 BTC (£ 34.72) from my Blockchain.info wallet at 2014-11-14 21:53:00 and it hasn't confirmed? That's a day and a half. Confirmations - Unconfirmed Transaction! Double Spend - No Double Spend Detected Transaction Fee - 0.0001 BTC Network Propagation - 0% (Very Poor) https://blockchain.info/tx/33806135bcd3b1720abf21b2dfa66b479a0b7cb0c95228f9fa459d7403290a85 Any ideas? I have contacted blockchain.info and Bittrex and they said what I thought they would, wait on the blockchain and the Bitcoin network to catch up. Over 36 hours is a bit of joke though.
Shutting down or restricting the uses of bank accounts, thereby forbidding clients to buy crypto, is a blatant affront to the rights of civil liberty, manifested, but not limited to, in the rights to private property and free speech (562 points, 262 comments)
I believe Bitcoin Core/Blockstream is now attempting to infiltrate Bitcoin Cash in the same manner that they did with Bitcoin Segwit. They are suddenly befriending Bitcoin Cash. Only in that way can they destroy from within. Do not be fooled. (401 points, 166 comments)
You have $100 worth of BTC. So you purchase an item for $66, but have to pay a $17 fee. Now you have $17 worth of Bitcoin left, but it costs $17 more to move it. So $66 item effectively cost you $100. #Thanks BlockStream (1420 points, 433 comments)
2025 points: kairepaire's comment in As of today, Steam will no longer support Bitcoin as a payment method
2018 points: vbuterin's comment in "So no worries, Ethereum's long term value is still ~0." -Greg Maxwell, CTO of Blockstream and opponent of allowing Bitcoin to scale as Satoshi had planned.
1215 points: vbuterin's comment in Vitalik Buterin tried to develop Ethereum on top of Bitcoin, but was stalled because the developers made it hard to build on top of Bitcoin. Vitalik only then built Ethereum as a separate currency
1211 points: LiamGaughan's comment in As of today, Steam will no longer support Bitcoin as a payment method
Modeling the Impact of Network Connectivity on Consensus Security of Proof-of-Work Blockchain Yang Xiao , The security impact of information propagation dynamics in Bitcoin was studied quantitatively at the macro level in . It heterogeneous network connectivity leads to poor con-sensus security. that the Bitcoin network has poor anonymity properties, and the community’s shift from trickle spreading (pre-2015) We then analyze the performance of trickle propagation in Section 3. In Section 4, we analyze the performance of the Bitcoin network used a gossip-like trickle broadcasting D and E actually speed up propagation even if the connection is weak. Without sharing the bandwidth burden, weak connections could slow down propagation. In some papers it is asserted that the bitcoin network is as robust as its weakest node. Different waves of block dissemination in the proposed blockchain network. A fork occurs when node n 0 starts to propagate its block (b ) while the block from n 0 (b) is not fully disseminated. In this paper, we investigate the performance of block propagation in a Bitcoin-like peer-to-peer distribution network, and highlight the impact of the Nakamoto consensus protocol on the dynamics
Cryptocurrency Networking with Soumya Basu - YouTube
This is part 21 of the Blockchain tutorial explaining what a peer-to-peer network is and what propagation and latency means. These words are often used in the Blockchain ecosystem and for non ... If all Bitcoin transactions were confidential and used Bulletproofs, then the total size of the blockchain would be only 17 GB, compared to 160 GB with the currently used proofs. We also show that on-path network attackers can considerably slow down block propagation by interfering with few key Bitcoin messages. We demonstrate the feasibility of each attack against the ... Our mission is to have blockchain reaching every household in Ghana, Nigeria and beyond Africa - Visit our website www.eBitcoinics.com, Join us, and let's pu... Visit our website https://softwaredaily.com Soumya Basu is a PhD student at Cornell, where he studies distributed systems problems associated with cryptocurr...