From: John Dillon <john.dillon892@googlemail•com>
To: Pieter Wuille <pieter.wuille@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Reward for P2SH IsStandard() patch.
Date: Sun, 14 Jul 2013 19:40:21 +0000 [thread overview]
Message-ID: <CAPaL=UXZP39CxjsVH5z0rvvvrFtt6uXbuy_Sn6Nz+CDUCt_T3A@mail.gmail.com> (raw)
In-Reply-To: <20130714192838.GA26941@vps7135.xlshosting.net>
-----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-----
prev parent reply other threads:[~2013-07-14 19:40 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-14 19:05 John Dillon
2013-07-14 19:28 ` Pieter Wuille
2013-07-14 19:40 ` John Dillon [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAPaL=UXZP39CxjsVH5z0rvvvrFtt6uXbuy_Sn6Nz+CDUCt_T3A@mail.gmail.com' \
--to=john.dillon892@googlemail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=pieter.wuille@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox