From: Gregory Maxwell <gmaxwell@gmail•com>
To: Aidan Thornton <makosoft@gmail•com>
Cc: kjj <kjj@jerviss•org>, bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Difficulty adjustment / time issues
Date: Wed, 14 Sep 2011 16:09:00 -0400 [thread overview]
Message-ID: <CAAS2fgQOuNKWD09arSzqKxYFRv95q4xyq0Wz4ZkeKdKSWJ-=kA@mail.gmail.com> (raw)
In-Reply-To: <CAB=c7TpFE_28BNpkW27kKK41w8QdaMKJ96=6H=xqonVDdTWUkA@mail.gmail.com>
On Wed, Sep 14, 2011 at 3:52 PM, Aidan Thornton <makosoft@gmail•com> wrote:
> Of course, if only a small percentage of mining power adopts this
> scheme, everyone that does so will presumably be harming themselves by
> doing so since they're essentially increasing the odds that the next
> block they mine will become invalid...
Perhaps better thing to do is to also delay the _forwarding_ of these
blocks _and_ blocks that extend them, until extended one more time.
This policy, if adopted by the forwarding nodes (who really shouldn't
care for much other than the overall health of bitcoins) puts miners
at risk if they don't run the augmented extension policy.
Though I generally agree with Luke that we should just fix the root
cause even though it forks the chain. Not for his reasons (I don't
give a crap about the burden on _one_ pool operator— the rest cope
with bitcoind scaling fine without excessive dependance on ntime
rolling), but simply because not fixing it makes the bitcoin security
model harder to explain and analyze.
"Here is a vulnerability, but its offset by this workaround" is
inferior to "the system is secure against this kind of attack".
next prev parent reply other threads:[~2011-09-14 20:09 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-13 15:06 Gavin Andresen
2011-09-13 15:15 ` Vladimir Marchenko
2011-09-13 15:54 ` John Smith
2011-09-13 16:24 ` kjj
2011-09-14 14:45 ` Gavin Andresen
2011-09-14 15:43 ` Luke-Jr
2011-09-14 16:06 ` Christian Decker
2011-09-14 19:52 ` Aidan Thornton
2011-09-14 20:09 ` Gregory Maxwell [this message]
2011-09-14 20:28 ` Gavin Andresen
2011-09-14 21:36 ` Alex Waters
2011-09-14 21:51 ` Gregory Maxwell
2011-09-14 22:07 ` theymos
2011-09-14 23:01 ` Luke-Jr
2011-09-13 16:48 ` Luke-Jr
2011-09-14 21:45 ` theymos
2011-11-07 15:02 ` Pieter Wuille
2011-11-07 15:27 ` Luke-Jr
2011-11-07 15:43 ` Pieter Wuille
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='CAAS2fgQOuNKWD09arSzqKxYFRv95q4xyq0Wz4ZkeKdKSWJ-=kA@mail.gmail.com' \
--to=gmaxwell@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=kjj@jerviss$(echo .)org \
--cc=makosoft@gmail$(echo .)com \
/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