4 ms·

the limitations have been researched extensively outside of the echo chamber of bitcoin development. It is possible to scale a utxo system like bitcoins to hund

by dylkil 6y ago

the limitations have been researched extensively outside of the echo chamber of bitcoin development. It is possible to scale a utxo system like bitcoins to hundreds of millions of txs per day. Xthinner[1] can compress blocksizes by 99%, but bitcoin devs have ignored this with handywavy arguments. [1]https://github.com/jtoomim/xthinner-spec https://github.com/jtoomim/xthinner-spec

gruez 6y ago
>but bitcoin devs have ignored this with handywavy arguments. Can you provide links to these discussions? I searched around on google and all the results are relating to bitcoin cash. I also searched the usual places that bitcoin (non cash) people congregate and turned up nothing.
- nullc 6y ago
  Sad that you're going to get no reply here, but not surprising.
deleted 6y ago
[deleted]
ryani 6y ago
That page claims it can compress a single transaction down to 12-16 bits. Unless the vast majority of btc transactions are between the same few wallet addresses, this seems impossible? Even if you assume that the transaction is an instance of a common known script, you still need from-address, to-address, and amount, all of which are >16 bit quantities and in general are cryptographically random. The only explanation I can think of is that they are relying on a sidechannel to communicate the actual transactions, which makes sense in the miner case (the utxo pool) but not in the general node case. Beyond that, I run a BTC node occasionally and the bottleneck is validating blocks, not downloading them. Transactions are complicated enough right now that I'm only able to catch up at about 350x real-time (that is, it takes around a full cpu-day to validate a year of blocks/transactions).
nullc 6y ago
A bitcoiner pinged me and asked for my comment here. It really sucks that people are so easily bamboozled by dishonest scammers. In the original bitcoin software a node would receive every transaction made while it was online twice: once when the transaction was first relayed, once when it was placed into blocks. This was obviously wasteful, so we created and deployed a reconciliation scheme that exploits the fact that normally all, or almost all the included transactions are already known. https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki https://github.com/bitcoin/bips/blob/master/bip-0152.mediawi... But because Bitcoin developers are not dishonest scammers they didn't run around putting out (no kidding) press releases claiming "98.6% compression"-- though that's what you get if you compare the size of the BIP152 message to the size of the block. In reality, since it depends on the transaction being known in advance the unachievable limit for this class of approaches is a 50% bandwidth reduction for a node compared to the original behaviour. BIP152 achieves 49.3% out of that 50%, as measured on the latest block. Even before compact blocks was created back in December 2015, we knew even smaller could be achieved. E.g. we published a scheme that requires asymptotically 0 bytes per transaction, only requiring data proportional to size of the difference between the block and the recipients guess at the next block. But what we found is that the simpler scheme actually propagated blocks much faster because once the block is down to just a few thousand bytes other factors (like CPU time) dominate. Expending a lot of additional code and cpu time to take 49.3% closer to 50% isn't a win in actual usage. [And for considerations other than block propagation, saving a few extra bytes per block is extremely irrelevant.] It's also the case that some of these dishonestly hyped supposed improvements beyond what Bitcoin has done for years are actually totally brain-damaged and wouldn't work in practice because they're not robust against attack-- but there isn't much reason to dive into technical minutia because what they _claim to achieve_, once you strip off the dishonest marketing, isn't all that interesting.
- jcpham2 6y ago
  This place is not a place to learn about bitcoin Greg, it’s all changed :( Thanks for this.

by dylkil 6y ago

gruez 6y ago

>but bitcoin devs have ignored this with handywavy arguments. Can you provide links to these discussions? I searched around on google and all the results are relating to bitcoin cash. I also searched the usual places that bitcoin (non cash) people congregate and turned up nothing.

nullc 6y ago
Sad that you're going to get no reply here, but not surprising.

deleted 6y ago

[deleted]

ryani 6y ago

That page claims it can compress a single transaction down to 12-16 bits. Unless the vast majority of btc transactions are between the same few wallet addresses, this seems impossible? Even if you assume that the transaction is an instance of a common known script, you still need from-address, to-address, and amount, all of which are >16 bit quantities and in general are cryptographically random. The only explanation I can think of is that they are relying on a sidechannel to communicate the actual transactions, which makes sense in the miner case (the utxo pool) but not in the general node case. Beyond that, I run a BTC node occasionally and the bottleneck is validating blocks, not downloading them. Transactions are complicated enough right now that I'm only able to catch up at about 350x real-time (that is, it takes around a full cpu-day to validate a year of blocks/transactions).

nullc 6y ago

A bitcoiner pinged me and asked for my comment here. It really sucks that people are so easily bamboozled by dishonest scammers. In the original bitcoin software a node would receive every transaction made while it was online twice: once when the transaction was first relayed, once when it was placed into blocks. This was obviously wasteful, so we created and deployed a reconciliation scheme that exploits the fact that normally all, or almost all the included transactions are already known. https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki https://github.com/bitcoin/bips/blob/master/bip-0152.mediawi... But because Bitcoin developers are not dishonest scammers they didn't run around putting out (no kidding) press releases claiming "98.6% compression"-- though that's what you get if you compare the size of the BIP152 message to the size of the block. In reality, since it depends on the transaction being known in advance the unachievable limit for this class of approaches is a 50% bandwidth reduction for a node compared to the original behaviour. BIP152 achieves 49.3% out of that 50%, as measured on the latest block. Even before compact blocks was created back in December 2015, we knew even smaller could be achieved. E.g. we published a scheme that requires asymptotically 0 bytes per transaction, only requiring data proportional to size of the difference between the block and the recipients guess at the next block. But what we found is that the simpler scheme actually propagated blocks much faster because once the block is down to just a few thousand bytes other factors (like CPU time) dominate. Expending a lot of additional code and cpu time to take 49.3% closer to 50% isn't a win in actual usage. [And for considerations other than block propagation, saving a few extra bytes per block is extremely irrelevant.] It's also the case that some of these dishonestly hyped supposed improvements beyond what Bitcoin has done for years are actually totally brain-damaged and wouldn't work in practice because they're not robust against attack-- but there isn't much reason to dive into technical minutia because what they _claim to achieve_, once you strip off the dishonest marketing, isn't all that interesting.

jcpham2 6y ago
This place is not a place to learn about bitcoin Greg, it’s all changed :( Thanks for this.