From: Gregory Maxwell <gmaxwell@gmail•com>
To: Andy Parkins <andyparkins@gmail•com>
Cc: bitcoin-development@lists•sourceforge.net
Subject: [Bitcoin-development] On fork awareness Was: 0.8.1 ideas
Date: Wed, 13 Mar 2013 14:15:22 -0700 [thread overview]
Message-ID: <CAAS2fgSxZw56TNzGEBeTpykJcc=4WKixG2LEd3EnY46z7wy1VA@mail.gmail.com> (raw)
On Wed, Mar 13, 2013 at 2:06 PM, Andy Parkins <andyparkins@gmail•com> wrote:
> On Wednesday 13 Mar 2013 12:56:29 Luke-Jr wrote:
>> Here's a simple proposal to start discussion from...
>
> It seems to me that the biggest failure was not the development of two
> chains, but the assurance to users (by the client) that their transactions
The development of two chains was maximally bad because the state was
irreconcilable without the manual intervention. The only reason you're
saying that it was only the false confirms that were bad is because
manual intervention resolved the worse badness. :) A whole bunch of
people spending coins that can only exist in the different exclusive
chains would have been very bad indeed.
> Is it possible to change the definition of "6 confirmations" so that it's
> something like: "six confirmations clear of any other chain". While there
> are two competing chains, it's possible that one will go pop at any moment.
> That makes the confirmation count of any transaction on one of those chains,
> zero.
Not reliably, you will only hear of a competing chain if some of your
peers have accepted it. If your peers were all pre-0.8 or all 0.8 you
only would have heard of one chain.
Relaying non-primary chains has some obvious and subtle challenges—
Obviously you need some way of preventing it from being a DOS vector,
but thats not a fundamental issue— you could rate limit by only
relaying chains which are close to the current best in sum difficulty—
just a software engineering one.
A more subtle issue is it that it's not in a node's self-interest to
tell peers about a chain it thinks is invalid: it wants its peers on
_its_ view of the consensus, not some other one. Though perhaps this
could be addressed by only relaying headers for non-primary chains.
reply other threads:[~2013-03-13 21:15 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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='CAAS2fgSxZw56TNzGEBeTpykJcc=4WKixG2LEd3EnY46z7wy1VA@mail.gmail.com' \
--to=gmaxwell@gmail$(echo .)com \
--cc=andyparkins@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/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