Hot answers tagged

10

Original meaning of nSequence in transactions nSequence is a 4 byte input level feature. The original meaning of nSequence was to allow modification of transactions in the mempool. So, if the nSequence value of the input was less than 0xFFFFFFFF (4294967295 in decimal), it indicated a transaction that was not yet finalized. Such a transaction would be held ...


7

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. ...


7

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.


6

The bunch of input addresses (usually) come from a single HD wallet. That's one possibility. It could also be that they come from a non-HD wallet, so that they correspond to a bunch of independently generated private keys that happen to belong to the same person. Or they could all belong to different people, who have agreed to combine their coins and send ...


6

3045022100d52330113ccd033ccb1aaa3b759e9696c216e802922e5f1902cd5ada69c612e5022057880205319dccb05eebbe34323a852ee82653f09f81253ddccd08a810e9d42d01 Is a DER encoded ECDSA signature. I'll break it down: 30 indicates that a compound structure follows (ECDSA signatures are treated as a compound of 2 integers, r and s) 45 is the total length of the ...


4

the signature: 483045022100d52330113ccd033ccb1aaa3b759e9696c216e802922e5f1902cd5ada69c612e5022057880205319dccb05eebbe34323a852ee82653f09f81253ddccd08a810e9d42d01 and it's decomposition: ################################################################## ### tcls_in_sig_script.sh: decode SIG_script OPCODES from a TX ### #################################...


4

Can it safely be said that the first input in the inputs of the transaction is the sender's? No, no such ordering exists. Transactions consume UTXOs as inputs, and create new UTXOs as outputs. A transaction can have multiple inputs from one person, or inputs from multiple people. In some cases, more than one person can own an input. So there isn't really ...


3

3045022100d52330113ccd033ccb1aaa3b759e9696c216e802922e5f1902cd5ada69c612e5022057880205319dccb05eebbe34323a852ee82653f09f81253ddccd08a810e9d42d01 is an ECDSA signature with the sender's key. 03e5b9f0bb669b289efb8d2826487a24ef5f3985624c8bc3a3e34f6bd54e080b27 is the sender's public key (whose hash is stored in the address the coins were previously sent to)...


3

The sighash type conditions what is part of the digest which is eventually signed for the transaction to be valid. Some sighash types allow to either include (commit to) part --or none-- of the outputs of the transaction in the digest. Using these far less common sighash types introduce some malleability for a transaction, which usually allow more ...


2

When creating a Bitcoin transaction, each input explicitly states which unspent transaction output (UTXO) is consumed (via an outpoint consisting of txid:vout) and then proves the spender's authority to use this unspent. For the standard output format such a proof is a signature created by the private key corresponding to the public key the funds were ...


2

The current signature scheme that bitcoin is using (ECDSA) doesn't support signature aggregation, so you will have to sign each input and provide one signature per input (assuming it requires only one signature) and your transaction size will grow accordingly. sell 5000 pcs coffee every day for $1 each Then you might want to look into Lightning Network....


2

No, that would not necessarily be true. If multiple users have created the transaction in collaboration (e.g. during a coinjoin, a payjoin, or other type of multiparty transaction), the address that received the first input could be owned by another party than the one paying you or could have shared ownership by more than one party. If the sender used a ...


1

Inputs do not reference the value of the UTXO they spend. You need to look up the spent UTXO to find the value. Usually, this information is available to a node via the UTXO set, or can be looked up by inspecting the transaction that created the UTXO.


1

As RedGrittyBrick suggested in a comment: Give each user a different deposit address. Think of your process as the users purchasing credits in exchange for a Bitcoin payment. You respond to each purchase request with an offer. The offer includes an invoice address. Each new offer should have a new address, so you can identify which user took what offer. ...


1

By input script, if you mean scriptSig, the max standard scriptSig can be up to 1650 bytes. See policy.cpp : // Biggest 'standard' txin is a 15-of-15 P2SH multisig with compressed // keys (remember the 520 byte limit on redeemScript size). That works // out to a (15*(33+1))+3=513 byte redeemScript, 513+1+15*(73+1)+3=1627 // bytes of scriptSig, which we ...


1

You do not have to calculate the in/out values to see how many bitcoins have been "sent" to an address. You see, outputs from a transaction can be "locked" to a specific address. However, the address page on blockchain.info shows all the transactions that have resulted in an output being locked to that address. In the most recent transaction on that page, ...


1

It is different for each input. Each input's hash preimage contains that input's previous output's scriptPubKey in that input's scriptSig. All other inputs have empty scriptSigs. This means that the preimage for each input is unique, and thus has a unique hash.


Only top voted, non community-wiki answers of a minimum length are eligible