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
164
165
166
167
168
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <andyparkins@gmail.com>) id 1RYx68-0005nk-B9
for bitcoin-development@lists.sourceforge.net;
Fri, 09 Dec 2011 09:50:32 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.215.175 as permitted sender)
client-ip=209.85.215.175; envelope-from=andyparkins@gmail.com;
helo=mail-ey0-f175.google.com;
Received: from mail-ey0-f175.google.com ([209.85.215.175])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1RYx66-0001OD-24
for bitcoin-development@lists.sourceforge.net;
Fri, 09 Dec 2011 09:50:32 +0000
Received: by eaal1 with SMTP id l1so28680eaa.34
for <bitcoin-development@lists.sourceforge.net>;
Fri, 09 Dec 2011 01:50:23 -0800 (PST)
Received: by 10.213.15.69 with SMTP id j5mr674075eba.128.1323424223705;
Fri, 09 Dec 2011 01:50:23 -0800 (PST)
Received: from dvr.localnet (mail.360visiontechnology.com. [92.42.121.178])
by mx.google.com with ESMTPS id d6sm29065994eec.10.2011.12.09.01.50.18
(version=TLSv1/SSLv3 cipher=OTHER);
Fri, 09 Dec 2011 01:50:19 -0800 (PST)
From: Andy Parkins <andyparkins@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Date: Fri, 9 Dec 2011 09:50:03 +0000
User-Agent: KMail/1.13.6 (Linux/3.0.0-1-686-pae; KDE/4.6.3; i686; ; )
References: <201112081047.09082.andyparkins@gmail.com>
<4EE13D8C.2020308@justmoon.de>
In-Reply-To: <4EE13D8C.2020308@justmoon.de>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart4632628.C0BYzMbHC6";
protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <201112090950.10974.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
X-Headers-End: 1RYx66-0001OD-24
Subject: Re: [Bitcoin-development] Lowering confirmation requirements and
preventing double spends
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: Fri, 09 Dec 2011 09:50:32 -0000
--nextPart4632628.C0BYzMbHC6
Content-Type: Text/Plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
On 2011 December 08 Thursday, Stefan Thomas wrote:
> Bitcoin already does something which in practice has exactly this
> effect: If a transaction is reversed, any transactions based on its
> outputs are rejected.
That part is fine; I was aware that Bitcoin did this. How could it not? T=
he=20
transactions form multiple signature chains of their own. It impossible to=
=20
have a transaction depend on a non-existent input transaction.
> Hosted wallets can make use of this - but as you correctly point out,
> depending on the service, it can get tricky. What if I exchange the
> money to USD and back before withdrawing? You could have an algorithm
> where MtGox prefers to spend outputs from your own deposits as the
> inputs for your withdrawals, it's not trivial though and never 100% secur=
e.
Quite so; this is essentially the problem my suggestion addresses. What do=
=20
you do when a transaction is dependent on another transaction financially b=
ut=20
not technically? That is to say that your accounting software would show a=
=20
credit and a debit to a particular entity, but the bitcoin block chain woul=
d=20
not. In the old world we might do this as "I'll write you a cheque and you=
=20
give me cash"; if that cheque bounces, you've lost your cash.
> I have trouble thinking of a good example where you need an explicit
> block dependency as you describe. The only times you'd want to use this
> dependency of transactions on specific previous transactions is when you
> can clearly and easily associate the money. But if you can clearly and
> easily associate the money, you might as well just relate the
> transactions (use the outputs from the deposit transaction as the inputs
> of the withdrawal transaction.)
The MyBitcoin debacle (if we are to believe their reports) would have been=
=20
avoided by my suggestion. They were accepting deposits in one chain, and=20
allowing withdrawls from another. That meant that while there was a financ=
ial=20
connection, there was not a bitcoin-connection. The withdrawls happened fr=
om=20
the pool address, most likely well funded, so were valid on either chain. =
If=20
MyBitcoin had been able to broadcast the withdrawl transactions as being ba=
sed=20
on the same chain as the deposit (even though it was not using transactions=
in=20
that chain) then the attack would have failed.
> This is btw something that would strongly agree with: Hosted wallets
> should absolutely keep each account as separate public keys. With that
> you lose free and instant internal transactions, but you gain instant
> deposits and much better risk isolation.
I'm not sure I agree. There is certainly a case for both types: one-to-one=
=20
correspondence between address and account has the advantages you list but =
is=20
highly identifiable and trackable. However the disadvantage is that all fu=
nds=20
would have to be kept online. Places like Mt.Gox can (although there is=20
evidence to suggest that they don't, tut tu) move the majority of the funds=
to=20
five USB sticks, and keep them in five fire-proof safes or deposit boxes or=
=20
whatever only because deposited funds are pooled.
> This is just my view. Thanks and keep the thought-provoking stuff coming!
Thanks for the encouragement. It's appreciated.
Andy
=2D-=20
Dr Andy Parkins
andyparkins@gmail.com
--nextPart4632628.C0BYzMbHC6
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEABECAAYFAk7h2cwACgkQwQJ9gE9xL21pBQCfcZdGOTke/RxOqU/QWdihvfqj
j1wAnjdn1Z+/n8qr0SOadlaIcsT9b4QE
=Ty27
-----END PGP SIGNATURE-----
--nextPart4632628.C0BYzMbHC6--
|
