An address is a convenience feature designed to make human usage of Bitcoin easier - the Bitcoin protocol itself does not know anything about addresses.
All outputs are actually sent to programs written in the Bitcoin Script language. These programs can take any form.
We have defined certain programs that can be encoded as addresses - namely, pay-to-public-...
How is it then that a transaction can have four outputs? Is it possible to pay more than one person (address) in a single transaction?
Yes, a transaction can have several inputs and several outputs. Those inputs and outputs can belong to the same user or a different user. So user A and B could make a transaction that combines several of their addresses and ...
allowed by the protocol?
Yes. It is possible to spend an output immediately. And two (three-four-etc) chaining transactions will be included in the same block. There are a lot of examples in blockchain. Note, that the their order in block is fixed.
do any of the common clients allow spending unconfirmed Bitcoins
Bitcoin-core client allows to send "raw ...
By block they are not referring to the blockchain. They just mean that the 24,518 BTC will be divided into 12 different lots (or blocks) with each auction containing about 2,000 BTC.
"Ernst & Young will be selling the confiscated cryptocurrency in auction form, allowing bidders to compete ...
Can two UTXOs ever be combined into one UTXO?
Yes, absolutely. Each transaction can have any number of inputs and outputs; it can certainly have fewer outputs than inputs.
Here for example is a transaction with four inputs and one output, leading to a net decrease of three UTXOs.
The vout index (n) that you see after calling decoderawtransaction is added by bitcoind. It is not present in the raw transaction data.
If you manually decode the serialized tx for your example, you get this for the output section:
02 # Number of outputs
# value lockscript_length lockscript
005a620200000000 17 ...
Since it's an array, couldn't you just use the array index? Seems redundant, but i'm sure there's a reason. Thanks
Yes, you could. In fact, that is how n is calculated since it isn't actually stored in the transaction. n is only provided as a convenience so that those constructing raw transactions do not need to count possibly hard to read JSON lines in ...
Which part / field of the input refers to the hash of the output?
The outpoint contains a txid (32 bytes) and vout (4 bytes), which specify the output you're spending.
This is not the sending address!
What you do (when you're not dealing with a coinbase transaction) is that you look up the transaction with the txid, and look at the transaction output ...
When you said "as a result you have two outputs: The spent amount and the change", that is only one special case for Bitcoin transactions.
In a general Bitcoin transaction, here is what actually happens:
One or more inputs, each with a valid signature, "dumps" coin value into the transaction.
One or more outputs each "extracts" value from the transaction.
The outputs have no address because they are data-carrying outputs.
The script argument is the serialized equivalent of
(The hex decodes to "...
Note the word normally at the beginning of the sentence. This isn't imposing a restriction but merely describing a common use case.
It's obviously useful to allow more than two outputs, and there's no particular reason to impose any arbitrary limit on the number. I don't think such a limit was ever contemplated.
In any case, the whitepaper isn't ...
Each miner (or mining pool) sets their own policy, but miners using Bitcoin Core 0.9.0 and later will, by default, mine OP_RETURN (null data) outputs with zero value. They will not, by default, mine any other outputs with a value below the dust threshold, which is 1/3 as many satoshis as it would take to relay the output plus the corresponding input ...
The rule that at least one output is required is part of the original code, and changing it would mean a hard fork. There are many good changes that are possible with a hard fork, but none of them is considered worth the disruption that a hard fork would create. Changing the rules to permit no-output transactions would not even worth a soft fork, since, just ...
Ethereum is an account based system. It relies on the sender specifying the sequence of transactions to prevent double spending. The balance is associated with an address and when you spend from that address, you can specify what portion of the balance should be spend.
Bitcoin is not an account based system, but structured around transaction outputs. Double ...
The scriptPubKey contains the public key used to synthesize the public address. Here are two pedantic approaches, not using bitcoinj, applying bx commands to synthesize the public address of interest above.
% echo 04678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f | bx sha256 | ...
I'm assuming you're talking about P2SH addresses here, since that's really the only time this matters.
For standard P2SH addresses, you cannot find the spending requirements by just looking at the address. Let's look at 3DzSVk4veMCkNbNT9CdETeE26uWxmNbBnD from a recent block as an example.
The output script of this address is ...
tx_hash and tx_hash_big_endian are the transaction id of the transaction that this output originated from in little endian and big endian (reversed).
tx_output_n is the number of the output in the referenced transaction, i.e if a transaction has 5 outputs and you need to refer to the 5th you use a tx_output_n = 5.
tx_index I believe is an internal unique ...
It is not invalid.
The code you are looking it is unrelated to validation and relay of actual transactions. You are looking at the code for RPCs which are just things for users. The RPC disallows sending to an address multiple times because this is not efficient and usually a mistake by the user.
But this is only for creating a raw transaction using the ...
The transaction digest alone would take around 2 days of non-stop work:
That's before you even start the 32-byte multiplication required to compute an ECDSA signature.
It might be humanly possible if the UTXO you are spending does not require a signature. An "anyone-can-spend" ...
If you create a raw transaction yourself, then that is the raw transaction. Whatever you put in it is exactly what the transaction will be, in the same order.
There are some conventions around output ordering. Some software will randomly permute the outputs; other software uses BIP69 which specifies a deterministic ordering. There is however no requirement ...
It is the position of your txo in the outputs array of the transaction that created it. You can see that this transaction created 2 outputs and that your output is the first one (0).
This index is also sometimes refer to as vout.
Bitcoin doesn't track a balance on an address. You can get a balance but that is for humans and isn't how the protocol really works. What bitcoin nodes do track is a list of unspent transaction outputs.
Here is your scenario reworded a bit.
address ddd111 received 2 BTC by mining block 108 in transaction A:0
(By this I mean transaction A has ...
You are right, however you are not interpreting the result correctly. The value is indeed 287, that is (2288 >> 3) + 1, however this does not mean that the bitvector contains 287 bytes, but that it contains 287 non-zero bytes, so when parsing the bitvector, you should decrease the byte counter only when you find a non-zero value. Here you have a piece ...
I want to send one transaction with 5 BTC to one address and a transaction with 2 BTC to another.
The fastest (and cheapest) way to do this is with a single transaction.
Many transactions have 2 outputs, one being for change, but it doesn't need to be for change, and doesn't need to be limited to 1 or 2 outputs either.
Take this transaction for example, ...
Yes, this is possible. Although most consumer wallets will probably not do that, they're simply meant to scan one QR code, send some coins to that address and return the remainder to a change address you own yourself.
I'm fairly sure the Bitcoin-qt GUI wallet can create transactions to multiple destinations. Command line certainly can do everything.
Not every UTXO has an associated address.
An address is really just a shorthand notation for a particular Bitcoin Script. There exist many interesting scripts which do not correspond to an address, but are still spendable under some conditions.
Note that every P2SH output does have associated address, and almost all interestong scripts these days use P2SH.
No. A notable example of a pubkey script that doesn't typically include addresses or keys is the nulldata standard transaction type. Examples of pubkey scripts that include public keys but not addresses are pay-to-pubkey (P2PK) and "bare" multisig.
Although I'm not absolutely sure, I believe its allowed to have an empty pubkey script. (That is, the ...