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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1RrNB8-0007SL-PL
for bitcoin-development@lists.sourceforge.net;
Sun, 29 Jan 2012 05:19:50 +0000
Received-SPF: pass (sog-mx-4.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-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1RrNB8-0004n2-3a
for bitcoin-development@lists.sourceforge.net;
Sun, 29 Jan 2012 05:19:50 +0000
Received: by vcbfk26 with SMTP id fk26so2873901vcb.34
for <bitcoin-development@lists.sourceforge.net>;
Sat, 28 Jan 2012 21:19:44 -0800 (PST)
MIME-Version: 1.0
Received: by 10.220.150.206 with SMTP id z14mr6692859vcv.5.1327814384679; Sat,
28 Jan 2012 21:19:44 -0800 (PST)
Received: by 10.220.141.211 with HTTP; Sat, 28 Jan 2012 21:19:44 -0800 (PST)
In-Reply-To: <1327812740.41242.YahooMailNeo@web121002.mail.ne1.yahoo.com>
References: <1327812740.41242.YahooMailNeo@web121002.mail.ne1.yahoo.com>
Date: Sun, 29 Jan 2012 00:19:44 -0500
Message-ID: <CAAS2fgRWJb+p=gM4eG_p4fr1+UsT-EO_YZOvkgh6SnktRRTyEw@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Amir Taaki <zgenjix@yahoo.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
(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.6 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1RrNB8-0004n2-3a
Cc: "bitcoin-development@lists.sourceforge.net"
<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 05:19:50 -0000
On Sat, Jan 28, 2012 at 11:52 PM, Amir Taaki <zgenjix@yahoo.com> wrote:
> How could you have a 70 byte long address without a P2SH scheme? Is this a mistake?
... No it's not a mistake. P2SH _prevents_ needing long addresses.
Lets unpack the acronym "pay to script _hash_". Hashes only need to
be 128-256 bits in size or so to have acceptable security, so you
don't need something longer than that for paying to a hash.
Note that gavin is saying 70 characters, not bytes.
Without some form of P2SH then only way for you to make a personal
choice of asking people to pay to a two-factor protected account or
two a multiparty trust that manages the finances of an organization
is using some form of "P2S", pay-to-script.
In other words, you'd have to have an address that encodes a full
script specification for the sender to pay to, instead of just
encoding its hash. As a result these addresses would be much longer
(and potentially very long).
The minimum size of a two address involving encoded script would be on
that order, but they get bigger quite quickly if you add more options
to the script (actually 70 sounds quite small, it should be more like
100 for a minimum two pubkey script).
In addition to the unworkability of very long addresses as described
by gavin (amusingly I am unable to copy and paste the quoted example
in one go) a P2S solution has several problems which you might
consider more or less important:
(1) They are highly vulnerable to invisible substitution. E.g. I can
trivially take a P2S address, change one or two characters and get a
script which is redeemable by anyone. With P2SH you have to do
computation which is exponential in the number of unchanged digits to
get a look alike address.
(2) The sender is fully responsible for fees related to the enlarged
transactions. Even if _you're_ willing to take the txn-processing time
and fee burden of a 30 person joint trust address, random e-commerce
sites will not be and will randomly reject your addresses.
(3) They create another input vector for non-trivial data which must
be inspected and validated, potentially presenting an attack surface.
(4) They leave the complicated (long) release rules in the transaction
outputs. When a transaction is mined we can't be sure if it will ever
be redeemed. The outputs are unprunable. In a future world where
many nodes prune output space is far more important than input space
and it would make sense to require more fees for it because we're
never sure how long it would need to be stored (making it an
attractive target for someone who wants to make Bitcoin unusable by
spamming it with worthless data). P2SH reduces output sizes to the
absolute minimum without inflating the total data size.
|
