path: root/5b/e9aa30d798337a84b3a2c49af908f93047ee10

Return-Path: <jgarzik@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id EA76B1A5E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 29 Sep 2015 13:04:22 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com
	[209.85.212.171])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D1D8B1BA
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 29 Sep 2015 13:04:10 +0000 (UTC)
Received: by wicfx3 with SMTP id fx3so149372843wic.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 29 Sep 2015 06:04:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=qUnzaeAqYdkt7bNap8iwL5qBrBixVRjkDd2FsHz28FY=;
	b=AJiUwQsNXTKmvCGps9WLAwj9NqbX8YgMyM/dazI/FTxtFx9cz+pc8H/ePrPBTnD8I/
	gnWsFlYB2z3i/hJRJXBCj7qqWR50Prc30dcwTOzAw32dZPBNXGP0N2J4BZgauXfmbx4+
	M5Mq1kVLyyTTiwanYfjjWCFhI0AjsGap20eAyzcTSIlsiv4IoHpFC097NA39UXM2KVBF
	mNJHc5mgSKcfuTnUVMwMYWYz6UhNxWufMIDwgou35082Xx0dRPVIoChvmI0eWbISVtys
	QQ+dVv6d6/z+wL9+GAoUnLNOt7X8XpCtpWymdovm9k3By/9xaBO2sl/gGxAov7uRp7sj
	9pdA==
MIME-Version: 1.0
X-Received: by 10.180.37.232 with SMTP id b8mr26674450wik.46.1443531849326;
	Tue, 29 Sep 2015 06:04:09 -0700 (PDT)
Received: by 10.28.158.9 with HTTP; Tue, 29 Sep 2015 06:04:09 -0700 (PDT)
In-Reply-To: <CAGLBAhciSUZuKTcKmKFxy5O3Pmou=_-PG9Dk5m=y9p3TSBikAA@mail.gmail.com>
References: <CADm_WcY8Vy+k+5BaBS+jV6D6tmSXrok8rAxoPxxKOzUhyPWgMg@mail.gmail.com>
	<CABm2gDoXa9ERY7iSsouxjypq1PwV_9HuBrtFQ_jrs5pGFst=KQ@mail.gmail.com>
	<CAGLBAhciSUZuKTcKmKFxy5O3Pmou=_-PG9Dk5m=y9p3TSBikAA@mail.gmail.com>
Date: Tue, 29 Sep 2015 09:04:09 -0400
Message-ID: <CADm_WcYDXLX2QDpTDxQRQXve8QTJH8u+zb_oy6FrXdocqCmYJg@mail.gmail.com>
From: Jeff Garzik <jgarzik@gmail.com>
To: Dave Scotese <dscotese@litmocracy.com>
Content-Type: multipart/alternative; boundary=e89a8f64725319e7630520e273b1
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] libconsensus and bitcoin development process
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Sep 2015 13:04:23 -0000

--e89a8f64725319e7630520e273b1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

There seemed to be some agreement on IRC - after a bit of haranguing by
myself :) -- that large refactors should (a) occur over a small window of
time and (b) have a written plan beforehand.



On Tue, Sep 22, 2015 at 7:49 PM, Dave Scotese <dscotese@litmocracy.com>
wrote:

> If I'm reading this situation correctly, Jeff is basically pointing out
> that developers need more links (hooks, rungs, handholds, data points,
> whatever you want to call them) so that they can see all the things his
> email insinuated are missing (a plan, order, sense, etc.).  He didn't say
> these things were missing, but that it kind of feels like it from the
> 10,000 foot view.
>
> If you use Google to search the list, as in <<site:
> lists.linuxfoundation.org libconsensus plan>> you DO NOT get the page
> Jorge gave.  He wrote that page, so he had a good idea what to search for
> to find it again.  I just want to recommend that when you describe the wo=
rk
> you're doing on bitcoin, imagine several different ways people might try =
to
> find this description in the future and make them work.  In other words,
> Jorge could have put "A plan for abstracting out libconsensus" in the ema=
il
> where he wrote "Here are some things that need to happen first..."
>
> Likewise, if Jeff had searched for <<site:lists.linuxfoundation.org
> libconsensus plan>> (maybe he did, but he didn't list any results), he ma=
y
> have found enough clues to see Jorge's overall plan.  The "site:" keyword
> on Google fascinated me when I discovered it, so I let it inspire this
> email :-)
>
> Maybe someone can explain this if I have it wrong: A few people are able
> to pull code into Bitcoin/bitcoin.  Isn't is possible that those few peop=
le
> can agree to merge in a lot of refactor-hell PRs for those making the
> requests, but postpone them to that one-week-per-month that someone
> suggested?  The idea of letting that "hell" come in (predictable) waves i=
s
> excellent and I was hoping to see some agreement.  But I don't know who
> those few are, so even if they all wrote "Yeah, we'll do that," I wouldn'=
t
> recognize that I got what I wanted.
>
> notplato
>
> On Tue, Sep 22, 2015 at 11:12 AM, Jorge Tim=C3=B3n <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On Tue, Sep 15, 2015 at 6:10 AM, Jeff Garzik via bitcoin-dev
>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> > [collating a private mail and a github issue comment, moving it to a
>> > better forum]
>> >
>> > On libconsensus
>> > ---------------
>> > In general there exists the reasonable goal to move consensus state
>> > and code to a specific, separate lib.
>> >
>> > To someone not closely reviewing the seemingly endless stream of
>> > libconsensus refactoring PRs, the 10,000 foot view is that there is a
>> > rather random stream of refactors that proceed in fits and starts
>> > without apparent plan or end other than a one sentence "isolate
>> > consensus state and code" summary.
>> >
>> > I am hoping that
>> > * There is some plan
>> > * We will not see a five year stream of random consensus code movement
>> > patches causing lots of downstream developer headaches.
>> >
>> > I read every code change in every pull request that comes into
>> > github/bitcoin/bitcoin with three exceptions:
>> > * consensus code movement changes - too big, too chaotic, too
>> > frequent, too unfocused, laziness guarantees others will inevitably
>> > ACK it without me.
>> > * some non-code changes (docs)
>> > * ignore 80% of the Qt changes
>> >
>> > As with any sort of refactoring, they are easy to prove correct, easy
>> > to reason, and therefore quick and easy to ACK and merge.
>> >
>> > Refactors however have a very real negative impact.
>> > bitcoin/bitcoin.git is not only the source tree in the universe.
>> > Software engineers at home, at startups, and at major companies are
>> > maintaining branches of their own.
>> >
>> > It is very very easy to fall into a trap where a project is merging
>> > lots of cosmetic changes and not seeing the downstream ripple effects.
>> > Several people complained to me at the conference about all the code
>> > movement changes breaking their own work, causing them to stay on
>> > older versions of bitcoin due to the effort required to rebase to each
>> > new release version - and I share those complaints.
>> >
>> > Complex code changes with longer development cycles than simple code
>> > movement patches keep breaking.  It is very frustrating, and causes
>> > folks to get trapped between a rock and a hard place:
>> > - Trying to push non-trivial changes upstream is difficult, for normal
>> > and reasonable reasons (big important changes need review etc.).
>> > - Maintaining non-trivial changes out of tree is also painful, for the
>> > aforementioned reasons.
>> >
>> > Reasonable work languishes in constant-rebase hell, and incentivizes
>> > against keeping up with the latest tree.
>> >
>> >
>> > Aside from the refactor, libconsensus appears to be engineering in the
>> > dark.  Where is any sort of plan?  I have low standards - a photo of a
>> > whiteboard or youtube clip will do.
>>
>> Just because you don't understand the changes proposed it doesn't mean
>> that they are random.
>> I may have done a poor job in communicating "my plan for libconsensus"
>> but I have tried many times and in many ways.
>> #bitcoin-dev logs show that I have not worked "in the dark" at all, on
>> the contrary, I've been very tenacious when asking for review and
>> opinions, to the point that several people (at least @laanwj and
>> @theuni have complained about their github inboxes being full of
>> "spam").
>> This is a relatively recent thread where I describe my plan:
>>
>> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009568.=
html
>> Not my first attempt on this list.
>>
>> It is very frustrating that everybody seems to agree that separating
>> libconsensus is a priority to maximize the number of people that can
>> safely contribute to the project, but at the same time, nobody thinks
>> that reviewing the necessary refactors to do so is a priority.
>> I tried creating big PRs for people to see "the big picture" #5946 but
>> those were too many commits and nobody wanted to read it. Gavin asked
>> for an API.
>> So I tried a smaller step: exposing just VerifyHeader in libconsensus
>> and leave VerifyTx and VerifyBlock for later #5995
>> Again, this was "too big" and "a moving target". In the meantime I
>> always had smaller one-little-step PRs that were part of a longer
>> branch:
>>
>> ** [8/8] MERGED Consensus
>> - [X] Consensus: Decouple pow from chainparams #5812 [consensuspow]
>> - [X] MOVEONLY: Move constants and globals to consensus.h #5696
>> [consensus_policy0]
>> - [X] Chainparams: Refactor: Decouple IsSuperMajority from Params()
>> #5968 [params_consensus]
>> - [X] Remove redundant getter CChainParams::SubsidyHalvingInterval()
>> #5996 [params_subsidy]
>> - [X] Separate CValidationState from main #5669 [consensus]
>> - [X] Consensus: Decouple ContextualCheckBlockHeader from checkpoints
>> #5975 [consensus_checkpoints]
>> - [X] Separate Consensus::CheckTxInputs and GetSpendHeight in
>> CheckInputs #6061 [consensus_inputs]
>> - [X] Bugfix: Don't check the genesis block header before accepting it
>> #6299 [5975-quick-fix]
>> ** [5/5] DELETED
>> *** DELETED Refactor: Create CCoinsViewEfficient interface for
>> CCoinsViewCache #5747 [coins]
>> *** DELETED Chainparams: Explicit Consensus::Params arg in consensus
>> functions #6024 [params_consensus2]
>> *** DELETED MOVEONLY: Move most of consensus functions (pre-block)
>> #6051 [consensus_moveonly] (depends on consensus-blocksize-0.12.99)
>> *** DELETED Consensus: Refactor: Separate CheckFinalTx from
>> main::IsFinalTx #6063 [consensus_finaltx]
>> *** DELETED Consensus: Refactor: Turn CBlockIndex::GetMedianTimePast
>> into independent function #6009 [consensus_mediantime]
>> *** DELETED Consensus: Adapt declarations of most obviously consensus
>> functions #6591 [consensus-params-0.12.99]
>> *** DELETED Consensus: Move blocksize and related parameters to
>> consensusparams ...without removing consensus/consensus.h [#6526
>> alternative] #6625 [consensus-blocksize-0.12.99]
>>
>> After a while I stop rebasing the longer branches and just maintained
>> a few small consensus-related PRs at a time.
>>
>> Now I consolidated 3 of them in
>>
>> *** REVIEW Optimizations: Consensus: In AcceptToMemoryPool,
>> ConnectBlock, and CreateNewBlock #6445 [consensus-txinputs-0.12.99]
>>
>> with the hope that it would be merged relatively fast.
>> After that it will be much simpler to start talking about potential C
>> APIs for VerifyHeader, VerifyTx and VerifyBlock; as well as separating
>> the library to a subtree.
>>
>> I'm more than happy to answer any questions anyone may have about any
>> of the PRs or commits, until everybody interested is convinced that
>> there's nothing random in the proposed changes.
>> I'm also more than happy to get advice on how to better communicate my
>> plans and structure my PRs.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
>
> --
> I like to provide some work at no charge to prove my value. Do you need a
> techie?
> I own Litmocracy <http://www.litmocracy.com> and Meme Racing
> <http://www.memeracing.net> (in alpha).
> I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com>
> which now accepts Bitcoin.
> I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
> "He ought to find it more profitable to play by the rules" - Satoshi
> Nakamoto
>

--e89a8f64725319e7630520e273b1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">There seemed to be some agreement on IRC - after a bit of =
haranguing by myself :) -- that large refactors should (a) occur over a sma=
ll window of time and (b) have a written plan beforehand.<div><br></div><di=
v><br></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"=
>On Tue, Sep 22, 2015 at 7:49 PM, Dave Scotese <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:dscotese@litmocracy.com" target=3D"_blank">dscotese@litmocracy.=
com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><div><div><div>If I&#39;m reading this situation correctly, Jeff is basic=
ally pointing out that developers need more links (hooks, rungs, handholds,=
 data points, whatever you want to call them) so that they can see all the =
things his email insinuated are missing (a plan, order, sense, etc.).=C2=A0=
 He didn&#39;t say these things were missing, but that it kind of feels lik=
e it from the 10,000 foot view.<br><br></div>If you use Google to search th=
e list,<b> </b>as in &lt;&lt;site:<a href=3D"http://lists.linuxfoundation.o=
rg" target=3D"_blank">lists.linuxfoundation.org</a> libconsensus plan&gt;&g=
t; you DO NOT get the page Jorge gave.=C2=A0 He wrote that page, so he had =
a good idea what to search for to find it again.=C2=A0 I just want to recom=
mend that when you describe the work you&#39;re doing on bitcoin, imagine s=
everal different ways people might try to find this description in the futu=
re and make them work.=C2=A0 In other words, Jorge could have put &quot;A p=
lan for abstracting out libconsensus&quot; in the email where he wrote &quo=
t;Here are some things that need to
happen first...&quot;<br><br></div>Likewise, if Jeff had searched for &lt;&=
lt;site:<a href=3D"http://lists.linuxfoundation.org" target=3D"_blank">list=
s.linuxfoundation.org</a> libconsensus plan&gt;&gt; (maybe he did, but he d=
idn&#39;t list any results), he may have found enough clues to see Jorge&#3=
9;s overall plan.=C2=A0 The &quot;site:&quot; keyword on Google fascinated =
me when I discovered it, so I let it inspire this email :-)<br><br></div><d=
iv>Maybe someone can explain this if I have it wrong: A few people are able=
 to pull code into Bitcoin/bitcoin.=C2=A0 Isn&#39;t is possible that those =
few people can agree to merge in a lot of refactor-hell PRs for those makin=
g the requests, but postpone them to that one-week-per-month that someone s=
uggested?=C2=A0 The idea of letting that &quot;hell&quot; come in (predicta=
ble) waves is excellent and I was hoping to see some agreement.=C2=A0 But I=
 don&#39;t know who those few are, so even if they all wrote &quot;Yeah, we=
&#39;ll do that,&quot; I wouldn&#39;t recognize that I got what I wanted.<b=
r></div><div><br></div>notplato<br></div><div class=3D"gmail_extra"><br><di=
v class=3D"gmail_quote"><div><div class=3D"h5">On Tue, Sep 22, 2015 at 11:1=
2 AM, Jorge Tim=C3=B3n <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@=
lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundat=
ion.org</a>&gt;</span> wrote:<br></div></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div><div class=3D"h5">On Tue, Sep 15, 2015 at 6:10 AM, Jeff Garzik via bi=
tcoin-dev<br>
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt; [collating a private mail and a github issue comment, moving it to a<b=
r>
&gt; better forum]<br>
&gt;<br>
&gt; On libconsensus<br>
&gt; ---------------<br>
&gt; In general there exists the reasonable goal to move consensus state<br=
>
&gt; and code to a specific, separate lib.<br>
&gt;<br>
&gt; To someone not closely reviewing the seemingly endless stream of<br>
&gt; libconsensus refactoring PRs, the 10,000 foot view is that there is a<=
br>
&gt; rather random stream of refactors that proceed in fits and starts<br>
&gt; without apparent plan or end other than a one sentence &quot;isolate<b=
r>
&gt; consensus state and code&quot; summary.<br>
&gt;<br>
&gt; I am hoping that<br>
&gt; * There is some plan<br>
&gt; * We will not see a five year stream of random consensus code movement=
<br>
&gt; patches causing lots of downstream developer headaches.<br>
&gt;<br>
&gt; I read every code change in every pull request that comes into<br>
&gt; github/bitcoin/bitcoin with three exceptions:<br>
&gt; * consensus code movement changes - too big, too chaotic, too<br>
&gt; frequent, too unfocused, laziness guarantees others will inevitably<br=
>
&gt; ACK it without me.<br>
&gt; * some non-code changes (docs)<br>
&gt; * ignore 80% of the Qt changes<br>
&gt;<br>
&gt; As with any sort of refactoring, they are easy to prove correct, easy<=
br>
&gt; to reason, and therefore quick and easy to ACK and merge.<br>
&gt;<br>
&gt; Refactors however have a very real negative impact.<br>
&gt; bitcoin/bitcoin.git is not only the source tree in the universe.<br>
&gt; Software engineers at home, at startups, and at major companies are<br=
>
&gt; maintaining branches of their own.<br>
&gt;<br>
&gt; It is very very easy to fall into a trap where a project is merging<br=
>
&gt; lots of cosmetic changes and not seeing the downstream ripple effects.=
<br>
&gt; Several people complained to me at the conference about all the code<b=
r>
&gt; movement changes breaking their own work, causing them to stay on<br>
&gt; older versions of bitcoin due to the effort required to rebase to each=
<br>
&gt; new release version - and I share those complaints.<br>
&gt;<br>
&gt; Complex code changes with longer development cycles than simple code<b=
r>
&gt; movement patches keep breaking.=C2=A0 It is very frustrating, and caus=
es<br>
&gt; folks to get trapped between a rock and a hard place:<br>
&gt; - Trying to push non-trivial changes upstream is difficult, for normal=
<br>
&gt; and reasonable reasons (big important changes need review etc.).<br>
&gt; - Maintaining non-trivial changes out of tree is also painful, for the=
<br>
&gt; aforementioned reasons.<br>
&gt;<br>
&gt; Reasonable work languishes in constant-rebase hell, and incentivizes<b=
r>
&gt; against keeping up with the latest tree.<br>
&gt;<br>
&gt;<br>
&gt; Aside from the refactor, libconsensus appears to be engineering in the=
<br>
&gt; dark.=C2=A0 Where is any sort of plan?=C2=A0 I have low standards - a =
photo of a<br>
&gt; whiteboard or youtube clip will do.<br>
<br>
Just because you don&#39;t understand the changes proposed it doesn&#39;t m=
ean<br>
that they are random.<br>
I may have done a poor job in communicating &quot;my plan for libconsensus&=
quot;<br>
but I have tried many times and in many ways.<br>
#bitcoin-dev logs show that I have not worked &quot;in the dark&quot; at al=
l, on<br>
the contrary, I&#39;ve been very tenacious when asking for review and<br>
opinions, to the point that several people (at least @laanwj and<br>
@theuni have complained about their github inboxes being full of<br>
&quot;spam&quot;).<br>
This is a relatively recent thread where I describe my plan:<br>
<a href=3D"http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July=
/009568.html" rel=3D"noreferrer" target=3D"_blank">http://lists.linuxfounda=
tion.org/pipermail/bitcoin-dev/2015-July/009568.html</a><br>
Not my first attempt on this list.<br>
<br>
It is very frustrating that everybody seems to agree that separating<br>
libconsensus is a priority to maximize the number of people that can<br>
safely contribute to the project, but at the same time, nobody thinks<br>
that reviewing the necessary refactors to do so is a priority.<br>
I tried creating big PRs for people to see &quot;the big picture&quot; #594=
6 but<br>
those were too many commits and nobody wanted to read it. Gavin asked<br>
for an API.<br>
So I tried a smaller step: exposing just VerifyHeader in libconsensus<br>
and leave VerifyTx and VerifyBlock for later #5995<br>
Again, this was &quot;too big&quot; and &quot;a moving target&quot;. In the=
 meantime I<br>
always had smaller one-little-step PRs that were part of a longer<br>
branch:<br>
<br>
** [8/8] MERGED Consensus<br>
- [X] Consensus: Decouple pow from chainparams #5812 [consensuspow]<br>
- [X] MOVEONLY: Move constants and globals to consensus.h #5696<br>
[consensus_policy0]<br>
- [X] Chainparams: Refactor: Decouple IsSuperMajority from Params()<br>
#5968 [params_consensus]<br>
- [X] Remove redundant getter CChainParams::SubsidyHalvingInterval()<br>
#5996 [params_subsidy]<br>
- [X] Separate CValidationState from main #5669 [consensus]<br>
- [X] Consensus: Decouple ContextualCheckBlockHeader from checkpoints<br>
#5975 [consensus_checkpoints]<br>
- [X] Separate Consensus::CheckTxInputs and GetSpendHeight in<br>
CheckInputs #6061 [consensus_inputs]<br>
- [X] Bugfix: Don&#39;t check the genesis block header before accepting it<=
br>
#6299 [5975-quick-fix]<br>
** [5/5] DELETED<br>
*** DELETED Refactor: Create CCoinsViewEfficient interface for<br>
CCoinsViewCache #5747 [coins]<br>
*** DELETED Chainparams: Explicit Consensus::Params arg in consensus<br>
functions #6024 [params_consensus2]<br>
*** DELETED MOVEONLY: Move most of consensus functions (pre-block)<br>
#6051 [consensus_moveonly] (depends on consensus-blocksize-0.12.99)<br>
*** DELETED Consensus: Refactor: Separate CheckFinalTx from<br>
main::IsFinalTx #6063 [consensus_finaltx]<br>
*** DELETED Consensus: Refactor: Turn CBlockIndex::GetMedianTimePast<br>
into independent function #6009 [consensus_mediantime]<br>
*** DELETED Consensus: Adapt declarations of most obviously consensus<br>
functions #6591 [consensus-params-0.12.99]<br>
*** DELETED Consensus: Move blocksize and related parameters to<br>
consensusparams ...without removing consensus/consensus.h [#6526<br>
alternative] #6625 [consensus-blocksize-0.12.99]<br>
<br>
After a while I stop rebasing the longer branches and just maintained<br>
a few small consensus-related PRs at a time.<br>
<br>
Now I consolidated 3 of them in<br>
<br>
*** REVIEW Optimizations: Consensus: In AcceptToMemoryPool,<br>
ConnectBlock, and CreateNewBlock #6445 [consensus-txinputs-0.12.99]<br>
<br>
with the hope that it would be merged relatively fast.<br>
After that it will be much simpler to start talking about potential C<br>
APIs for VerifyHeader, VerifyTx and VerifyBlock; as well as separating<br>
the library to a subtree.<br>
<br>
I&#39;m more than happy to answer any questions anyone may have about any<b=
r>
of the PRs or commits, until everybody interested is convinced that<br>
there&#39;s nothing random in the proposed changes.<br>
I&#39;m also more than happy to get advice on how to better communicate my<=
br>
plans and structure my PRs.<br></div></div>
_______________________________________________<span class=3D""><br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</span></blockquote></div><span class=3D"HOEnZb"><font color=3D"#888888"><b=
r><br clear=3D"all"><br>-- <br><div><div dir=3D"ltr">I like to provide some=
 work at no charge to prove my value. Do you need a techie?=C2=A0 <br>I own=
 <a href=3D"http://www.litmocracy.com" target=3D"_blank">Litmocracy</a> and=
 <a href=3D"http://www.memeracing.net" target=3D"_blank">Meme Racing</a> (i=
n alpha). <br>I&#39;m the webmaster for <a href=3D"http://www.voluntaryist.=
com" target=3D"_blank">The Voluntaryist</a> which now accepts Bitcoin.<br>I=
 also code for <a href=3D"http://dollarvigilante.com/" target=3D"_blank">Th=
e Dollar Vigilante</a>.<br>&quot;He ought to find it more profitable to pla=
y by the rules&quot; - Satoshi Nakamoto</div></div>
</font></span></div>
</blockquote></div><br></div>

--e89a8f64725319e7630520e273b1--