Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An analysis of Bitcoin's throughput bottlenecks

github.com

Post reply on HN
Print view View original

121–130 of 234 posts

Re: An analysis of Bitcoin's throughput bottlenecks

#121

Post by billytetrud »

CyberDildonics wrote: post #99
wyager wrote: post #90

Earlier quoted context omitted.

> It has been in development for 7 years. Good. They need to get it right. > Why use this complicated hack solution It’s complicated but not a hack at all. It makes perfect sense. > when anyone can just use a different cryptocurrency and not have these problems in the first place? There are 0 (zero) cryptocurrencies that scale better than Bitcoin that don’t also compromise on security or decentralization. Lightning i…

There is at least monero, bitcoin cash and ethereum. Bitcoin Cash and Ethereum both have more transactions than bitcoin already. Ethereum has four times the transaction throughput. Bitcoin Cash has 32x the max block size. There is no technical reason bitcoin could not increase their max block size, but then there would be no reason for their hacky second layer to exist. The only way what you are saying makes sense is…

> There is no technical reason bitcoin could not increase their max block size

You should read the paper this thread is about. It tells you tons of technical reasons that it would be a bad idea to increase the max block size very much if at all.

Re: An analysis of Bitcoin's throughput bottlenecks

#122

Post by vmception »

billytetrud wrote: post #115
vmception wrote: post #106

Earlier quoted context omitted.

Ethereum has 8 distinct active layer 2 technologies including things analogous to lightning network, as they are permissionless to build and deploy there. Turns out nobody likes watchtowers which lightning style solutions require, the market is not choosing that Bitcoin does not represent choice, it represents throwing all eggs in one basket and defending that with no competition (lightning). More like a state capita…

> Bitcoin does not represent choice Why not? Anyone can use bitcoin for anything they want. And any other cryptocurrency can compete with bitcoin if they want (and clearly many try). Seems we have plenty of choice in the market at the cryptocurrency moment. The difference is that in Bitcoin land, people cooperate to build standards. In Ethereum, far fewer standards are created, and instead people just build whatever…

There are many standards on Ethereum. There are also many people building their own things to try and extract value for themselves.

Bitcoin has some obscure things besides lightning due to the permissionless nature as well, but the limitations come from the block space and the smaller set of operations allowed

The comparison about what the market chose comes from TVL and volume metrics. see www.defipulse.com which also includes lightning

Re: An analysis of Bitcoin's throughput bottlenecks

#123

Post by billytetrud »

homakov wrote: 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-...

Your proposal isn't trustless anymore. At that point, why not just have normal centralized bank accounts?

You wrote that article in 2018 too, what do you think about the state of the LN now, where its no longer common to get payment failures?

Re: An analysis of Bitcoin's throughput bottlenecks

#124

Post by billytetrud »

Qworg wrote: post #39
homakov wrote: 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?

Payment channels are not at all credit. Credit means you're relying on someone to pay you back, and have a risk that they won't pay you back. Credit relies on trust. Payment channels do not rely on trust. You can always retrieve your money even if your channel partner doesn't want to give it back.

Re: An analysis of Bitcoin's throughput bottlenecks

#125

Post by greenshackle2 »

scotty79 wrote: post #29
chromaton wrote: post #11

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?

It is based on usage statistics not a technical benchmark. That number is not their peak throughput capacity it's how many transactions they actually do, which I'd wager is bottle-necked by user adoption not by tech.

Re: An analysis of Bitcoin's throughput bottlenecks

#126

Post by homakov »

billytetrud wrote: post #123
homakov wrote: 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-...

Your proposal isn't trustless anymore. At that point, why not just have normal centralized bank accounts? You wrote that article in 2018 too, what do you think about the state of the LN now, where its no longer common to get payment failures?

> Your proposal isn't trustless anymore

not black and white. I didn't say to drop collateral channels to have credit, but to use credit in addition to collateral on receiving side. Also, on ETH those credits are enforceable (as i answered below) so it is far better than a custodial balance.

> where its no longer common to get payment failures?

nothing changed, the inbound capacity flaw is fundamental. Download a wallet - you can't receive a payment - full stop. Until this is solved say goodbye to adoption. With credits on both sides the total capacity of the network skyrockets. And somebody is taking the risks anyway, either liquidity providers as in delusional LN model, or users themselves as in XLN.

Re: An analysis of Bitcoin's throughput bottlenecks

#127

Post by billytetrud »

scotty79 wrote: post #32
dylkil wrote: 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.

In my experience, I have seen literally 0 devs that are trying to increase miner profits. No one is worried that miners aren't getting paid enough.

Re: An analysis of Bitcoin's throughput bottlenecks

#128

Post by CryptoPunk »

billytetrud wrote: post #112

A little late, but I wanted to mention that I came to work on this because of the debate about block size and scaling ideas around the segwit update. Lots of opinions are generally thrown around without a whole lot of data to back it up, so I wanted to put in the work to make a systematic framework for estimating and comparing alternatives. I wanted to make it easier for other people to evalute what bitcoin's actual…

For a rebuttal to your analysis, please see this:

https://news.ycombinator.com/item?id=27136533

Re: An analysis of Bitcoin's throughput bottlenecks

#129

Post by billytetrud »

dylkil wrote: 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 actual transactions must all still be transmitted, so this "compression" is actually a way to avoid transmitting transaction data that has already been received by the other side. Bitcoin already does this and while maybe xthinner is better (I don't know) its absolutely not a 99X improvement over standard bitcoin. The problem with the bch people was that they were reckless and dishonest, not that they didn't occasionally create interesting things and have good points. It was a community that was problematic, but still contained some people doing good work.

Re: An analysis of Bitcoin's throughput bottlenecks

#130

Post by jlrubin »

dylkil wrote: 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…

Bitcoin incorporated Compact Blocks which similar improves average case behavior.

https://github.com/bitcoin/bips/blob/master/bip-0152.mediawi...

Things like thinblocks or compact blocks only help on average. Bitcoin must be robust for worst case.

Post reply on HN