From: Stefan Thomas <moon@justmoon•de>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Double spend detection to speed up transaction trust
Date: Fri, 05 Aug 2011 00:10:59 +0200 [thread overview]
Message-ID: <4E3B18F3.4010605@justmoon.de> (raw)
In-Reply-To: <1312490305.3109.46.camel@Desktop666>
Since nobody else has mentioned it: There is another (more pragmatic?)
way to detect double spends:
1. Connect to lots of clients
2a. If they all send you the same transaction -> double spend unlikely
2b. If some don't send you the transaction (or send a conflicting one)
-> double spend in progress
Obviously not everyone will run a double spend detector - it's much more
easily realized as a service (just like mining.) Jan put up a proof of
concept: http://www.transactionradar.com/
Would network support like a MSG_DOUBLESPEND be better? I used to think
yes, but looking at the reality of Transaction Radar, I'm not so sure.
Nothing stops such a service from scaling up and connecting to thousands
of random nodes (especially when the network itself grows bigger),
pushing the probabilities of missing a double spend "in the wild" to
near zero. It could also connect directly to important miners/pools as
others have suggested.
Of course this doesn't help against double spends where the attacker
does his own mining*, but neither would MSG_DOUBLESPEND. Given the added
network load I'd argue that network support for double spends is
unnecessary and potentially damaging. DoS is more scary to me than
non-instant transactions.
* In this case of course the hacker will be exposed to some randomness,
and I doubt many attackers will buy 100 televisions, newspaper
subscriptions or MP3s to get one for free. So this is only a problem for
liquid goods with tiny spreads (any investment or stored value instrument.)
next prev parent reply other threads:[~2011-08-04 22:11 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 [this message]
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
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=4E3B18F3.4010605@justmoon.de \
--to=moon@justmoon$(echo .)de \
--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