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

On Tue, Dec 12, 2017 at 9:07 PM, Suhas Daftuar wrote: > I agree with this. Specifically the way I envisioned this working is that > we could introduce a new 'cmpctheaders'/'getcmpcthdrs' message pair for > syncing using this new message type, while leaving the existing >

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

On Tue, Dec 12, 2017 at 9:07 PM, Suhas Daftuar wrote: > But I think we should be able to get nearly all the benefit just by > including nBits in any messages where the value is ambiguous; ie we include > it with the first header in a message, and whenever it changes from the >

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

Hi, First, thanks for resurrecting this, I agree this is worth pursuing. On Mon, Dec 11, 2017 at 4:04 PM, Gregory Maxwell via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > Nbits _never_ needs to be sent even with other consensus rules because > its more or less necessarily a

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

On Mon, Dec 11, 2017 at 10:41 PM, Tier Nolan via bitcoin-dev wrote: > There is a method called "high hash highway" that allows compact proofs of > total POW. That provides no security without additional consensus enforced commitments, so I think pretty

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

On Mon, Dec 11, 2017 at 9:56 PM, Jim Posen via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Omitting nBits entirely seems reasonable, I wrote up a possible > implementation here > . > The

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

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

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

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 uses (eg. the fact that > difficulty is only recalculated

[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

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

On Mon, Aug 28, 2017 at 12:26:48PM -0400, Greg Sanders via bitcoin-dev wrote: > Well, if anything my question may bolster your use-case. If there's a > heavier chain that is invalid, I kind of doubt it matters for timestamping > reasons. Timestamping can easily be *more* vulnerable to malicious

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

Well, if anything my question may bolster your use-case. If there's a heavier chain that is invalid, I kind of doubt it matters for timestamping reasons. /digression On Mon, Aug 28, 2017 at 12:25 PM, Riccardo Casatta < riccardo.casa...@gmail.com> wrote: > > 2017-08-28 18:13 GMT+02:00 Greg

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

Is there any reason to believe that you need Bitcoin "full security" at all for timestamping? On Mon, Aug 28, 2017 at 11:50 AM, Riccardo Casatta via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi everyone, > > the Bitcoin headers are probably the most condensed and important

[bitcoin-dev] "Compressed" headers stream

Hi everyone, the Bitcoin headers are probably the most condensed and important piece of data in the world, their demand is expected to grow. When sending a stream of continuous block headers, a common case in IBD and in disconnected clients, I think there is a possible optimization of the