8
The first number does not include the prevout, sequence number, or the length byte for the scriptSig. It also uses 65 bytes for the public key (which is correct if it is uncompressed, but compressed keys of 33 bytes are more common now). Correcting it gives 139 + 36 + 4 + 1 + (33 or 65) = 148 or 180.
The developer in the third case forgot to include the ...
8
Transfer from Legacy ⟶ SegWit: pay full fee (doesn't benefit from SegWit discount)
Transfer from SegWit ⟶ Legacy or SegWit: discounted.
Note: SegWit addresses can be Bech32 bc1... or they can be nested in a legacy P2SH 3... address which are backwards-compatible (although less efficient). Many exchanges, wallets support the legacy "nested" form only.
7
Let's compare a 2 input and 2 output transaction for variants of pay-to-pubkeyhash. (Full data below.)
P2PKH has no witness, so raw size is equal to stripped size is equal to virtual size. A P2PKH transaction with two inputs and two outputs has 374 bytes (= 374 vBytes).
P2SH-P2WPKH (wrapped segwit) locks funds to a P2SH output in which it redirects to a ...
6
Inside transaction inputs, you have to refer to previous transactions using the txid. Allowing a wtxid there would be (1) a hard fork and (2) defeating the purpose, as it'd make transactions malleable again.
The wtxid is only used to compute the Witness merkle root, which is committed to in the coinbase.
6
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 ...
5
The inputs are chosen by the function SelectCoins() in CreateTransaction() and then added one by one (without shuffling) to the transaction.
The order is defined by the coin selection (CWallet::SelectCoinsMinConf) which does a random shuffle of the potential useful inputs and a stochastic approximation.
Mind also that Bitcoin-Core's coin selection could be ...
5
Can somebody take the transaction tx0 I signed and publish it in order to spend the new coins with the old transaction?
No.
Firstly, the transaction inputs are already known to have been used. Any node examining the block will know that the rerun transaction has invalid inputs.
Secondly I expect (but haven't checked) the inputs to the signature include ...
4
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 | ...
4
I suppose you are the same person who made this thread on bitcointalk: https://bitcointalk.org/index.php?topic=1969807.0
I'll answer you here too to help other people too.
You are treating the pubkey as a string, but it is really a blob of binary data that is 33 bytes long. What you want to do instead is initialize an array with your pubkey and then use ...
4
Bitcoin Core has no idea which transactions already exist in the chain. It does not maintain a full index, because... it doesn't need to. In fact, when running in pruning mode, it doesn't even have the chain or its transactions at all.
The only thing it has is the set of unspent transaction outputs. Since you're trying to replay an existing transaction, all ...
4
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 ...
4
The number of inputs/outputs is encoded as a "var_int" or "variable length integer".
Start by looking at the first byte. If it's 252 or less, then that's it, that's your number (like you've been using), there are no more bytes to read.
If the first byte is 253, there are 2 more bytes following it, which are a 16 bit little endian integer. 254 means 4 ...
4
When you send a Bitcoin transaction, your wallet software will use one or more existing Unspent Transaction Outputs (UTXO) to fund the transaction. The transaction will then specify the new owners of the consumed balance in the outputs. If the amount spent in the inputs does not match the amount in the outputs plus fees perfectly, the remainder will be sent ...
4
There is no real concept of sender identities, as far as the blockchain is concerned. The fee split is entirely determined by the change output values, which are entirely determined by the signers of the transaction.
A transaction involving inputs from two separate parties will require some coordination between them to decide on the recipient and change. It ...
4
The UTXO is referenced as an outpoint(TXID, Index) in the input of your time-locked spending transaction.
So, when creating your time-locked transaction, you need to know the TXID of the (unconfirmed) transaction you are spending.
Simply double+sha256 and swap endianness of the over-the-wire transaction serialisation to get the TXID you wish to reference. ...
4
Transactions explicitly refer to which UTXOs they are spending.
You can construct a transaction which only spends one of the two 5-BTC UTXOs, and sends 2 BTC to the destination and 3 BTC to a (possibly new) address of yourself.
You can also construct a transaction which spends both, and sends 8 BTC back to yourself. Or it could have multiple outputs that ...
4
No, the number that can be represented by the varint has no effect on the maximum number of inputs. That number is far too large. Rather the maximum number of inputs is constrained by the block size.
If it really matters to you what the maximum number that a varint can represent is, it's just the maximum value for a 64-bit integer. That's 0xffffffffffffffff....
3
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, ...
3
Every transaction input consists of a number of fields:
The txid of the transaction whose output is being spent.
The index of the output being spent (also called vout).
The scriptSig, or unlocking script.
The sequence number.
(SegWit inputs only) The scriptWitness.
The first two (txid, vout) are called the outpoint.
3
Worth keeping in mind: Unless all inputs to the original transaction are segwit and at least one is sighash all, the original transaction will be vulnerable to third party malleability so your second spend could get invalidated.
3
It appears to largely be just a belt-and-suspenders check. As you say, it is unnecessary to do this check. However it doesn't hurt to have this check in there. At worst, it just adds a few nanoseconds to verification time. At best, it will catch some serious bugs.
Given that this is consensus related, it does not hurt to have extra checks that are ...
2
Shabahat's answer is good, but here's how each method of getting an address works:
getFromAddress() takes the last element of the scriptSig, and hashes it to find the P2SH address. If the transaction is valid and P2SH, this will always be correct. You can do something similar for P2PKH, but you can't do this for P2PK. (P2PK does not include the public key ...
2
After going through bitcoinj API documentation regarding the methods you have asked about, the way you make the second method work, you are supposed to connect the input transaction to get the output from that particular tx. You can go through the link I have given above and report back if required.
2
What problems could arise if the scriptCode of the input were not included in the digest?
Almost certainly nothing.
The reason for doing this is a very intentional design choice to limit the number of changes SegWit makes. Given that it has script versioning, it would be easy to introduce different sighashing schemes later if desired, we had the option of ...
2
In general spending from a segwit output (i.e. "sending from" a segwit address) will be cheaper than spending a non-segwit output (i.e. "sending from" a non-segwit address). So yes, if you "send from" a bech32 address, it will be cheaper than "sending from" a P2PKH address.
2
It works just fine.
Bitcoin transactions can have multiple inputs and outputs; each input is a "pointer" to an output of a previous transaction (specifically, it consists of a transaction id and output index). So you would create a new transaction with two inputs:
the A1->A3 transaction (or more properly, the particular output of this transaction that ...
2
Do i need to sign each input in a raw transaction?
Technically, yes. But software like Bitcoin Core Client signs all inputs where the private keys are known. And of course, leave unsigned/untouched all other inputs.
2
Good day! Finally I found a solution, I hope it will useful to someone.
The problem was that I tried to sign inputs before adding outputs and other info into transaction. So now I add inputs with method addInput(). Before I did it with addSignedInput() method. After adding all inputs and outputs in my TX I try to sign every input manually:
for (int i = 0;...
2
Yes, if the second transaction spends the output of the first one, then #2 cannot be confirmed until after #1 is confirmed. (Though they can be confirmed in a single block, as long as #1 appears before #2 in that block, in which case the confirmations are effectively simultaneous.)
Most miners will consider transactions on a "child pays for parent" basis, ...
2
It looks to me like each input to a bitcoin transaction has an index that specifies only one output from the input its spending.
That is correct.
Is there a way to specify more than one output index, or do you have to create a second input line that contains the same input ID with a different index?
You have to add an extra input, which repeats the txid....
Only top voted, non community-wiki answers of a minimum length are eligible
