Pieter Wuille [ARCHIVE] on Nostr: 📅 Original date posted:2013-07-14 📝 Original message:On Sun, Jul 14, 2013 at ...
📅 Original date posted:2013-07-14
📝 Original message: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.
--
Pieter
Published at
2023-06-07 15:04:33Event JSON
{
"id": "c4c784bc8d5ce2441173557dc93c09785e705e99dc436cd53164999884721b52",
"pubkey": "5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6",
"created_at": 1686150273,
"kind": 1,
"tags": [
[
"e",
"2ff57a82e9eaf0c081d4bbf6a285b183f88308632ec43fab11d76bbf1d027ae6",
"",
"root"
],
[
"e",
"1c0fd7c45f73deac90137e3ec6708525002be9fcacf9cc11504b487aedafda72",
"",
"reply"
],
[
"p",
"a0b592adfee20cad7bb28c238a9fc1fccf4511a458be8e3d96b00c914c8c3564"
]
],
"content": "📅 Original date posted:2013-07-14\n📝 Original message:On Sun, Jul 14, 2013 at 07:05:26PM +0000, John Dillon wrote:\n\u003e Long-term we should be using P2SH with an inner OP_CHECKSIG for most addresses\n\u003e as it's a 1 byte savings. Change addresses can have this done first, although\n\u003e bitcoinj support will help so that satoshidice and similar sites can pay to\n\u003e P2SH change. As for multisig's P2SH overhead for a 1-of-2 and 2-of-2 and\n\u003e 3-of-3, is 10%, 8.6% and 6.2% respectively, all pretty minor, especially if you\n\u003e assume the blocksize limit will be raised.\n\nSmall comment: the current implementation in the reference client uses a custom\nscript encoder for the UTXO database, which stores every (valid) send-to-pubkey\nas 33 bytes and every send-to-pubkeyhash or send-to-scripthash as 21 bytes.\nSo for \"standard\" address payment, there is no storage impact of using P2SH\ninstead.\n\n-- \nPieter",
"sig": "e8b155d687e26c0dba6c82254f1d999b455c883447671afc550d2865181959b4581e38ac3c1d5f630197eb8864f15186ba5cfde9f32737358b952b309a0848aa"
}