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

191–200 of 234 posts

Re: An analysis of Bitcoin's throughput bottlenecks

#191

Post by dylkil »

billytetrud wrote: post #129
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 occa…

>problem with the bch people was that they were reckless and dishonest

Anything relevant you would like to share to back up this claim?

Re: An analysis of Bitcoin's throughput bottlenecks

#192

Post by grlass »

topranks wrote: post #179
billytetrud wrote: post #129

Earlier quoted context omitted.

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

It’s core principal; that the 1MB blocks use cap was arbitrary and holding back the network, remains 100% true. The arguments against SPV wallet use in this text don’t ring true for me.

It may be arbitrary, but increasing blocksize to mitigate network congestion is not a good solution, since any cap you set it to will also be arbitrary, and harm decentralisation (block propagation time, node operation costs, etc).

And given how valuable it is to have data in a semi-permanent near-immutable distributed ledger, that block space would be filled up pretty quickly, solving nothing.

Keeping the limit however has inspired a number of novel innovations to use the space more efficiently, including segwit (effectively increasing blocks to 4MB), and taproot.

In short, block size increases are an "easy solution" that don't really solve much.

Re: An analysis of Bitcoin's throughput bottlenecks

#193

Post by lowtto »

ButtSpark69 wrote: post #177
dboreham wrote: post #77

Earlier quoted context omitted.

"already working" hmm.

they're not lying. Loopring is one example among half a dozen. The issue is that current L2's are purpose-built by individual dapps. What doesn't currently exist (should be released in next few months) is the code that lets you copy/paste your current L1 code into an L2 code with almost no effort. At that point all the current dapps running on L1 can just port over to L2 very quickly and without the huge risk of a bu…

> What doesn't currently exist (should be released in next few months) is the code that lets you copy/paste your current L1 code into an L2 code with almost no effort

Why does that sounded like its already being solved by Matic? From my understanding, Polygon Matic do exactly that.

Re: An analysis of Bitcoin's throughput bottlenecks

#194

Post by dylkil »

grlass wrote: post #192
topranks wrote: post #179

Earlier quoted context omitted.

It’s core principal; that the 1MB blocks use cap was arbitrary and holding back the network, remains 100% true. The arguments against SPV wallet use in this text don’t ring true for me.

It may be arbitrary, but increasing blocksize to mitigate network congestion is not a good solution, since any cap you set it to will also be arbitrary, and harm decentralisation (block propagation time, node operation costs, etc). And given how valuable it is to have data in a semi-permanent near-immutable distributed ledger, that block space would be filled up pretty quickly, solving nothing. Keeping the limit howe…

>since any cap you set it to will also be arbitrary

Unless you done quantitative analysis into the most appropriate blocksize. But that will never happen at this stage.

Re: An analysis of Bitcoin's throughput bottlenecks

#195

Post by tootahe45 »

jayd16 wrote: post #111
aeternum wrote: post #33

Earlier quoted context omitted.

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.

Why is that more novel than, say, intra-bank transactions?

You can't make a huge return holding USD. We just need to pretend this is real adoption to recruit more to the ponzi.

Re: An analysis of Bitcoin's throughput bottlenecks

#196

Post by wyager »

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…

Yeah no shit you can just increase the block size. That doesn’t result in better asymptotic scaling.

Spinning up an ethereum full node (“archive node”) is way harder than spinning up a Bitcoin full node, partially because the eth blockchain is over 7TB vs about 300GB for BTC.

Re: An analysis of Bitcoin's throughput bottlenecks

#197

Post by wyager »

zionic wrote: post #133
billytetrud wrote: post #121

Earlier quoted context omitted.

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

Ethereum has increased its max block size 7+ times in the last 5 years and has had zero issues doing so. “Papers” from technically illiterate authors that ignore very real, tangible evidence contradicting them are about as useful as flat earth “math”.

Ethereum archive nodes are >20x larger than Bitcoin full nodes and notoriously hard to set up.

Re: An analysis of Bitcoin's throughput bottlenecks

#199

Post by uncletammy »

billytetrud wrote: post #129
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 occa…

https://news.bitcoin.com/xthinner-protocol-tested-on-bch-mai...

Re: An analysis of Bitcoin's throughput bottlenecks

#200

Post by answertojob »

chromaton wrote: post #47
answertojob wrote: post #35

Earlier quoted context omitted.

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

I looked into this and IOTA requires special blessed "Coordinator" nodes, so it's not really decentralized.

i want to elucidate my downvoters that I was not shilling the project. I was just pointing towards a network structure that you guys might find interesting given the problems we were discussing. I was not expecting to get some kind of reddit r/cryptocurrency style backlash. what you said is indeed true chromaton, but is also already solved and on its way to removing it this year. the theoretical solution to that was found in 2019 in one of their researchers conventions
Post reply on HN