Live data from Hacker News

An analysis of Bitcoin's throughput bottlenecks

github.com

31–40 of 234 posts

Re: An analysis of Bitcoin's throughput bottlenecks

#32
post #23

its a pity bitcoin devs are so opposed to changing the protocol. So much research has been done showing the feasibility of increasing bitcoins throughput. Xthinner for instance is capable of compressing bitcoin blocks by up to 99% using bloom filters [1]. Much of this research was conducted on the bitcoin fork, bitcoin cash, by people ostracized from the bitcoin community for wanting to explore these ideas. [1] https…

The lower transaction throuput,the higher the fees, the higher the incentive for the miners to process transactions.

They probably don't want to mess with that dynamic too harshly.

Re: An analysis of Bitcoin's throughput bottlenecks

#33

Here is the real world, Bitcoin is currently running a blazing 3.3 transactions per second. Etherium dwarfs that at a mighty 14 transactions per second. Meanwhile, PayPal crawls along with a pathetic 488 tps. https://www.statista.com/statistics/730838/number-of-daily-c... https://www.businessofapps.com/data/paypal-statistics/

Those are on-chain transactions. Coinbase and many other wallets now support offline, or 'Instant Sends' which is more akin to the simple database update that PayPal/Visa performs.

Sure those aren't purely decentralized but a decentralized settlement layer is probably where most of the value is anyway.

Re: An analysis of Bitcoin's throughput bottlenecks

#34

Here is the real world, Bitcoin is currently running a blazing 3.3 transactions per second. Etherium dwarfs that at a mighty 14 transactions per second. Meanwhile, PayPal crawls along with a pathetic 488 tps. https://www.statista.com/statistics/730838/number-of-daily-c... https://www.businessofapps.com/data/paypal-statistics/

Seriously? Bitcoin that has intentionally low transaction throuput is only two orders of magnitude slower than largest online payment processor that was designed with highest possible throuput in mind?

VisaNet will do 76,000 tps - 4 orders of magnitude.

Re: An analysis of Bitcoin's throughput bottlenecks

#35

Here is the real world, Bitcoin is currently running a blazing 3.3 transactions per second. Etherium dwarfs that at a mighty 14 transactions per second. Meanwhile, PayPal crawls along with a pathetic 488 tps. https://www.statista.com/statistics/730838/number-of-daily-c... https://www.businessofapps.com/data/paypal-statistics/

check IOTA if you want to learn (if you have not) about DAG structure that potentially solves decentralized scalability. GOSSIP protocol

Re: An analysis of Bitcoin's throughput bottlenecks

#36
post #21

Earlier quoted context omitted.

Yeah that's how all centralized crypto exchanges do it

What if there's a run on the exchange?

they suddenly have a 'technical issue' and suspend trading until it is 'fixed.' sometimes its never fixed and the exchange founder mysteriously disappears to Thailand or dies, or claims to start an orphanage in india. sometimes all three.

Re: An analysis of Bitcoin's throughput bottlenecks

#37

Here is the real world, Bitcoin is currently running a blazing 3.3 transactions per second. Etherium dwarfs that at a mighty 14 transactions per second. Meanwhile, PayPal crawls along with a pathetic 488 tps. https://www.statista.com/statistics/730838/number-of-daily-c... https://www.businessofapps.com/data/paypal-statistics/

has anyone ever done the modeling on the dynamic limits of decentralized network consensus? my intuition has always been that getting, say, 100,000 globally distributed voting nodes to agree on even a simple truth value will quickly run into exponential (or worse) latency bottlenecks by way of metcalfe's law. the speed of light, as a hard limit, starts to become insurmountable when your consensus pathway has to be tr…

Bitcoin's Proof of Work algorithm has linear scaling. Basically 100,000 nodes all trying to build consensus using Nakamoto PoW can do it in O(100,000) messages. The scaling factor on the number of miners is not what is a bottleneck here.

The main bottleneck for cryptocurrencies is that every single node has to validate every single transaction. So your global throughput is effectively limited to what a single node can process.

Technologies like STARKs can improve these bottlenecks without introducing new trust layers or trust assumptions but still carry data availability requirements which once again require every node to have all the data, even if they don't have to actually process all the data.

There are additional techniques you can use to minimize the data availability impact but then you start introducing trust assumptions again.

It's a tricky problem and there's a good reason none of the major chains have adopted a solution, but it's not as dire as your post suggests, nor does your post highlight any of the fundamental issues at play.

Re: An analysis of Bitcoin's throughput bottlenecks

#38

Here is the real world, Bitcoin is currently running a blazing 3.3 transactions per second. Etherium dwarfs that at a mighty 14 transactions per second. Meanwhile, PayPal crawls along with a pathetic 488 tps. https://www.statista.com/statistics/730838/number-of-daily-c... https://www.businessofapps.com/data/paypal-statistics/

Those are on-chain transactions. Coinbase and many other wallets now support offline, or 'Instant Sends' which is more akin to the simple database update that PayPal/Visa performs. Sure those aren't purely decentralized but a decentralized settlement layer is probably where most of the value is anyway.

>a decentralized settlement layer is probably where most of the value is anyway.

Why?

Re: An analysis of Bitcoin's throughput bottlenecks

#39
post #31

Bitcoin dominance is fading this year only because it has bet on LN with fundamental inbound capacity problem. LN rejected my proposal to solve it and extend channels with credit lines: XLN https://medium.com/fairlayer/xln-extended-lightning-network-...

Payment channels ARE credit, generally - I'm sorry this proposal was rejected. Was there a reason for the rejection?

Re: An analysis of Bitcoin's throughput bottlenecks

#40
post #23

its a pity bitcoin devs are so opposed to changing the protocol. So much research has been done showing the feasibility of increasing bitcoins throughput. Xthinner for instance is capable of compressing bitcoin blocks by up to 99% using bloom filters [1]. Much of this research was conducted on the bitcoin fork, bitcoin cash, by people ostracized from the bitcoin community for wanting to explore these ideas. [1] https…

The lower transaction throuput,the higher the fees, the higher the incentive for the miners to process transactions. They probably don't want to mess with that dynamic too harshly.

this was the debate circa 2014/2015. Should the bitcoin network consist of many low fee transactions or few high fee transactions. Right now the incentive for miners to secure the network is produced with the block reward, but when the block reward runs out this incentive will be from fees alone. In order to provide miners with the same revenue as today when the block reward runs out, the average fee per tx will need to be close to $200. If you increase the block size to 100mb and use block compression tech like xthinner to make blocks essentially 1mb (like today), then the average fee needed is only $2.
Post reply on HN