proposal: delete blocks older than 1000

[hennessyhemp]

I propose deleting all but the last 1000 blocks. this will keep the blockchain small and lean. as blocks build upon each other, older blocks are not needed. The only problem with this is if  there is a 1001 block chain fork which shoudl not happen.

[1714987805]

1714987805

[1714987805]

1714987805

[1714987805]

1714987805

[tiberiandusk]

Pruning is in the works I believe.

[Birdy]

You cannot just delete old blocks, there may still be unspent coins in there.
I think you could analyse it and only use those with actual coins in it though, so that the old blockchain could be compressed.

[franky1]

the problem is that hoarders still have coins in very old blocks. so pruning will only work on blocks where every single transaction is 'spent'

edit:  birdy beat me to the punchline of how simply removing x amount of blocks wont work

[Birdy]

the problem is that hoarders still have coins in very old blocks. so pruning will only work on blocks where every single transaction is 'spent'

edit:   birdy beat me to the punchline of how simply removing x amount of blocks wont work

The early bird catches the worm punchline

[DannyHamilton]

I propose deleting all but the last 1000 blocks. this will keep the blockchain small and lean. as blocks build upon each other, older blocks are not needed. The only problem with this is if  there is a 1001 block chain fork which shoudl not happen.

Learn more about how a system works before you start guessing at ways to "improve" it.  Otherwise, your guesses aren't likely to make very much sense.

I propose reducing the energy released in a fission reaction.  This will keep the temperature of the reaction down, and make nuclear energy far safer.  The only problem is if there isn't enough energy released to be cost effective.

[dirtscience]

I propose deleting all but the last 1000 blocks. this will keep the blockchain small and lean. as blocks build upon each other, older blocks are not needed. The only problem with this is if  there is a 1001 block chain fork which shoudl not happen.

I support this idea fully.

[bigbeninlondon]

I propose deleting all but the last 1000 blocks. this will keep the blockchain small and lean. as blocks build upon each other, older blocks are not needed. The only problem with this is if  there is a 1001 block chain fork which shoudl not happen.

What if the last transaction to my wallet was 2000 blocks ago?  Remember that 2016 blocks are mined every two weeks.  So if I had a transaction over 2 weeks old I'm SOL?

[justusranvier]

I propose deleting all but the last 1000 blocks. this will keep the blockchain small and lean. as blocks build upon each other, older blocks are not needed. The only problem with this is if  there is a 1001 block chain fork which shoudl not happen.

Learn more about how a system works before you start guessing at ways to "improve" it.  Otherwise, your guesses aren't likely to make very much sense.

I propose reducing the energy released in a fission reaction.  This will keep the temperature of the reaction down, and make nuclear energy far safer.  The only problem is if there isn't enough energy released to be cost effective.

I think you're on to something here. I propose a lower value for the gravitational constant to make space travel more efficient. Let's start a petition on change.org.

[jackjack]

We better make the speed of light higher so that optic fibers can allow much faster data transfers

[wiggi]

the problem is that hoarders still have coins in very old blocks. so pruning will only work on blocks where every single transaction is 'spent'

Won't help with hoarders in very old blocks but... the one transaction that makes an entire block 'spent',
or rather the last x transactions for each block, could get incentivized.

Like, another free 27kb/block reserved only for these transactions. Easy and painless soft fork.

Or even a small negative fee. Would miners do this? (for the greater good) 

[solex]

I propose deleting all but the last 1000 blocks. this will keep the blockchain small and lean. as blocks build upon each other, older blocks are not needed. The only problem with this is if  there is a 1001 block chain fork which shoudl not happen.

Learn more about how a system works before you start guessing at ways to "improve" it.  Otherwise, your guesses aren't likely to make very much sense.

I propose reducing the energy released in a fission reaction.  This will keep the temperature of the reaction down, and make nuclear energy far safer.  The only problem is if there isn't enough energy released to be cost effective.

Agreed. I also propose redesigning 3-stage rockets so that the top two stages carry payload and only the bottom stage carries fuel. That way twice as much could be carried into orbit for half the fuel. I am surprised it wasn't done like that for the manned space program.

[gmaxwell]

Agreed. I also propose redesigning 3-stage rockets so that the top two stages carry payload and only the bottom stage carries fuel. That way twice as much could be carried into orbit for half the fuel. I am surprised it wasn't done like that for the manned space program.

We better make the speed of light higher so that optic fibers can allow much faster data transfers

I think we can achieve both of these by first making space-time riemannian instead of Pseudo-Riemannian. With euclidean space-time there should be no need for pesky limits like a constant speed of light, and the extra payload mass should be offset-able by simply moving some of the fuel you didn't need into the past.

ObOntopic:  While not all nodes need to constantly store the complete history— it is not so simple as waving some hands and saying "just keep X blocks": access to historical data is important to Bitcoin's security model. Otherwise miners could invent coins out of thin air or steal coins and later-attaching nodes would know nothing about it, and couldn't prevent.   There is a careful balancing of motivations here: part of the reason someone doesn't amass a bunch of computing power to attack the system is because of how little they can get away with if they try.

[cr1776]

I propose that we make P = NP. 

Oh wait, then we have a real problem.  :-)

Agreed. I also propose redesigning 3-stage rockets so that the top two stages carry payload and only the bottom stage carries fuel. That way twice as much could be carried into orbit for half the fuel. I am surprised it wasn't done like that for the manned space program.

We better make the speed of light higher so that optic fibers can allow much faster data transfers

I think we can achieve both of these by first making space-time riemannian instead of Pseudo-Riemannian. With euclidean space-time there should be no need for pesky limits like a constant speed of light, and the extra payload mass should be offset-able by simply moving some of the fuel you didn't need into the past.

ObOntopic:  While not all nodes need to constantly store the complete history— it is not so simple as waving some hands and saying "just keep X blocks": access to historical data is important to Bitcoin's security model. Otherwise miners could invent coins out of thin air or steal coins and later-attaching nodes would know nothing about it, and couldn't prevent.   There is a careful balancing of motivations here: part of the reason someone doesn't amass a bunch of computing power to attack the system is because of how little they can get away with if they try.

[hennessyhemp]

This was a very odd account hack...this guy made posts like this in my name all day yesterday...I hope no one was scammed.

bastard.

[Come-from-Beyond]

This was a very odd account hack...this guy made posts like this in my name all day yesterday...I hope no one was scammed.

bastard.

This reminded me Fight Club...

[Pieter Wuille]

Deleting old blocks is perfectly possible - this was a design goal when the 0.8 database changes (called "ultraprune" for a reason, back then) were developed.

Old transactions are not affected, as the set of unspent transaction outputs is maintained separately from the block database. Their unspent outputs remain in the database, even if the block that contained the transaction itself isn't anymore.

The reason this is not yet implemented, is because we first need to make some protocol changes to help new nodes that start up find peers to download the blockchain from. If a majority of nodes goes to delete their old blocks, they'd have a very hard time finding a peer that still has those blocks otherwise.

[TierNolan]

The reason this is not yet implemented, is because we first need to make some protocol changes to help new nodes that start up find peers to download the blockchain from. If a majority of nodes goes to delete their old blocks, they'd have a very hard time finding a peer that still has those blocks otherwise.

I think the proposal to use bittorrent for that is best.  A tracker could be started for the blockchain state every 10k blocks.

Does bittorrent do merkle-like hashing?  I sounds like it just is a list of hashes per piece?

The file could be defined to exclude all orphans.  This gives a consistent target for each tracker.

Since all blocks that are included in the snapshot have 10k confirms, it would be clear which blocks are orphans by the time the tracker is created.

You could add the sha256 hash of the blockchain from 0 to 229999 (excluding orphans) into the coinbase for block 235000.  To save coinbase space you could spread it out over multiple blocks.

This gives miners 5000 blocks to compute the next hash.

[gmaxwell]

I think the proposal to use bittorrent for that is best.  A tracker could be started for the blockchain state every 10k blocks.

Our effort to use a trackerless torrent was a failure— it was basically unusable. So you'd be introducing a critical path point of failure both at the trackers and in the torrent files.  Beyond that, even with the infrequently updated bootstrap we only get a handful of seeds, I can't imagine _more_ frequent torrents improving that.  Now multiply that with the fact that bittorrent is another network facing protocol with similar software complexity to the whole of the Bitcoin reference software, and one with a less impressive security history, so anyone that participates in that is increasing their security critical surface area. Then exponentiate that by the fact that bittorrent is _forbidden_ on many networks both because massively parallel TCP connections are hostile to the network (use an unfair share of capacity) and the associations with illicit file transfer, and even where it isn't outright forbidden it often gets detected by IDS and can draw unwanted adverse attention. The association of IRC and Botnets (and the resulting blocking and confused "you've been hacked" warnings from network admins) is one of the reasons we removed the original IRC introduction method.

Providing the data necessary for the operation of the network is something the network ought to do. It provides a 1:1 mapping between interesting parties and available parties. It also makes some kind of attack resistance easier because Bitcoin software can actually validate the information without any centrally controlled official torrents, whereas using torrent would ignore all the special structure our data has that makes dos attacking difficult.

I believe that using bittorrent for this is unnecessary, that using it as a primary method (as opposed to a backup or alternative option) would be bad and dangerous.  Also, you're a bad bad person for proposing it, and you smell too. (no, not really. But I'm finding it a little difficult to state how throughly bad I think that idea is without being gratuitously insulting— it's not intended that way, and it's nothing personal. Perhaps some awkward humor will help? ).

[justusranvier]

The Freenet project has managed to create a 30+ terabyte distributed, redundant, content-addressed filesystem. It works in a plug-and-play fashion, where individual nodes specialize with regards to routing and as to which keys they choose to store automatically without requiring any explicit configuration. Nodes can enter and leave the network randomly without having much of an impact on key retrievablity.

Their design would be a good starting point for building a distributed datastore for Bitcoin. All the objects that we care about are already identified by their hashes, so it would be easy to adapt their storage model for Bitcoin.