📅 Original date posted:2013-07-14
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Sun, Jul 14, 2013 at 7:28 PM, Pieter Wuille <pieter.wuille at 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-----
John Dillon [ARCHIVE] /
npub15z…kn0zr
2023-06-07 15:04:33
in reply to nevent1q…gfmz
Author Public Key
npub15z6e9t07ugx267aj3s3c487pln852ydytzlgu0vkkqxfznyvx4jq4kn0zrPublished at
2023-06-07 15:04:33Event JSON
{
"id": "ffae79dd43fcfeea91a538e0693e5dc4e636f2dff207e762e1799dbd679a8d2f",
"pubkey": "a0b592adfee20cad7bb28c238a9fc1fccf4511a458be8e3d96b00c914c8c3564",
"created_at": 1686150273,
"kind": 1,
"tags": [
[
"e",
"2ff57a82e9eaf0c081d4bbf6a285b183f88308632ec43fab11d76bbf1d027ae6",
"",
"root"
],
[
"e",
"c4c784bc8d5ce2441173557dc93c09785e705e99dc436cd53164999884721b52",
"",
"reply"
],
[
"p",
"5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6"
]
],
"content": "📅 Original date posted:2013-07-14\n📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA256\n\nOn Sun, Jul 14, 2013 at 7:28 PM, Pieter Wuille \u003cpieter.wuille at gmail.com\u003e wrote:\n\u003e On Sun, Jul 14, 2013 at 07:05:26PM +0000, John Dillon wrote:\n\u003e\u003e Long-term we should be using P2SH with an inner OP_CHECKSIG for most addresses\n\u003e\u003e as it's a 1 byte savings. Change addresses can have this done first, although\n\u003e\u003e bitcoinj support will help so that satoshidice and similar sites can pay to\n\u003e\u003e P2SH change. As for multisig's P2SH overhead for a 1-of-2 and 2-of-2 and\n\u003e\u003e 3-of-3, is 10%, 8.6% and 6.2% respectively, all pretty minor, especially if you\n\u003e\u003e assume the blocksize limit will be raised.\n\u003e\n\u003e Small comment: the current implementation in the reference client uses a custom\n\u003e script encoder for the UTXO database, which stores every (valid) send-to-pubkey\n\u003e as 33 bytes and every send-to-pubkeyhash or send-to-scripthash as 21 bytes.\n\u003e So for \"standard\" address payment, there is no storage impact of using P2SH\n\u003e instead.\n\nBy \"impact\" I am referring to the impact on transaction size and thus\nblockchain space and fees, not UTXO size as stored by nodes themselves.\nSpecifically take the size of the txout and txin and compare the version using\nP2SH to the equivalent version not using it to get my numbers.\n\nAnyway, given how much uncompressed keys are still used obviously fee pressure\nisn't even close to getting people to create efficient transactions.\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.11 (GNU/Linux)\n\niQEcBAEBCAAGBQJR4v6QAAoJEEWCsU4mNhiP/ToH/1zwzkG0v8OphBaglzhF/dha\nQgRXy3CGQqs43w1hEsfPNaZUyKIZz2gmGtJV2PUh5FavhWY9IUuMCVLvPJ18KZkc\neCLtAWSlUkjemXz6S52RPXW3vmKTJzZK4ZBZP0JiRYfhBQWbUlArLh+mQw9RcWng\n9fdS/Xw4QYFfnN46NMlHdHyqGn4Mu8VgsozeUlxWXBGorf2+IFbMxR1BRi33CluH\n3r6AIRHXPSqgHf6qnHgWqKh/WXMxuG8lLyLa00Rj+ByNcNQCwLV/+9AzSJYNA5Ol\nnnGdkbVDtLjmDS4KjwuSXGP8jh/uRrHLubcgk6UEm27K2/yJxARBfECo78aBLsg=\n=Nx+9\n-----END PGP SIGNATURE-----",
"sig": "f681fc3124ce5c840f728d74cdf36491c9c1e9dc20a476c8f528ea10c7883f97e3eed038328ef70307ff38eda198b6b6e0332d61c8f480252b89d2dcd73975a4"
}