summaryrefslogtreecommitdiff
path: root/ef/93117958f9584e55f72db0ac5b66f7dec70185
blob: 3ac9679b0db5a19fc6b0226eb43d2fd6f441a650 (plain)
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
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mh.in.england@gmail.com>) id 1QZPsc-0005Kh-3D
	for bitcoin-development@lists.sourceforge.net;
	Wed, 22 Jun 2011 16:02:14 +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 1QZPsZ-0003Ft-9u
	for bitcoin-development@lists.sourceforge.net;
	Wed, 22 Jun 2011 16:02:14 +0000
Received: by vws2 with SMTP id 2so1055063vws.34
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 22 Jun 2011 09:02:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.175.133 with SMTP id ca5mr1197276vdc.82.1308758525871; Wed,
	22 Jun 2011 09:02:05 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.52.155.38 with HTTP; Wed, 22 Jun 2011 09:02:05 -0700 (PDT)
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 18:02:05 +0200
X-Google-Sender-Auth: _SnfUXJUcLTfZKGltsYEvuCRKaA
Message-ID: <BANLkTikThwkSBjmxqkVTqdht1dM6=SVO+MFu_-NB0BaNLpy5yg@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.2 (-)
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 freemail (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.0 RFC_ABUSE_POST Both abuse and postmaster missing on sender domain
	0.3 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1QZPsZ-0003Ft-9u
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:02:14 -0000

> All of which makes me wonder if the straightforward "n PUBKEYS m
> CHECKMULTISIG" transaction type is the right thing to do.

As far as I understand the only reason for hashing the public key is
for typing convenience. Otherwise we'd all just pass raw public keys
around and use the simple form seen in the direct-to-ip case.

But as there'd need to be a higher level protocol on top of the
multipay transactions in order to verify who the other parties are,
there's no need for typing convenience. It'd all be done
automatically.