<unnamed>

Public Key

npub1n4mfz49w8xq76xc6uy55jlzjymk38gy5lswc9lrqksqqu4xlam7sft6mlq

Profile Code

nprofile1qqsf6a532jhrnq0drvdwz22f03fzdmgn5z20c8vzl3stgqqw2n07algpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgqg5waehxw309aex2mrp0yhxgctdw4eju6t0qyxhwumn8ghj7mn0wvhxcmmvckgwr0

Publishing to

relay.primal.net

relay.damus.io

nos.lol

Last Notes

2023-06-07 17:47:54 UTC

- reply

📅 Original date posted:2016-01-19
📝 Original message:On Monday, January 18, 2016 12:14:16 PM Wladimir J. van der Laan wrote:
> It has been tested in git for almost half a year. This RC is the first
> binary release that contains the functionality.
>
> It is extremely unlikely that the wallet will eat your coins (always backup
> nevertheless), but I can't guarantee there won't be some issue where the
> wallet and chain get out of sync and you're forced to redownload the
> blockchain.
I think I asked the wrong way, sorry: My question was not really meant at
whether it is bug-free (testing that is the purpose of a release candidate, so
we of course don't know yet), but rather whether it is at least feature
complete now.
Remember, the previous v0.11.0 release notes said:
> Block pruning is currently incompatible with running a wallet due to the
> fact that block data is used for rescanning the wallet and importing keys
> or addresses (which require a rescan.) However, running the wallet with
> block pruning will be supported in the near future, subject to those
> limitations.
So I'm interested whether this limitation has been lifted, and the whole
feature is considered as finished.
If yes, I would highly recommend advertising it in the new release notes - as
said, the disk space reduction is a big deal.
Thank you!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160119/54b4bd69/attachment-0001.sig>

2023-06-07 17:47:54 UTC

- reply

📅 Original date posted:2016-01-25
📝 Original message:On Monday, January 25, 2016 01:03:17 PM Wladimir J. van der Laan wrote:
> > If yes, I would highly recommend advertising it in the new release notes -
> > as said, the disk space reduction is a big deal.
>
> Good idea, has been added by Marco Falke in commit fa31133,
Thanks. The RC2 changelog now says:
> To enable block pruning set prune=<N> on the command line or in
> bitcoin.conf, where N is the number of MiB to allot for raw block & undo
> data.
From having read the Bitcoin whitepaper quite a few months ago ago, I have the
very very basic understanding that pruning is meant to:
- delete old transaction data which merely "moves coins around"
- instead only store the "origin" (= block where coins were mined) and
"current location" of the coins, i.e. the unspent transactions. Notably, I
understood it as "this is as secure as storing everything, since we know where
the coins were created, and where they are".
So from that point of view, I would assume that there is a "natural" amount of
megabytes which a fully pruned blockchain consists of: It would be defined by
the final amount of unspent coins.
I thereby am confused why it is possible to configure a number of megabytes
"to allot for raw block & undo data". I would rather expect pruning just to be
a boolean on/off flag, and the number of megabytes to be an automatically
computed result from the natural size of the dataset.
And especially, I fear that I could set N too low, and as a result, it would
delete "too much". I mean could this result in even security relevant
transaction data being deleted?
Thus, it would be nice if you could yet once more edit the release notes to:
- explain why a N must be given
- what a "safe" value of N is. I.e. how large must N be at least to not delete
security-relevant stuff?
- maybe mention if there is a "auto" setting for N to ensure that it choses a
safe value on its own?
Sorry if my descriptions are from a layman's point of view. I intentionally
did *not* re-read the Bitcoin whitepaper to have a better understanding:
I think having a layman's understanding is a good usability test for such
stuff.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160125/87785117/attachment.sig>

2023-06-07 17:47:54 UTC

- reply

📅 Original date posted:2016-01-17
📝 Original message:On Sunday, January 17, 2016 11:08:08 AM Wladimir J. van der Laan via bitcoin-
dev wrote:
> Preliminary release notes for the release can be found here:
>
> https://github.com/bitcoin/bitcoin/blob/0.12/doc/release-notes.md
The part which lists raw Git pull requests says:
> #6057 ac5476e re-enable wallet in autoprune
But the main, handwritten part does not mention this.
Is pruning really finished, i.e. could I safely use it as a wallet "end-user"?
IMHO it would be one of the most interesting feature for users, as it could
fix the issue of taking >60 GB of disk space.
So if it is finished, please mention that
- it's finished
- how to enable it.
Thanks for your hard work! :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160117/8190b24a/attachment.sig>

2023-06-07 17:31:49 UTC

- reply