From: Gregory Maxwell <gmaxwell@gmail•com>
To: Andy Parkins <andyparkins@gmail•com>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Double spend detection to speed up transaction trust
Date: Thu, 4 Aug 2011 16:08:07 -0400 [thread overview]
Message-ID: <CAAS2fgSMFmtLeDzzOf5dxrGUEGCrUzAqbuzGeSaDzBFx940x7Q@mail.gmail.com> (raw)
In-Reply-To: <201108042042.55214.andyparkins@gmail.com>
On Thu, Aug 4, 2011 at 3:42 PM, Andy Parkins <andyparkins@gmail•com> wrote:
> On Thursday 04 August 2011 19:39:56 Matt Corallo wrote:
>
>> But why? It results in slightly more network traffic which is exactly
>> what we don't want, and it adds yet another message people have to know
>> about.
>
> "Slightly" is an understatement. It add more network traffic for every
> double spend attempt. Which don't happen very often.
But they can be trivially generated on demand, and potentially result
in unbounded flooding.
Even if you carefully don't duplicate an announcement I can easily
generate an unlimited number of double-spends for the network to
flood. The normal anti-DDOS logic doesn't work because there can be no
additional proof-of-workish costs for the double spend (they'd share
whatever anti-ddos fees the first txn had).
This is somewhat soluble, I guess. Rather than NAK the transaction the
way it would work is propagating conflicts on each of the conflicted
inputs. "I've seen at least two transactions recently trying to spend
input X, here is proof: (two txn IDs)". Even if there are more spends
of that input you don't need to hear about them, knowing about two
spends of an input is enough to consider that input (and perhaps all
inputs with an identical script to that one) temporarily suspect.
Though it would have to be done input by input.
This might be an interesting feature if not for the fact that the
software already waits a fair number of confirms before considering
something confirmed. Of course, a sybil can just filter these messages
diminishing their usefulness.
I suppose I could add this as a (7) to this list:
https://bitcointalk.org/index.php?topic=28565.msg359948#msg359948
next prev parent reply other threads:[~2011-08-04 20:08 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-04 13:23 Andy Parkins
2011-08-04 17:45 ` Matt Corallo
2011-08-04 18:22 ` Andy Parkins
2011-08-04 18:39 ` Matt Corallo
2011-08-04 19:42 ` Andy Parkins
2011-08-04 20:07 ` Andrew Schaaf
2011-08-04 20:38 ` Matt Corallo
2011-08-04 22:10 ` Stefan Thomas
2011-08-04 22:18 ` Gregory Maxwell
2011-08-04 22:21 ` Matt Corallo
2011-08-05 0:07 ` Gavin Andresen
2011-08-04 20:08 ` Gregory Maxwell [this message]
2011-08-04 20:33 ` Matt Corallo
2011-08-04 21:36 ` Mike Hearn
2011-08-04 22:16 ` Matt Corallo
2011-08-05 0:14 ` Stefan Thomas
2011-08-05 11:05 ` Mike Hearn
2011-08-05 11:58 ` Andy Parkins
2011-08-05 12:06 ` Matt Corallo
2011-08-05 13:03 ` Andy Parkins
2011-08-05 21:23 ` Gregory Maxwell
2011-08-05 21:30 ` Matt Corallo
2011-08-05 12:00 ` Matt Corallo
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=CAAS2fgSMFmtLeDzzOf5dxrGUEGCrUzAqbuzGeSaDzBFx940x7Q@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