A message from our CEO about the future of Stack Overflow and Stack Exchange. Read now.
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 ...


2

A first thing to correct is that UTXOs are not referenced by address, but by the txid that created them. The addresses are purely a human abstraction about locking conditions to help think about ownership. So in your example what happens is that in the initial transaction tx0 created by A, B was credited with 10 BTC. Assume that transaction only had one ...


2

Uneconomical UTXO requested This usually means the amounts you are trying to send are so incredibly tiny that the transaction fees will cost more (perhaps much much more) than the amount being sent. See dust See helpful comments to other similar unanswered questions: cant send btc, Uneconomical UTXO requested Uneconomical UTXO requested Maybe its like ...


2

From Elliptic Curve Cryptography perspective everything you sign is a "message" but the term "message" in bitcoin context means a random string that user wants to sign with his key (usually used for proof of ownership or something similar). This means when you use sign*message*withprivkey the code interprets the input as a string and signs it with a ...


2

What malleability means is that you can create a transaction that is identical in its meaning (same inputs, same outputs) but with a different TXID. That is problematic for 2nd layer protocols where transactions build onto each other but aren't necessarily published to chain. But a "malleated" transaction is still a double spend. And it appears newer ...


1

UTXO are uniquely identified by their outpoint. An outpoint consists of the id of the transaction that created the output and the position in the output list. As transaction ids are the full transaction body's hash, they are collision resistant, and as each position in the output list can occur only once, outpoints can be expected to be unique. E.g. the ...


1

Transaction do not need to be signed. They are if the locking script requires so, which is the most usual thing, but scripts redeemable without a signature can also be valid. That being said, a transaction redeeming from a script that does not requires a signature could be highly insecure, since a peer (or a miner) that receives so can easily change the ...


1

how do you determine if that peer created the transaction or if it is simply relaying the transaction You cannot, at least not with absolute certainty. This is by design: it helps preserve the privacy of users on the network. That said, if you decided to run a whole bunch of nodes, and positioned them carefully in the network graph, then you could start ...


1

"fundrawtransaction" and "walletcreatefundedpsbt" are wallet RPCs. They add inputs and change outputs from your wallet to aim for a specific feerate for the transaction. These operations inherently require the relevant wallet. Change addresses are generated by the sender's wallet, and inputs have to come from the wallet of the sender. If you don't have that ...


1

To elaborate on this part of Ugam Kamat's excellent answer: "When you sign the transaction with your private key, you include the hash of the entire transaction data as a message." The function that turns the transaction into a hash to be signed is not just any hash function; in the code it's called a "sighash" or "signature hash". Each signature contains ...


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