On 2/4/19 8:18 PM, Jim Posen via bitcoin-dev wrote:
- snip -
> 1) Introduce a new P2P message to retrieve all prev-outputs for a given
> block (essentially the undo data in Core), and verify the scripts
> against the block by executing them. While this permits some forms of
> input script mallea
Hi Laolu,
The only advantage I see in the current design choice is filter size, but even
that is less
impressive in recent history and going forward, as address re-use is much less
frequent nowadays
than it was Bitcoin’s early days.
I calculated total filter sizes since block 500,000:
input sc
Hi Matt,
> In (the realistic) thread model where an attacker is trying to blind you
> from some output, they can simply give you "undo data" where scriptPubKeys
> are OP_TRUE instead of the real script and you'd be none the wiser.
It depends on the input. If I'm trying to verify an input that's P
Hi Tamas,
> The only advantage I see in the current design choice is filter size, but
> even that is less impressive in recent history and going forward, as
address
> re-use is much less frequent nowadays than it was Bitcoin’s early days.
Gains aren't only had with address re-use, it's also the c
Hi Laolu,
space savings come with the rather serious current disadvantage, that a light
client is not
in the position to check the filter. Also the advanced uses you mention are
subject to this, for now.
Building more on a shaky fundament does not make it look better.
Now that we have seen ad
It's not quite enough to just do SHA512, you missed out this condition
(incredibly rare as it is):
> In case IL is 0 or ≥n, the master key is invalid.
Also I can't see how I would use this to seed a hardware wallet that
requires a BIP39 seed as mentioned in your abstract.
For both of those reaso
