Bitgo support compression
Transactions that spend bitcoins secured by segregated witness segwit use less space in a block than equivalent non-segwit legacy transactions, allowing segwit transactions to pay less total fee to achieve the same feerate as legacy transactions.
The amount of savings varies depending on the details of your transaction, but here are a few common transaction types an an example:. Note that the multisig examples above use the same security as the equivalent legacy P2SH multisig. Segwit optionally allows access to a multisig form that is more secure on one dimension but it requires an extra 12 vbytes per output, which would reduce efficiency somewhat. To access these savings, you must use a wallet that supports generating P2SH-wrapped segwit addresses addresses that start with a "3", although not all addresses that start with a 3 are segwit-enabled.
When you spend bitcoins received to these P2SH-wrapped segwit addresses, your transactions will automatically consume less block space, allowing your wallet to pay proportionally less fee. Complete usage requires native segwit adoption by the people sending you bitcoins, but you may be able to use it for your change outputs immediately. The P2SH-wrapped segwit described above is backwards compatible with the P2SH address format supported by older wallets, but a new and non-backwards compatible format is available that saves additional space.
The following examples and savings are compared to the size of the P2SH-wrapped examples above:. To access these savings, you must use a wallet that supports generating native segwit addresses, called bech32 addresses addresses that start with a "bc1". When you spend bitcoins received to these native segwit addresses, your transactions will automatically consume less block space than even P2SH-wrapped segwit addresses, allowing your wallet to pay proportionally less fee.
Once a wallet supports native segwit, it can begin using it immediately for any change outputs it generates back to itself without waiting for anyone else to begin using native segwit. In early , when native segwit adoption is low, this may make it easier to identify which output is change and so reduce your privacy. However, once native segwit adoption increases just slightly, this is not expected to adversely affect privacy. Useful for high-frequency recipients e. When a Bitcoin transaction references the funds it wants to spend, it's required to spend all of those funds.
For this reason, almost all Bitcoin transactions currently pay some bitcoins back to the spender. For example, you'd return the remaining 3 BTC from the previous example back to yourself. A typical change output adds about 32 vbytes to the size of a transaction. In addition, a change output will later be spent at a typical cost of 69 vbytes or more, but when paying with exact change, this future cost is also avoided.
To use change avoidance requires having previously received a payment or set of payments that's close to the size of the amount being spent including the transaction fee. This can be rare in the case of individual user wallets that don't receive many payments to choose from and can't significantly vary the amount of their spending transactions, but for organization wallets that receive many payments and already use payment batching to combine multiple outgoing payments, change avoidance can be an easily-obtainable efficiency improvement.
The spender doesn't need to match the inputs and outputs of their transaction exactly to Bitcoin's full 10 nanobitcoin precision, but can instead overpay or underpay fees slightly by including inputs that are respectively slightly more or slightly less than the desired amount. Even when paying slightly more fees than desired, this can result in savings if the slight increase in fees is still less than would normally be paid for the extra 32 vbytes or so for a change output and the typical mininum of 69 vbytes for later spending that output.
The amount of fee a transaction pays is proportional to its size in vbytes , and one the main contributors to size is the number of inputs the transaction spends.
Each input is a reference to the funds the transaction wants to spend, and when a wallet contains only low-value inputs, it can't create a comparatively higher output paying a recipient without adding many of those inputs to the transaction. Each input adds a minimum of 41 vbytes to the transaction and almost always 69 or more vbytes, so any strategy that reduces the number of inputs is worth considering.
Given that fees vary over time , one method that can reduce overall fees is input consolidation—combining a set of smaller inputs into a single larger input by spending them from yourself to yourself during a period of time when fees are lower than normal.
Also, if you combine inputs that were originally sent to addresses unconnected to each other, you may reduce your privacy in some cases by making that connection in your consolidation transaction although it's believed that few people currently manage to spend their inputs in a manner that preserves this element of privacy. When it comes to fees, sending a Bitcoin transaction is similar to mailing a package: This section describes several techniques for taking advantage of the more affordable low-priority service.
Already widely deployed but still being improved as research and development continues. Early Bitcoin wallets often defaulted to paying a fixed fee on every transaction—enough to incentivize a miner to include it but not enough to compete against other transactions seeking confirmation in a fee market.
As blocks have filled, this has changed, and as of early all widely-used wallets use dynamic fee estimation to select a fee based on the condition of the current fee market. However, some fee estimation tools may be better than others, achieving confirmation by the desired time even when paying lower fees.
Although data from multiple wallets and fee estimation services can be compared [3] and there have been some attempts to compare fee estimation between different wallets, [4] there is no known survey of fee estimation quality across a large number of popular wallets as of early In addition, also as of early , some techniques have recently been described that could significantly improve fee estimation, such as factoring current mempool data into confirmation-based fee estimates.
Spenders who can patiently wait for their transactions to confirm can take advantage of variations in the feerate necessary to achive confirmation. In the data plotted above, the Bitcoin Core fee estimator suggests that for this sample period the following savings are available:. Although waiting up to four days is impractical for many use cases, there are also many cases where it can be practical.
Although not strictly a method for reducing fees by itself, opt-in transaction replacement allows a wallet to update previously-sent transactions with new versions that pay higher fees and, possibly, make other changes to the transaction.
This technique allows wallets to initially pay lower fees in case there's a sudden increase in the supply of block space, a sudden decrease in demand for that space, or another situation that increases the chance of low-fee transactions being confirmed.
If none of those things happens, the spender can then increase "bump" the transaction's fee to increase its probability of confirming. This often allows wallets that support transaction replacement to pay lower fees than wallets that don't support replacement. Transaction replacement can appear odd in some recipient wallets. Wallets such as Bitcoin Core pictured below show each replacement as a separate payment in the list of transactions.
When one version of the replacements is confirmed, it is shown as a normal transaction; the other versions are then shown with an X icon to indicate that they are conflicted cannot occur together in the same valid block chain. This helps communicate the status of all affected payments to the recipient, but it may not be entirely clear what's happening to users who aren't familar with replacements.
Other wallets may not show transactions opting in to replacement at all until one version of the transaction has been confirmed. There's no clear community consensus on the correct way to handle this situation using user interfaces, documentation, or both.
Transaction replacement can be advantageously combined with payment batching described previously. Instead of waiting, for example, 30 minutes to batch all outgoing payments, the spender can batch the first 10 minutes of payments with a low feerate.
If that doesn't get confirmed within 10 minutes, the spender can replace that transaction with a slightly higher feerate transaction that also includes then next 10 minutes of payments.
If that again doesn't confirm, another update can also include the third 10 minutes of transactions at the original intended feerate. This allows the recipients of the first 10 minutes of payments to receive a notification that the payment has been sent up to 20 minutes earlier than with normal batching, and it also gives those early payments a chance to confirm at a lower-than-expected feerate. Updating a batched transaction with more payments can be done as many times as necessary up to a relay limit on transaction size of kilobytes.
Currently, transaction replacement does have one significant downside: When the fee on a transaction is increased, either additional inputs must be added or the value of the change output must be decreased. In either case, this makes the change output easier to identify among the different outputs being paid by a transaction.
Value-blinding techniques such as confidential transactions could improve this situation, but there are no near-term plans to add such a feature to Bitcoin as of early It supports multiple wallets, each with with its own configuration, such as 3-of-5 3 required signatures from 5 participant peers or 2-of To create a multisig wallet shared between multiple participants, Copay requires the extended public keys of all the wallet participants.
Those public keys are then incorporated into the wallet configuration and combined to generate a payment address where funds can be sent into the wallet. Conversely, each participant manages their own private key and that private key is never transmitted anywhere. To unlock a payment and spend the wallet's funds, a quorum of participant signatures must be collected and assembled in the transaction.
The funds cannot be spent without at least the minimum number of signatures required by the wallet configuration 2 of 3, 3 of 5, 6 of 6, etc. Once a transaction proposal is created, the proposal is distributed among the wallet participants for each to sign the transaction locally.
Finally, when the transaction is signed, the last signing participant will broadcast the transaction to the Bitcoin network. Copay also implements BIP32 to generate new addresses for peers. The public key that each participant contributes to the wallet is a BIP32 extended public key. As additional public keys are needed for wallet operations to produce new addresses to receive payments into the wallet, for example new public keys can be derived from the participants' original extended public keys.
Once again, it's important to stress that each participant keeps their own private keys locally - private keys are not shared - and are used to sign transaction proposals to make payments from the shared wallet. For more information regarding how addresses are generated using this procedure, see: The standard BIP44 is used for wallet address derivation. Information about Backup and recovery procedures is available at https: To extract the private key of your wallet you can use https: The resulting JSON will have a key named: That information is enough to sign any transaction from your wallet, so be careful when handling it!
The backup also contains the key publicKeyRing that holds the extended public keys of the Copayers. Note that addresses generated at BWS use the 'shared cosigner index' so Copay address indexes look like: The maximum values of x and y depend on the wallet usage, and in a restore procedure, the generated addresses are scanned on the blockchain for transactions this is the 'scan' procedure that you can see inside the Copay App settings.
To generate the wallet addresses, the required number of Copayers also need to be specified backup key m. A BWS instance can be setup and operational within minutes or you can use a public instance like https: Switching between BWS instances is very simple and can be done with a click from within Copay.