I should also add that the mempool should exist in (2). This way the
peer services layer can manage all relay policy and mempool management.
-- Original Message --
From: "Eric Lombrozo"
To: "Jorge Timón" ; "Wladimir J. van der Laan"
Cc: "Bitcoin development mailing list"
Sent: 9/22
Here's what I propose as a long-term plan:
1) libconsensus
==
We should probably start by defining an API for libconsensus. It should
support an abstract DB model, track chain state, provide query
mechanisms for blocks and transactions with optional pruning and
indexing, expose a subsc
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 thin
On Fri, Sep 18, 2015 at 2:07 AM, Wladimir J. van der Laan via
bitcoin-dev wrote:
> My long-term vision of bitcoind is a P2P node with validation and blockchain
> store, with a couple of data sources that can be subscribed to or pulled from.
I agree with this long term vision.
Here's how I think
On Tue, Sep 15, 2015 at 6:10 AM, Jeff Garzik via bitcoin-dev
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
On Fri, Sep 18, 2015 at 12:44 AM, Peter Todd wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
>
>
> On 17 September 2015 12:14:38 GMT-07:00, "Jorge Timón via bitcoin-dev"
> wrote:
>>Fill or kill us normally used for trades and I think it can be
>>confusing.
>>Previous times this has
Hello,
There was overwhelming response that weekly IRC meetings are a good thing.
Thanks to the doodle site we were able to select a time slot that everyone
(that voted) is available:
Thursday 19:00-20:00 UTC, every week, starting September 24 (next Thursday)
I created a shared Google Cale
On Mon, Sep 21, 2015 at 03:51:29PM +0200, gb wrote:
>
> Although the planning for this a bit far along now, one consideration I
> might add from experience on working with other transglobal IT projects
Nah, we can always change the scheduling later... But let's first try it out
with one time.
W
