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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <moon@justmoon.de>) id 1RYmgl-0001O5-BI
for bitcoin-development@lists.sourceforge.net;
Thu, 08 Dec 2011 22:43:39 +0000
X-ACL-Warn:
Received: from sulfur.webpack.hosteurope.de ([217.115.142.104])
by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1RYmgi-0003u2-Vm for bitcoin-development@lists.sourceforge.net;
Thu, 08 Dec 2011 22:43:39 +0000
Received: from 84-72-69-153.dclient.hispeed.ch ([84.72.69.153]
helo=[192.168.0.21]); authenticated
by sulfur.webpack.hosteurope.de running ExIM with esmtpsa
(TLSv1:AES256-SHA:256)
id 1RYmgc-0000Rq-K9; Thu, 08 Dec 2011 23:43:30 +0100
Message-ID: <4EE13D8C.2020308@justmoon.de>
Date: Thu, 08 Dec 2011 23:43:24 +0100
From: Stefan Thomas <moon@justmoon.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <201112081047.09082.andyparkins@gmail.com>
In-Reply-To: <201112081047.09082.andyparkins@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-bounce-key: webpack.hosteurope.de;moon@justmoon.de;1323384217;9561c2c3;
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1RYmgi-0003u2-Vm
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: Thu, 08 Dec 2011 22:43:39 -0000
Hey Andy,
Bitcoin already does something which in practice has exactly this
effect: If a transaction is reversed, any transactions based on its
outputs are rejected.
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% secure.
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.)
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.
This is just my view. Thanks and keep the thought-provoking stuff coming!
Cheers,
Stefan
On 12/8/2011 11:47 AM, Andy Parkins wrote:
> Hello,
>
> Another of my crazy ideas:
>
> When a transaction is first broadcast, it should include the hash of the block
> it wants to appear after, let's call it's basis block. That block can be
> anything the claimer wants; but it allows the miners to add this condition:
> the transactions outputs a new transaction claims must be before the new
> transaction's basis block.
>
> Consider this block chain fork:
>
> * -- * -- F -- * -- 1 -- 4 -- 5
> \
> * -- 2 -- 3
>
> Let's say in block 2; I transfer coins from address A to Mt.Gox (or any other
> pooled-account online wallet). In block 1 I transfer credit from address A to
> address B. In block 3 I transfer credit from Mt.Gox's pool to address B.
>
> The chain at 3 races out first, but eventually the chain at 5 becomes "the
> one". If Mt.Gox are foolish enough to broadcast my withdrawl in 3; there is
> nothing to stop that same withdrawl making it into 4 (since it comes from a
> pooled fund address). Therefore Mt.Gox can't allow such a fast turnaround and
> must wait for six confirmations of 2 before allowing use of the funds. That
> is an inconvenience for all the honest users.
>
> With my proposed change, the Mt.Gox transaction broadcast at 3 would include
> "block 2" as its basis block. Therefore that transaction could never make it
> into block 4, as no miner will include a transaction based on block 2 in the
> block 4 chain.
>
> Mt.Gox is probably not a good example, as they have problems with fiat to deal
> with too. However, for other online wallet accounts it would allow faster
> acceptance of received funds, since there is no danger of loss should an
> attacker arrange a reorganisation.
>
> This basis block would be optional (implied by the input transactions if it
> isn't present); and would only need storing for the pending transactions, so
> no incompatible change is needed to the block format.
>
>
>
> Andy
|
