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.
7
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
Checkpoints serve two purposes:
They hardcode a historic part of the chain
They allow us to disable a check (expensive signature checking) in that historic part.
I personally dislike the first part, as it requires users to trust the software they're downloading contains the right checkpoints. Of course, they're already trusting the code anyway in much more ...
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
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 ...
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
Your first question is kind of a pointless retrospective question. Sure, now that we know that overflow can be a problem in this way, we should consider transactions that attempt to overflow to be suspicious.
The bug was detected by inspection of the blockchain. The bad transactions stood out. Had it not been detected by inspection, sooner or later it would ...
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
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
As every Client verifies each block they receive and reject every Block that is invalid, this situation is rather unlikely to happen. However, if by chance some invalid Block would propagate (such as in case of value overflow bug, or perhaps by being spread by some alternative Clients that don't follow the Protocol to the letter), it would eventually be ...
4
There already are downloadable versions of the blockchain. There's no problem in principle in having them GPG-signed by several trusted people. However:
It somewhat weakens security. With the software itself you can trust the signatures and you can inspect the code. With blockchain data inspecting it is infeasible.
Future versions will use a different DB ...
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
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
This is probably a test transaction by the seller to confirm that you are able to receive funds at that address.
If you are using the Bitcoin.org client, a transaction for that test transaction should appear under transactions and it should get at least one confirmation (or preferably several) before you confirm that you received it.
3
Do you own the address specified by the seller (as in, did you provide them the address)? If so, the seller probably wants you to confirm "yes, the address is correct" or something like that. If you don't own the address, I think you should ask the seller what exactly does he mean by that.
Generally, you don't verify a wallet. All the Bitcoin addresses ...
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
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 ...
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
There is no way in the current P2P protocol to request a historical (=confirmed) transaction, without requesting the block it is in. Supporting that would require the peer to have a full index of all transactions ever, which isn't necessary for normal operation.
To request a transaction, you will either:
Use getdata MSG_TX <txid> to request a memory ...
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
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 ...
Only top voted, non community-wiki answers of a minimum length are eligible
