From: Troy Benjegerdes <hozer@hozed•org>
To: shaolinfry <shaolinfry@protonmail•ch>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Height based vs block time based thresholds
Date: Wed, 5 Jul 2017 02:25:33 +0000 [thread overview]
Message-ID: <20170705022533.GH4885@hostname.unassigned> (raw)
In-Reply-To: <KXL-Ie0q1dKTlbQ2XCyTRCzoQLND-Q7M9CFvYTfhjgeiZ4K3knpetQSwwLviO6whuHXQnFPg-rg8q1xW8w5mNnYFxalvx5_9Vci63lC9ju4=@protonmail.ch>
On Tue, Jul 04, 2017 at 09:30:26PM -0400, shaolinfry via bitcoin-dev wrote:
> Some people have criticized BIP9's blocktime based thresholds arguing they are confusing (the first retarget after threshold). It is also vulnerable to miners fiddling with timestamps in a way that could prevent or delay activation - for example by only advancing the block timestamp by 1 second you would never meet the threshold (although this would come a the penalty of hiking the difficulty dramatically).
If there are miners that start doing 1 second timestamp advances, it would be
simpler (and probably safer) to require a minimum block time spacing of say
30 seconds or 1 minute, and orphan blocks that are too close in time and more
than say an hour behind real-time.
I cannot picture any realistic scenario in which an attempt to block activation
in this way is in anything other than a very expensive temper tantrum for any
miners foolish enough to attempt it.
It *might* be a delay tactic as a 'nuclear option' attack vector for a mining
cabal to run up the difficulty so high as to make it impractical to mine any
new blocks after the adjustment, but there are plenty of altcoins that have
hardforked and gotten along just fine after the same kind of thing due to
profit-switching pools.
> On the other hand, the exact date of a height based thresholds is hard to predict a long time in advance due to difficulty fluctuations. However, there is certainty at a given block height and it's easy to monitor.
> If there is sufficient interest, I would be happy to amend BIP8 to be height based. I originally omitted height based thresholds in the interests of simplicity of review - but now that the proposal has been widely reviewed it would be a trivial amendment.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
next prev parent reply other threads:[~2017-07-05 2:28 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-05 1:30 shaolinfry
2017-07-05 2:25 ` Troy Benjegerdes [this message]
2017-07-05 3:39 ` Bram Cohen
2017-07-05 3:50 ` Luke Dashjr
2017-07-05 4:00 ` shaolinfry
2017-07-05 4:10 ` Luke Dashjr
2017-07-05 19:44 ` Hampus Sjöberg
2017-07-06 17:20 ` Jorge Timón
2017-07-06 17:41 ` Eric Voskuil
2017-07-05 8:06 ` Gregory Maxwell
2017-07-05 8:54 ` Kekcoin
2017-07-06 20:43 ` Luke Dashjr
2017-07-07 5:52 ` shaolinfry
2017-07-07 9:51 ` Jorge Timón
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170705022533.GH4885@hostname.unassigned \
--to=hozer@hozed$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=shaolinfry@protonmail$(echo .)ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox