On 9/19/2016 10:56 AM, Peter Todd wrote:
> I should state that assumption more clearly.
Glad to get you thinking, and I need to change my suggestion. The
catch-up formula is not applicable because it doesn't limit how long the
dishonest miners have to catch up.
Instead you want the probability t
On Mon, Sep 19, 2016 at 09:13:40AM -0700, Tom Harding via bitcoin-dev wrote:
>
> On 9/17/2016 9:20 PM, Peter Todd via bitcoin-dev wrote:
> > The probability that all N blocks are found by dishonest miners is q^N,
>
> That's the probability that dishonest miners find N blocks in a row
> immediatel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 9/17/2016 9:20 PM, Peter Todd via bitcoin-dev wrote:
> The probability that all N blocks are found by dishonest miners is q^N,
That's the probability that dishonest miners find N blocks in a row
immediately. What you want is the probability that
On Sun, Sep 18, 2016 at 03:45:40PM +0200, Jannes Faber wrote:
> Would you not also have to consider (all) earlier blocks?
>
> T = max(block[i].nTime for i in {x-100, ..., x, ..., x + N-1}) + max_offset
>
> In case one or more previous blocks have an nTime considerably in the
> future and blocks>=
As part of my recent work(1) on OpenTimestamps I've been putting some thought
towards how to interpret the nTime fields in block headers, for the purpose of
timestamping. I'd like to get some peer review on the following scheme I've
come up with.
# Motivation
We want to use the Bitcoin blockchai
