I would suggest 50+ 6-sided dice rolls, giving about 128 bits of entropy.
Compared to a shuffle, it's easier to be sure that you got the right amount
of entropy, even if the dice are somewhat biased.
On Mon, Feb 4, 2019 at 2:33 PM James MacWhyte via bitcoin-dev <
Hi Tamas,
This is how the filter worked before the switch over to optimize for a
filter containing the minimal items needed for a regular wallet to function.
When this was proposed, I had already implemented the entire proposal from
wallet to full-node. At that point, we all more or less decided
James
On Sun, Feb 3, 2019 at 10:27 AM Ryan Havar via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Conveniently a shuffled deck of cards also can serve as a physical backup
> which is easy to hide in plain sight with great plausible deniability.
>
To make sure someone doesn't
I participated in that discussion in 2018, but have not had the insight
gathered by now though writing both client and server implementation of
BIP157/158
Pieter Wuille considered the design choice I am now suggesting here as
alternative (a) in:
Please see the thread "BIP 158 Flexibility and Filter Size" from 2018
regarding the decision to remove outpoints from the filter [1].
Thanks for bringing this up though, because more discussion is needed on
the client protocol given that clients cannot reliably determine the
integrity of a block
TLDR: a change to BIP158 would allow decision on which filter chain is correct
at lower bandwith use
Assume there is a BIP157 client that learned a filter header chain earlier and
is now offered an alternate reality by a newly connected BIP157 server.
The client notices the alternate reality
Unlike mouse movement it works in a CLI software, which is great. However,
isn't there something else you can use instead of cards? Something with
invariant culture and maybe more common.
On Sun, Feb 3, 2019 at 7:27 PM Ryan Havar via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
