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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <bgroff@lavabit.com>) id 1QwHYY-0002g3-6q
for bitcoin-development@lists.sourceforge.net;
Wed, 24 Aug 2011 17:48:02 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of lavabit.com
designates 72.249.41.33 as permitted sender)
client-ip=72.249.41.33; envelope-from=bgroff@lavabit.com;
helo=karen.lavabit.com;
Received: from karen.lavabit.com ([72.249.41.33])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1QwHYX-0003hR-7E for bitcoin-development@lists.sourceforge.net;
Wed, 24 Aug 2011 17:48:02 +0000
Received: from a.earth.lavabit.com (a.earth.lavabit.com [192.168.111.10])
by karen.lavabit.com (Postfix) with ESMTP id 887DE11BB22;
Wed, 24 Aug 2011 12:47:55 -0500 (CDT)
Received: from lavabit.com
(load-me-in-a-browser-if-this-tor-node-is-causing-you-grief.riseup.net
[77.109.139.87]) by lavabit.com with ESMTP id 186KC9EVMFGQ;
Wed, 24 Aug 2011 12:47:55 -0500
Received: from 77.109.139.87 (SquirrelMail authenticated user bgroff)
by lavabit.com with HTTP; Wed, 24 Aug 2011 13:47:55 -0400 (EDT)
Message-ID: <21952.77.109.139.87.1314208075.squirrel@lavabit.com>
In-Reply-To: <CABsx9T1uw43JuvhEmJP0KCyojsDi1r7v6BaLBHz7wWazduE5iw@mail.gmail.com>
References: <CABsx9T1uw43JuvhEmJP0KCyojsDi1r7v6BaLBHz7wWazduE5iw@mail.gmail.com>
Date: Wed, 24 Aug 2011 13:47:55 -0400 (EDT)
From: bgroff@lavabit.com
To: "Gavin Andresen" <gavinandresen@gmail.com>
User-Agent: SquirrelMail/1.4.13
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.9 (-)
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
-0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
X-Headers-End: 1QwHYX-0003hR-7E
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] New standard transaction types: time to
schedule a blockchain split?
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: Wed, 24 Aug 2011 17:48:02 -0000
"Gavin Andresen" <gavinandresen@gmail.com> wrote:
> It seems to me the fastest path to very secure, very-hard-to-lose
> bitcoin wallets is multi-signature transactions.
>
> To organize this discussion: first, does everybody agree?
I agree. For example, a corporate wallet can require threshold signature=
s
to disburse. Or for personal use you can have a couple of additional
keys, one stored on a secure device for confirmation and one offline as
emergency backup if you lose your secure device.
...
> I've been trying to get consensus on low-level 'standard' transactions
> for transactions that must be signed by 2 or 3 keys; current draft
> proposal is here:
> https://gist.github.com/39158239e36f6af69d6f
> and discussion on the forums here:
> https://bitcointalk.org/index.php?topic=3D38928.0
> ... and there is a pull request that is relevant here:
> https://github.com/bitcoin/bitcoin/pull/319
For context - I am the author of the latter.
> I still think it is a good idea to enable a set of new 'standard'
> multisignature transactions, so they get relayed and included into
> blocks. I don't want to let "the perfect become the enemy of the
> good" -- does anybody disagree?
>
> The arguments against are that if the proposed standard transactions
> are accepted, then the next step is to define a new kind of bitcoin
> address that lets coins be deposited into a multisignature-protected
> wallet.
>
> And those new as-yet-undefined bitcoin addresses will have to be 2 or
> 3 times as big as current bitcoin addresses, and will be incompatible
> with old clients.
Incompatible at the UI level, but not at the block chain level. Changing
the block chain rules will be quite an undertaking. You will have to set
a block number for the rule change a few months in advance and will have
to get agreement from the pools. I think it is important to increase
trust in the bitcoin ecosystem sooner than that. The current flat
exchange rate and difficulty may be a signal that people are getting risk
averse.
> So, if we are going to have new releases that are incompatible with
> old clients why not do things right in the first place, implement or
> enable opcodes so the new bitcoin addresses can be small, and schedule
> a block chain split for N months from now.
>
> My biggest worry is we'll say "Sure, it'll only take a couple days to
> agree on how to do it right" and six months from now there is still no
> consensus on exactly which digest function should be used, or whether
> or not there should be a new opcode for arbitrary boolean expressions
> involving keypairs. And people's wallets continue to get lost or
> stolen.
That is my worry too. We already have working code for this (pull 319),
and the addresses are not so long as to be unusable. I hope we can move
forward on the existing code and in parallel move forward on block chain
rule proposals at an agreed upon block number.
--
Bobby Groff
|
