MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII; format=flowed
Message-id: <543A52A1.2010408@bitminter.com>
Date: Sun, 12 Oct 2014 12:06:25 +0200
From: Geir Harald Hansen <operator@bitminter.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101
	Thunderbird/31.1.2
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
References: <CAPg+sBjG86ZYKZZXA4VCMiFhz0sdxr_so41Zr+DATOXyRa9_Jw@mail.gmail.com>
	<543A3EB9.4040803@bitminter.com>
	<CA+s+GJA=zgacbURh83DKyAV=x_t15xT=5cJTwSY8Omk2XZyuxA@mail.gmail.com>
In-reply-to: <CA+s+GJA=zgacbURh83DKyAV=x_t15xT=5cJTwSY8Omk2XZyuxA@mail.gmail.com>
Subject: Re: [Bitcoin-development] Request for review/testing: headers-first
 synchronization in Bitcoin Core
Precedence: list

On 12.10.2014 11:52, Wladimir wrote:
> On Sun, Oct 12, 2014 at 10:41 AM, Geir Harald Hansen
> <operator@bitminter.com> 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 blocks whose parent is not
> known. In the case of a reorganization the client 'jumps' to a new
> best chain, for this to happen the original tip and the new best tip
> and all their parents must be already known.

I was thinking of shorter sides of forks as being orphaned. Sorry for 
the confusion.

Regards,
Geir H. Hansen, Bitminter