Skip to content
Go to file
Cannot retrieve contributors at this time
155 lines (79 sloc) 6.47 KB
CIP: 15
Title: Segwit Support
Authors: Devon Weller
Status: Draft
Type: Standards Track
Created: 2017-09-12


This is a proposal to support spending and creating segwit outputs for Counterparty transactions

  • Modify counterparty-lib to generate P2WPKH or P2WSH outputs
  • Modify counterparty-lib to parse P2WPKH or P2WSH outputs
  • Modify counterparty-lib to interpret Bech32 (BIP 173) addresses in API methods
  • Modify counterwallet to display Bech32 (BIP 173) P2WPKH addresses in addition to the standard base58 P2PKH addresses


Neither counterparty-lib nor counterwallet are segwit aware. Transactions are constructed using standard P2PKH and P2SH scripts.

By utilizing P2WPKH and P2WSH scripts to send assets, users can spend less on transaction fees sent from counterparty-lib and counterwallet.

Adding segwit compatibility to counterparty-lib also enables potential future enhancements.


Addresses for P2PKH and P2WPKH outputs

Bitcoin uses 20-byte pubkey hashes for standard addresses. These addresses can be represented in base58 format or in Bech32 format as defined in BIP 173.

The same public key hash can be represented in two different address formats. Below is a table for 3 different representations of the public key hash 0x751e76e8199196d454941c45d1b3a323f1433bd6.

Type Representation Preferred Output Type
Public key hash 0x751e76e8199196d454941c45d1b3a323f1433bd6 n/a
base58 address 1BgGZ9tcN4rm9KBzDn7KprQz87SZ26SAMH P2PKH
Bech32 address bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4 P2WPKH

In this CIP, we will refer to the base58 address as a P2PKH address. Likewise, we will refer to the Bech32 address as a "P2WPKH address" or "segwit address".

P2WPKH addresses

Counterparty will continue to track all P2PKH/P2WPKH account balances by their P2PKH address internally. Any asset transfers involving the P2PKH or P2WPKH address for a given pubkey hash will be tracked internally by the P2PKH address. Querying the balance of either the P2PKH or P2WPKH address will result in the same response.

By converting all P2WPKH addresses internally to P2PKH addresses we can make it easy for wallets and users to gradually transition to using segwit addresses.

Users can give out their P2WPKH addresses to other users who use a wallet that supports sending to segwit addresses. Likewise they can provide their P2PKH address to legacy applications and wallets that don't support sending to segwit addresses yet.

Note that a traditional BTC wallet would separate P2PKH and P2WPKH addresses by generating new segwit addresses separately from old P2PKH addresses. Counterparty re-uses addresses and therefore must take a different approach to transition users to segwit. Counterparty will represent the same pubkey hash in both address formats.

P2WSH addresses

Segwit compatible pay-to-script-hash addresses use 32-byte script hashes instead of the old 20-byte script hashes, this makes them incompatible with applying any backwards compatability tricks.

Counterparty will be able to receive and send assets to and from these addresses. These addresses will be referenced only by their 62 character Bech32 address.

Segwit embedded inside P2SH

It is possible to embed a P2WPKH or P2WSH inside a P2SH script, resulting in a 3xxxx style address and enabling segwit while keeping backwards compatible addresses. The complexity involved in doing this within counterparty-lib and counterwallet is high and the gain is much smaller than using native segwit scripts.

While Counterwallet does not support the use of P2SH addresses, Counterparty remains compatible with P2SH at the protocol level. Other counterparty wallets may implement segwit embedded in P2SH scripts if desired.


API Changes

Counterparty APIs will accept P2WPKH and P2WSH addresses as input arguments and will continue to support P2PKH and P2SH addresses.

Counterparty APIs will return P2PKH addresses for all API calls with the exception of operations involving P2WSH addresses. P2WSH addresses will be returned in 62 character Bech32 format.


For this CIP, counterwallet will be modified to show the P2WPKH address in smaller text next to the standard P2PKH address.

The P2PKH address will become less prominent and be hidden by default in the future. But that is outside the scope of this CIP implementation.

Sending BTC

When generating a transaction that sends BTC to the recipient, counterparty-lib will generate the transaction outputs based on the format of the destination address.

  • If the recipient address is a Base58 encoded P2PKH (1xxxx) address, then a standard P2PKH output will be generated.
  • If the recipient address is a Base58 encoded P2SH (3xxxx) address, then a standard P2SH output will be generated.
  • If the recipient address is a Bech32 encoded P2WPKH (bc1xxxx) address, then a segwit P2WPKH output will be generated.
  • If the recipient address is a Bech32 encoded P2WSH (bc1xxxxxxx) address, then a segwit P2WSH output will be generated.

Change outputs

All change outputs sent back to a counterparty source address will be encoded as a segwit (P2WPKH) output.

Bitcoin Core v0.13.2

We will continue to use the addrindex-0.13.2 version of bitcoind at this time. The addrindex patch will continue to work as expected.

Transaction Parsing by counterparty-lib

Counterparty server will parse P2WPKH outputs in addition to P2PKH outputs.

Backwards Compatibility

Segwit support will be a consensus change that will activate at a specific block to be determined after implementation. All parsing servers will need to upgrade before this block to maintain consensus.




Fundraising goal = 500 XCP

Milestone #1 (70% - 350 XCP)

counterparty-lib and counterwallet code merged into the master branch

Milestone #2 (30% - 150 XCP)

Code Released and supported on Mainnet for 1 month

Bounty Address (escrow by J-Dog)



This document is placed in the public domain.

You can’t perform that action at this time.