Hi all,
I've also been spending a few months coding upon the change's Pieter has
been making with the headersfirst8 pull request.
My code updates are also ready to test, and are available on github at
https://github.com/rebroad/bitcoin/ and the branch is
"sipa-headersfirst8-patches".
I've made
When forgoing bootstrapping due to disk space constraints, you, and the
network, are likely better off -reindex-ing from current blk000??.dat files.
Which brings up an interesting point: The improvements related to the
headers first approach are likely to increase, how ever marginally, the
percent
Great work, Pieter. I've been spooling up several nodes per week lately and can
testify that stalled downloads during initial syncing are a pain. I usually
forgo bootstrapping on VPSes because I don't want to have to adjust the disk
space allocation.
With headers-first I'm saturating my home ca
On 12.10.2014 11:52, Wladimir wrote:
> On Sun, Oct 12, 2014 at 10:41 AM, Geir Harald Hansen
> wrote:
>> On 12.10.2014 01:34, Pieter Wuille wrote:
>>> * No orphan blocks stored in memory anymore (reducing memory usage during
>>> sync).
>>
>> Will this slow down reorgs after a fork, compared to tod
On Sun, Oct 12, 2014 at 10:41 AM, Geir Harald Hansen
wrote:
> On 12.10.2014 01:34, Pieter Wuille wrote:
>> * No orphan blocks stored in memory anymore (reducing memory usage during
>> sync).
>
> Will this slow down reorgs after a fork, compared to today?
Why would you think so? Orphan blocks are
On Sunday, October 12, 2014 8:41:29 AM Geir Harald Hansen wrote:
> On 12.10.2014 01:34, Pieter Wuille wrote:
> > * No orphan blocks stored in memory anymore (reducing memory usage during
> > sync).
>
> Will this slow down reorgs after a fork, compared to today?
It shouldn't... he's talking about
On 12.10.2014 01:34, Pieter Wuille wrote:
> * No orphan blocks stored in memory anymore (reducing memory usage during
> sync).
Will this slow down reorgs after a fork, compared to today?
Regards,
Geir H. Hansen, Bitminter
On Sat, Oct 11, 2014 at 11:34 PM, Pieter Wuille wrote:
> * Parallel block downloading (much faster sync on typical network
> connections).
"Much faster" is an understatement. Benchmarking here shows one hour
five minutes syncing to 295000. Old code isn't even at 25 after
7 hours.
(I'm us
This is great Pieter. I was able to sync the entire blockchain from
scratch in a little over 4 hours on a laptop over cable modem. :) No
issues to report. Even my family photos are intact! This makes it
practical to run a full node, part time on a laptop again.
Aaron Voisine
breadwallet.com
On S
Hi all,
I believe that a large change that I've been working on for Bitcoin
Core is ready for review and testing: headers-first synchronization.
In short, it changes the way the best chain is discovered, downloaded
and verified, with several advantages:
* Parallel block downloading (much faster sy
10 matches
Mail list logo
