Thomas Voegtlin: Blocksize, Bitcoin Unlimited, ASICBoost and Activating SegWit (Episode 179)

Support the show, consider donating:
BTC: 1KgnEbgUAtpmBBNKGhR7JroJBoMvEpJ5GZ ( )
ETH: 0x8cdb49ca5103Ce06717C4daBBFD4857183f50935 ( )

Years into the great Bitcoin scaling debate no solution is in reach. Neither bigger blocks nor Segregated Witness have anywhere near consensus support. With the conflict escalating, a Bitcoin fork has become a real possibility.

Electrum Developer Thomas Voegtlin joined us to discuss the state of the Bitcoin scaling debate. We discussed Bitcoin Unlimited, ASICBoost, SegWit activation without miner support and how a Bitcoin fork could play out. Possible outcomes include that Bitcoin Unlimited gains a majority of hashing power and starts mining bigger blocks. In the event of a fork, a proof-of-work change could be done to defend the minority chain from miner attacks. And lately a proposal was brought forward to activate SegWit without the support of the hashing power.

Topics discussed in this episode:
– ASICBoost and its potential role in the conflict
– How a Bitcoin fork could happen
– How to split coins in case of a fork
– How UASF could be used to activate SegWit without miner support
– Requirements for UASF to be safe
– How Electrum would handle a fork

Links mentioned in this episode:
– Electrum Bitcoin Wallet:
– ASICBoost – Hacker Noon:
– Bitcoin's New Controversy: The AsicBoost Allegations Explained – CoinDesk:
– Timo Hanke on ASICBoost and SegWit Non-Activation:
– From AsicBoost to UASF: Greg Maxwell on Bitcoin's Path Forward – CoinDesk:
– [bitcoin-dev] Thomas Voegtlin: Soft Fork Threshold Signaling Proposal:
– UASF Working Group:
– [bitcoin-dev] Greg Maxwell: I do not support the BIP 148 UASF:
– Thomas Voegtlin: Electrum, SPV Wallets And Bitcoin Aliases — Epicenter:

– Jaxx: Wallets that Unify the Blockchain Experience Across Devices –

This episode is also available on :
– YouTube:
– Souncloud:

Watch or listen, Epicenter is available wherever you get your podcasts.

Epicenter is hosted by Brian Fabian Crain, Sébastien Couture & Meher Roy.

15 Comments on Thomas Voegtlin: Blocksize, Bitcoin Unlimited, ASICBoost and Activating SegWit (Episode 179)

  1. 7 minutes in, a bunch of assertions are made, not even some back to the envelope calculation to show that numbers are realistic.

  2. Brian and Sebastien, I’m so disappointed in you guys for failing to address scaling options in a factual and non-biased manner. The whole Bitcoin community counts on guys like you to stay off of political band-wagons and present important issues in a well-rounded fashion. I get the SegWit argument, but it does not justify artificial limitations on block size, nor is it helpful to imply incompatibility between Lightning and options like Unlimited. On-chain transactions are extremely important for applications well beyond payment. Seeing this debate as purely about payment systems is MISSING THE POINT. Please respect the potential of the world’s strongest public blockchain and re-visit these issues from a broader and more informed perspective. Thanks.

    • sanisidrocr What are some important applications of Lightning Network and what might Bitcoin “look like” should it adopt LN?

    • Dan Lindy This interview did seem to lean towards SegWit support, though I did find that Dan and Sebastien did ask some insightful questions in an effort to understand why actors on both sides of the debate have taken their positions. Furthermore, I think it’s important to observe that this was an interview, not a debate, with only one subject. If you want to listen to Epicenter cover the bigger block side, then you might want to watch the Epicenter episode where Dan and Sebastien interview Andrew Stone and Andrew Clifford from BU.

    • LN will allow bitcoin to scale with secure instant confirmations , instead of slow confirmations or insecure 0conf txs. It will allow machine to machine and micropayments as well. Current functioning versions of LN allow 20k TPS per channel and the first stage of routing will allow several thousand channels, thus millions of TPS (transactions per second) to start.

    • Who will likely create these channels and why? Don’t channels require the creator to lock a certain amount of bitcoin for the lifetime of the channel? Doesn’t this represent a kind of loan while the coins are reserved in the channel?

  3. There is no good justification to limit the blocks to 1 MB every 10 minutes.

    If we all started accepting 16 MB blocks, we could still easily run full nodes validating all the blocks and all the transactions on a 1 Megabit connection. The global average is about 6.3 Megabit/s .
    With 16 MB every 10 minutes, the blockchain grows a maximum of about 850 GB per year. This is easily within the reach of hard drive space available to ordinary people now, and then we’re not even counting the steadily increasing capacity of hard drives and the dropping price per GB.

    • Lightning network is certainly not as secure as bitcoin transactions with confirmations. When your coins are locked in a lightning channel, you always have a risk of never getting them back. When you’ve received coins in a bitcoin transaction with confirmations, you have your coins, and nobody can prevent you from having them anymore. Please explain why you think lightning network transactions are as secure?

    • Its not either or , wallets are being designed so that LN or regular Txs are in both , and the wallet GUI defaults to whatever is available.

    • >When your coins are locked in a lightning channel, you always have a risk of never getting them back.

      This is false. Please explain how in detail you cannot get your coins back.

      >When you’ve received coins in a bitcoin transaction with confirmations, you have your coins, and nobody can prevent you from having them anymore.

      This is also false. Chain reorgs.

    • “about 850 GB per year. This is easily within the reach of hard drive space available to ordinary people now” – actually, that is asking for quite alot from users, almost like dedicating an entire machine to just be a full node so that you can trustlessly use bitcoin. Also, imagine a blockchain size of over 2TB – how is a new user supposed to download that much data when so many ISP’s currently impose monthly data limits of 1TB?? It just wouldn’t work. With SegWit alone, we are probably going to have to deal with growth of 100GB per year, and I don’t think it is safe to push it further than that in the short term.

  4. I’m trying to listen with a neutral perspective here but I can’t understand Brian’s point of view, which presumably is for on-chain scaling. I see many reasons outlined by proficient bitcoin developers as to why increasing the block size is not the ideal next step in scaling, and to me they make sense. One of the main reasons being a reduction in centralisation as running a full node becomes unfeasible for everyday users. Not to mention other more technical effects on centralisation with regards to the network effects on block propagation and geographical location.

    I don’t pretend to know/understand the inner workings of the code base, but I have taken the time to read up on how segwit works and I think this debate could be settled by simply understanding the answer to this question: why not implement Segwit? I can understand why miners may fear losses from transaction fees moving to other layers, or other economic incentives like asicboost being removed, but what I can’t understand is why an apparent observer, and a technically adept one at that, like Brian is not in support of segwit? Why would someone like Brian, a regular user, not support segwit? I’d like to hear him out. Maybe there’s some information I’m missing?

    It would seem if you follow the economic incentives of each group, the answers to these questions are very clear, hence the gridlock.

  5. At 4:50 you say “theres no argument, that big blocks do cause decentralization”, as if this is an accepted fact. I used to think this was a good reason to keep blocks small.. but in fact it is not a plausible argument, because blocks are much much smaller on the network, and the propagation latency is tiny compared to the block solve time :

    The “bigblocks = centralization” argument goes like this “big blocks take longer to send to peers, so peers who are closer on the network get a time head-start advantage in mining the next block, which concentrates mining in one place.. not a good thing”. I would agree.. except that isn’t what happens, because since compact blocks feature, bitcoin sends the hashes of the transactions, not the whole transaction bodies, because the peers already have the transactions in their mempool. Blocks sent over the network are around 30k for 1MB blocks today, will be around 60k for 2MB blocks. So the difference in time to send a block is very small compared to the 10min average block mining time, an order of 1/2000 advantage – so this contributes very little to decentralization, other economic factors are far more significant, such as cheap electricity, cool weather in certain geographic areas like iceland and china etc.

    Likewise, small blocks are not needed to prevent spam attacks – if you charge spammers a small fee, it will cost them a fortune to spam the network – its just not cost effective.

    After looking into these arguments, I don’t think there is any plausible/rational economic or engineering reason to keep the blocksize small – the only reason could be if you want fees high for some other reason. To my mind, Bitcoin is meant to be used as Cash by everyman – it should not be turned into something only the 1%ers can afford to use, with hundred dollar transaction fees.

Comments are closed.