-
Notifications
You must be signed in to change notification settings - Fork 203
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
6 changed files
with
193 additions
and
142 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
24 changes: 6 additions & 18 deletions
24
counterparty-core/counterpartycore/test/regtest/apidoc/group-compose.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,21 +1,9 @@ | ||
**Notes about the Optional `encoding` Parameter.** | ||
**Notes about the Optional `sat_per_vbyte` Parameter.** | ||
|
||
By default the default value of the `encoding` parameter detailed above is `auto`, which means that `counterparty-server` automatically determines the best way to encode the Counterparty protocol data into a new transaction. If you know what you are doing and would like to explicitly specify an encoding: | ||
To calculate the fees required for a transaction, we do not know the final size of the transaction before signing it. | ||
So the composer injects fake script_sig and witnesses into the transaction before calculating the vsize. | ||
Two remarks: | ||
|
||
- To return the transaction as an **OP_RETURN** transaction, specify `opreturn` for the `encoding` parameter. | ||
- **OP_RETURN** transactions cannot have more than 80 bytes of data. If you force `OP_RETURN` encoding and your transaction would have more than this amount, an exception will be generated. | ||
1. this only works for standard scripts | ||
|
||
- To return the transaction as a **multisig** transaction, specify `multisig` for the `encoding` parameter. | ||
- `pubkey` should be set to the hex-encoded public key of the source address. | ||
- Note that with the newest versions of Bitcoin (0.12.1 onward), bare multisig encoding does not reliably propagate. More information on this is documented [here](https://github.com/rubensayshi/counterparty-core/pull/9). | ||
|
||
- To return the transaction as a **pubkeyhash** transaction, specify `pubkeyhash` for the `encoding` parameter. | ||
- `pubkey` should be set to the hex-encoded public key of the source address. | ||
|
||
- To return the transaction as a 2 part **P2SH** transaction, specify `P2SH` for the encoding parameter. | ||
- First call the `create_` method with the `encoding` set to `P2SH`. | ||
- Sign the transaction as usual and broadcast it. It's recommended but not required to wait for the transaction to confirm as malleability is an issue here (P2SH isn't yet supported on segwit addresses). | ||
- The resulting `txid` must be passed again on an identic call to the `create_` method, but now passing an additional parameter `p2sh_pretx_txid` with the value of the previous transaction's id. | ||
- The resulting transaction is a `P2SH` encoded message, using the redeem script on the transaction inputs as data carrying mechanism. | ||
- Sign the transaction following the `Bitcoinjs-lib on javascript, signing a P2SH redeeming transaction` section | ||
- **NOTE**: Don't leave pretxs hanging without transmitting the second transaction as this pollutes the UTXO set and risks making bitcoin harder to run on low spec nodes. | ||
1. the size of DER signatures can vary by a few bytes and it is impossible to predict it. The composer uses a fixed size of 70 bytes so there may be a discrepancy of a few satoshis with the fees requested with `sat_per_vbyte` (for example if a DER signature is 72 bytes with `sat_per_vbyte=2` there will be an error of 4 sats in the calculated fees). |
Oops, something went wrong.