Segwit | Replace-by-Fee

Segwit Addresses

What are segwit addresses? Transactions that spend bitcoins secured by segregated witness (segwit) use less block weight than equivalent non-segwit (legacy) transactions, allowing segwit transactions to pay less total fee to achieve the same feerate as legacy transactions.

Tested: on web

Tested on: 2019-12-17

Receive support

  • Allows receiving to P2SH-wrapped segwit
    Allows the generation of P2SH-wrapped (either P2WPKH or P2WSH) segwit receiving addresses.
  • Allows receiving to bech32 segwit addresses
    Allows the generation of bech32 native (either P2WPKH or P2WSH) segwit receiving addresses.
  • Not tested: Can bech32m transaction outputs be received?
    We either didn’t test this or could not appropriately determine the results.
  • Default receiving address is bech32 P2WPKH
    This service generates bech32 P2WPKH segwit receiving addresses by default.

Send support

  • Allows sending to bech32 P2WPKH addresses
    Allows sending to bech32 P2WPKH native segwit addresses.
  • Allows sending to bech32 P2WSH addresses
    Allows sending to bech32 P2WSH native segwit addresses.
  • Not tested: Can transaction outputs be sent to bech32m addresses?
    We either didn’t test this or could not appropriately determine the results.
  • Creates bech32 change addresses
    When sending, generates bech32 (either P2WPKH or P2WSH) segwit change addresses.

Usability

Click on a thumbnail for a larger image or to play its video.

Purse deposit addresses are bech32 P2WPKH (native segwit) by default.
Purse deposit addresses are bech32 P2WPKH (native segwit) by default.

As an option for users with legacy wallets, Purse also accepts deposits to P2SH-wrapped P2WPKH (nested segwit) addresses.
As an option for users with legacy wallets, Purse also accepts deposits to P2SH-wrapped P2WPKH (nested segwit) addresses.


Purse allows withdraws to both legacy and segwit addresses.
Purse allows withdraws to both legacy and segwit addresses.

Replace-by-Fee (RBF)

What is Replace-by-Fee (RBF)? An unconfirmed transaction can be replaced by another version of the same transaction that spends the same inputs. Most full nodes support this if the earlier transaction enables BIP125 signaling and the replacement transaction increases the amount of fee paid. In terms of block chain space used, this is the most efficient form of fee bumping.

Tested: on web

Tested on: 2019-12-17

Receiving support

  • Notification does not note RBF
    Notification of incoming transaction does not note that the transaction signals RBF.
  • Received transaction not labeled replaceable in list
    Does not visually indicate that an incoming transaction has signaled RBF.
  • Received transaction not labeled replaceable in transaction details
    Does not visually indicate that a received transaction has signaled RBF when viewing the transaction details.
  • No unconfirmed transactions
    Neither the original nor replacement transactions are shown in the transaction list. Unconfirmed transactions are probably not supported.

Sending support

  • Does not signal BIP125 replaceability when sending transactions
    Does not allow sending of BIP125 opt-in-RBF transactions in the interface.
  • Not tested: Does transaction list show whether sent transactions signal RBF?
    We were not able to test this because sending a BIP125 signaling transaction is not supported.
  • Not tested: Does transaction details page show whether received transaction signals RBF?
    We were not able to test this because sending a BIP125 signaling transaction is not supported.
  • Not tested: Are replacement and original sent transactions displayed?
    We were not able to test this because sending a BIP125 signaling transaction is not supported.

Usability

Click on a thumbnail for a larger image or to play its video.

Receiving Transaction Signaling RBF - No unconfirmed transactions appear in transaction list.
Receiving Transaction Signaling RBF - No unconfirmed transactions appear in transaction list.