From: Andy Parkins <andyparkins@gmail•com>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Double spend detection to speed up transaction trust
Date: Thu, 4 Aug 2011 19:22:16 +0100 [thread overview]
Message-ID: <201108041922.16956.andyparkins@gmail.com> (raw)
In-Reply-To: <1312479917.3109.25.camel@Desktop666>
On Thursday 04 August 2011 18:45:17 Matt Corallo wrote:
> There really is no reason to add the extra network complexity for this.
It's hardly complex. It's exactly as it is now, with exactly the messages
there are now, but with an extra type added to the inventory list. A
transaction _already_ propagates using inv messages with MSG_TX, is it
really so "complex" to add MSG_DOUBLESPEND to the enum? What's more it's
backward compatible because clients that don't understand MSG_DOUBLESPEND
will ignore the inv ending up exactly where we are now.
> First of all (as you point out) no one buying a Ferrari will refuse to
> wait an hour for the payment to confirm. If someone is attempting to
> pull a similar trick on, say, a vending machine however it might make
> sense. But that changes the equation. In order for these two scammers
Vending machine, newspaper salesman, ice creams, a beer. The list of small
vendors is endless. I picked Ferrari's out of the air.
> to pull it off, some effort is required in terms of communicating the
> time to send the coins and the nodes of the targets (vending machines or
> whatever) must be figured out. So now its less of "make it impossible"
> and more of "make it really hard to the point that it is no where near
> worth the effort".
I think you've missed the point. Double spend transactions that enters the
network at two reasonably evenly connected points are each only seen by half
the network, since the first one locks out the second from propagation.
> Lets simplify the scenario a bit so that one scammer can pull it off.
> Send one copy of your transaction to the target node and another to
> large mining operations so that the payment transaction is considered
> invalid to miners and a transaction which pays you is confirmed.
There is no "target" node. There is only a vending machine listening for
transactions. It's unlikely that vending machines will even have incoming
connections enabled. They certainly won't be keeping a full copy of the
block chain or be mining.
> If you are the vending machine, your goal is not to figure out any
> transactions which are yours, but to figure out which transactions which
It is a little bit. Your job is _first_ to figure out which are yours;
then, as you say, to see which are going to be confirmed. Well: once you've
seen a transaction on the net you know it's going to be confirmed... unless
a matching double spend transaction was accepted by the next miner to
generate a block.
> are yours are going to be confirmed. So, you peer with the largest
> miners (a "Bitcoin backbone" or large miners and merchants has been
> suggested over and over again and really hasn't happened) and modify
It hasn't happened, and yet it seems to be that this non-existant thing is
your solution to the problem.
> your client to, instead of dropping transactions which are
> double-spends, keep both in memory pool and consider them both invalid
> until one of them confirms.
Well that's what happens now. But that doesn't help the poor sap who's just
handed over some goods. I want it so that small businesses can use the
client to give them practical answers instead of this "0/unconfirmed" stuff
which requires understanding of the system.
> This will work with 1, 2, or n scammers, doesn't require any additional
> network messages, and offers just as good, if not better security over a
> double spend message.
I'm not really trying to prevent double spends -- bitcoin _already_ prevents
double spends. Also: the only difference between your suggestion (don't
drop) and my suggestion (don't drop but mark with MSG_DOUBLESPEND) is a
single number in the inv. I really don't get the objection.
> Additionally, in the future, when(/if) Bitcoin payment processors exist,
"In the future" is all well and good. What if there is no future because
bitcoin is still too difficult for average joe to use?
Andy
--
Dr Andy Parkins
andyparkins@gmail•com
next prev parent reply other threads:[~2011-08-04 18:22 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 [this message]
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
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=201108041922.16956.andyparkins@gmail.com \
--to=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