14
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 ...
9
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 ...
8
why some of transactions have one input and one output?
A bitcoin transaction can have many inputs and many outputs. Bitcoin has a transaction oriented logic, where amounts are transferred from previous transactions. As an example (neglecting the fees): to be able to spend 1 bitcoin, when the wallet has 2 previous tx with amounts of 0.5 BTC, then a new tx ...
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 ...
6
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. ...
6
When you sign the transaction with your private key, you include the hash of the entire transaction data as a message. This means the signature which is generated is specific to that transaction itself and any modification to the transaction will render the signature invalid. In this case, the user who has signed the transaction has already specified the ...
6
Taproot generally has two ways of spending. The default way is to spend the output using the key path: pay-to-taproot then behaves like a p2pk output except that it is using a schnorr signature and the corresponding address being encoded using bech32.
The alternative is to reveal that the inner key was tweaked with the root of a Merkle tree, the Merkle path ...
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 ...
5
No, that's not accurate. Witness data is on-chain, inputs have a similar byte length as before (they are just weighed differently), and the transaction throughput is increased because segwit is a defacto blocksize increase.
Thus, with segwit, the witness data was separated from the rest of the input. More specifically, the witness data is now "off-...
4
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 ...
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
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 ...
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
Is it possible to decode the private key from a signed input?
No. Signatures and public keys are meant to be public. In typical use, using a correct implementation of the signing code, it is currently not possible to determine the private key for a signature and pubkey pair.
Signed inputs are not encrypted or obfuscated in any way, so when you broadcast ...
4
TL;DR:
A P2WPKH input should be conservatively estimated with 68.0 vbytes. Standard P2WPKH inputs generally weigh 67.75 or 68.0 vbytes, depending on whether the r-value in the signature is low or high. A wallet using signature grinding (which is highly recommended) will always produce 67.75 vbyte inputs. 68.0 vbytes is the conservative estimate allowing for ...
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
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;...
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
There may be multiple utxos that the same script would unlock. The most common example is two transactions that both pay the same address. If inputs weren't signed, an attacker could replace one input utxo by a different utxo that pays the same address, and this would be bad.
Consider the following scenario. Alice has received two payments to her address ...
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.
Only top voted, non community-wiki answers of a minimum length are eligible
