Jim Posen,
A few years ago you mentioned roastbeef’s proposal of a P2P message to
retrieve all prev-outputs for a given block:
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
On Thu, 7 Feb 2019 at 12:19, Tamas Blummer via bitcoin-dev
wrote:
> I did restart the discussion which I read and participated in at its first
> instance because implementing the current proposal taught me how problematic
> as is until not committed and because I have not seen a sign to assume
The attack was in your implication that I would assume ill intent of those
contributed to the proposal. That is not my position. I explained why, I
think, rolling out a commitment could face opposition. This foreseable
opposition, that must not come from you makes me prefer a provable
uncommitted
I do not think this ad hominem attack of you on me was justified.
I wrote code, gathered and shared data now and back in 2018. I showed
understanding of non technical issues. Is there an actual action that
defies my observation that a commitment is not yet in sight?
Is there anything technically
On Wed, Feb 6, 2019 at 8:10 AM Tamas Blummer wrote:
> I am skeptical that commitment of any filter will come into Core soon. [...]
> A committed filter makes light clients much more reliable and attractive, for
> some taste too much more.
You keep repeating this smear. Please stop.
If you
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
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
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
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
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
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
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
14 matches
Mail list logo
