New answers tagged transactions
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 ...
0
In the backend of the bitcoin network's operation, there is no concept of 'account balance'. Rather, the network keeps track of coin ownership via a UTXO model.
So when a node validates the history of the network during the initial sync, it will construct a UTXO set and update it accordingly as it works through history. So a node will store the blockchain ...
0
How an account's balance is found if the latest input and previous output are away from each other away more than 1 transaction.
They never are. They are the same. Someone's input becomes someone else's output, until he decides to spent said output as an input in a new transaction.
Or, am i not understanding the question? Are you asking why a wallet ...
0
One of the standardness rules (relay rules) in Bitcoin Core is that the scriptSig must contain only operations that push data to the stack. Since you have actual opcodes that do non-push things, this transaction is non-standard so your node is not accepting it.
On regtest, you can disable standardness checks by adding -acceptnonstdtxn to your startup ...
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 ...
0
EDIT: I wrote this hours ago, but apparently forgot to hit the post button. There are now a couple great answers, but I'll still post this anyways.
A has previously transferred 10BTC to B. So B has an unspent transaction output (that it can spend) referenced by the address of A.
UTXOs are not 'forwarded to an address', they exist until they are used ...
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 ...
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 ...
0
The transfer amount (BTC) is, (somewhat dependant on the library used), most commonly denominated as "value:"
Read: the outs => value: *
{
value: 1000000,
script: <Buffer a9 14 14 ea 69 2e 87 76 ec c6 2e 6a aa a1 7d cc d2 8f f3 30 b7 46 87>
},
{
value: 3299775,
script: <Buffer a9 14 73 e2 99 78 43 31 1e cc 32 b5 ac ...
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 ...
0
Bitcoin is not meant for transactions in large scale.
You need to set up a Lightning-network for this.
It is the promised solution to the transaction prob.
0
Just go to BTC explorer any search in google
example:
https://www.blockchain.com/explorer
type your wallet adress or transaction ID
And check.
0
It's possible to do this externally, but it's tricky to get right and a cause of loss of funds if you do.
You need to correctly identify transactions you can spend. This is relatively trivial with P2PKH addresses, but a little more involved if using more exotic script types. You need to understand rules like transaction maturity before considering a UTXO ...
0
So how we can calculate txn fee before signing and sending txn for external addresses?
As a reference:
P2PKH P2SH-P2WPKH P2WPKH
-------------------------------
Input : 592 WU 364 WU 272 WU
Output : 136 WU 128 WU 124 WU
All transactions include 40 WU by default. If your transaction spends a P2SH-P2WPKH or P2WPKH ...
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 ...
0
I analyzed a bit with forensic tools and found that with high likelihood either you or the scammer (or both) have an Huobi.com account.
If I understand you right then 03281a511f38992dff51dee176c66dfc5f873e92cd76228956ca5099a27214fd shows the scam transaction and the input addresses on the left side are yours and you initiated the transaction?
If yes then ...
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 ...
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 ...
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 ...
Top 50 recent answers are included
