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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1Qwunz-0001bp-NP
for bitcoin-development@lists.sourceforge.net;
Fri, 26 Aug 2011 11:42:35 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.47 as permitted sender)
client-ip=209.85.212.47; envelope-from=mh.in.england@gmail.com;
helo=mail-vw0-f47.google.com;
Received: from mail-vw0-f47.google.com ([209.85.212.47])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Qwuny-0002XD-UF
for bitcoin-development@lists.sourceforge.net;
Fri, 26 Aug 2011 11:42:35 +0000
Received: by vwe42 with SMTP id 42so3893122vwe.34
for <bitcoin-development@lists.sourceforge.net>;
Fri, 26 Aug 2011 04:42:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.27.37 with SMTP id q5mr964660vdg.362.1314358949493; Fri, 26
Aug 2011 04:42:29 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.52.164.165 with HTTP; Fri, 26 Aug 2011 04:42:29 -0700 (PDT)
In-Reply-To: <CABsx9T1uw43JuvhEmJP0KCyojsDi1r7v6BaLBHz7wWazduE5iw@mail.gmail.com>
References: <CABsx9T1uw43JuvhEmJP0KCyojsDi1r7v6BaLBHz7wWazduE5iw@mail.gmail.com>
Date: Fri, 26 Aug 2011 13:42:29 +0200
X-Google-Sender-Auth: zRCjFLkjQRlNHJNgrbyRuhlfGaY
Message-ID: <CANEZrP2FYjJXvB=kzu+wBcoGOyL=45QeDqLfyZONxYu-9M50Uw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.0 (-)
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
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
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
0.5 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1Qwuny-0002XD-UF
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: Fri, 26 Aug 2011 11:42:35 -0000
> It seems to me the fastest path to very secure, very-hard-to-lose
> bitcoin wallets is multi-signature transactions.
Agreed.
That said I'm not sure it makes sense for payers to care about the
details of how somebody is protecting their wallets (which is what new
address types means). It's possible for a users software to notice
inbound payments to a regular Bitcoin address and then immediately
respend them to multi-signed outputs. This way key management can be
simpler as you don't need to integrate it with your shopping cart
software or anything like that - you can just do the usual thing of
pre-generating a few hundred thousand addresses, fill up your cart
implementation and go. When a payment is received, your wallet
software can keep an eye on how much unlocked balance it has and start
locking value once it goes over a pre-set amount, or use any other
policy the user might have.
This fits with my belief that we'll eventually move away from senders
attaching tx fees, instead receivers will respend the fee-less
transaction adding whatever fee they believe is appropriate (eg, maybe
it's very low in the case of a buyer with good reputation, or higher
for unknown buyers). It doesn't make a whole lot of sense for buyers
to have to attach more fees just because the merchant is using complex
wallet policies.
Whitelisting the basic CHECKMULTISIG form (assuming it can be made to
work) seems uncontroversial, why not do it today? The forms designed
to make fancier addresses be embeddable inside QRcodes, can come later
if people feel it's necessary. I'm still not convinced it is.
Once malware can't just email wallets to the attacker, or steal the
keys when the user decrypts due to a second factor, the next easiest
attack is to that malware can rewrite addresses on-screen as it sees
fit, forwarding small payments so the user doesn't notice then
stealing a big one. To solve that, Bitcoin addresses need to contain
not only a pubkey[hash] but some kind of endpoint the second factor
can use to verify ownership of the key. It can be discussed later, I
don't think there are many possible designs here so it shouldn't be
too controversial.
|
