{"type":"rich","version":"1.0","author_name":"npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6r","author_url":"https://nostr.ae/npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6r","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2011-12-18\n🗒️ Summary of this message: Bitcoin developers are proposing changes to the scripting language to reduce the amount of data required to be stored on the blockchain. The changes include using compressed public keys, compact signatures, and pubkey recovery. These changes could result in several proposed transaction types, including send-to-pubkeys-hash, send-to-recovered-pubkeys-hash-with-compact-signature-inside-op_eval, send-to-pubkey, send-to-compressed-pubkey, and send-to-compressed-pubkeys-hash. The proposed changes would reduce the amount of space required on the blockchain and improve transaction efficiency.\n📝 Original message:On Sun, Dec 18, 2011 at 01:15:26PM +0100, Jorge Timón wrote:\n\u003e But anyway, reading some comments I feel I'm missing something about\n\u003e this proposal. How can you save space by putting the whole public key\n\u003e instead of just the address (a hash of the public key) with each\n\u003e output?\n\u003e Is this what it's being proposed?\n\nYes. The reason is that currently a send-to-address puts the address in the\noutput script, while redeeming requires the full pubkey plus the signature\nto be placed in the input script. Overall, this requires more space than a\nsend-to-pubkey, where the output contains the pubkey, and the input the\nsignature.\n\nThere are several possible improvements however, and they may not all have\nbeen explained in this thread. To summarize:\n* compressed public keys (33 byte pubkeys instead of 65 bytes)\n* compact signatures (66 bytes instead of 72, including hash type byte)\n* pubkey recovery (allows the public key to be derived from a compact signature)\n\nThe first is very easy to implement (see pull #649). Compact signatures \nand pubkey recovery require a change to the scripting language (though are\nalready implemented, as they are used for message signing).\n\nThese result in several combinations that could be proposed:\n1) send-to-pubkeys-hash\n   - currently the default addres type\n2) send-to-recovered-pubkeys-hash-with-compact-signature-inside-op_eval\n   - extend the scripting language inside OP_EVAL, as described in\n     https://gist.github.com/1262449\n   - use compact signatures\n   - use key recovery, and never put a pubkey in the blockchain data\n3) send-to-pubkey\n   - traditional transaction type\n4) send-to-compressed-pubkey\n   - what Luke proposes as new address type\n5) send-to-compressed-pubkeys-hash\n   - what pull #649 would bring\n\nGregory Maxwell made a small table to compare these options:\n\n  http://people.xiph.org/~greg/addr.compare.html\n\nIf you don't consider pruning, everything is better than send-to-pubkeys-hash\nas we have now. Both using pubkeys instead of hashes, using compressed pubkeys\ninstead of full ones improve the situation independently, and using key\nrecovery is even better.\n\nIf you do consider pruning, the advantages are smaller, but it is far from\nclear to me how pruning will be implemented in the future (as a pruning\nnode cannot function as a NODE_NETWORK service anymore).\n\n-- \nPieter"}