From: Tier Nolan <tier.nolan@gmail•com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] "Compressed" headers stream
Date: Mon, 11 Dec 2017 22:41:50 +0000 [thread overview]
Message-ID: <CAE-z3OUetqa16Ub792dCXodpzafsgMyvO9QaVNWJ3bKZ59HWVQ@mail.gmail.com> (raw)
In-Reply-To: <CADZtCSi1vimZ88kqG=HQHa3sHeLtvMjdJrZuqS2=iYr-=EHaLw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1837 bytes --]
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
> <https://github.com/bitcoin/bitcoin/compare/master...jimpo:compact-headers-difficulty>.
> The downside is that it is more complex because it leaks into the
> validation code. The extra 4 byte savings is certainly nice though.
>
A compromise would be to have 1 byte indicating the difference since the
last header.
Since the exponent doesn't use the full range you could steal bits from
there to indicate mode.
- no change
- mantissa offset (for small changes)
- full difficulty
This would support any nBits rule and you say 3 of the 4 bytes.
> Can you elaborate on how parallel header fetching might work? getheaders
> requests could probably already be pipelined, where the node requests the
> next 2,000 headers before processing the current batch (though would make
> sense to check that they are all above min difficulty first).
>
I suggest adding a message where you can ask for the lowest N hashes
between 2 heights on the main chain.
The reply is an array of {height, header} pairs for the N headers with the
lowest hash in the specified range.
All peers should agree on which headers are in the array. If there is
disagreement, then you can at least narrow down on which segment there is
disagreement.
It works kind of like a cut and choose. You pick one segment of the ones
he gave you recursively.
You can ask a peer for proof for a segment between 2 headers of the form.
- first header + coinbase with merkle branch
- all headers in the segment
This proves the segment has the correct height and that all the headers
link up.
There is a method called "high hash highway" that allows compact proofs of
total POW.
[-- Attachment #2: Type: text/html, Size: 2865 bytes --]
next prev parent reply other threads:[~2017-12-11 22:42 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-11 20:40 Jim Posen
2017-12-11 21:04 ` Gregory Maxwell
2017-12-11 21:56 ` Jim Posen
2017-12-11 22:41 ` Tier Nolan [this message]
2017-12-11 23:11 ` Gregory Maxwell
2017-12-12 21:07 ` Suhas Daftuar
2017-12-13 0:01 ` Gregory Maxwell
2017-12-13 0:12 ` Gregory Maxwell
-- strict thread matches above, loose matches on Subject: below --
2017-08-28 15:50 Riccardo Casatta
2017-08-28 16:13 ` Greg Sanders
2017-08-28 16:25 ` Riccardo Casatta
2017-08-28 16:26 ` Greg Sanders
2017-09-04 14:10 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAE-z3OUetqa16Ub792dCXodpzafsgMyvO9QaVNWJ3bKZ59HWVQ@mail.gmail.com \
--to=tier.nolan@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox