9
Yes, you can use "Message Signing", available in most Bitcoin clients, including Bitcoin core. If I sign with my address the message "I am Meni Rosenfeld and I am proving to user127317 that this is my address", you can be sure it's mine.
8
Simple, the sender shows the pubkey when spending from whatever address the bitcoins are in. As part of the verification, the receiver (actually, every node in the network), can verify that the pubkey hashes to the address given and then and only then verifies the signature.
8
Bitcoin uses the Elliptic Curve Digital Signature Algorithm (ECDSA). Your private key is used to create the signature and your public key is used to verify the signature. This allows anybody to verify your signature as long as they have your public key.
For more detailed information: Digital Signature Algorithm and Elliptic Curve DSA
7
Bitcoins and satoshis do not have unique identities.
However, Bitcoin balances are stored in uniquely identifiable "transaction outputs" that can only be spent by the owner of the recipient address.
Example:
Alice sends Bob 1 BTC, Bob uses it to send another payment.
When Alice sends Bob a payment of 1 BTC, she signs a transaction that deducts 1 ...
7
It depends significantly if you're asking about the average, N-th percentile time, or a worst case including the possibility of maliciously constructed blocks.
Nodes use the first copy of a block they receive, obviously. A consequence of this is that block propagation along a slower path will be outpaced by block propagation on a faster path. As a result, ...
6
But aren't both errors just variant of a failure in executing the OP_EQUALVERIFY? At what step of the evaluation each error is thrown and what can we make out of it?
No, they're different errors. There are two rules that must be satisifed here:
The hash of the public key must match a certain value. (A failure here means you have the wrong key, or no key.)
...
5
What you described only works for transactions with one input and one output.
In general, what you do is you take the transaction that you want to verify, remove the scriptSigs from all of the inputs, and for the particular input you want, you place in the scriptSig the scriptPubKey (prepended by its length) of the output that input spends. If the output ...
5
You are almost certainly being scammed.
Bitcoin wallets do not require activation.
In any case, even if you were dealing with some entity that does require verification for using their services, the amount you claim is stored with them exceeds the amount they are asking for - a sane, legitimate business would just charge the amount against what they ...
4
You cannot "own" a transaction. But you can own the private keys for one or more of the addresses from the inputs of the transaction.
A (regular) transaction must be signed with the private keys of the addresses of all the inputs. So if you own one of the addresses, the transaction could not have been verified without you, which may count as "ownership" if ...
4
The other answer seems to be out of date, even at the time it was answered. The following seems to be a more up to date explanation:
From https://bitcointalk.org/index.php?topic=141200.msg1504768#msg1504768
0: Validate all block headers + compare (by hash) to blocks on disk for the last -checkblocks blocks
1: In addition, verify (standalong) validity of ...
4
You could:
$bitcoin-cli decoderawtransaction <HEX>
Then check if all your vins have a correct scriptSig.
A unsigned tx would look like (partial):
{
"txid" : "8b2c1d3cfb884406747ac8d37b5e66ae18cba9acacb6074cc74e3aab1bfae55d",
"version" : 1,
"locktime" : 0,
"vin" : [
{
"txid" : "...
4
Forget about the Merkle tree. Assume that instead, the block header would just contain a hash of the concatenation of all transactions.
A lightweight node could then download all headers, verify their proof of work, and make the assumption it has seen the longest chain. It is now convinced it has seen the chain the network accept. This is different from a ...
4
Do full nodes have any incentive to validate transactions they're not directly benefiting from?
Yes. If they did not validate all blocks and transactions, they could end up on a blockchain fork which could be facilitated by an attacker. Validating all blocks and transactions allows them to be sure that the node is on the right blockchain.
How often do ...
4
Is it recommendable/indispensable?
Yes, it is a MUST not just recommendable. There are a number of ways in which an attacker could modify the binary that you download from the bitcoin.org website.
Attacker can compromise the Bitcoin.org website, so any information hosted on that page could be modified by the attacker for its own benefit
Attacker can ...
4
This is most likely a scam! there have been a similar question recently Why do I have to deposit BTC as missing turnover
There is no need to send bitcoin or money to receive a private key or unlock a bitcoin wallet, be careful.
3
Other nodes do the same computation, in a deterministic fashion, and they compare their result to the result the miner got. That's why there's no function that returns random results - different nodes would come up with different numbers, and the chain would fork. All other miners verify your block, and the penalty for building an incorrect block is losing ...
3
Bitcoin transactions are not encrypted, they are cryptographically signed.
You can use a public/private keypair 2 ways:
(massive simplification warning)
Encrypt a message using a public key and then decrypt it with a private key
Sign a message using a private key and validate the signature with the public key
The second method is the one that is used by ...
3
Okay, I will bite.
No, I don't think it would be useful to publish software hashes in the blockchain.
As you recognize, a hash of a software package is useless unless it is somehow authenticated. Currently, the most popular way to do this is to make the hash available on a "well-known" website which uses HTTPS, and provides an X.509 certificate signed by ...
3
Nothing. It is mostly only useful for checking data integrity, not detecting malicious modification (unless you know someone trustworthy that signed the hash). SSL has the same problems though, because public keys can be altered too of course.
There are multiple solutions to this problem, although none is perfect.
Trusting some central authority to decide ...
3
Yes. Bitcoin uses asymmetric key cryptography, so the natural approach is to have the user use (rather than reveal) their secret key in a way that can be verified using only the public key. The only disadvantage is that the public key will be revealed---Bitcoin is in a sense even safer than most other uses of asymmetric key cryptography in that this only ...
3
Check comments in this commit
https://gitorious.org/bitcoin/luke-jr-bitcoin/commit/4538e45c46d3829a21aed7685e6fbac7e8aafad3
Add -checklevel and improve -checkblocks
-checkblocks now takes a numeric argument: the number of blocks that must be verified at the end of the chain. Default is 2500, and 0 means all blocks.
-checklevel specifies how thorough the ...
3
TL;DR: Each block only needs to be verified once. Upon receiving a new block, only the reference to the parent and the validity of the new block need to be checked.
When one gets started with Bitcoin, the client or mining software will download and verify the blockchain. During this synchronization, each block starting from the genesis block will be ...
3
Yes, it is possible. You would do that by signing a message using the private key of the address which you sent the transaction from. Bitcoin-QT offers this functionality by clicking the button called "Sign Message". Anybody can then verify that the message could only have come from the owner of said address.
To ensure privacy, you would perhaps not want to ...
3
I was facing the same issue while I was creating a raw transaction. I got the message: mandatory-script-verify-flag-failed
(Script failed an OP_EQUALVERIFY operation)
I figure out that the issue behind is that I am signing with an erroneous key which wasn't related to the UTXO.
I had to backup the key tied to the UTXO address using dumpprivkey and sign ...
3
The verification progress is an estimate, based on how many transactions have been seen versus known statistics about the transaction rate on the network.
If the latest block timestamp is in the past, the verification progress will be below 1. If the latest block timestamp is in the future, the verification progress will be above 1.
Nothing is wrong by it ...
3
How Bitcoin dose find and verify UTXO?
By Bitcoin, I think you must mean "Bitcoin core" - the Bitcoin wallet software derived from the original reference implementation by Satoshi Nakamoto. The word Bitcoin also encompasses the specific set of concepts outlined in the Bitcoin whitepaper, the network protocol definitions, the Bitcoin improvement proposals (...
2
A bit late, but for the audience eventually searching for this response:
point toward some technical resource where I could find that
description ?
https://en.bitcoin.it/wiki/Transaction#Verification
https://en.bitcoin.it/wiki/Protocol_rules#.22tx.22_messages
Short cut&paste (march 2018):
These messages hold a single transaction.
Check syntactic ...
2
They achieve the same result as if they did this, though not by actually doing it. (There are a number of obvious optimizations, for example, maintaining an indexed database of unspent outputs.)
2
bitcoind -help-debug shows these options, not shown in man bitcoind or bitcoind --help:
-checkblocks=<n> : Check the last n blocks. Defaults to 6, and 0 indicates checking all which would take a very long time.
-checklevel=<n> : Perform the following verification on each block to be checked, including verifications at lower levels: (defaults to ...
2
It is to verify the block database has not been damaged or tampered with. It does not modify the databases in any way.
Only top voted, non community-wiki answers of a minimum length are eligible