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
|
Return-Path: <tmagik@hozed.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id E31062C
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 3 Aug 2016 21:13:56 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from bc.grid.coop (bc.grid.coop [162.221.205.91])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 47B21112
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 3 Aug 2016 21:13:56 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) (uid 1000)
by bc.grid.coop with local; Wed, 03 Aug 2016 21:13:20 +0000
id 00000000004800EC.0000000057A25E70.000048F3
Date: Wed, 3 Aug 2016 21:13:20 +0000
From: Troy Benjegerdes <hozer@hozed.org>
To: Matthew Roberts <matthew@roberts.pm>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20160803211320.GA18597@hostname.unassigned>
References: <CAAEDBiGMGWLeC81vkojGwEqQTT1HQaE=a3z114u6=FXXM2DRtQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
In-Reply-To: <CAAEDBiGMGWLeC81vkojGwEqQTT1HQaE=a3z114u6=FXXM2DRtQ@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 04 Aug 2016 09:06:15 +0000
Subject: Re: [bitcoin-dev] BIP clearing house addresses
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Aug 2016 21:13:57 -0000
On Thu, Aug 04, 2016 at 04:16:20AM +1000, Matthew Roberts via bitcoin-dev wrote:
> In light of the recent hack: what does everyone think of the idea of
> creating a new address type that has a reversal key and settlement layer
> that can be used to revoke transactions?
I think many of us who think about human - computer interactions see the
need for a well defined process to roll back unexpected behavior in a computer
system. My 2014 era proposal is https://bitbucket.org/tmagik/catoshi/issues/24
The fundamental assumption around cryptocoins is you have a secret (private
key) known only by you. Currently in bitcoin if that assumption changes, the
response is blame the user. 'Incompetence, etc, etc'
This is bad business. For any cryptocurrency to really get mass market, we
need to provide our users with key revocation, to be used when the assumption
about being the only holder of a secret is broken.
I think there's a hardfork-worthy choice here:
1) implement reversal/revocation as an add-on feature
2) implement reversal/revocation as a fundamental that every address gets.
Ethereum made a quick hardfork choice to reverse a *single* instance of
unexpected behavior, and looks a lot like a bank bailout. We have the chance
to learn from this mistake, and, apparently, make a lot of money trading
on both sides of the hardfork.
> You could specify so that transactions "sent" from these addresses must
> receive N confirmations before they can't be revoked, after which the
> transaction is "settled" and the coins become redeemable from their
> destination output. A settlement phase would also mean that a transaction's
> progress was publicly visible so transparent fraud prevention and auditing
> would become possible by anyone.
>
> The reason why I bring this up is existing OP codes and TX types don't seem
> suitable for a secure clearing mechanism; Nlocktimed TXs won't work for
> this since you can't know ahead of time when and where a withdrawal needs
> to be made, plus there's still the potential for key mismanagement; Similar
> problems with OP_CHECKLOCKTIMEVERIFY apply too ??? unless you keep a private
> key around on the server which would defeat the purpose. The main use case
> here, would be specifically to improve centralized exchange security by
> making it impossible for a hot wallet to be raided all at once.
>
> Thoughts?
>
> Some existing background:
>
> http://hackingdistributed.com/2016/08/03/how-bitfinex-heist-could-have-been-avoided/
> -- Proposed the basic idea for a time-based clearing house but using
> blockchains directly, this is a much better idea than my own.
>
> roberts.pm/timechain -- My original paper written in 2015 which proposed a
> similar idea for secure wallet design but implemented using time-locked
> ECDSA keys. Obviously a blockchain would work better for this.
>
> Other -- if the idea has already been brought up by other people, I
> apologize.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
