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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <bgroff@lavabit.com>) id 1QZQDY-00083M-Jt
for bitcoin-development@lists.sourceforge.net;
Wed, 22 Jun 2011 16:23:52 +0000
Received-SPF: pass (sog-mx-3.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-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1QZQDX-0005nH-HX for bitcoin-development@lists.sourceforge.net;
Wed, 22 Jun 2011 16:23:52 +0000
Received: from a.earth.lavabit.com (a.earth.lavabit.com [192.168.111.10])
by karen.lavabit.com (Postfix) with ESMTP id 5603611BBAE;
Wed, 22 Jun 2011 11:23:46 -0500 (CDT)
Received: from lavabit.com (chomsky.torservers.net [77.247.181.162])
by lavabit.com with ESMTP id E884OOME90MX;
Wed, 22 Jun 2011 11:23:46 -0500
Received: from 77.247.181.162 (SquirrelMail authenticated user bgroff)
by lavabit.com with HTTP; Wed, 22 Jun 2011 12:23:46 -0400 (EDT)
Message-ID: <59140.77.247.181.162.1308759826.squirrel@lavabit.com>
In-Reply-To: <BANLkTikP-VheXQyXikH6jvaqnWfH_cNjnw@mail.gmail.com>
References: <18440.87.106.138.84.1308200020.squirrel@lavabit.com>
<BANLkTi=FTLnU-riNVYssnR9FLdcEeZX7gOS6Zdv1f_XDcJoSSg@mail.gmail.com>
<BANLkTikkBoHBr8z6Uv7oGU_KuT0bvgx3HA@mail.gmail.com>
<BANLkTinUbJ6CKczHiyX2esMyRWgUrJ_9ASeOqZbRj+23GZgjcQ@mail.gmail.com>
<BANLkTikP-VheXQyXikH6jvaqnWfH_cNjnw@mail.gmail.com>
Date: Wed, 22 Jun 2011 12:23:46 -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.4 (-)
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 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-0.0 SPF_PASS SPF: sender matches SPF record
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
X-Headers-End: 1QZQDX-0005nH-HX
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] [PULL] Add scriptPubKey enforced
sendescrow and redeemescrow API calls
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, 22 Jun 2011 16:23:52 -0000
Gavin said:
> It would be spiffy to publish a new type of bitcoin address that is an
> "m of n address", that anybody could pay into, but would require m of
> n signatures to spend. Publishing a really really long address with
> all n public keys would work.
I currently have 2,ADDR1,ADDR2,ADDR3 (2-of-3 example) as this new address
type.
>
> It would be great if the "higher level protocol" for pay-to-escrow was
> just get a bitcoin address via https (or other secure mechanism), like
> we do now for pay-to-single-party. Where the person you're paying has
> their own mechanisms for generating or fetching/authenticating the
> public keys, and knows which bitcoin addresses they've published.
Agreed.
> All of which makes me wonder if the straightforward "n PUBKEYS m
> CHECKMULTISIG" transaction type is the right thing to do.
> Following the pattern of our standard DUP HASH160 etc. transaction
> type, maybe 2 of 2 and 2 of three should be:
>
> 2DUP ADD HASH160 ...hash(pubkey1+2)... EQUALVERIFY 2 2 ROLL
> CHECKMULTISIGVERIFY
> 3DUP ADD ADD HASH160 ...hash(pubkey1+2+3)... EQUALVERIFY 2 3 ROLL
> CHECKMULTISIGVERIFY
>
> Spending those transactions would mean putting the m signatures and
> the n public keys in the TxIn, but sending funds you'd only need the
> hash of the sum of the public keys.
This is similar to the way the current implementation works. It uses
HASH160, but there's no attempt to save space by hashing the sum of the
pubkeys. The major advantage of summing is shorter address for the end
user to copy-paste. The disadvantage is the need for long term storage o=
f
the key set so you know what keys to sign with.
> --
> Gavin Andresen
> http://clearcoin.com/
--
Bobby Groff
|
