I want to resurrect this thread from August/September because it seems like
a significant improvement for light clients at very little cost. From the
mailing list, it seems like this got stalled in determining how many more
bytes could be save in addition to the prev_block.
The ideas I've gathered
On Mon, Dec 11, 2017 at 1:04 PM, Gregory Maxwell wrote:
> On Mon, Dec 11, 2017 at 8:40 PM, Jim Posen via bitcoin-dev
> wrote:
> > Firstly, I don't like the idea of making the net header encoding
> dependent
> > on the specific header validation rules that Bitcoin
One of the ideas that Greg Maxwell brought up in the "'Compressed' headers
stream" thread is the possibility of a header sync mechanism that allowed
parallel download from multiple peers. With the current getheaders/headers
semantics, headers must be downloaded sequentially from genesis. In my
test
I like this proposal, it seems sufficiently general.
How are scripts with OP_CLTV and OP_CSV handled by verifiers? Do they
always succeed? Or should an nLockTime and nSequence also be included in
the proof in a way that can be parsed out and displayed to verifiers?
I assume any signatures in the
>
> Good question.. Since you don't really have the input(s), I think it's
> fine to always assume sufficient time/height on CLTV/CSV checks.
>
In this general signing-a-script context, I think a verifier might want to
see the time conditions under which it may be spent. The proof container
could
Based on some ideas that were thrown around in this thread (
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-December/015385.html),
I have been working on a P2P extension that will allow faster header sync
mechanisms. The one-sentence summary is that by encoding headers more
efficientl
ve
queries. Beyond that, the response for a particular query (start_height,
end_hash, encoding version) can be cached, so if some service wants to
precompute max size responses for all start_height multiples of 1,000, they
could cache those.
-Jim
[1] https://www.youtube.com/watch?time_continue=840
:14 GMT+02:00 Anthony Towns :
>
>> On Thu, Mar 29, 2018 at 05:50:30PM -0700, Jim Posen via bitcoin-dev wrote:
>> > Taken a step further though, I'm really interested in treating the
>> checkpoints
>> > as commitments to chain work [...]
>>
>> In that
Hey. This idea sounds quite interesting. It'd be helpful to see some more
numbers to evaluate it.
- How much bandwidth is consumed by redundant tx INVs currently? What is
this as a % of overall bandwidth usage?
- How would filtering txs through N=2 links affect network propagation?
This probably r
I'll just mention that non-interactive one-way aggregation with BLS
signatures solves this problem rather nicely.
On Mon, Apr 2, 2018 at 10:31 PM, Rusty Russell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Anthony Towns via bitcoin-dev
> writes:
> > If you've got one bundle
Why not add the outpoints owned by the wallet to the filter and watch for
those instead of elements in the input script or witness data?
On Fri, Apr 13, 2018 at 12:12 PM, Jonas Schnelli via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi Andreas
>
> Thanks for bringing this up an
ood for privacy
> anyway, so this might be a non-issue.
>
> On Sat, Apr 14, 2018, 00:17 Jim Posen via bitcoin-dev linuxfoundation.org> wrote:
>
>> Why not add the outpoints owned by the wallet to the filter and watch for
>> those instead of elements in the input script or
This construction is pretty neat and seems to solve a lot of problems. I
find the use of CLTV with past timestamps to provide ordering in particular
to be quite clever.
If my understanding is correct though, this construction would
significantly increase the safe CLTV delta requirements because HT
Can you explain why a fixed offset along the whole circuit is enough to
ensure safely as opposed to an increased delta at each hop?
On Tue, May 1, 2018, 5:05 AM Christian Decker
wrote:
> Jim Posen writes:
> > If my understanding is correct though, this construction would
> > significantly incre
I'm still not following why this doesn't accumulate.
In the example route, let's look at it from the point of view of C. C sees
the following regardless of whether D or E or someone behind E is the last
hop in the route:
B -> HTLC(expire = X + delta) -> C -> HTLC(expire = X) -> D
So D is not req
OK, I see what you are saying. You are effectively suggesting pipelining
the broadcasts of the update transactions. I think this introduces a
problem that a node in the circuit that withholds the preimage for too long
can force all upstream channels to be closed, at only the expense of their
one up
That is a good observation that most of the historical data does not need
to be kept around. I believe what you are suggested is already implemented,
however. Bitcoin Core can operate in a pruned mode, where the bulk of the
historical block data is discarded and only the current UTXO set (and a few
>
> This brings us another theoretical problem: someone could spend our
> OP_TRUE with a low-fee non-RBF tx, and we'd not be able to use it to
> CPFP the tx. It'd be hard to do, but possible. I think the network
> benefits from using OP_TRUE (anyone can clean, and size, vs some
> only-known-to-me
>
> I think lite clients cross checking is something which very likely
> will never be implemented by anyone, and probably not stay working
> (due to under-usage) if it is implemented. This thought is driven by
> three things (1) the bandwidth overhead of performing the check, (2)
> thinking abou
>
> It isn't a question of 'some lite clients' -- I am aware of no
> implementation of these kinds of measures in any cryptocurrency ever.
>
Doesn't mean there can't or shouldn't be a first. :-)
> The same kind of comparison to the block could have been done with
> BIP37 filtering, but no one ha
>
> My suggestion was to advertise a bitfield for each filter type the node
> serves,
> where the bitfield indicates what elements are part of the filters. This
> essentially
> removes the notion of decided filter types and instead leaves the decision
> to
> full-nodes.
>
I think it makes more sen
sing the whole thing and has slower lookups than an uncompressed
> version. Writing such a thing sounds like an interesting project though.
>
> On Wed, May 23, 2018 at 4:48 PM, Jim Posen via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> I decided to lo
> Is there an application that requires watching for output scripts that
> doesn't also require watching for input scrips (or, less efficiently,
> input outpoints)?
>
Certain wallets may be able to use only the output script filter by using
output scripts to watch for confirmations on sent transac
To address the at-least-one-honest peer security assumption for light
clients, I think this is a rather good security model for light clients.
First it significantly reduces the chances that an attacker can eclipse a
client just by chance, and clients can implement measures like ensuring
connectivi
>
> I was wondering why this multi-layer multi-block filter proposal isn't
> getting any comment,
> is it because not asking all filters is leaking information?
>
It's an interesting idea, but it adds more complexity to the client and
could be added later on if clients adopt BIP 157 and complain a
>
> I don't understand this comment. The bandwidth gains are not from
> address reuse, they are from the observed property that false
> positives are independent between two filters. I.e. clients that
> connect once a day will probably download 2-3 filters at most, if they
> had nothing relevant in
I generally like the direction of this proposal in terms of allowing full
nodes to run with a different storage/bandwidth tradeoff. Cory, were this
implemented, would you expect Core to support both operating modes (full
UTXO set and UHS) depending on user configuration, or would UHS be
mandatory?
This is awesome, nice work!
On Mon, Jul 2, 2018 at 4:16 PM Roman Zeyde via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hello all,
>
> I was working on this project for the last few months, so a user could run
> his own Electrum server, with required hardware resources not much b
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 f
Big Concept ACK. I think this would be one of the biggest usability
improvements for Bitcoin and I see no security issues with the assumevalid
approach. I also agree that it's important to start work on this even
before the ultimate, perfect accumulator has been designed/tested and the
commitment s
>
> Learning C++ is something within everyone's capability. Even people who do
> not
> wish to learn it can hire someone to perform review for them.
>
Anyone with enough knowledge of C++ to audit the entire the Bitcoin Core
codebase is more than capable of running it with assumeutxo disabled and
c
31 matches
Mail list logo