I think a slight problem with this is that wallets (often ones made by
third party wallet software) do not fully empty. I don't know how often
this happens, but some wallets, even if you tell them to send all funds,
leave a small fraction of bitcoin remaining. If this is the case, it could
be detri
>>> 5) The problem with node pruning is that it is not standardized, and
for a new node to enter the network and to verify the data, it needs to
download all data and prune it by itself. This will drastically lower the
information needed by the full nodes by getting rid of the junk. Currently
we a
I also like only keeping the last "n" blocks. Every "n" minus all the previous
balances are kept, but the transactions are deleted. There's good enough record
keeping, and there's excessive. Part of scaling is being able to get the
blockchain and sync quickly.
Jason
Original Message -
This is a link to the most updated version of the problem and my proposed
solution, granted it still needs work, but this problem needs to be
resolved quickly. So I hope it will receive the attention it deserves, even
if the solution comes from somebody else.
https://bitcointalk.org/index.php?topic
How do you trust your <1000 block blockchain if you don't
download/validate the whole thing? (I know it should be easy to spot
that by looking at the blocks/tx or comparing to other nodes, but from a
programmatic point of view this is much harder). You can of course
include a checkpoint in the code
Regarding storage space, have you heard about pruning? Probably you should.
On 27 Aug 2017 12:27 am, "Adam Tamir Shem-Tov via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Thank You Christian for your response.
>
> https://bitcointalk.org/index.php?topic=473.0 : I dont see the r