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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1RrPts-0002r2-AL
for bitcoin-development@lists.sourceforge.net;
Sun, 29 Jan 2012 08:14:12 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.220.175 as permitted sender)
client-ip=209.85.220.175; envelope-from=gmaxwell@gmail.com;
helo=mail-vx0-f175.google.com;
Received: from mail-vx0-f175.google.com ([209.85.220.175])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1RrPtr-0000HS-LB
for bitcoin-development@lists.sourceforge.net;
Sun, 29 Jan 2012 08:14:12 +0000
Received: by vcbfk26 with SMTP id fk26so2911775vcb.34
for <bitcoin-development@lists.sourceforge.net>;
Sun, 29 Jan 2012 00:14:06 -0800 (PST)
MIME-Version: 1.0
Received: by 10.220.116.10 with SMTP id k10mr6835712vcq.25.1327824846254; Sun,
29 Jan 2012 00:14:06 -0800 (PST)
Received: by 10.220.141.211 with HTTP; Sun, 29 Jan 2012 00:14:06 -0800 (PST)
In-Reply-To: <4F24D7C1.3070106@gmail.com>
References: <1327812740.41242.YahooMailNeo@web121002.mail.ne1.yahoo.com>
<1327813841.99379.YahooMailNeo@web121006.mail.ne1.yahoo.com>
<4F24D7C1.3070106@gmail.com>
Date: Sun, 29 Jan 2012 03:14:06 -0500
Message-ID: <CAAS2fgQhfYfwrT6M8AVDRYETwS0WrXD7iYoxUvcPT3VMJm5ryA@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Alan Reiner <etotheipi@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.1 (-)
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
(gmaxwell[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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: 1RrPtr-0000HS-LB
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Quote on BIP 16
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: Sun, 29 Jan 2012 08:14:12 -0000
On Sun, Jan 29, 2012 at 12:23 AM, Alan Reiner <etotheipi@gmail.com> wrote:
[snip]
> But gmaxwell has expressed some compelling reasons why plain multi-sig
> might be abused, which maybe suggests we don't want it ever considered
> standard...? =C2=A0I guess I'm not really promoting one thing or another,=
but
Be careful not to conflate multisig _addresses_ and P2S with multisig
output scripts in general.
Of the issues I raised only the size of the potentially unprunable
transaction outputs is an argument against multisig outputs which
aren't getting packed up in addresses.
Things like negotiated escrow arrangements can work okay either way.
I think P2SH is still better for these for two reasons: Reasonable
anti-spam behavior by network participant may make it hard to make
large output scripts (see above), but this isn't an issue yet... and
P2S(H) lets you use a separate escrow-maker tool for clients paying
into escrow without any knowledge or support of escrow transactions in
that client. This uncoupling is important both for general "feature
velocity" as well as providing a uniform feature set across bitcoin
services (e.g. you negotiate paying someone via escrow, you use a tool
to make a mutually agreed escrow configuration, but your funds are in
MTGOX=E2=80=94 no issue if P2SH is widely used).
|
