bip-STUAFS.mediawiki

  BIP: ___
  Title: Short Term Use Addresses for Scalability
  Author: Jeremy Rubin <jr@mit.edu>
  Status: Draft
  Type: Standards Track
  Created: 2015-06-23

Table of Contents Abstract Motivation Specification Backward compatibility Discussion Acknowledgement

Abstract

Increase the total number of transactions per block by reducing the address size for short lived addresses.

Motivation

1. Enable network growth.
2. Make transactions less expensive for users when a per-byte fee market develops.

Specification

1. Current standard transaction is of the following form:

   OP_DUP OP_HASH160 [pubKeyHash] OP_EQUALVERIFY OP_CHECKSIG

2. Proposed new standard transaction is of the following form:

   OP_DUP OP_HASH160 [LEN_PARAM] OP_LEFT [pubKeyHash[:LEN_PARAM]] OP_EQUALVERIFY OP_CHECKSIG

3. OP_LEFT must be enabled
4. LEN_PARAM is by default 10 (assuming OP_LEFT operates on bytes). Desired security can be tuned by adjusting LEN_PARAM
5. Transactions where the pubKeyHash length != LEN_PARAM would not be relayed as a safeguard

Backward compatibility

The required opcodes are currently disabled. Therefore, clients before this change would not be compatible.

Discussion

This BIP would reduce the size of a standard form UTXO by approximately 78 bits (80 bit reduction, 2 bit script increase).

This would allow for more UTXOs per block.

Security wise, each hash would now be 80-bit, which should still be secure for short term use addresses.

It could be argued that instead of, or in addition to, using a smaller hash, one could also use a smaller key. However, this is not explored to be maximally compatible with the existing protocol and standards. Furthermore, attacks against hashes and ECDLP scale differently (O(2^n) brute force for hashes vs O(2^(n/2)) Pollard's rho for ECDLP), so at the same security level, signatures have roughly twice the bitlength as a hash, limiting the potential for savings. This could be a topic for more discussion as more performance is desired from the network.

Furthermore, it would perhaps be better to XOR together both halves of the key, but this would have more overhead in script length, it would be likely better to just use a slightly longer address.

Acknowledgement

Thanks to Madars Virza for reading an earlier version of this draft.