In 2018 bitcoin might collapse...

[Wilhelm]

This is not a problem and never was. OP, go read the white paper and the developments in the dev subforum. This is what happens when n00bs spend too much time in Speculation and not enough time learning about the bitcoin protocol itself.

We get a thread whining about scalability at least every month.
1) You do not need the entire blockchain
2) Blockchain compression
3) Big hard drives. When I was a kid people had 32 megabyte hard drives. And again, you don't need the entire blockchain!!!
4) Lite clients that require 0 trust using some devious merkel tree tricks
5) Read the fucking available material on the problem already, smart people have already solved it.

About point 1.
I assume this is correct but imo there is no simple way to determine what can be deleted.
They cannot purge transactions older than X years since this might kill peoples offline wallets.
You can only remove transactions to accounts that now hold 0 BTC but that might give the spender free money again.
The only way you could pull it off is by making a 5year checkpoint every 1st of January, in which all the balances of blockchain accounts ever used are stored and only transactions from that date forward are processed.
I see a lot of problems with your point 1.

P.S. haven't read the smart people solution but a link would be appreciated.

[1714772336]

1714772336

[1714772336]

1714772336

[1714772336]

1714772336

[1714772336]

1714772336

[adamstgBit]

[notme]

This is not a problem and never was. OP, go read the white paper and the developments in the dev subforum. This is what happens when n00bs spend too much time in Speculation and not enough time learning about the bitcoin protocol itself.

We get a thread whining about scalability at least every month.
1) You do not need the entire blockchain
2) Blockchain compression
3) Big hard drives. When I was a kid people had 32 megabyte hard drives. And again, you don't need the entire blockchain!!!
4) Lite clients that require 0 trust using some devious merkel tree tricks
5) Read the fucking available material on the problem already, smart people have already solved it.

About point 1.
I assume this is correct but imo there is no simple way to determine what can be deleted.
They cannot purge transactions older than X years since this might kill peoples offline wallets.
You can only remove transactions to accounts that now hold 0 BTC but that might give the spender free money again.
The only way you could pull it off is by making a 5year checkpoint every 1st of January, in which all the balances of blockchain accounts ever used are stored and only transactions from that date forward are processed.
I see a lot of problems with your point 1.

P.S. haven't read the smart people solution but a link would be appreciated.

There are multiple levels available with existing software.

Bitcoin-qt stores the entire blockchain, but supports bloom filters on the network side.  Bloom filters allow clients connected to the network to specify a small hash value that represents the addresses they are interested in.  Mobile/thin clients can use these filters to only receive transactions for the addresses they care about (and some false positives as a privacy feature).  They still get the full block header, which is small, but allows them to verify the transaction hash is indeed confirmed.  In the future, the official client will likely move to a model where some nodes store the full chain, but most nodes only store a GB or so.  This GB can be randomly selected (other than the transactions the user clearly cares about) and this will enable wide coverage of the blockchain spread across many nodes.  Miners only need the unspent transaction output set, or UTXO.  This is still only a few hundred megabytes.

[Wilhelm]

This is not a problem and never was. OP, go read the white paper and the developments in the dev subforum. This is what happens when n00bs spend too much time in Speculation and not enough time learning about the bitcoin protocol itself.

We get a thread whining about scalability at least every month.
1) You do not need the entire blockchain
2) Blockchain compression
3) Big hard drives. When I was a kid people had 32 megabyte hard drives. And again, you don't need the entire blockchain!!!
4) Lite clients that require 0 trust using some devious merkel tree tricks
5) Read the fucking available material on the problem already, smart people have already solved it.

About point 1.
I assume this is correct but imo there is no simple way to determine what can be deleted.
They cannot purge transactions older than X years since this might kill peoples offline wallets.
You can only remove transactions to accounts that now hold 0 BTC but that might give the spender free money again.
The only way you could pull it off is by making a 5year checkpoint every 1st of January, in which all the balances of blockchain accounts ever used are stored and only transactions from that date forward are processed.
I see a lot of problems with your point 1.

P.S. haven't read the smart people solution but a link would be appreciated.

There are multiple levels available with existing software.

Bitcoin-qt stores the entire blockchain, but supports bloom filters on the network side.  Bloom filters allow clients connected to the network to specify a small hash value that represents the addresses they are interested in.  Mobile/thin clients can use these filters to only receive transactions for the addresses they care about (and some false positives as a privacy feature).  They still get the full block header, which is small, but allows them to verify the transaction hash is indeed confirmed.  In the future, the official client will likely move to a model where some nodes store the full chain, but most nodes only store a GB or so.  This GB can be randomly selected (other than the transactions the user clearly cares about) and this will enable wide coverage of the blockchain spread across many nodes.  Miners only need the unspent transaction output set, or UTXO.  This is still only a few hundred megabytes.

Thank you for the insight!

I agree this could work as long as there are enough full-blockchain nodes available or enough partial nodes to "seed" all the addresses as false positives so you still get full coverage.
It's a good thing to know that the size of the blockchain won't become a problem

[Tzupy]

... In the future ...

About the same answer was given 6 months ago in another thread. In theory, the problem can be solved, but it's not so simple,
or the devs would have solved it already. It requires some effort to code and test, and IMO the early adopters should be putting
some money into solving it before it becomes more than a nuisance.

[notme]

... In the future ...

About the same answer was given 6 months ago in another thread. In theory, the problem can be solved, but it's not so simple,
or the devs would have solved it already. It requires some effort to code and test, and IMO the early adopters should be putting
some money into solving it before it becomes more than a nuisance.

Except work is being put into it.  There are several projects, but one is listed right on the bitcoin wiki's scalability page under "Related works".  You really haven't put much effort into researching this.  The problem really only exists with the reference client, and most new users aren't using that anyway.  They use a mobile wallet or a web wallet.

[Hyena]

let's cross that bridge when we get there.