Topic: KISS pruning for the blockchain (Read 2265 times)

I've clicked over and noticed that you are an Israeli, thus I have a constructive answer:

to test your sense of humour.

Seriously, you have a great opportunity there in Isreal: serve in the IDF and apply into the Talpiot program. Even if you ultimately don't qualify the testing process is going to really build your character:
I had an oppotunity to work with many Israelis, and I was always very surprised why Israeli girls/women have more fortitude than their American and Western European boy/men peers. The answer turned out to be the service in the IDF.

After that you are going to laugh at the version of yourself who was flustered by some random loser on some random Internet board not being "nice". Unless you are "Profile 21".

When a transaction is created, the BTC is put into Outputs. These Outputs have a script with them that allows someone to redeem (include as an Input in another transaction) if the script executes as true when the correct parameters are provided. Usually, the script just requires the signature of the recipient (owner of public/private keys). BUT, you can, for instance, create a script that allows anyone to redeem, or a script that requires multiple signatures. Thus, it is not possible to associate every unspent transaction Output (UTxO) with a wallet/balance, because what wallet would you put multisignature transactions into, or any other weird non-standard but possible script? Your method would essentially delete the scripting functionality from Bitcoin and leave only standard, address-to-address transactions possible.

Why not just say that and give a pointer to such a discussion?

I think his point was that this idea is suggested here quite frequently, and has already debunked for a large number of reasons.

Why are you not nice to people you don't know?
Nobody made you respond if you didn't feel like it, and if you did, you may as well have done it in a nice and polite manner.

Please try to be a bit more specific than FAIL, I don't have anything smart to say about 'FAIL'.


Who gets to decide what is 'Right' and what is 'Wrong'? In my plan the snapshot database keeps wallets & balances. There is no use for unspent transaction outputs in a static snapshot of the balances.


Some people are more comfortable with thinking alone and coming up with a complete answer, others like to discuss options / suggestions & exchange knowledge / ideas / criticism with others. I guess you are the first type, I am more of the second type, and I respect your way of thought / work - please respect mine.

Still graded FAIL, but shows promise. BTW, reading stackexchange is not doing homework. StackExchange is shaping up to be a premiere resource for pretenders lacking education, it gets really good at consolidating the mutual admiration rings of upvoters.

1) "addresses carying balance" is a wrong measure. You need to count the "unspent transaction outputs" (UTxO)
2) search this board for "ultraprune" and other discussions of pruning

What happened to the old "researching the field first, thinking it through second and publishing it last?"

It's not really that simple in reality, since bitcoin wallet contents aren't really just numbers, but scripts. You could still merge the standard format transactions though, I guess.

AFAIK KISS means "Keep it SIMPLE, stupid"

Anyways, I did my homework and here are my results:

Let's assume 5 million non-zero balance wallets rough estimate - see http://bitcoin.stackexchange.com/questions/2828/how-many-bitcoin-addresses-are-have-been-carrying-a-balance

With 20 bytes for the address and 5 bytes for the balance, I ended up with an S block of 125 Mb.

Of course, such a block would save X * [average block size] of disk space, so all is left is to make X large enough for optimum benefit.

Validating such a block is not very hard if you already compute what should be in there on your idle time, knowing that an S block is coming soon.

I realize that such a block is hard to transmit due to its size, so optionally such snapshots can be off the blockchain, meaning every full node holds both a blockchain (which holds the transactions) AND a startup snapshot.

[EDIT] Thinking about it a bit more, the startup snapshot doesn't need to be transmitted as all full nodes can compute it locally on idle times, all that is needed is a snapshot hash embedded to S blocks. Of course new nodes would need to download both the snapshot AND the blockchain (which would be cheaper than downloading a bloated blockchain only).

[EDIT 2] 5 million non-zero wallets gives a 125 Mb snapshot, 50 million -> 1.25 Gb, 500 million -> 12.5 Gb, 5 billion -> 125 Gb. I think we can happily live with that.

How about it?

It is KISS as "Keep it slow and stupid". For homewhork please estimate the size of your proposed "S block" and the time it will take to transmit and verify it.

Hi guys,
I have been looking for the right place to put my idea and get your input, and couldn't find the right place, so I'm putting it here.

My suggestion is to add a very simple (KISS) pruning method for the blockchain, so we don't need to worry (or worry much less) about block sizes and the bloating of the blockchain.

So, I suggest adding a snapshot block every X blocks (2016?), this snapshot dates back Y blocks (420000?) and consists of all the non-empty wallets and their balance.

After such a block is mined (let's call it S), all full-nodes validate it and can safely drop all blocks BEFORE S-Y.

Such nodes are not needed so far, as HEAD-Y < 0, but will start when we reach Y+2*X.

What do you think? Did I re-invent the wheel or is it new?

Thanks,
Gil