summaryrefslogtreecommitdiff
path: root/18/d2ad6349e896ffeec14a892980717f6ef868c1
blob: 088fb4c171653378c8316561e55cc3eb98442e20 (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
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <pete@petertodd.org>) id 1Wwdrh-0005ro-WD
	for bitcoin-development@lists.sourceforge.net;
	Mon, 16 Jun 2014 20:50:54 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.149.43 as permitted sender)
	client-ip=62.13.149.43; envelope-from=pete@petertodd.org;
	helo=outmail149043.authsmtp.co.uk; 
Received: from outmail149043.authsmtp.co.uk ([62.13.149.43])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1Wwdrg-0007Nr-3q for bitcoin-development@lists.sourceforge.net;
	Mon, 16 Jun 2014 20:50:53 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
	by punt17.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s5GKogKB006390;
	Mon, 16 Jun 2014 21:50:42 +0100 (BST)
Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109])
	(authenticated bits=128)
	by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s5GKoYii028653
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
	Mon, 16 Jun 2014 21:50:37 +0100 (BST)
Date: Mon, 16 Jun 2014 16:50:41 -0400
From: Peter Todd <pete@petertodd.org>
To: Daniel Rice <drice@greenmangosystems.com>
Message-ID: <20140616205041.GA21784@savin>
References: <loom.20140616T181739-326@post.gmane.org>
	<CANEZrP3er1NVoAiVmROTxQ3TC80r7enKaHkWjOYTbKehf7qJjQ@mail.gmail.com>
	<loom.20140616T184930-521@post.gmane.org>
	<CANEZrP2fg9k9fC+QAO2GQS7VC-JCtbEjubHB9j1TJtR9vuaDSQ@mail.gmail.com>
	<loom.20140616T190550-931@post.gmane.org>
	<CALDj+Bbvvs4rkrSOndk4rbt9JGwSwF1VeFk2XPjFy7Ro4O9heg@mail.gmail.com>
	<CANEZrP384LFKaCbAL-p06FQdHHp1bqmcRs+XZDbwVXVrPRDS7g@mail.gmail.com>
	<CAFDyEXg8OnoYCNLT1WeX2tBPTB_zcXsZ6ujP_8YmPvGyf4pzkw@mail.gmail.com>
	<CANEZrP2NKG8etGtGgbkA8rPr3BqCMPmVQ-3xqiKXVOK2vf9+7w@mail.gmail.com>
	<CAFDyEXistfW2Y-93ipty_Z5NgtqT_1BRUNqBsYQNRFz_GjOQ6w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="n8g4imXOkfNTN/H1"
Content-Disposition: inline
In-Reply-To: <CAFDyEXistfW2Y-93ipty_Z5NgtqT_1BRUNqBsYQNRFz_GjOQ6w@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: df61d414-f597-11e3-b396-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
	http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
	bgdMdwQUEkAaAgsB AmIbWVVeVV17Wms7 bAxPbAVDY01GQQRq
	WVdMSlVNFUsrBGt6 WXdHCxlwfwNDezBy YERhXj4PCkJ7IUJ8
	RlMCEGQBeGZhPWMC AkNRcR5UcAFPdx8U a1UrBXRDAzANdhES
	HhM4ODE3eDlSNilR RRkIIFQOdA4lHzIx QxEeDH0lGksJXG09
	KAZuJlMXEUANKEw2 MEksVRoZNQQOAwtC fQlGBylXJkMETjYq
	CgUSUlMXCjRbXSpR GXUA
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 76.10.178.109/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: 1Wwdrg-0007Nr-3q
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
	Lawrence Nahum <lawrence@greenaddress.it>
Subject: Re: [Bitcoin-development] Fidelity bonds for decentralized instant
 confirmation guarantees
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: Mon, 16 Jun 2014 20:50:54 -0000


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

On Mon, Jun 16, 2014 at 01:37:52PM -0700, Daniel Rice wrote:
> True, that would work, but still how are you going to bootstrap the trust?
> TREZOR is well known, but in a future where there could be 100 different
> companies trying to release a similar product to TREZOR it seems like one
> company could corner the market by being the only one that is an accepted
> instant provider at most vendors. It seems to encourage monopoly unless
> there is a standard way to bootstrap trust in your signature.

You can always use fidelity bonds, or as I called it at the time(1),
"Trusted identities":

    Lets suppose Alice has some bitcoins held at bitcoin address A. She
    wants to establish trust in the "identity" associated with the ECC
    keypair associated with A, for instance for the purpose of having other
    users trust her not to attempt to double spend. Since the trust she
    seeks is financial in nature, she can do this by valuing the identity
    associated with A, by delibrately throwing away resources. A simple way
    to do this would of course be to transfer coins to a null address,
    provably incurring a cost to her.

    A more socially responsible way would be for her to create a series of
    transactions that happen to have large, and equal, transaction fees.
    Bitcoin makes the assumption that no one entity controls more than 50%
    of the network, so if she makes n of these transactions consecutively,
    each spending m BTC to transaction fees, there is a high probability
    that she has given up at least n/2 * m BTC of value. This of course is
    all public knowledge, recorded in the block chain. It also increases the
    transaction fees for miners, which will be very important for the
    network in the future.

    Now Bob can easily examine the block chain, and upon verifying Alice's
    trust purchase, can decide to accept a zero-confirmation transaction at
    face value. If Alice breaks that promise, he simply publishes her signed
    transaction proving that Alice is a fraudster, and future Bob's will
    distrust Alice's trusted identity, thus destroying the value needed to
    create it.

    In effect, we now have a distributed green address system.

Note that the second paragraph is seriously obsolete - better to either
use announce-commit sacrifices, or much preferably, simple destruction
of coins. (sacrifice to fees encourages mining centralization for
obvious reasons)

1) "[Bitcoin-development] Trusted identities", Apr 26th 2012, Peter Todd,
   http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/=
msg01005.html

Incidentally, my first post to this mailing list!

--=20
'peter'[:-1]@petertodd.org
000000000000000058ca7ee3a40438ea5a96e499910638352468c6d69abdb226

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

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

iQGrBAEBCACVBQJTn1icXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDA1OGNhN2VlM2E0MDQzOGVhNWE5NmU0OTk5MTA2MzgzNTI0
NjhjNmQ2OWFiZGIyMjYvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfsi+gf/fUtrKJFBP94dEn22EQJ5Jc9r
CI4Sb/zuzUiteirnV2CImBUY0xP/e5ohKNz1O4+6ulwIuUrTWYuOL2P+t2LOmpqV
6teSWnM19DSKqFrAD/UN1KGp1q+pzs62fgw9z58oc6EmRZ9aNU5gCE9MEa96evEE
51cACpW1nle8ZQqDmexkda4MHYMSDvWsYiUocGFI+OHJEQsOBEZ25+iz8Nc27Wq5
94yAYpDvzj9IpjbsJM+xgHvvgMMsJmMvg1LGjgKpWwYXgzcPdnZawLobbZzVH4eo
VSZSBLbEJODYDhpMl1UA5ogkVI/IldKL1E0hEfIJVnoUi49bUiCKeMzRrUj8Bg==
=VSVN
-----END PGP SIGNATURE-----

--n8g4imXOkfNTN/H1--