diff options
author | Andy Parkins <andyparkins@gmail.com> | 2011-08-04 19:22:16 +0100 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2011-08-04 18:22:29 +0000 |
commit | 3149dc52cf1c7497ee4869e2572797b551aff517 (patch) | |
tree | 5f4f42ee9c7c7efe9f134d43ade7c26f64fffa2c | |
parent | 1d11ce13d18c69578bcf9b6e1ac2ef37a2248553 (diff) | |
download | pi-bitcoindev-3149dc52cf1c7497ee4869e2572797b551aff517.tar.gz pi-bitcoindev-3149dc52cf1c7497ee4869e2572797b551aff517.zip |
Re: [Bitcoin-development] Double spend detection to speed up transaction trust
-rw-r--r-- | 6b/be54f80ea0c03870341043959d4d890e508ea2 | 152 |
1 files changed, 152 insertions, 0 deletions
diff --git a/6b/be54f80ea0c03870341043959d4d890e508ea2 b/6b/be54f80ea0c03870341043959d4d890e508ea2 new file mode 100644 index 000000000..c0ea743a7 --- /dev/null +++ b/6b/be54f80ea0c03870341043959d4d890e508ea2 @@ -0,0 +1,152 @@ +Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] + helo=mx.sourceforge.net) + by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <andyparkins@gmail.com>) id 1Qp2Yv-0003Hm-Jz + for bitcoin-development@lists.sourceforge.net; + Thu, 04 Aug 2011 18:22:29 +0000 +Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com + designates 74.125.82.53 as permitted sender) + client-ip=74.125.82.53; envelope-from=andyparkins@gmail.com; + helo=mail-ww0-f53.google.com; +Received: from mail-ww0-f53.google.com ([74.125.82.53]) + by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1Qp2Yu-00013y-RO + for bitcoin-development@lists.sourceforge.net; + Thu, 04 Aug 2011 18:22:29 +0000 +Received: by wwf26 with SMTP id 26so1989209wwf.10 + for <bitcoin-development@lists.sourceforge.net>; + Thu, 04 Aug 2011 11:22:22 -0700 (PDT) +Received: by 10.227.160.78 with SMTP id m14mr993615wbx.80.1312482142615; + Thu, 04 Aug 2011 11:22:22 -0700 (PDT) +Received: from grissom.localnet ([91.84.15.31]) + by mx.google.com with ESMTPS id gd1sm1682851wbb.10.2011.08.04.11.22.19 + (version=TLSv1/SSLv3 cipher=OTHER); + Thu, 04 Aug 2011 11:22:20 -0700 (PDT) +From: Andy Parkins <andyparkins@gmail.com> +To: bitcoin-development@lists.sourceforge.net +Date: Thu, 4 Aug 2011 19:22:16 +0100 +User-Agent: KMail/1.13.6 (Linux/2.6.39-2-686-pae; KDE/4.6.4; i686; ; ) +References: <201108041423.14176.andyparkins@gmail.com> + <1312479917.3109.25.camel@Desktop666> +In-Reply-To: <1312479917.3109.25.camel@Desktop666> +MIME-Version: 1.0 +Content-Type: Text/Plain; + charset="iso-8859-15" +Content-Transfer-Encoding: 7bit +Message-Id: <201108041922.16956.andyparkins@gmail.com> +X-Spam-Score: -1.6 (-) +X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. + See http://spamassassin.org/tag/ for more details. + -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for + sender-domain + 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider + (andyparkins[at]gmail.com) + -0.0 SPF_PASS SPF: sender matches SPF record + -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from + author's domain + 0.1 DKIM_SIGNED Message has a DKIM or DK signature, + not necessarily valid + -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature + 0.0 T_TO_NO_BRKTS_FREEMAIL To: misformatted and free email service +X-Headers-End: 1Qp2Yu-00013y-RO +Subject: Re: [Bitcoin-development] Double spend detection to speed up + transaction trust +X-BeenThere: bitcoin-development@lists.sourceforge.net +X-Mailman-Version: 2.1.9 +Precedence: list +List-Id: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> +X-List-Received-Date: Thu, 04 Aug 2011 18:22:29 -0000 + +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 + + |