summaryrefslogtreecommitdiff
path: root/64/87217b4d06eb6bba2723fff5e023af417b6f5c
blob: f2bb5b7b74cdc289dc4a0628c174ec462f1f931d (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <pete@petertodd.org>) id 1UemGg-0000IP-P7
	for bitcoin-development@lists.sourceforge.net;
	Tue, 21 May 2013 13:06:18 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.148.96 as permitted sender)
	client-ip=62.13.148.96; envelope-from=pete@petertodd.org;
	helo=outmail148096.authsmtp.net; 
Received: from outmail148096.authsmtp.net ([62.13.148.96])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1UemGe-0004Mz-Tj for bitcoin-development@lists.sourceforge.net;
	Tue, 21 May 2013 13:06:18 +0000
Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232])
	by punt9.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id
	r4LD67eN006867; Tue, 21 May 2013 14:06:07 +0100 (BST)
Received: from tilt (dhcp184-48-74-214.hil-sckmthx.sjc.wayport.net
	[184.48.74.214]) (authenticated bits=128)
	by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r4LD5x1P026666
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
	Tue, 21 May 2013 14:06:03 +0100 (BST)
Date: Tue, 21 May 2013 06:05:57 -0700
From: Peter Todd <pete@petertodd.org>
To: Gregory Maxwell <gmaxwell@gmail.com>
Message-ID: <20130521130534.GA27580@tilt>
References: <519AC3A8.1020306@quinnharris.me>
	<CA+i0-i_+Tes+ePRqmDGEXDQ_L=S5y8gHBKk77zaLgTGOS3OMyA@mail.gmail.com>
	<CAPg+sBjmXyLkgfwzC8h+ZFkmyUf6nzbGo0oAWR9nsJOTOfOXEg@mail.gmail.com>
	<CAAS2fgRCpXUgw=GpE9_AcTgWcdCaDC6_16Xp5+oOZC0_1xmf-w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="LyciRD1jyfeSSjG0"
Content-Disposition: inline
In-Reply-To: <CAAS2fgRCpXUgw=GpE9_AcTgWcdCaDC6_16Xp5+oOZC0_1xmf-w@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 317eaac6-c217-11e2-b10b-0025903375e2
X-AuthReport-Spam: If SPAM / abuse - report it at:
	http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
	aQdMdAMUFVQNAgsB AmUbWlBeUFt7WWc7 agJVcwFVfE1KQQdr
	VFdMSlVNFUsqBWB1 A1YfMhlwcQNAfjBx YUFrXD5YXUMvJBcu
	RFMHF2wBeGZhPWIC AkFYJR5UcAFPdx9G aVd6AXFDAzANdhES
	HhM4ODE3eDlSNilR RRkIIFQOdA4nGSM2 Qx1KJi0iG0FNYSIv
	LhInIVcAHUEXWgAA 
X-Authentic-SMTP: 61633532353630.1019:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 184.48.74.214/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
	anti-virus system.
X-Spam-Score: -1.5 (-)
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 SPF_PASS               SPF: sender matches SPF record
X-Headers-End: 1UemGe-0004Mz-Tj
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Double Spend Notification
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: Tue, 21 May 2013 13:06:19 -0000


--LyciRD1jyfeSSjG0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, May 20, 2013 at 08:54:25PM -0700, Gregory Maxwell wrote:
> One point that was only recently exposed to me is that replacement
> combined with child-pays-for-parent creates a new kind of double spend
> _defense_: If someone double spends a payment to an online key of
> yours, you can instantly produce a child transaction that pays 100% of
> the double spend to fees... so a double spender can hurt you but not
> profit from it.  (and if your side of the transaction is
> potentially/partially reversible he will lose)...

You can do better than that actually: you can arrange the transaction
such that the double-spender is hurt by asking them to pay an excess on
top of the initial payment, and having that excess get returned to them
in a subsequent transaction. Of course, that's trusting the merchant,
but you're trusting the merchant to ship to a product anyway so...

A really interesting example for this though would be applications where
you are making a deposit. You credit the customer account immediately
with half of the deposit amount, allowing them to immediately spend that
portion for something transferable. (perhaps an alt-coin) If the
customer tries to double-spend you burn half to fees, still leaving the
other half to pay for what they did spend. If they don't double-spend,
the rest of the balance becomes available after n confirmations. A
BTC->alt-coin exchange could use this mechanism for instance, although
it only works with widespread replace-by-fee adoption; blockchain.info's
shared-send service is another application, as is SatoshiDice. (the
failed bet tx can be the refund)

What's nice here is even if the customer tries to pay a miner to do the
dirty work, a short-term rational miner still has an incentive to screw
over the customer by accepting the merchant's double-spend. Now the
customer can promise the miner future business, but they've shown
themselves to be dishonest... how much honor is there among thieves?

--=20
'peter'[:-1]@petertodd.org
00000000000000f31f5cd20f915e3edb8e3fceea49580235b984fea63f1f882c

--LyciRD1jyfeSSjG0
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBCAAGBQJRm3EyAAoJEH+rEUJn5PoE0lMIAIFuhpTM+ZELXNYLay9461Kr
42vN7QiSz6qgQODac9XYxUAqTFd6UHmpe2BnpdjpsVdmK3daq0XShPxOL0XuZjL5
7/7gIZoty/f3wVVHjGqE4OVpTxIU1ZcmrNkY87bjKx7kffNTNoKyYQXicWIfJgJl
STN15Y615T46llwQS85TpZ7cKwOi55BJehL7QHDQc0e1hS95Yu504s3rQEnZJlnE
62xZpwlkwHjmG4YV3ZCLoFvqR6LbBNPURkJPBGi2X/pxhbn0jqsv/dlYS8G25UWG
ZY+WL73VyDgjlKdLph6fsSoGYnNfCB5C1y1a7GQxuciu6TcNzdLQjHQRF2ESjAU=
=fkoJ
-----END PGP SIGNATURE-----

--LyciRD1jyfeSSjG0--