Re: [bitcoin-dev] assumeutxo and UTXO snapshots

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

Re: [bitcoin-dev] assumeutxo and UTXO snapshots

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

Re: [bitcoin-dev] Interrogating a BIP157 server, BIP158 change proposal

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

Re: [bitcoin-dev] An efficient re-implementation of Electrum Server in Rust

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

Re: [bitcoin-dev] UHS: Full-node security without maintaining a full UTXO set

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?

Re: [bitcoin-dev] BIP 158 Flexibility and Filter Size

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

Re: [bitcoin-dev] BIP 158 Flexibility and Filter Size

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

Re: [bitcoin-dev] BIP 158 Flexibility and Filter Size

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

Re: [bitcoin-dev] BIP 158 Flexibility and Filter Size

> 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

Re: [bitcoin-dev] TXO bitfield size graphs

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

Re: [bitcoin-dev] BIP 158 Flexibility and Filter Size

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

Re: [bitcoin-dev] BIP 158 Flexibility and Filter Size

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

Re: [bitcoin-dev] BIP 158 Flexibility and Filter Size

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

Re: [bitcoin-dev] Making OP_TRUE standard?

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

Re: [bitcoin-dev] Why not archive the backend of Bitcoin blockchain?

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

Re: [bitcoin-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts

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

Re: [bitcoin-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts

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

Re: [bitcoin-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts

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

Re: [bitcoin-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts

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

Re: [bitcoin-dev] BloomFilter issue with segwit addresses

ivacy > anyway, so this might be a non-issue. > > On Sat, Apr 14, 2018, 00:17 Jim Posen via bitcoin-dev <bitcoin-dev@lists. > 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

Re: [bitcoin-dev] BloomFilter issue with segwit addresses

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

Re: [bitcoin-dev] Signature bundles

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

Re: [bitcoin-dev] Low-bandwidth transaction relay

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

Re: [bitcoin-dev] Optimized Header Sync

s <a...@erisian.com.au>: > >> 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

[bitcoin-dev] Optimized Header Sync

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

Re: [bitcoin-dev] {sign|verify}message replacement

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

Re: [bitcoin-dev] {sign|verify}message replacement

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

[bitcoin-dev] Parallel header download during sync

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

Re: [bitcoin-dev] "Compressed" headers stream

On Mon, Dec 11, 2017 at 1:04 PM, Gregory Maxwell <g...@xiph.org> wrote: > On Mon, Dec 11, 2017 at 8:40 PM, Jim Posen via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> wrote: > > Firstly, I don't like the idea of making the net header encoding > dependent

[bitcoin-dev] "Compressed" headers stream

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