P2PUBKEY in witness program (P2WPUBKEY)

0

Old standard transactions format included 3 types: P2PUBKEY, P2PKH, P2SH. After Segwit soft fork, we have got 2 additional types: P2WPKH and P2WSH.

If we compare the cost of spending inputs (in bytes we write on HDD) for P2PUBKEY, P2PKH, and P2WPKH and we got next values:

  • P2PUBKEY 33 bytes public key(we do not consider uncompressed keys) + signature 72 bytes = 105 bytes
  • P2PKH 20 bytes public key hash + 33 bytes public key + 72 bytes signature = 125 bytes
  • P2WPKH 20 bytes public key hash + 33 bytes public key + 72 bytes signature = 125 bytes

From this comparison, we can conclude that P2PUBKEY the best for reducing blockchain size. We can save about 19% of spending input size. I understand that P2PKH give more security in case we do not reuse the address. If we reuse address, there are no advantages to use P2PKH. We can observe the quite frequent use of addresses repeatedly. For a specific range of tasks, we do not need extra security like P2PKH. Why in Segwit transaction types we don't have the ability to use P2WPUBKEY as standard transaction? This type of transaction help to reduce blockchain size in case a user does not need/want use "no address reuse" security model? 20 bytes for each input this is a good opportunity to save the size of the blockchain.

Also, I read this thread https://bitcointalk.org/index.php?topic=6430.0, what is the reason why bitcoin core developers do not want to use public key recovery and save 33 bytes for each input? If the concerns are related to performance, we can observe how the ethereum works and reaches about 1M tx per day (this is like 1M inputs per day in Bitcoin).

bitaps.com

Posted 2018-07-09T22:05:46.933

Reputation: 563

Answers

3

If the concerns are related to performance, we can observe how the ethereum works and reaches about 1M tx per day (this is like 1M inputs per day in Bitcoin).

Ethereum is really not a good comparison considering that it is impossible to sync a fully validating archival Ethereum node.

Regardless, the concern isn't just "performance" but rather Denial of Service attack risk. Performing pubkey recovery is much more computationally expensive than computing a hash of something. Thus there is potentially a DoS attack where an attacker creates many transactions with invalid signatures which a node then has to perform pubkey recovery on only to discard the transaction because it is invalid. By requiring a node to do a lot of computations on invalid transactions, it can be prevented from doing any verification of actual transactions thus preventing the node from actually doing its job.

With key hashes, this is less of a risk because the attacker needs to know the pubkey in order to get a node to break on the invalid signature step. Thus an attacker could not just use any output that has the same format (as you could with any output using key recovery) but has to use specific outputs which he knows the pubkeys for which limits how many of these transactions can be created.

Andrew Chow

Posted 2018-07-09T22:05:46.933

Reputation: 40 910

To sync fully validating Ethereum node you just need SSD disk. The bottleneck is disk io, not computation and CPU. About denial service attack, transactions with invalid signature will not be relayed to other nodes, so this attack on a single node or group of nodes. Single node easily able block attacker nodes who sent invalid transactions. At this moment in bitcoin core implemented algorithm with a penalty and blocking misbehavior nodes. – bitaps.com – 2018-07-10T11:59:01.293

The banning function in Bitcoin Core is less of a punishment or more of a protective measure against legitimate nodes that are functioning. If an attacker really wanted to attack you, it is trivial for them to connect to you through many different IP addresses and circumvent the ban system. – Andrew Chow – 2018-07-10T20:58:21.700

Asked: 2018-07-09T22:05:46.933

Viewed: 58 times

Active: 2018-07-09T22:45:53.543