You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
94 lines
4.8 KiB
94 lines
4.8 KiB
10 years ago
|
# > `bitcore.Transaction`
|
||
|
|
||
|
## Description
|
||
10 years ago
|
|
||
10 years ago
|
Bitcore provides a very simple API for creating transactions. We expect this API to be accessible for developers without knowing the working internals of bitcoin in deep detail. What follows is a small introduction to transactions with some basic knowledge required to use this API.
|
||
10 years ago
|
|
||
|
A Transaction contains a set of inputs and a set of outputs. Each input contains a reference to another transaction's output, and a signature that allows the value referenced in that ouput to be used in this transaction.
|
||
|
|
||
|
Note also that an output can be used only once. That's why there's a concept of "change address" in the bitcoin ecosystem: if an output of 10 BTC is available for me to spend, but I only need to transmit 1 BTC, I'll create a transaction with two outputs, one with 1 BTC that I want to spend, and the other with 9 BTC to a change address, so I can spend this 9 BTC with another private key that I own.
|
||
|
|
||
|
So, in order to transmit a valid transaction, you must know what other transactions on the network store outputs that have not been spent and that are available for you to spend (meaning that you have the set of keys that can validate you own those funds). The unspent outputs are usually referred to as "utxo"s.
|
||
10 years ago
|
|
||
|
Let's take a look at some very simple transactions:
|
||
|
|
||
|
```javascript
|
||
|
var transaction = new Transaction()
|
||
|
.from(utxos) // Feed information about what unspend outputs one can use
|
||
|
.to(address, amount) // Add an output with the given amount of satoshis
|
||
|
.change(address) // Sets up a change address where the rest of the funds will go
|
||
|
.sign(privkeySet) // Signs all the inputs it can
|
||
|
```
|
||
|
|
||
10 years ago
|
Now, this could just be serialized to hexadecimal ASCII values (`transaction.serialize()`) and sent over to the bitcoind reference client.
|
||
10 years ago
|
|
||
|
```bash
|
||
|
bitcoin-cli sendrawtransaction <serialized transaction>
|
||
|
```
|
||
|
|
||
10 years ago
|
You can also override the fee estimation with another amount, specified in satoshis:
|
||
|
```javascript
|
||
|
var transaction = new Transaction().fee(5430); // Minimum non-dust amount
|
||
|
var transaction = new Transaction().fee(1e8); // Generous fee of 1 BTC
|
||
|
```
|
||
|
|
||
10 years ago
|
## Transaction API
|
||
|
|
||
10 years ago
|
You can take a look at the javadocs for the [Transaction class here](link missing).
|
||
|
|
||
|
## Input
|
||
|
|
||
|
Transaction inputs are instances of either [Input](https://github.com/bitpay/bitcore/tree/master/lib/transaction/input) or its subclasses. The internal workings of it can be understood from the [API reference](link missing).
|
||
|
|
||
|
## Output
|
||
|
|
||
|
Transaction outputs are a very thin wrap around the information provided by a transaction output: its script and its output amount.
|
||
10 years ago
|
|
||
|
## Multisig Transactions
|
||
|
|
||
10 years ago
|
To send a transaction to a multisig address, the API is the same as in the above example. To spend outputs that require multiple signatures, the process needs extra information: the public keys of the signers that can unlock that output.
|
||
10 years ago
|
|
||
|
```javascript
|
||
|
var multiSigTx = new Transaction()
|
||
10 years ago
|
.from(utxo, publicKeys, threshold)
|
||
10 years ago
|
.change(address)
|
||
10 years ago
|
.sign(myKeys);
|
||
|
|
||
|
var serialized = multiSigTx.serialize();
|
||
|
```
|
||
|
|
||
|
This can be serialized and sent to another party, to complete with the needed
|
||
|
signatures:
|
||
|
|
||
|
```javascript
|
||
|
var multiSigTx = new Transaction(serialized)
|
||
10 years ago
|
.from(utxo, publicKeys, threshold) // provide info about the multisig output
|
||
|
// (lost on serialization)
|
||
10 years ago
|
.sign(anotherSetOfKeys);
|
||
|
|
||
|
assert(multiSigTx.isFullySigned());
|
||
|
```
|
||
|
|
||
|
## Advanced topics
|
||
|
|
||
10 years ago
|
### Internal Workings
|
||
|
|
||
10 years ago
|
There are a number of data structures being stored internally in a `Transaction` instance. These are kept up to date and change through successive calls to its methods.
|
||
10 years ago
|
|
||
|
* `inputs`: The ordered set of inputs for this transaction
|
||
|
* `outputs`: This is the ordered set of output scripts
|
||
10 years ago
|
* `_inputAmount`: sum of the amount for all the inputs
|
||
|
* `_outputAmount`: sum of the amount for all the outputs
|
||
|
* `_fee`: if user specified a non-standard fee, the amount (in satoshis) will be stored in this variable so the change amount can be calculated.
|
||
|
* `_change`: stores the value provided by calling the `change` method.
|
||
10 years ago
|
|
||
10 years ago
|
### Unspent Output Selection
|
||
|
|
||
10 years ago
|
If you have a larger set of unspent outputs, only some of them will be selected to fulfill the amount. This is done by storing a cache of unspent outputs in a protected member called `_utxos`. When the `to()` method is called, some of these outputs will be selected to pay the requested amount to the appropriate address.
|
||
10 years ago
|
|
||
10 years ago
|
A nit that you should have in mind is that when the transaction is serialized, this cache can't be included in the serialized form.
|
||
10 years ago
|
|
||
|
## Upcoming changes
|
||
|
|
||
10 years ago
|
We're debating an API for Merge Avoidance, CoinJoin, Smart contracts, CoinSwap, and Stealth Addresses. We're expecting to have all of them by some time in early 2015. First draft implementations of Payment Channel smart contracts extensions to this library are already being implemented independently.
|