xor at freenetproject.org [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2016-01-17 to 2016-01-25
💬 Posted a total of 6 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 17:48:03

- reply

📅 Original date posted:2016-01-23
📝 Original message:On Thursday, January 21, 2016 03:14:47 PM Rusty Russell wrote:
> +1s here means simpling say "+1" or "me too" that carries no additional
> information. ie. if you like an idea, that's great, but it's not worth
> interruping the entire list for.
>
> If you say "I prefer proposal X over Y because <reasons>" that's
> different. As is "I dislike X because <reasons>" or "I need X because
> <reasons>".
So "+1"ing is OK as long as I provide a technical explanation of why I agree?
While I still think that this is too much of a restriction because it prevents
peer-review, I would say that I could live with it as a last resort if you
don't plan to abolish this rule altogether.
So in that case, to foster peer review, I would recommend you amend the rules
to clarify this.
Example: "+1s are not allowed unless you provide an explanation of why you
agree with something".
-------------- 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/20160123/710d3845/attachment.sig>

2023-06-07 17:48:02

- reply

📅 Original date posted:2016-01-21
📝 Original message:On Thursday, January 21, 2016 11:20:46 AM Rusty Russell via bitcoin-dev wrote:
> So, what should moderation look like from now on?
The original mail which announced moderation contains this rule:
> - Generally discouraged: [...], +1s, [...]
I assume "+1s" means statements such as "I agree with doing X".
Any sane procedure of deciding something includes asking the involved people
whether they're for or against it.
If there are dozens of proposals on how to solve a particular technical
problem, how else do you want to decide it than having a vote?
It's very strange that this is not allowed - especially if we consider that
the Bitcoin community is in a state of constant dissent currently.
The effect is likely that you push the actual decision-making to IRC, which
less people have access to (since it's difficult to bear the high traffic),
and thus form some kind of "inner circle" - which makes decisions seem even
more as if they're being dictated.
So please consider allowing people to say whether they agree with something
something or don't.
Other than that, thanks for the good latency of moderation, I guess you're
doing hard work there :)
-------------- 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/20160121/aee4edba/attachment.sig>

2023-06-07 17:47:56

- reply

📅 Original date posted:2016-01-25
📝 Original message:On Monday, January 25, 2016 04:05:59 PM Wladimir J. van der Laan wrote:
> I don't have time to work on the release notes right now, but if someone
> else wants to contribute that'd be awesome.
I cooked my first pull request to resolve this:
https://github.com/bitcoin/bitcoin/pull/7416
Thanks for all the explanations you folks provided! :)
-------------- 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/603d7652/attachment.sig>

2023-06-07 17:47:54

- 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

- 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

- 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>

- reply

- reply

- reply

- reply