Block chain size/storage and slow downloads for new users

[zkfq123]

i just create another new accout in blockchain and input my blockchain backup
but it just can see my all Transaction history but btc is zero i found all of my old btc address
miss,does somebody knows why?

[oldmaid]

There's nothing special about the old blocks from years ago. Besides the money that is in some of those old addresses. Why not just move them to a new block every so often and then just delete all the blocks behind that point. You don't need block 0 to verify block 2000 as long as everything below block 2000 is empty. Like, how about every 4 years when the reword is halved, run a script that compresses all Bitcoin transactions down to just the addresses that actually have money. That way a new genesis block is created every 4 years which just contains the addresses that matter. I don't think it would be that hard for all nodes to agree on a compression system like that.



                                          ^^^
                                          [BLOCK]
                                          [BLOCK]
                                          [BLOCK]
[BLOCK]         >>>>             [NEW GENESIS]
[BLOCK]
[BLOCK]
[BLOCK]
[BLOCK]
[BLOCK]
[BLOCK]
[BLOCK]
[BLOCK]
[GENESIS]

[justusranvier]

Like, how about every 4 years when the reword is halved, run a script that compresses all Bitcoin transactions down to just the addresses that actually have money

The problem with your plan is that addresses don't exist on the blockchain, much less have a balance.

[CoinCidental]

Like, how about every 4 years when the reword is halved, run a script that compresses all Bitcoin transactions down to just the addresses that actually have money

The problem with your plan is that addresses don't exist on the blockchain, much less have a balance.

another problem with that is people may have a certain payment address they have given to customers to use in the future  etc even if it contains no balance right now ,they may well be expecting to use it in future and its too much hassle to give your customers 1 payment address and then have to tell them we need to usea difernt one now because the ...........................

what happens to transcations sent to addresses that no longer exist ?

i dont think this is the answer to the problem tbh .............

[oldmaid]

Like, how about every 4 years when the reword is halved, run a script that compresses all Bitcoin transactions down to just the addresses that actually have money

The problem with your plan is that addresses don't exist on the blockchain, much less have a balance.

another problem with that is people may have a certain payment address they have given to customers to use in the future  etc even if it contains no balance right now ,they may well be expecting to use it in future and its too much hassle to give your customers 1 payment address and then have to tell them we need to usea difernt one now because the ...........................

what happens to transcations sent to addresses that no longer exist ?

i dont think this is the answer to the problem tbh .............

Thanks for your feedback. However that's not how Bitcoin works. There are billions of Bitcoin addresses out there that have no money attached to them. You don't need to register a number with Bitcoin to make it valid. The only addresses that matter are the ones in the blockchain with money. If I create a new address that's just a public and private key, there's nothing that needs to be registered in the blockchain unless it has money. So NO old addresses would be deleted you can still use whatever old address are out there. It would just look like a new address after the genesis block. Nothing would be lost. I'm just proposing a way to clean out some of the clutter.

[oldmaid]

Like, how about every 4 years when the reword is halved, run a script that compresses all Bitcoin transactions down to just the addresses that actually have money

The problem with your plan is that addresses don't exist on the blockchain, much less have a balance.

I think that you are on the wrong forum because your comment doesn't make any sense. Of course blocks have address and balances. They may not be in a list like I'm talking about. But that's just an example. The developers would have to adapt it to work in that situation.

[giszmo]

Like, how about every 4 years when the reword is halved, run a script that compresses all Bitcoin transactions down to just the addresses that actually have money

The problem with your plan is that addresses don't exist on the blockchain, much less have a balance.

I think that you are on the wrong forum because your comment doesn't make any sense. Of course blocks have address and balances. They may not be in a list like I'm talking about. But that's just an example. The developers would have to adapt it to work in that situation.

There really is no object like a balance of an address in Bitcoin. When you think you spend x from your address, you really spend from prior transactions that spent to your address but to spend it, you don't need the address but its public key and a signature using your private key. If the "address" was a script hash, things are slightly more complicated. You would have to present the script that hashes to said script hash and then provide whatever the script asks for. That might be 3 signatures.

So in a sense justusranvier is right and you old maid may check if you are on the right forum.

[oldmaid]

Like, how about every 4 years when the reword is halved, run a script that compresses all Bitcoin transactions down to just the addresses that actually have money

The problem with your plan is that addresses don't exist on the blockchain, much less have a balance.

I think that you are on the wrong forum because your comment doesn't make any sense. Of course blocks have address and balances. They may not be in a list like I'm talking about. But that's just an example. The developers would have to adapt it to work in that situation.

There really is no object like a balance of an address in Bitcoin. When you think you spend x from your address, you really spend from prior transactions that spent to your address but to spend it, you don't need the address but its public key and a signature using your private key. If the "address" was a script hash, things are slightly more complicated. You would have to present the script that hashes to said script hash and then provide whatever the script asks for. That might be 3 signatures.

So in a sense justusranvier is right and you old maid may check if you are on the right forum.

Thanks for your response. And your answer is much more informed then the previous one. And in a sense your right, but your explanation is going into how Bitcoins are transferred rather then my example of a solution to the blockchain length. Your forgetting that Bitcoin is just a program and therefor can be adapted to any new ideas that may come about. I am very well aware of how the Bitcoin program works and have been programming Java Bitcoin key generators for a long time. I understand all your points very well. That being said, I still don't see anything stopping the Bitcoin nodes from creating a "Summary" block of the address that have the money. And then either deleting everything since then, or just using that as the block for new nodes to start from. For example, rather then downloading 25 years of Bitcoin transactions, maybe my new computer node just download everything since the last "Summary" block. The only problem I see is that you will have a trust problem with that "Summary" block. Perhaps the miners can build the "Summary" block and then put a hash of that in the next transaction or something so that each new node can verify the "Summary" block. Maybe someone else out there can build upon this idea.

Actually, now that I think about it it's not that hard. The miners, every 4 years create a summary block as a special block in the blockchain with the info right in it. The nodes then each verify the "Summary" block and if one of the miners tried to create a false amount they would reject the "Summary" block. Therefore the Summary block would be verifiable by everyone and as a new node all you would do is start from that summary block and build from there. Rather then downloading 25 years of data. Now if you want to you still could maybe it could be an option on the client. And for the "Light" clients they just keep up to date from "Summary" to "Summary" rather then the whole thing.

[giszmo]

Thanks for your response. And your answer is much more informed then the previous one. And in a sense your right, but your explanation is going into how Bitcoins are transferred rather then my example of a solution to the blockchain length. Your forgetting that Bitcoin is just a program and therefor can be adapted to any new ideas that may come about. I am very well aware of how the Bitcoin program works and have been programming Java Bitcoin key generators for a long time. I understand all your points very well. That being said, I still don't see anything stopping the Bitcoin nodes from creating a "Summary" block of the address that have the money. And then either deleting everything since then, or just using that as the block for new nodes to start from. For example, rather then downloading 25 years of Bitcoin transactions, maybe my new computer node just download everything since the last "Summary" block. The only problem I see is that you will have a trust problem with that "Summary" block. Perhaps the miners can build the "Summary" block and then put a hash of that in the next transaction or something so that each new node can verify the "Summary" block. Maybe someone else out there can build upon this idea.

Actually, now that I think about it it's not that hard. The miners, every 4 years create a summary block as a special block in the blockchain with the info right in it. The nodes then each verify the "Summary" block and if one of the miners tried to create a false amount they would reject the "Summary" block. Therefore the Summary block would be verifiable by everyone and as a new node all you would do is start from that summary block and build from there. Rather then downloading 25 years of data. Now if you want to you still could maybe it could be an option on the client. And for the "Light" clients they just keep up to date from "Summary" to "Summary" rather then the whole thing.

In essence, this is done by pruning, which will come very soon. Pruning does not group transactions to a concluding total which would be a change to the protocol that will very likely never come, as it assumes address reuse which should be reduced and not be encouraged. Pruning does though get rid of transactions that were already spent. You will be able to tell your node how many GB you want to spend on the bitcoin db and it will never exceed that. In turn, you will not be able to serve data for nodes that start up verifying data from the genesis block.

(highly controversial daydreaming: I would advocate for a rule that forbids spending of outputs that are older than a year, forcing users to at least move all their bitcoins once per year but I know this will never make it into the code. Benefit would be to get rid of lost coins that will become a problem once sha256 becomes weak and we need to transition to the next better thing. Most likely it will become weak gradually but at some point people will "mine" the biggest wallets out there instead of the next block. With the max age rule, we would get rid of the satoshi dice sins of unspendable satoshis and of all the "lost" coins. Satoshi would have to move his coins which would be a great event but we would only learn that he's still alive and nothing more. If coins are moved from output to output independently, this would not merge a thing. The transactions would also almost always qualify for no transaction fees.)

[sobitcoin]

This thread only makes me think: Bitcoin is too much. The possibilities it opens, technologies it enables - it's all just too much for businesses and governments and people to grasp easily.
Having said that, it is precisely these kinds of threads that help us digest bits and pieces.

Thanks Mike, retep, and everyone else!

Too much.. Curious about where you believe other technologies began? Everyone understood them from day 1?

[biscotaste]

Education is very important for the future of Bitcoin. I can see the industry trying to become simpler for all the Homer Simpsons of the world.

[allgoodthings1]

New user downloads are on the brink of becoming much faster with version 0.9.4. It's out of development as of this morning in the Ubuntu/Linux PPA. It should be out soon for other versions.

[nickxrod]

So I just built my new Hack Pro - it's a beast. And for the past two days now I've been trying to synchronize Bitcoin QT and I'm at about 10%.
I figured I'd see what Bitcointalk would say about it, and I wondered if anyone ever thought that there might be a time when the blockchain might get too ridiculously large, and what was my surprise to see this thread as the first thread listed when I logged in!

K, I'm going to go back and read it now.

[Mcqueen44]

I noticed some slow down even with 8 connections of Core...

[oneoff]

AAArgghhhhh.

I have waited for five days to get my wallet synchronized. Having qt.exe and appdata on a NAS. Once the wallet had two weeks to sync the wallet crashed due to full disk. I'm back to square one, now temporary put the wallet on an external USB drive to my gaming computer, hoping the wallet will synchronize faster...

Once this is done I'll move my coins to Multibit, hoping all this sync struggle will be over.

[Orangina]

I got a small question , why Bitcoin Core when it's Synchronizing with the network .. It download various files with small MB's like 150MB or something ... then if I download the torrent , the Bitcoin Core only read that 1 Single Boostrap.dat file ?
Does the Bitcoin client mix all the 150mb files together to get that .dat file of 20 GB or something ?

[tvbcof]

AAArgghhhhh.

I have waited for five days to get my wallet synchronized. Having qt.exe and appdata on a NAS. Once the wallet had two weeks to sync the wallet crashed due to full disk. I'm back to square one, now temporary put the wallet on an external USB drive to my gaming computer, hoping the wallet will synchronize faster...

Once this is done I'll move my coins to Multibit, hoping all this sync struggle will be over.

Dunno if it would help you or not, but I seem to be able to spend my BTC when the blockchain catches up to the point where the wallet was created and funded.  2011 in my cases, and of course the blockchain was much smaller at that point.  Then I can shut the client down.  The blockchain is now three times my total monthly data allowance on my satellite connection so being an actual useful participant in the so-called P2P solution is not very practical.

Some people think that satellite links add some magic diversity to the transmission backbone.  I happen to think this is nonsense given how tightly satellite connections are controlled (even though they are remarkably functional these days though fairly expensive) but whatever the case, you can at best run something like Multibit behind one which makes you more akin to headcount in a herd of sheep than an active participant in supporting the network.  As I see it.

BTW, I asked on another thread but nobody really knew the answer:  If there was a block chain fork and a war broke out between miners, could one make their own choices about which chain to follow in some way with Multibit?  Or is it just sort of hard coded that transaction attempts go into a nebulous cloud and results are put on whatever fork the server decides?  In other words, if there was a fork with unlimited block size and it formed the longest chain (for a while at least), could most Multibit transactions just get slapped on it without the user upgrading or being aware of what is happening?

[2112]

Some people think that satellite links add some magic diversity to the transmission backbone.  I happen to think this is nonsense given how tightly satellite connections are controlled (even though they are remarkably functional these days though fairly expensive) but whatever the case, you can at best run something like Multibit behind one which makes you more akin to headcount in a herd of sheep than an active participant in supporting the network.  As I see it.

1) Have you talked to your satellite ISP about using SCTP/IP instead of TCP/IP?

2) Have you talked to your satellite ISP about using UDP/IP multicast in the downlink?

3) - - - - - - - about using MPEG system sub-channels in the downlink?

[tvbcof]

Some people think that satellite links add some magic diversity to the transmission backbone.  I happen to think this is nonsense given how tightly satellite connections are controlled (even though they are remarkably functional these days though fairly expensive) but whatever the case, you can at best run something like Multibit behind one which makes you more akin to headcount in a herd of sheep than an active participant in supporting the network.  As I see it.

1) Have you talked to your satellite ISP about using SCTP/IP instead of TCP/IP?

2) Have you talked to your satellite ISP about using UDP/IP multicast in the downlink?

3) - - - - - - - about using MPEG system sub-channels in the downlink?

Have you ever tried to talk to a satellite network provider for consumer class connectivity and got farther than some Indian telling you to re-boot your modem for the 15th time and clear your browser cache again?  Viasat had some horrible DHCP issues with very common routers when I first got the service some years ago.  I did packet captures and showed the problem on a forum, but that is as close as I was able to get to talking tech to anyone.  And it was mainly one other ordinary user who had some skilz.

I'll be switching to T1 this fall.  The phone company says they can do it.  We'll see.

---

BTW, it occurs to me that if an Indian costs Hughes $0.50 and hour and I'm paying them $80/mo, they could keep me on the support line for literally days and still make a profit.  This is not unlike tossing rings at a carnival.  The amount you pay for a chance to win is more than the cost of the prize that you might get.

[2112]

Have you ever tried to talk to a satellite network provider for consumer class connectivity and got farther than some Indian...

Yes, I did. I even got invited to Hughes' headquarters in Inglewood to discuss various technical options (not related to Bitcoin).

I think you understand that their consumer market are the proverbial "hicks" and it requires the approach appropriate to hicks. From your avoidance of the 3 technical questions I asked I'm going to assume that you actually don't have the required technical background for a productive discussion with their engineering and NOC staff.

At least T1 is fully symmetric, so you'll have no problems then.