There are additional verifications but you can't get something for nothing.
A transaction having 225 bytes is replaced with its 32 byte hash in the block where it is fully spent and the same 32 byte hash in the block of origin.
This is a 3.5 times compression of blocksize, for bigger transactions the ratio increases.
So this kind of blocksize bloat will be very hard to notice.
Topic: Blockchain optimisation BIP (Read 619 times)
I think it would be useless. New nodes synchronizing would still want to verify all that data themselves to ensure it is correct. (I think?) It would increase bloat in blocksize.
Thanks for the answer and for the work you are doing.
There are at least two faults in one sentence, I should have written fully spent transaction hashes and fully spent block numbers.
This would allow a node to receive and to store blocks with fully spent transactions replaced with only their hashes, when synchronizing blockchain backwards from the last block to the first one.
There are at least two faults in one sentence, I should have written fully spent transaction hashes and fully spent block numbers.
This would allow a node to receive and to store blocks with fully spent transactions replaced with only their hashes, when synchronizing blockchain backwards from the last block to the first one.
Add spent transaction hashes and spent block numbers in mined block.
spent transaction hashes are there, spent block numbers are not needed: the blockchain is not used to validate transactions.
Add spent transaction hashes and spent block numbers in mined block.
Jump to: