Author: Gregory Maxwell 2011-12-17 23:46:34
Published on: 2011-12-17T23:46:34+00:00
In a discussion on Bitcoin development, Luke-Jr proposed that full public key addresses be required to be "compact" and use version 21. However, this would introduce another address type that services will have to cope with and no currently deployed software knows how to spend or receive it. Additionally, pay-to-pubkey schemes shift storage to TXN output scripts which are the least prunable place, resulting in more storage for nodes that are pruning. Ignoring pruning, pay-to-address plus key recovery is smaller than pay-to-compressed pubkey. While pay to non-compressed pubkey is smaller than pay-to-address-without-recovery, assuming you don't prune, and more deployable because nodes can already receive it, it's still larger than key recovery either way. Pay-to-compressed has all the disadvantages, as it's larger than recovery and doesn't have the advantage of already deployed software.Excitement over key recovery fell when it was pointed out that it only saves space in input scripts, which isn't important because they're quickly prunable. If pruning becomes common on many nodes, then pay-to-address should be preferred since it's the smallest in that case. However, if pruning isn't assumed, then pay-to-address plus key recovery should be preferred since it's the smallest without pruning. Luke-Jr expressed frustration that discussion on recovery in OP_EVAL was dropped because "input script size doesn't matter because of pruning" and now people are talking about adding another address type, which creates seriously bloated transactions where there is pruning because it's slightly smaller in the no-pruning case and still not as small for key recovery.
Updated on: 2023-05-18T22:51:48.535647+00:00