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
|
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 <john.dillon892@googlemail.com>) id 1UyS9l-0002Xa-UI
for bitcoin-development@lists.sourceforge.net;
Sun, 14 Jul 2013 19:40:29 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of googlemail.com
designates 209.85.215.182 as permitted sender)
client-ip=209.85.215.182;
envelope-from=john.dillon892@googlemail.com;
helo=mail-ea0-f182.google.com;
Received: from mail-ea0-f182.google.com ([209.85.215.182])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UyS9k-0006Oi-2X
for bitcoin-development@lists.sourceforge.net;
Sun, 14 Jul 2013 19:40:29 +0000
Received: by mail-ea0-f182.google.com with SMTP id d10so7369737eaj.41
for <bitcoin-development@lists.sourceforge.net>;
Sun, 14 Jul 2013 12:40:21 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.14.211.67 with SMTP id v43mr56202830eeo.55.1373830821713;
Sun, 14 Jul 2013 12:40:21 -0700 (PDT)
Received: by 10.223.12.131 with HTTP; Sun, 14 Jul 2013 12:40:21 -0700 (PDT)
In-Reply-To: <20130714192838.GA26941@vps7135.xlshosting.net>
References: <CAPaL=UW4zXui8Jh-qaFgmfhbzhRSHNyh7U5MSJo2bHoWmtoCkA@mail.gmail.com>
<20130714192838.GA26941@vps7135.xlshosting.net>
Date: Sun, 14 Jul 2013 19:40:21 +0000
Message-ID: <CAPaL=UXZP39CxjsVH5z0rvvvrFtt6uXbuy_Sn6Nz+CDUCt_T3A@mail.gmail.com>
From: John Dillon <john.dillon892@googlemail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(john.dillon892[at]googlemail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
digit (john.dillon892[at]googlemail.com)
-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
X-Headers-End: 1UyS9k-0006Oi-2X
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Reward for P2SH IsStandard() patch.
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, 14 Jul 2013 19:40:30 -0000
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Sun, Jul 14, 2013 at 7:28 PM, Pieter Wuille <pieter.wuille@gmail.com> wrote:
> On Sun, Jul 14, 2013 at 07:05:26PM +0000, John Dillon wrote:
>> Long-term we should be using P2SH with an inner OP_CHECKSIG for most addresses
>> as it's a 1 byte savings. Change addresses can have this done first, although
>> bitcoinj support will help so that satoshidice and similar sites can pay to
>> P2SH change. As for multisig's P2SH overhead for a 1-of-2 and 2-of-2 and
>> 3-of-3, is 10%, 8.6% and 6.2% respectively, all pretty minor, especially if you
>> assume the blocksize limit will be raised.
>
> Small comment: the current implementation in the reference client uses a custom
> script encoder for the UTXO database, which stores every (valid) send-to-pubkey
> as 33 bytes and every send-to-pubkeyhash or send-to-scripthash as 21 bytes.
> So for "standard" address payment, there is no storage impact of using P2SH
> instead.
By "impact" I am referring to the impact on transaction size and thus
blockchain space and fees, not UTXO size as stored by nodes themselves.
Specifically take the size of the txout and txin and compare the version using
P2SH to the equivalent version not using it to get my numbers.
Anyway, given how much uncompressed keys are still used obviously fee pressure
isn't even close to getting people to create efficient transactions.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJR4v6QAAoJEEWCsU4mNhiP/ToH/1zwzkG0v8OphBaglzhF/dha
QgRXy3CGQqs43w1hEsfPNaZUyKIZz2gmGtJV2PUh5FavhWY9IUuMCVLvPJ18KZkc
eCLtAWSlUkjemXz6S52RPXW3vmKTJzZK4ZBZP0JiRYfhBQWbUlArLh+mQw9RcWng
9fdS/Xw4QYFfnN46NMlHdHyqGn4Mu8VgsozeUlxWXBGorf2+IFbMxR1BRi33CluH
3r6AIRHXPSqgHf6qnHgWqKh/WXMxuG8lLyLa00Rj+ByNcNQCwLV/+9AzSJYNA5Ol
nnGdkbVDtLjmDS4KjwuSXGP8jh/uRrHLubcgk6UEm27K2/yJxARBfECo78aBLsg=
=Nx+9
-----END PGP SIGNATURE-----
|
