Skip to content

Instantly share code, notes, and snippets.

Last active December 22, 2017 11:32
Show Gist options
  • Save shelby3/c786018a8bb2d8d837abce3a4cf4e799 to your computer and use it in GitHub Desktop.
Save shelby3/c786018a8bb2d8d837abce3a4cf4e799 to your computer and use it in GitHub Desktop.
5.4 Synchronous

5.4 Synchronous

PoW’s lack of concurrent (aka asynchronous) partial orders as elaborated in the sub-section Aliasing, doesn’t directly negate resiliency and liveness, because every mining node is eligible to produce the next block. But the resiliency and liveness provided by the availability of a diverse (in geography, performance, policies, cost structure, etc) plurality of miners competing to produce the next block is always diminishing as explained in the sub-section Censorship.

There is no asynchronous (i.e. concurrency of) transaction ordering for scaling transaction volume throughput. Only the mining node (possibly a pool) that produces the next block may add transactions during the block period, and all transactions must be propagated to every node. The transaction throughput can theoretically be increased by increasing the block size, although this creates other scaling limitations such as O(n²) propagation to, and validation load on, all nodes― even those with low hashrate and profitability.

5.4.1 Segregated Witness

Segregated Witness (aka “SegWit”) enables light (or partially validating) nodes to trust the full nodes, so as to eliminate their need to propagate and validate transaction signatures. This enables a short-lived reprieve from the scalepocalyse cliff with a one-time increase in transaction volume forsaking optimally diversified decentralized security due to the absolute trust placed in the highest economy-of-scale full nodes. Worse is that decentralized scaling remains implausible at O(n²). SegWit could only scale by continual increases in centralization because the only mathematical way that O(n²) scales is by quadratically reducing the number of full nodes n. Contrary to popular misconception[54] (or intentional deception?[55]), periodic block size increases have nothing to do with why O(n²) doesn’t scale. The proponents erroneously claim PoW offers the choice between small blocks with permissionless, decentralized miners where only the privileged few can participate in transactions, or the gargantuan blocks with centralized miners (limited to tycoons, tai-pans, and gazillionaires) where everyone can participate in transactions but we all must trust and obtain permission from a privileged few overlords.[56] [57] The former case doesn't exist due to variance in mining blocks[19] and economies-of-scale in mining due to specialization. The latter was the status quo political economics dilemma[3] [4] which PoW was created to eliminate.

It appears that block size increases will only come as necessary to maximize profits for what the centralized full nodes on their private networks can scale to; thus the cartel for the monopoly on transaction fees appears to already exist as a thinly veiled Sybil attack. SegWit is also ostensibly the “Trojan horse” for enabling Blockstream (Bitcoin Core) to more easily make any changes they want to scripting with a change to only requiring a versioned softfork instead of the status quo hardfork requirement.[58] Vitalik Buterin explained the distinction between decentralized and distributed with a humorous definition:[39]

Decentralization, n. The security assumption that a nineteen year old in Hangzhou and someone who is maybe in the UK, and maybe not, have not yet decided to collude with each other.

5.4.2 Lightning Networks

Lightning Networks (aka “LN”) is being proposed as a solution for scaling asynchronous transaction volumes, but it is technically implausible to do so without centralization (which seems to fit the vested interests?[50]) because:

  • Popular nodes will become more popular “suffering a massive network effect”.[55] [59]
  • Routing does not scale in LN unless “a significant number of nodes remain continuously online”.[60]
  • Routing will give less reliable results unless routing through stable nodes[61] which coordinate dynamic changes in real-time.[62]
  • Settling back to the blockchain must be coordinated else chaos can result.[63]
  • Which seem to suggest technical constraints, economic incentives, and game theory, which is another power vacuum that is either a winner-take-all centralization or creative destruction chaos.[59]

Compared to the design proposed in this paper, LN appears to be an extreme case of “when the high heel shoe fits, don’t wear it to play basketball”, i.e. trying to force fit an incorrect, non-optimal asynchronous design to the ill conceived design limitations of the protocols of the synchronous one.


[3]: Eric S. Raymond, Some Iron Laws of Political Economics. Armed and Dangerous blog, May 27, 2009.

[4]: Paul Sztorc. Nothing is Cheaper than Proof of Work. blog, §Money and Politics, Aug 4, 2015.

[19]: Meni Rosenfeld. Analysis of Bitcoin Pooled Mining Reward Systems. Dec 21, 2011.

[39]: Vitalik Buterin. On Mining. blog, §ASICs and §ASIC Resistance, Jun 19, 2014.

[54]: Jacob Donnelly. Segregated Witness: The Right Answer to the Wrong Question. Bitcoin Magazine, §Segregated Witness Should Hard Fork, Dec 28, 2015.

[55]: dconroy. The Blockstream Business Plan. blog, Aug 2015.

[56]: Joseph Poon, Thaddeus Dryja. Bitcoin failure modes and the role of the Lightning Network. Scaling Bitcoin Montreal conference Day 2 morning session, Sept 13, 2015.

[57]: Alex Berg. The artificial block size limit. Medium blog, Nov 22, 2016.

[58]: Segregated Witness Benefits. Bitcoin Core, §Script versioning, Jan 26, 2016.

[59]: Jameson Lopp. Lightning’s Balancing Act: Challenges Face Bitcoin’s Scalability Savior. Coindesk, §Macro complexities, Feb 28, 2016.

[60]: Pavel Prihodko, Slava Zhigulin, Mykola Sahno, Aleksei Ostrovskiy. Flare: An Approach to Routing in Lightning Network. BitFury Group. §6 Discussion, Jul 7, 2016. Coindesk summary.

[61]: Alyssa Hertig. What's Left Before Bitcoin's Lightning Network Goes Live. Coindesk, §Future Unknowns, Nov 12, 2016.

[62]: Pavel Prihodko, Slava Zhigulin, Mykola Sahno, Aleksei Ostrovskiy. Flare: An Approach to Routing in Lightning Network. BitFury Group. §2.2 Routing Algorithms Solving Similar Problems: Hybrid Protocols, §3 Proposed Hybrid Routing Algorithm, pp. 9–10, Jul 7, 2016.

[63]: Kyle Torpey. Here’s How Bitcoin's Lightning Network Could Fail. Bitcoin Magazine, Jul 5, 2016.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment