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

181–190 of 234 posts

Re: An analysis of Bitcoin's throughput bottlenecks

#181

Post by topranks »

billytetrud wrote: post #127
scotty79 wrote: post #32

Earlier quoted context omitted.

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.

The miners control the network, longest chain and all that.

They also have lots of money to pay for devs.

Foolish to think a bunch of open source devs are controlling the protocol in defiance of miners who would rather they do something else.

Re: An analysis of Bitcoin's throughput bottlenecks

#182

Post by topranks »

scotty79 wrote: post #43
dylkil wrote: post #40

Earlier quoted context omitted.

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…

Why many low fee transactions were not chosen?

Because Bitcoin works in a way that means miners, collectively, control the network.

They voted with their hash power against Bitcoin Cash when it forked, which was the “increase the limit” fork aiming at low fees and high number of transactions.

Those miners can now enjoy high fees as a result.

Re: An analysis of Bitcoin's throughput bottlenecks

#183

Post by topranks »

billytetrud wrote: post #121
CyberDildonics wrote: post #99

Earlier quoted context omitted.

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.

It doesn’t really though.

It makes laughable claims like miners have only 94KB of bandwidth.

It’s the same old fud that says SPV is unsafe for the average user, Moore’s law is nonexistent, and even then makes crazy lowball assumptions about what hardware and network connectivity people have.

It’s basic fallacy is the same old one that says every user needs to download and validate the entire chain and all transactions to use Bitcoin.

If that’s true it’s going nowhere anyway.

Re: An analysis of Bitcoin's throughput bottlenecks

#184

Post by Havoc »

billytetrud wrote: post #114
Havoc wrote: post #109

Earlier quoted context omitted.

>What scaling technologies do they have? The ones I'm aware of are Not Eth, but you're missing one option - tree graph based. They've pushed 3000+ TPS through it already in testnets...and that's on layer 1. High level description: https://confluxnetwork.medium.com/tree-graph-structure-of-co... >or layer 2 on BTC, aka lightning network? Indeed - that could work. I do think Eth has the edge though. Throughput only matt…

> They've pushed 3000+ TPS through it already in testnets Whenever someone says something like "they've tested it with X throughput", it usually means that they're not considering security properties. Sure, you can push throughput through on test machines in a test setting and it will happen. But in an adversarial environment, systems pushed to those limits can often be attacked. Its not sufficient to test throughput…

>usually means that they're not considering security properties.

They claim they have managed security, scalability and decentralization. I'm in no position to evaluate this. However they've got Sequoia onboard, plus a Turing award winner, plus Shanghai gov and team is full of PhDs...so I figured good enough for me.

Re: An analysis of Bitcoin's throughput bottlenecks

#185

Post by alfiedotwtf »

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…

Why not fork? Sure, it may no longer be Bitcoin Core... but legitimate non-backwards compatible forks seem like a good reason to start a new chain

Re: An analysis of Bitcoin's throughput bottlenecks

#186

Post by tromp »

wyager wrote: post #90
CyberDildonics wrote: post #88

Earlier quoted context omitted.

Why? It has been in development for 7 years. Why use this complicated hack solution when anyone can just use a different cryptocurrency and not have these problems in the first place?

> 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…

Mimblewimble improves on Bitcoin's scalability by allowing all spent outputs to be removed from the Initial Block Download.

Re: An analysis of Bitcoin's throughput bottlenecks

#187

Post by tromp »

Taek wrote: post #37
ChainOfFools wrote: post #30

Earlier quoted context omitted.

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 ca…

What are the data availability requirements in a chain whose header commits to UTXO set Merkle Mountain Range peaks, where tx inputs come with Merkle proofs up to an MMR peak, and the miner adds a STARK proof of existence of a valid history?

Re: An analysis of Bitcoin's throughput bottlenecks

#188

Post by dylkil »

gruez wrote: post #81
dylkil wrote: post #40

Earlier quoted context omitted.

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…

>use block compression tech like xthinner to make blocks essentially 1mb (like today), then the average fee needed is only $2. Claiming that xthinner can reduce 100mb blocks down to 1mb is dishonest. It might reduce the network transfer down to 1mb (assuming you already the txes), but on-disk storage would stay the same. https://news.ycombinator.com/item?id=25688004

block propagation was the main reason for being opposed to a block size increase, storage costs were debunked time and time again as being irrelevant.

Re: An analysis of Bitcoin's throughput bottlenecks

#189

Post by dylkil »

gruez wrote: post #83
itsdsmurrell wrote: post #74

Earlier quoted context omitted.

They (the devs that control the repo that almost all miners run code from) chose to stifle the base layer to profit from higher layers using 'goat herders should be able to run a full node' as the excuse.

>to profit from higher layers How are they profiting?

the liquid network is owned by blockstream and they get the fees for transactions on it.

Re: An analysis of Bitcoin's throughput bottlenecks

#190

Post by dylkil »

alfiedotwtf wrote: post #185
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…

Why not fork? Sure, it may no longer be Bitcoin Core... but legitimate non-backwards compatible forks seem like a good reason to start a new chain

this is exactly what bitcoin cash is
Post reply on HN