Do I need a full node to perform OP_RETURN transactions? I want to build a services that allows people to perform OP_RETURN for proof of existence. Do I need to run a full node to do this (then e.g. using the OP_RETURN PHP scripts from https://github.com/coinspark/php-OP_RETURN)? I have found no API that allows to do this.

Thanks
Chris

You do not need to run a full node in order to submit a transaction, regardless of which OP codes that transaction contains.  Any node that can submit transactions to the Bitcoin network will do.

What you should look for instead, is a library in your chosen language that allows you to construct transactions manually, rather than using templates for typical payment transactions.  Once you have a transaction constructed, you can broadcast it to the network via whichever type of node you feel like.


How much does the market cap increase when a certain amount of $'s go in the market? Lets say that $1B worth of money is going in to bitcoin and its current market cap is $100B. How much would the market cap increase with that $1B?

Would it go to $101B, $105B, $110B, $100.1B?

I know that it will change according to how the money is put in. If they find someone selling by hand locally than it wouldn't affect the market price/market cap at all.

But I'm more curious on the average of the increase? I'm guessing there is a formula for it in finance? What is it?

Given that the Bitcoin market is pretty unstable + unregulated I don't think it is possible to predict the outcome of this.

Have a look at the paper Price Manipulation in the Bitcoin Ecosystem by Neil Gandal et al. to get an idea of why this is very hard (if not impossible) to predict.


What is the 25th word in a mnemonic seed when used on a ledger nano s? By default ledger nano s generates a 24 word mnemonic. What is the 25th word feature? Is the the passphrase they are talking about?

From BIP39:"A user may decide to protect their mnemonic with a passphrase. If a passphrase is not present, an empty string "" is used instead."

The passphrase can be added in the transformation from the mnemonic phrase to the seed. It is not added IN the mnemonic but in an other point of the procedure.

A consequence of this is that:
"The described method also provides plausible deniability, because every passphrase generates a valid seed (and thus a deterministic wallet) but only the correct one will make the desired wallet available."

The passphrase is a second parameter in the "generate the seed from the mnemonic" procedure. If you don't provide it the procedure assumes that the second parameter is "".


If Bitcoin mining is becoming more and more impractical, what then? If Bitcoin mining is becoming more and more impractical, where you'll need to buy like a ButterflyLabs unit, and where even eventually a room full of these units might not be enough some day, what then?

Or, am I failing to understand some controls on Bitcoin that make it where eventually the processing power requirements go down again by some market factor? Forgive me, I'm new at this.

I think you misunderstand the problem. The reason mining is becoming impractical is because there's too much of it. It's like a restaurant that's too crowded. It means you can't get a table, but the restaurant is not going to go out of business.


How to read a tx's comment? How can I retrieve the comment field from a payment transaction that I made from my QT wallet?

I can see the comment when I click "Show transaction details" in my QT but I cannot find a way to do this from the RPC console.

Any ideas?

Use the listtransactions RPC call, and look for a field named comment:

$ bitcoin-cli listtransactions
[
...
    {
        "account" : "",
        "address" : "msj42CCGruhRsFrGATiUuh25dtxYtnpbTx",
        "category" : "send",
        "amount" : -0.00001000,
        "vout" : 0,
        "fee" : -0.00000225,
        "confirmations" : 0,
        "txid" : "0ecdc2da9266635349ad04b7374eb1032919c34e7949e60cec198b47e31d2f26",
        "walletconflicts" : [
        ],
        "time" : 1427561024,
        "timereceived" : 1427561024,
        "comment" : "COMMENT" <--- Here
    },
...
]

Note that this comment only exists in your wallet, and is not sent across the network. The other party to the transaction will not see it.


What is the purpose of the block time/ difficulty in mining? I understand the point of mining is to decentralize away from allowing one entity to add to the ledger. What I don't understand is why it's necessary for miners to compete over who gets to add to the ledger. Why can't a random miner just be selected instantly and therefore bypass any block time? It would be just as random. What am I missing here?

Why can't a random miner just be selected instantly and therefore bypass any block time?

The problem is: how do you select a miner in a truly random way? If the mining process was just a simple random election, who gets to enter in that lottery? How would you stop someone from just running a million fake nodes, in order to increase their chance of being selected?

These are the sort of problems that are solved by Bitcoin's proof-of-work mining. In a proof-of-work scheme, a miner must expend computational resources in order to 'enter the lottery', there are no 'free tickets', if you will.

Proof-of-work also provides a mechanism of security: in order to change the blockchain history, an attacker would need to redo all of the work from the point of change onwards. To do so, they would need more computational power than the rest of the network (51% or more). A simple 'random election' would not include this 'real world resource expenditure', or the type of security it provides.


How do I import to MultiBit from Blockchain.info? I have a single password and a yubikey on my account at blockchain.info.

When I try to import the wallet.aes.json file nothing happens.

When I select the import file, MultiBit never displays the 'Number of Keys' or 'Replay date', so I put in my password and click "Unlock" then click "Import Private Keys".

The Bitcoin addresses in my account never show up on either in the send or request tabs.

I have also tried importing the unencrypted base58 json file from blockchain.info and it too has the same behavior (save entering my password).

Could you please point out how to export my wallet from blockchain.info to MultiBit?

Step one : Update your Multibit, normally since 0.3.4 it can import Blockchain.info
https://groups.google.com/forum/?fromgroups=#!topic/bitcoin-multibit/G87Y3e1-0Ak

Anyway, if it's not working you can try this :

Go to Import/Export in Blockchain.info

Now "Export Unencrypted", change Base58 by Bitcoin-Qt format and take the key after "priv".

Now go to Multibit and EXPORT (yes export) your wallet WITHOUT password.
Edit the file exported and you'll see several lines with ADDRESS (whitespace) DATE

Replace address with the blockchain's address. Change the date by the date you created the account (or a few time ago).

Now save and import this file in Multibit, et voilà !


Are there any POS coin open source mobile wallets implementations? Specifically, I'm interested in the thick clients with Simplified Payment Verification. Haven't found these so far, do they even exist? Why are the POS mobile wallets such poorly distributed comparatively to the POW coins?

Thanks in advance.

AFAIU, PoS is considered flawed by large parts of the cryptocurrency community.

I've not kept abreast of POS coins, but some that I could think of are Peercoin, NXT and Blackcoin, which are currently ranked 38, 39, and 58 on Coinmarketcap.

Unless I'm missing some new more popular ones, I'd say there is less software for them because they have less of an ecosystem / they are less popular?


Been reading the bitcoin source code but unsure what this segment of Serialize.h does I decided to learn about crypto (and C++) by first reading the entire C++ implementation of bitcoin. I'm having issue with this segment of serialize.h

template<typename Stream, typename I>
void WriteVarInt(Stream& os, I n)
{
    unsigned char tmp[(sizeof(n)*8+6)/7];
    int len=0;
    while(true) {
        tmp[len] = (n & 0x7F) | (len ? 0x80 : 0x00);
        if (n <= 0x7F)
            break;
        n = (n >> 7) - 1;
        len++;
    }
    do {
        ser_writedata8(os, tmp[len]);
    } while(len--);
}

I get that it is writing some variable to a stream, however I don't understand the significance of

(sizeof(n)*8+6)/7

for the array size. Then it enters some loop where it performs a bitwise or of the bitwise and of the loop counter and the hex representation of 127, and either the hex of 128 or 0 depending on whether or not the loop counter is 0.

Then if the number is less than 127 it is going to exit and write the reverse of the array to the stream.

What I don't understand is:

What is the significance of that size of the array?
Why the bitwise operations?
Why write the array to the stream in reverse order?

The encoding used fits 7 bits of data in each byte of output. So, to figure out the number of bytes of output you will produce, you need to take the number of bits of input and divide by 7 (since 7 bits of input fit in each byte of output), rounding up.

So, sizeof(n) is the number of bytes of output. Multiplying by 8 gives the number of bits of input. We divide by 7 to get the number of bytes of output needed to fit that many bits of input.

But integer division rounds down. To divide by 7 but round up, we add 6 to the number before dividing. That makes it round up.


How to generate a valid hash for a bip39 seed phrase? I'm trying to prove to myself that I understand how bip39 seed phrases work...  I'm doing most of this in a spreadsheet because I thought it would be easier but I'm having trouble with the checksum value...  These are the steps I'm taking:

I start with a valid 24 word seed
then change each word to its index value
then change those to a single 264 binary digit string
then change that to a 66 character hexadecimal string
I manually enter the first 64 hexadecimal characters into a
binary editor to create a 32 byte file
then I use the linux terminal command 'shasum -a 256' on that 32 byte file to get the hash

However, the leading byte of that hash does not match the last byte of the 66 character hexadecimal string from above...

As I understand it, 24 word bip39 seed phrases have a single byte checksum value at the end.  That checksum is the first byte of a sha256 hash of the first 32 bytes of the number encoded by the seed phrase.  But, so far, I haven't been able to supply a 33rd byte that reproduces a valid seed phrase...  Any suggestions?

You can create a valid seed calculating a valid last word (23+1).

Even using the browser JS console:

mywords="sausage liquid same heart ... "

allwords = WORDLISTS["english"]
m = new Mnemonic("english")
for (var w in allwords) {
       curr_word=allwords[w];
       test_words = mywords + " " + curr_word;
       if (m.check(test_words)) { console.log(curr_word) }
 }

Source:

http://wikistas.com/u/cryptodog!Ccsi1HdXWr/Wd5q-generating-secure-bip39-seeds


Can a bitcoin cold wallet become incompatible (newby-question)

If I plan to use a cold wallet for longterm storage without following the news around bitcoin and my cold wallets application does not get maintained anymore in the meantime, can it be that I cannot access my funds in that wallet anymore or is this totally impossible?

Regarding that question is there a difference between a client that creates a seed of words and a client that creates a private key?

Background

In order to answer the question let's first identify the key components inside a Bitcoin wallet:

Bitcoin public keys are derived by applying Elliptic Curve maths to a large random number (the private key).

A Bitcoin address is, in turn, derived by applying a series of transformations to a public key.

One private key is associated with one public key, and each public key creates one Bitcoin address. The Bitcoin wiki provides details and examples.

A standard wallet typically contains and manages several private keys and their associated public keys and addresses.

BIP32 specifies a schema for creating a Hierarchical Deterministic (HD) wallet that uses a seed phrase to reliably and repeatably generate a single master private key and set of addresses.

When we speak of "cold storage", it can mean that we either store bitcoin in

a single standard address with a single private key, or
an HD wallet - a set of addresses with a common master private key - all of which can be recreated from the seed phrase, or the xprv format private key

The client mechanism for creating a standard address is different from the mechanism for creating an HD extended private key and its associated set of addresses. However, the mechanism for creating each is standardized. Wallet clients, like Electrum, can generally create addresses by either mechanism but implement their own schema for generating the HD seed phrase. Variations and changes are evident between different clients and even between different versions of the same client, e.g. the length of Electrum's seed phrase was changed some years ago.

The Bitcoin protocol accepts addresses produced by either method - the network simply sees valid Bitcoin address referenced in a transaction.

Conclusion

So, coming to your concern about HD client maintenance and its implications for cold storage, yes, there are risks. Who knows what the future holds, right?

Storing bitcoin, long-term, in a standard address means that you only have to back-up and secure the underlying private key. The bitcoin can be accessed easily and reliably, in future, by simply importing the private key into any standard wallet client or address tool script.

Using an HD wallet application for long-term storage could have the outcome that, after years or decades, the application has fallen out of maintenance or has changed its HD implementation. A solution would be to keep a backup of the application version that you had originally used to create the HD wallet. Also, exporting and securing the HD master private key in xprv format could be a mitigation. However, I have witnessed instances where xprv exports from one client fail to import to other HD clients, for whatever reason.

HD is useful and convenient for everyday use - provided it is frequently updated to new client versions. Otherwise, the HD client software will become outdated and may cease to function. Even when storing the original version, after years and decades, its dependencies on outdated software libraries and CPU/hardware architecture may render it inoperable.

For long-term cold storage a good rule of thumb is: simple and standard is safest.


How can a programmer contribute to the Bitcoin project? I'm a programmer and would like to support the development of Bitcoin, but I don't have an original idea for a new project. Where can I find information about tasks and issues that I could put some effort into?

Gavin Andresen, the Bitcoin client technical lead, has expressed a desire that effort be focused on closing bug reports in the client. You can find the current list of open issues on GitHub. You can also find some documentation about how to create your own fork of the project source and how to suggest that changes from your fork be pulled (imported) into the main release in Gavin's post here.


How to deserialize the Transaction Count in a raw block? In the bitcoin-book, the "Transaction Counter" part of a block is documented as being 1~9 bytes long instead of a fixed size.
How is this counter parsed from the raw data?

This number is encoded as a variable-length integer, see the txn_count in the block protocol message.
The idea is the following:

Read the first byte as marker
If marker < 0xFD

marker is the number

If marker == 0xFD

read the next 2 bytes as the number

If marker == 0xFE

read the next 4 bytes as the number

If marker == 0xFF

read the next 8 bytes as the number

Or, in Python:
def read_varint(byte_array):
    marker = byte_array[0]
    if marker < 0xfd:
        return marker
    elif marker == 0xfd:
        return int.from_bytes(byte_array[1:3], 'little')
    elif marker == 0xfe:
        return int.from_bytes(byte_array[1:5], 'little')
    else:
        return int.from_bytes(byte_array[1:9], 'little')

See also the implementation in Bitcoin Core here.


Question regarding stale blocks and the heaviest chain According to this website: https://forkmonitor.info/stale/btc/644543, at the block heigh 644543 multiple blocks were produced. If I understand correctly, in Bitcoin, the heaviest chain survives, while the other block(s) become stale.
So, in this case, the "empty" block containing one COINBASE transaction 644543 survived, while the block: https://www.blockchain.com/btc/block/0000000000000000000ac8d61492ab76dab7451373c6eaa6803ec0244f623395 (containing 2,426 transactions) became a stale! Moreover, the stale block was mined 3 seconds earlier.
Questions:

how the chain containing the "empty" block was heavier than the chain containing the stale block?
Is the mined block time important in resolving such situations?

how the chain containing the "empty" block was heavier than the chain containing the stale block?

"Heaviest" is technically not the correct terminology. Bitcoin uses the valid chain with the most cumulative work. This is unrelated to the size of blocks nor their "weight" (whether that be weight units as defined by segwit, or some other definition of weight). The chain containing the empty block becomes part of the main chain because someone mined a block on top of it so the cumulative work of that branch is greater than the others.

Is the mined block time important in resolving such situations?

The only effect the time has is on propagation. Otherwise the time doesn't matter. What matters is getting the block to someone who will mine a block on top of it, and that is where time matters.


how do i get my @host for LN I cannot find where to get the host to complete a lightning channel. I have tried searching in the command prompt but cannot find host info anywhere.

Your question seems a little bit underspecified. So not sure if I can really help you. The host is your public IP address so if you are logged on the machine on which the lightning node runs you can try typing curl -4 https://icanhazip.com/ to the command line.

if you are running c-lightning you can do: lightning-cli getinfo and it will also depict your public IP address. Not sure if the other implementations have an API call to depict this information.


Bitcoin mining process-the leading zeros before the hash-how is the mining puzzle solved exactly? Can someone please explain:

In Bitcoin proof of work, mining is done to create and validate new blocks. Who becomes the sole block producer is subject to winning a "mining puzzle".

As I understand, the difficulty is that the solution of this puzzle must have a specific number of leading zeros in the resulting hash.

My questions are:

1) must the hashing result have X number of leading zeros, or is the constraint more like "less or equal X number of leading zeros"?

2) If the mining puzzle's solution has a hash as a result, what is then the input parameters for doing the hashing? What are the miners exactly hashing, what are all the input factors?  As i understand, input factors are e.g. the Nonce, previous Block's hash, etc...

3) I understand a hash function is only one way function. You have an Input which produces a unique hash. This means that if multiple different parties are hashing the same input then their hash results must be identical, right?

Given this definition, I really do not understand how the situation of orphan blocks in Bitcoin can happen? Because orphans happen for example when 2 miners at the same time solve the mining puzzle. But both are solving the exact same mining puzzle right? This means, they both have dealt with the same difficulty level of the puzzle and arrived at the same number of leading zeros for their hash, right?

How is the blockchain then distinguishing between those 2 miners, who has "put more work into the mining" if they have solved the same thing? On which parameters is the network looking to determine which of the two miners should get the reward?

Thanks

I understand a hash function is only one way function. You have an Input which produces a unique hash. This means that if multiple different parties are hashing the same input then their hash results must be identical, right?

Multiple parties will never be hashing the same information. Either the parties are coordinating or they're not. If they're coordinating, they'll carefully avoid doing the same work because to do otherwise is foolish. If they're not coordinating, they can't possibly be doing the same work. I'm trying to find a hash that pays me money. If you're not coordinating with me, why would you also be doing that?

  Given this definition, I really do not understand how the situation of orphan blocks in Bitcoin can happen? Because orphans happen for example when 2 miners at the same time solve the mining puzzle. But both are solving the exact same mining puzzle right? This means, they both have dealt with the same difficulty level of the puzzle and arrived at the same number of leading zeros for their hash, right?

Probably. But they will produce different blocks since they're either trying to mine to different destination addresses or carefully coordinating to avoid duplication fo work.

  How is the blockchain then distinguishing between those 2 miners, who has "put more work into the mining" if they have solved the same thing? On which parameters is the network looking to determine which of the two miners should get the reward?

When the next block is found, whichever block the miner who found that block built on top of will be in a longer chain than the other, causing everyone to switch over to the longer chain. To get to keep your mining reward, the block you found must stay in the longest chain. To have the highest odds of this, you always try to mine to extend the chain that is already the longest. So any ties are quickly broken -- as soon as a block on top of one of the longest chains currently existing is found and no other block is found at around that same time, nearly everyone will be building on top of that block.


What happen to my bitcoin I have payed last april 21 and april 25 should be my payment but it took days already here is my transaction id

b5a9cb6a67429ec60c51f3aa197bec67af0003c841890132051f9fea40f71f76

And the same as april 22 and i should get my bitcoin on april 26 transaction id

77fc2aa152a80e0abe382a53d5254f113460a6f17cff95852bd0827a572e01cb

I waited how many days just for bitcoin to go to my wallet but it say bitcoin network i dont why and what happen ?please i need help

Your transaction are NOT unconfirmed. As you can see here:
https://blockchain.info/tx/b5a9cb6a67429ec60c51f3aa197bec67af0003c841890132051f9fea40f71f76
https://blockchain.info/tx/77fc2aa152a80e0abe382a53d5254f113460a6f17cff95852bd0827a572e01cb

Both of them have over 700 confirmations. All, but one of your outputs are already spent.


Litecoin core account info result I'm using Litecoin RPC in my app. I created two wallets on my server. Make some send-receive operations and last result is like that:

{
    "result": {
        "": -0.381788,
        "wallet1": 0.11,
        "wallet2": 0.271788
    },
    "error": null,
    "id": 12729
}

What it means? When I send some coins from wallet2 then ("") this wallet is decreasing but wallet2 staying same value. I think wallet2 must decrease. What is the issue on this? Thanks.

The current multi-account system is deprecated in Bitcoind (AFAIK Litecoind uses the same one) and has a bug that makes negative balances appear in accounts:

https://github.com/bitcoin/bitcoin/issues/9887


missing transaction not received I transfered 0.013 mBTC into Bitoincore.org wallet.on the 07/07/2020. As yet I have not received
Hash:-
13290114c5e1fe381c707e5f67b246cd0260f5bd24c9a1fc1aed0eab08dd2521
Address:-
1AKWvdsoAQC43sBANr9pCnk74nHCdrAvB6
0.0126 after fee, not recieved, can someone help me please

The hash mentioned is already confirmed on blockchain. It is already credited to receiver.  You can see it here
So, it must be issue with your local node syncing.


Bitcoin peer to peer network source code Does anybody know a place to get the source code of the Bitcoin Peer to Peer network? I only need the P2P network portion of the Bitcoin protocol. I am going to implement a new virtual currency. So i am going to reuse the existing bitcoin peer to peer network infrastructure for my project. Can someone advise me on this?

The source code for Bitcoin can be found at https://github.com/bitcoin/bitcoin. The P2P part is integrated within the core Bitcoin code, and is not available separately.


Multisig where one of the keys specifically is required? Is it possible to make a multisig wallet that requires one of the keys specifically and any of the other ones in order to sign a transaction?

For example, let's say I have a 2-of-3 multisig that has signators A, B, and C. Can I make a multisig that requires that every transaction be signed by A specifically and then one of either of the other keys?

No, but instead you can make a 3-of-4 multisig where you hold both keys A and B, then you give key C to a family member, and D to someone else(just as an example). This way you are certain that you are involved in all transactions. I presume this is the end result you are after?


How are Namecoins managed by the system? First of all, sorry for a potentially silly question, but I flicked through seven pages of questions here and I couldn't find a specific answer for that:

How does Namecoin basically work? I understand the basic principles of Bitcoin and heard these are the same in Namecoin - you mine coins, get a reward, which gradually decreases. But in Namecoin, the coins are also deleted, aren't they? Doesn't it mean that we will eventually run out of the supply of Namecoins?

First, I'd like to note that Namecoin and Bitcoin are separate - they share a lot of code, but they have different blockchains and networks.

Let me talk about the problem that Bitcoin solves: double spending. It solves this by having nodes vote with their hashpower on what they think the most accurate picture of the network is. This creates an ordered list of transactions.

  How does Namecoin basically work?

It turns out that having an ordered list of transactions is exactly the sort of thing you need to create a naming system that provides all three elements of Zooko's triangle

  Secure
  Memorable
  Decentralized

Registering a domain looks like this:

You publish a transaction that says, "You can find mysite.bit at 23.12.34.67"
Other nodes include that into a block.

It's about as difficult to steal your domain name when it has X confirmations as it is to double spend a transaction which has X confirmations.

  Doesn't it mean that we will eventually run out of the supply of Namecoins?

That's true, but the supply of nice sounding memorable domain names is so small that it makes sense for there to be a cost to registering domain names en masse.


Can a node broadcast a valid signed raw transaction while still syncing? Built and signed a native bech32 UTXO, but when I attempt to broadcast from my testnet node using the command sendrawtransaction it returns "missing inputs". I don't have the private keys in my wallet, and the testnet node is still syncing, but I was able to broadcast it fine with a testnet API service that lets you broadcast signed transactions.

Is it possible to broadcast a raw signed transaction to the network while still syncing?

You can only broadcast transactions if your node has synced to the point that it knows the outputs that were spent. This is because your node will always validate a transaction before it broadcasts it. If it has not synced to the point that it knows the outputs that your transaction spent, then it won't have the information necessary in order to validate the transaction.

So if your transaction spends outputs that were recently confirmed, then you will have to wait until it is basically fully synced before you can broadcast. But if your transaction spends very old outputs that are deep in the blockchain, then you can broadcast before it has synced.


Why do some generation transactions use pubkey, instead of hash? At BlockExplorer I can see that (edit: some) generation transactions use a pubkey in the script (<key> OP_CHECKSIG), while ordinary transactions use address/hash (OP_DUP OP_HASH160 <hash> OP_EQUALVERIFY OP_CHECKSIG). Why don't generation transactions use hash as well?

Pubkey transactions use a little less space in the block chain overall (if no pruning is used), so you might as well use them when you can.

I think that Satoshi's main reasoning was as follows, though:

Satoshi originally expected that most transactions would be pubkey transactions: the sender would contact the recipient directly and retrieve a public key to send funds to (the protocol has commands for getting this info from recipients, but it's almost never used nowadays). Bitcoin addresses were just a "hack" useful for sending BTC to offline recipients. You know your own public key for use in generation transactions, so addresses aren't necessary and Satoshi avoided using the "hack".


test cases for hash algorithm anywhere? RFC4231 gives test cases for SHA256 with several different sets of gozintas and gozoutas. I'm looking for something similar for the SHA256 hash as implemented in the Bitcoin mining algorithm.

Based on the answers given, here is a very simple test in Python. Note that the generated digest must be reversed before the check, as the 256-bit digest is apparently returned with the least significant bits first.

#!/usr/bin/python
import hashlib
GENESIS_BLOCK = \
    '0100000000000000000000000000000000000000000000000000000000000000' + \
    '000000003BA3EDFD7A7B12B27AC72C3E67768F617FC81BC3888A51323A9FB8AA' + \
    '4B1E5E4A29AB5F49FFFF001D1DAC2B7C01010000000100000000000000000000' + \
    '00000000000000000000000000000000000000000000FFFFFFFF4D04FFFF001D' + \
    '0104455468652054696D65732030332F4A616E2F32303039204368616E63656C' + \
    '6C6F72206F6E206272696E6B206F66207365636F6E64206261696C6F75742066' + \
    '6F722062616E6B73FFFFFFFF0100F2052A01000000434104678AFDB0FE554827' + \
    '1967F1A67130B7105CD6A828E03909A67962E0EA1F61DEB649F6BC3F4CEF38C4' + \
    'F35504E51EC112DE5C384DF7BA0B8D578A4C702B6BF11D5FAC00000000'
GENESIS_HASH = \
    '000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f'
def check_hash(block = GENESIS_BLOCK, blockhash = GENESIS_HASH):
    '''
    check that the calculated hash matches what Bitcoin expects

    >>> check_hash()
    True
    '''
    blockheader = block.decode('hex')[:80]
    header_hash = hashlib.sha256(blockheader).digest()
    check_hash = hashlib.sha256(header_hash).digest()
    return check_hash[::-1].encode('hex') == blockhash

if __name__ == '__main__':
    print check_hash()


Any supervisory power on earth to ensure that Bitcoin system will remain resilient if hashing conditions change rapidly? Assume that Bitcoin value versus the “fiat money” is of great significance and  imagine suddenly discounted by 50% or more, the current pools are not in money any more, stop hashing. The current Bitcoin system will automatically set the difficulty down ( exponentially decreasing mode and easy to mine blocks using again a laptop ). Any supervisory power on earth to ensure that  Bitcoin system will remain resilient if hashing conditions change rapidly?

Bitcoin is a decentralized currency and there is nobody with "supervisory power" over it.

Anyone is welcome to suggest improvements to the protocol (changing hashing rules or anything else) at any time, and can create a source code patch to any of the several pieces of Bitcoin client software to implement them.  (The maintainers of Bitcoin Core or another piece of client software can do so simply by releasing a new version.) Each user can then make their own decision whether to adopt this patch or new version, or to continue using the software they already have.  (Of course, they might be more likely to decide to adopt a patch if it comes from a "trustworthy" source, such as the software maintainers.)

If a general consensus emerges that the improvement is desirable, and essentially all Bitcoin users adopt the patch, then the protocol has effectively changed.  So such a method could be used to make a change to the difficulty adjustment rules, should there be a consensus that such a change was necessary.

Assume the patch changes the protocol in a way that is incompatible with the existing protocol, so that the old and new protocols disagree about the validity of certain blocks or transactions.  (For example, the new protocol might "lower difficulty" by saying a block of a certain low difficulty is valid in a certain situation, where the old protocol said it was invalid.)  If some people adopt the patch and others do not, then there will be a problem: those two groups will disagree over whether particular transactions or blocks are valid.  This situation is called a hard fork and essentially would split Bitcoin into two separate currencies: "old Bitcoin (BTCO)" and "new Bitcoin (BTCN)".  Anyone who held, say, 1 bitcoin before the fork would effectively now hold 1 BTCO and 1 BTCN.  The economic effects would be confusing, to say the least.   Many people consider that if such a state of affairs continued for a significant length of time, and with a significant population on each side, the effect would be to destroy confidence in both the new currencies and render them both valueless.

As a result, users are likely to be cautious about adopting patches that change the protocol.  They should only do so if they believe that the vast majority of other Bitcoin users will do the same.  For this reason, implementing protocol changes is as much a political challenge as a technical one, and it helps a lot to have "trustworthy" people advocating for the change.  So those trustworthy people may have some amount of power over the protocol, but not in a "supervisory" sense.  It's less like being the king, and more like being the prime minister of an unstable coalition government.

If there was a feeling that the existing difficulty adjustment rules were not working well, the software maintainers and other well-regarded people could propose a change and hope that the user community as a whole would agree.  That's what would likely have to happen in a situation like what you describe.


Why do I keep getting a connection lost error in Nicehash Bitcoin mining The algorithm I'm using is daggerhashimoto. At first I thought this was because of my country blocking Bitcoin mining or something, but it doesn't work even if I'm using a VPN (vpnbook.com/freevpn). Here's how the excavator console looks like. As you can see, the hashing speed stays at 0 H/s, and it's not connecting at all:

And I did leave my laptop mining overnight, but the speed never passed 0 H/s, so this has nothing to do with me not waiting long enough for it to connect.

I reinstalled Nicehash, this solved the problem :)


Bitcoin-qt data on external drive I have done the instructions listed here:
How to move Bitcoin data from Application Support on an external drive [Mac]

It works fine for a flash drive connected the mac, but I wanted to have the data read from my network storage device (ReadyNAS). Bitcoin-qt comes up with the following error when I link it to the NAS:

EXCEPTION: N5boost12interprocess22interprocess_exceptionE
Operation not supported
bitcoin in Runaway exception

Any ideas on what this could be?

It is trying to acquire a lock on the lockfile in the data directory, which likely fails due to not being supported on the network file system you use to access your NAS.

Even if that could be safely ignored (the lockfile is just there to prevent you from running multiple Bitcoin Core instances on the same directory), it is a warning that more problems exist. In general, running a database on a network filesystem is a bad idea because of lack of support for operations or guarantees that databases require. It would either just not work, be very slow, or get corrupted very easily.

However, this is all because of the databases used (blocks/ index/, chainstate/ and wallet.dat). The block data itself is not a database, and could be moved elsewhere. Bitcoin Core does currently not support moving just the block data elsewhere, though.


Is the following a valid bitcoin private key? - FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE In secp256k1 (Bitcoin's elliptic curve) it is defined that valid private keys may range from 1 to FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141 - 1. (https://crypto.stackexchange.com/questions/30269/are-all-possible-ec-private-keys-valid)

However I created an EC Keypair with the private key being FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE imported it into bitcoin core and sent a small amount of btc to the corresponding bitcoin address. I was able to spend these coins. Does that mean that bitcoin does not follow this restriction and any combination of 256 bits is a valid private key for bitcoin? Or might it be a bug that could get fixed in future?

I'm currently myself deriving bitcoin private keys/addresses from a seed and importing them via json-rpc. I saw that implementations of e.g. BouncyCastle check whether an EC is in that forbidden range. I currently don't do that but I also think that even if bitcoin wouldn't accept such keys the probability of deriving a private key in that forbidden range is too low to justify the additional implementation complexity (at least in my case). Is that problematic?

Update -
Here's how I created the private key:

byte[] privKeyBytes = {1,1,1,1,1,1,1,1,...,1,1,1,0};
byte[] version = { (byte) 128 }
byte[] privateBytesPlusVersion = MyUtils.concatenateByteArrays(version, privKeyBytes);
byte[] versionPrivateAndCompressed = MyUtils.concatenateByteArrays(privateBytesPlusVersion,
            COMPRESS_BYTE);
byte[] checksum = getChecksum(versionPrivateAndCompressed);
byte[] versionPrivateCompressedAndChecksum = MyUtils.concatenateByteArrays(versionPrivateAndCompressed,
            checksum);
String privKeyDump = Base58.encode(versionPrivateCompressedAndChecksum);

The Base58 class is from BitcoinJ. I then imported this string via json-rpc with importprivkey

Update2 -
As Pieter Wuille pointed out I had an error as privKeyBytes {1,1,1,...,1} is not 'FFFFF...FFF'. I tried to import such a private key again and bitcoins rpc interface answered with an error: "Private key outside allowed range". I'm still tempted to not check for this range as the probability of me generating something with 120 1 bits at the beginning seems low enough to discard that case.


What is the maximum transaction throughput of the Bitcoin network? I have seen different values mentioned but the 3.3--7 transactions/second appears to pop up a lot. In Section 2 of On Scaling Decentralized Blockchains (A Position Paper) it says the following:

  There are two interesting scenarios: The first scenario is when the
  Bitcoin network is operating at maximum throughput, namely 3.3–7
  transactions/sec. This maximum throughput is mainly constrained by
  Bitcoin’s 1MB maximum block size and the variable transaction size.
  The lower bound of the maximum throughput is inferred from the current
  average transaction size, about 500 bytes, while the upper bound is
  based on an oft-cited estimate from [1] which corresponds to unusually
  small (250 byte) transactions.

The maximum block size is 1,000,000 according to the source code. My calculations give me these values for average transactions sizes of 500 bytes for the lower bound and 250 bytes for the upper bound:

lower bound: 1,000,000 / 500 / 600 = 3.3333(3)
upper bound: 1,000,000 / 250 / 600 = 6.6666(6)

lower bound’: 1024*1024 / 500 / 600 = 3.4952533(3)
upper bound': 1024*1024 / 250 / 600 = 6.9905066(6)

According to my calculations, the correct rounded maximum throughput of the Bitcoin network is 3.3--6.7 for the transaction averages given above. I am wondering whether I got something wrong. The authors could have rounded only the upper bound but that doesn't make much sense though.

The smallest transaction that would commonly occur in the wild is a P2PKH transaction with one input and two outputs (send amount and change output). A P2PKH input has 148 bytes, a P2PKH output has 34 bytes and the transaction overhead is 10 bytes, 148 bytes + 2*34 bytes + 10 bytes = 226 bytes, in the case when no change output is required, this could actually be 192 bytes.

The blocksize limit is a megabyte, not a mebibyte, so it's 1,000,000 bytes.

If all transactions were only P2PKH with one input and two outputs, the throughput would be 1,000,000 / 226 / 600 = 7.37 tps. However, the mix is very different with a lot more transactions on the network making use of multisignature inputs or sending to boatloads of different addresses at the same time, and the current average transaction size is around 520 bytes, making the 3 tps figure much more accurate.

I don't know why the authors would have only rounded the upper bound.


Do miners have both the incentive and ability to keep the reward at 50BTC? There has been some concern about the fact that transaction fees (in their current form) are not an adequate replacement for the current 50BTC block reward.  Gavin has said as much, as have others.  The issues of incentive misalignment are described in other threads.

I'm curious: as the 50BTC->25BTC block reward reduction approaches, there is a strong incentive for the miners to modify their clients to simply ignore this rule, continue producing 50BTC-reward-blocks, and ignore any blocks which try to reduce the reward.  It requires changing only a single line of code!

It is in the best interest of every miner to do this, and the miners decide what winds up in the block chain.  Therefore, I suspect that it might actually happen.  Is there reason to believe otherwise?

Obviously if more than half the miners agree, they can change any aspect of the bitcoin protocol.  But this is a bit different: it's easier to get a bunch of people to agree to not make a scheduled change in the protocol than to make a new change.  It's also easier to do this if omitting the scheduled change is in all the miners' best interest.  So I think that eliminating the reward reduction is a lot more likely than any other protocol modification.  "Oops, I forgot to reduce the reward I pay myself!"  It's also less likely to produce panicked "OMG they changed the rules of the game" and a crash in the BTC exchange rate, since what's really happening here is less change, not more.

Additional note: although pooled mining makes it easier for this to happen, no "agreement between pools" or collusion is actually needed.  Think of it this way: the block that is supposed to reduce the reward to 25BTC is very likely to be a forking point in the blockchain.  Every miner will decide for him/herself which side of the fork to work on.  The fact that there is more reward on the non-reduced side of the fork means that a rational miner will choose that side.  The fact that more miners work on that fork means it will ultimately become the "real" blockchain.

It's not just about the miners, it is also about people using bitcoin. If miners decide to fork the chain and keep block bounty at 50btc, they cannot use those bitcoins in any place where people have not also modified their non-mining bitcoin client. Protocol changes are not just about >50% of miners, but about >50% of user clients.

In this case, since users do not have any incentive to modify their clients to treat the new fork as legitimate, rather than the original rules fork, any miner that decides to spend his resources mining the new "50 btc forever" fork is just going to be wasting time, since he will not be able to spend his coins anywhere; they'll be rejected as illegitimate by users, merchants, exchanges, etc.


Does anyone have insight into how Coinbase calculates the number of confirmations for a transaction? When you compare number of confirmations for a transaction by hash using Coinbase vs using Blockchain.info, Coinbase is always ~10 confirmations below Blockchain. Does anyone know why?

I'm using the two resources below to compare. Coinbase's transaction details page requires authentication, so compare using a transaction from your own wallet.
https://coinbase.com/network/transactions/TRX_HASH
http://blockchain.info/tx/TRX_HASHd

Coinbase allows BTC to become spendable after zero confirmations as long as they are in sync with the BTC blockchain, which they usually lag behind a bit.

The reason Coinbase lags behind the bitcoin blockchain is because their internal node is generally lagging behind the blockchain about 2-4 blocks; sometimes less, sometimes much more. I don't know why, but I imagine it helps reduce fraud with instant buys and maybe the system they use to sync their services with the blockchain gets bogged down under heavy loads..

Coinbase does have a network page (https://coinbase.com/network) that allows one to check the status of the last block seen on their side. Therefore, if it shows "Last block created 57 minutes ago," one can safely assume they are about 5-6 blocks behind the btc blockchain and will take some time to catch up.

It can be quite annoying and cause a purchase to be delayed or cancelled, but by watching the network page, one can make more informed decisions about when to send.


Where can I buy bitcoins with an American Express gift card? I recently got an American express gift card for my birthday. It has a value of $50. Where can I purchase bitcoins (or litecoins) with this giftcard?

http://btcquick.com uses Google Checkout and supports Amex, I have not tried a gift card but it should work.

They do require identity verification to combat the (massive) fraud risk they face.


What exactly is generator G in Bitcoin's elliptical curve algorithm? What exactly is the generator G in elliptical curve math?  It is typically described as a point on the curve.  Is this a tuple of values?  What properties does it have?

For a curve with for instance the equation:  y^2 = x^3 + a * x + b

The generator point G, or a ECDSA public key, is a pair of coordinates x and y, for which the above equation holds.

To reduce the storage size for a curve point, one can also store a sign and the x coordinate, this is what is known as point-compression.

You can then reconstruct the y by calculating  sign * sqrt(x^3+a*x+b).

Note that for calculations in modular fields the square root can only be calculated efficiently when the p != 1 (mod 8)


2-of-2 with different wallets? I've been using 2-of-2 on bitpay for some years, but relying on just one wallet, which can have its source code backdoored with malware, is very dangerous.
I've been researching about multisignature over different wallets, which makes it harder for these things to occur.
Electrum works with lots of other wallets but it's very user unfriendly. The only other one I know is BlueWallet, but its package.json dependencis worry me a lot: https://github.com/BlueWallet/BlueWallet/blob/master/package.json#L67
What would be a good solution for multisignature over 2 different wallets?

You can use Specter Desktop with the Bitcoin Core wallet and a hardware wallet for the first key and second key respectively in a 2-of-2 multisig.
For a disclaimer it states on the Specter README:

This software might be ready to be used but at your own risk.

Alternatives Michael Flaxman also discussed briefly on the Stephan Livera podcast are Caravan (Unchained Capital) and Sparrow.
These are all efforts to manage multisig for different hardware wallets with Bitcoin Core. I am not aware of any efforts from existing software wallets to expand their offering to multisig with other third party software wallets.


Exhaustive technical explanation of signing & verification I apologize for such a noobish question and am ashamed that I'm not getting this yet, but I can't seem to put together all of the pieces.  I've read every question I can find on the subject, the Satoshi paper, and bitcointalk.

How exactly is a transaction signed?

How exactly is a transaction verified?  I simply cannot understand how secure transactions signed with private keys that are presumably unknown to all else can be confirmed to be valid and correct without actually knowing the private key itself.  Please show me in detail how this works.

I know this looks like a dupe, but I've read every related question, and I just can't get to that "ah ha" moment that puts it all together.

This should get you started on public key verification: **Digical signature

In essence, the bitcoin address is the public key.  A hash is created of the transaction and this value is then encrypted using the private key that is known only to the owner of the bitcoin address.  Anybody can then use the public key (the bitcoin address) to decrypt this hash value and determine that the transaction has not been modified by creating a hash of the transaction and then comparing it to the decrypted value.  This serves a two-fold purpose: it protects against transaction modification and it proves that the transaction creator has access to the private key for the bitcoin address.


Why can't I see my transactions on Blockchain.com? I've a Bitcoin address on which I made a couple of transactions. From what I understand of the blockchain, the ledger is public and anyone can list the transactions linked to a particular address.

If so, why do I see zero transaction when keying my address 39QUZnHVbtXGreq3zndkPtrg1TSho2Mbht on https://www.blockchain.com ?

Same for https://blockexplorer.com.

My assumption would be that this is due to the way coinbase handles deposits.
You can tell more of the story by grabbing the transaction details from their website.

Click on the transaction in the Accounts section and look for the "View transaction" link and it will take you to it.


miner_proxy and minerd Settings I've started a mining account of Wemineltc.com, and have decided to go down the track of CPU mining.  I looked up the relative tutorials on how to do so, and I got some different results.  I set the proxy batch file to

mining_proxy.exe -o freedom.wemineltc.com -p3339

and the minerd batch file to

minerd -a scrypt -o stratum+tcp://freedom.wemineltc.com:3339 -O USER.1:12345

One of the tutorials says instead to use the minerd command line of

minderd -a scrypt http://127.0.0.1:8332 -O USER.1:12345

I tried the latter minerd command line and it didn't mine, so I tried my own version.  Is there any explanation to this? Am I doing something wrong?

Am I doing something wrong?

Yes. mining_proxy is used to translate from stratum to the old getwork protocol. This is useful if you want to use a mining program that does not support stratum, but you still want to get the benefits of stratum.

However, minerd supports stratum out of the box. You don't need mining_proxy.

You should remove the first and third commands.


What information does a lightning network node hold? Just setup my first lightning network node, what information exactly am I downloading when syncing?

When syncing the bitcoin node (a prerequisite to running Lightning securely), you are downloading the entire blockchain and validating all historical transactions, which takes a while and a over couple hundred GiB of information. Having a full validating node means that you are always receiving valid transaction information yourself, and you are not relying on third-parties who could present false information, or where you may have privacy leaks by requesting information about transactions from others.

The bitcoin node will continue to receive new blocks and transactions as they occur on the network, and each block acts as a synchronization point approximately every 10 minutes.

When initially syncing the Lightning node, you are receiving the most recent information about online nodes, open channels, and the policies by which you can send payments through those channels with Lightning's onion routing. By default, this information is limited to the previous 2 weeks only, so historical information about nodes and channels is not transmitted or stored.

After the initial sync, your node will constantly receive and rebroadcast new information about nodes and channels over Lightning's gossip network. Each node broadcasts information about itself or its channels each 2 weeks if there have been no changes and the channels are still active. Any changes to channel or node states are broadcast immediately, but nodes may limit the frequency of updates they accept to prevent potential DoS which would degrade the network. These broadcasts are also timestamped and signed.


Newbie question, bitcoind installation doubte I am not an expert of linux systems but I want to learn how to use it on a secure way. I have an vps with ubuntu and I installed bitcoind with the root user. I read into a lot of sites that I should use another user account and install the program which require privileges through sudo command. Is it very bad that I have installed bitcoin daemon as root? If it is very bad, which are the right steps that I should follow to have a clean and secure installation?

Maybe it is a stupid question, but if someone could reply me to improve my knowledges I'd be very grateful

The problem with running a network facing daemon as root, is that if in the future there is an exploit found for that daemon then potentially an attacker could execute code on your machine as root. This gives the attacker unlimited accesses to your machine. To fix this you would need to create a user/group that your daemon can run as and also assign that user/group to the files your daemon needs to access. This prevents an attacker from having free reign over your computer should he exploit that daemon.

To create a user/group for your daemon called user bitcoin you can run the following:

$ sudo useradd -U -r -s /bin/false bitcoin

-U create a group named bitcoin
-r create a system account
-s /bin/false sets the login shell to /bin/false (this way no one can potentially login with this user and get a shell

Now lets say you have chosen to store all the bitcoind related files in the /var/lib/bitcoind directory.

$ sudo mkdir /var/lib/bitcoind
$ sudo chown -R bitcoin: /var/lib/bitcoind

This will set bitcoin user and bitcoin group as the owner of all files within that directory as well as the directory itself.

When you run the bitcoind daemon you need to tell it to run as user bitcoin and to use /var/lib/bitcoind as it's data directory. Make sure your files like your wallet or blockchain data are inside /var/lib/bitcoind. Your bitcoin.conf is expected to be stored at /etc/bitcoin/bitcoin.conf in the following system script.

Now you just need to install a script that will start your daemon for you with your intended user. To do this please read the instructions (chances are you are using systemd so follow those instructions): https://github.com/bitcoin/bitcoin/blob/master/doc/init.md

I hope this helps!


How often do I need to backup my Copay wallet? Is a new backup after every transaction necessary? Is it true that I need to make a backup after each time an amount was sent from a wallet by writing down the 12 words?

Unfortunately, I had Copay and saved only before the transaction was sent, and now I can not get back the remaining amount.

As long as you did not import any additional private keys manually, you do not need to make a new backup every time. Those 12 words can be used to restore all addresses in your account, past, present, and future.

If you imported any additional keys manually, you will need to make a backup every time you import a key, since they are not linked to the 12 words.


How to change Nxt/Ardor wallet settings to keep the account ledger table untrimmed? For purposes of extracting all transactions of an Nxt/Ardor account, it would be very useful to export the complete account ledger table.
Is it then enough to just set nxt.ledgerTrimKeep=0 and nxt.ledgerAccount=ARDR-xxxx-xxxx-xxxx-xxxxx (the account ID in RS format) in nxt.properties or are there other settings to be changed?

How do you initiate a re-scan to generate the whole ledger table afterwards? The database re-downloading would also be an option here, however, would take more time I guess.

A good use for this would be to import the ledger table into a tool for computing taxes resulting from crypto transaction profits, e.g. CoinTracking.info.

To generate a full ledger for a specific account set the following nxt.properties:

# Do not trim the ledger
nxt.ledgerTrimKeep=0

# Only log these specific accounts
nxt.ledgerAccounts=NXT-V4D7-D3XW-JX9Z-EAC8K;NXT-XK4R-7VJU-6EQG-7R335

To rebuild the ledger, invoke the scan API with parameter height set to 0.
This operation can run for several hours depending on your configuration.


Recognize Bitcoin address from block hash, and transaction hash I'm building a block explorer using blockchain.info and their API
https://github.com/blockchain/api-v1-client-php/blob/master/docs/blockexplorer.md

but what I don't understand is, what is the best way to recognize if the user is searching for an address or a block hash, or what ever.
how do the other block explorers do that?
They allow to search for all of those in the same search box.

Thanks for any help !

Block explorers I've seen typically accept the following inputs:

Bitcoin address: 25-34 alphanumeric characters.
Block height: decimal number, up to let's say 10 digits
Block hash: 64 hex digits (0-9, a-f), representing a 256-bit number
Transaction ID: 64 hex digits

So it's easy to recognize a Bitcoin address or block height with a simple regex.

They can't tell apart a block hash from a transaction ID, because in principle any given 256-bit number could be the hash of either (or neither).  So when a string of 64 hex digits is input, they simply search for it as block hash and as a transaction ID, and if one of them is found, they return the appropriate information.  It's overwhelmingly improbable that the same string could be the hash of a valid block and of a valid transaction, so there isn't really any need to handle the possibility that both are found.

They could do some minor optimizations: for instance, if the string starts with a bunch of zeros, it's more likely to be a block hash, so maybe they search that table first.


Why is Python popular in Bitcoin projects? When checking out open source projects related to Bitcoin, I see that many are written in, or make a large use of, Python language. I mostly use Ruby and have little experience in Python; so, I would like to know why this is the case.

On this Github search result, you can see that Python is ranked second when you search the keyword 'bitcoin'.

In comparison to languages like Java or C++, Python has several advantages for coding bitcoin projects:

Simplified rules of coding allows beginners and experienced alike to code and get results without getting bogged down in formatting etc
Shell allows on the fly calculations
Python code is easily read and as such can be edited to suit
Python can be compiled into an executable or run uncompiled

I suppose in essence, Python is great for small scripts/applications and these small applications often align with difficult Bitcoin protocol mechanisms which are greatly simplified.

The caveat of course is that most Bitcoin Python utilities (Pybitcointools, Pycoin, sx/libitcoin require Python version 2, whereas Python 3 is the current release and, mind-bogglingly, 3.x is not backwards compatible with Python 2

If you want to get a feel for what Python can offer check out either:

RICHARD KISS blog
RICHARD KISS YouTube class
KEN SHERIFF blog


What are the risks of keeping USD in an exchange account? Bitfloor, mtgox and others allow me to keep a balance of both btc and usd that is not being traded. So the usd is apparently in the hands of the exchange company rather than at my bank. This is an advantage because it allows me to quickly buy in and out of btc without waiting for a wire transfer or paying for something like bitinstant.

Is my usd held by the exchange protected in anyway from hacking or other losses, the way it is at my bank?

Each exchange can be different.  Essentially with every bit of funds held at an exchange, either fiat or bitcoins, the account holder becomes an unsecured creditor of the exchange.

Regulated exchanges of other securities, commodities and currencies and brokers of those exchanges have clear instruction to keep customer funds segregated from the operating funds so that those funds are not at risk if the exchange itself runs into financial issues.

Whether any of these regulations affect a Bitcoin exchange or brokerage may vary based on jurisdiction.  It is possible these exchanges are operating without any regulatory oversight and thus no guarantee that they are holding all customers funds without lending those funds out or using those to fund operations.

An exchange that accepts deposits from an account-to-account (A2A) transfer could help lessen the risk.  For instance, Camp BX and Mt. Gox accept deposits from Dwolla.  So holding dollars at Dwolla until they will be used for trading is one approach to lessening the risk of keeping the funds at the exchange the whole time.   BitFloor accepts CapitalOne 360/ING transfers, as another A2A example.  And multiple exchanges accept transfers from OKPay.

Additionally there are site security concerns.  If the service gets hacked, or an individual account gets hacked, those funds could be used to buy bitcoins and withdrawn -- with the losses assessed to the account holder.  Use of two-factor authentication is essential a core requirement.


from Bitcoin Core to SPV client I have a wallet on Bitcoin Core with addresses that are receiving and will receive payments in the future (which I can't change); for this reason I cannot send my bitcoins to a new wallet; that said, how can I export my wallet from Bitcoin Core to another client (SPV: I'm unable to download 30GB and more)? Thank you very much

It's advisable to send bitcoins from one wallet to another. Messing with private keys always increases the risk of theft or user error.

If the reason that you want to change to an SPV wallet is that your harddisk is getting full, then update to the latest Bitcoin Core version (0.11) and have a look at the prune option. Sorry, the prune option actually disables the wallet, so that's not useful in your situation. Hopefully that will be fixed in the next version.

Note that an SPV wallet requires significantly more trust (in other people not lying to you) than Bitcoin Core.

As a more direct answer, you can export private keys from Bitcoin Core and load them into most(?) SPV wallets. I believe this should give you the details: How do I export my private keys from my Bitcoin-Qt client?


If bitcoin was created years earlier, would we see the same rate of mining hardware evolution? It seems like there has been a steady progression from CPU mining, to GPU, FPGA, and now ASIC, and it all happened in a relatively small amount of time.

If bitcoin was created in say, 2005 instead of 2009, and popularity grew at the same demand, would we likely see FPGA/ASIC hardware years earlier than we did, or would this be highly improbable at the time due to the then current technology?

Difficulty would have risen slower, but would have still been out of reach for most people at the same proportion as today. The GPU makers have not been creating graphics cards with the target audience of general processing and algorithm solving.

ASIC/FPGA mining hardware has zero innovative aspects than what you would have seen a decade ago. These are simply dedicated chips for solving Sha-256 algorithms. ASIC stands for "Application Specific Integrated Circuit" and could mean anything, although the cryptocurrency miners use this term very loosely. But for clarity, the bitcoin ones are ASIC for solving Sha-256 algorithm.

The industry has always been able to make dedicated chips, as you have dedicated chips for Mpeg-2 processing in video editing rigs, your digital camera has an ASIC for processing light very quickly. Whereas the CPU in your computer is for general processing, with the most R&D being to create faster and more efficient general processors for a variety of applications, instead of just one.

So to sum it up, with a profit motive the Sha-256 ASICs would have come out a decade ago because there has been little advance in technology needed to create them. Sha-2 was created by the NSA in 2001, or at least published by the NSA in 2001.

It is not a feat of engineering to make a machine efficient at solving one algorithm.

Another difference between a decade ago and today is that crowdfunding over the internet by presales would have been less trusted. Making securing the capital more difficult to create and produce ASIC mining equipment.

It is also worth noting that bitcoin can be switched to another algorithm if a vulnerability is found in the current algorithm (sha-256). This would mean that a different kind of ASIC would have to be created.

Finally, the folly of fiat currency mismanagement was not as apparent a decade ago during a period of prosperity, so people may not have viewed acquiring bitcoin as a worthy endeavor.


If someone with a business account wants to send me bitcoin, do I need a minimum deposit in my wallet? If they have a business account with a high amount in it, do I need a minimum of £550 in mine for them to be able to transfer?

No, anything claiming something like this is a scam.


One private key generate many public keys? I created wallet in BitPay. I have public and private keys.

Then I created wallet in Electrum using existing private key.

Now wallet in electrum has other public key than in BitPay but
the same private key.

Is it ok? Addresses generated in one application can be visible
in second one? Where can I read about rules of generation keys and
addresses described in simple words?

I generated wallet in electrum using the same private key second time
and i obtained the same public key like last time I generated on electrum, but not the same like in BitPay wallet. I do not understand why.

One private key can generate two different bitcoin addresses. That depends on the ECDSA logic and encoding schemes used. Probably you have heard about compressed and uncompressed keys. The details are deep under the hood, and requires some reading, e.g. Andreas book "Mastering Bitcoin" (2nd edition), which is online available. Chapter 4 and 5 are the relevant ones.

I am not sure, how bitpay creates his keys, but I have already imported privkeys into Electrum as well. As long as I was working with compressed keys in my source wallet, Electrum showed the same. However, this gets different, when you extract keys from bip39/44 wallets. From looking at their website, I think bitpay has only a function to extract an extended private key, that is for sure different from a "std private key". An extended private key is used in HD wallets, to generate a set of xpub keys, that can be used e.g. on websites, to avoid re-use of keys. And depending how the seed is implemented, wallets are not always compatible to each other. This might be the case, why you see different addresses. Electrum uses [m/44'/0'/a'] as xpriv path for derivation. But maybe there is a way, look for samuelt33's comment on 5 Aug 2017 on the webpage here.

On standard privkeys and pubkeys, there is a longer thread here: How are compressed PubKeys generated?


How to confirm custom transaction with solo mining? I'm looking to cgminer software (https://github.com/ckolivas/cgminer) for understand that how mining works. It is difficult to understand and there are lots of codes. For this I'm asking this question here.

Is it possible that can I confirm a specific transaction? For example I sent a bitcoin from my address to other address and it generates a transaction ID. Can I pass this transaction id to my custom solo miner and it confirms it. Is it possible?

Is there a software that mines custom transaction seems like:

myOwnGPUorCPUMiner -tx [my custom transaction id]

It will confirm my transaction and finished or continues to mine other transactions. (This code is just an example)

In Bitcoin, it is the miners' task to order the transactions. Thus, it is possible for a miner to pick which transactions they want to confirm. By default, they pick the ones that will provide the largest mining revenue to them, but often they will pick transactions to prioritize out of band.

However, you can only confirm a transaction by mining a block. That's what a confirmation is, a transaction being included in a block and thus being committed to on the blockchain.

However, it is infeasible for you to mine a block at home. Whatever minig power you may be able to acquire and run at home will likely not help you mine a single block in the next 1,000 years. I've elaborated here: In the ASIC-age, is it worth starting mining Bitcoin at home?


When creating a Bitcoin Farm, how do you evade having 20,000 modems How do you evade having to have 20,000 modems for all the Bitcoin Miners (utilising Antminer S9's)?

Thanks!

By using a network switch, like how it's done in the server rooms.

Switches extend the network, allowing more devices to be connected.


Why do miners validate transactions? It seems that if most transactions are valid, a miner could save a little time and increase its chance of mining a block by not validating.  Is the reason that there are enough invalid transactions to make this an ineffective strategy, because the risk of having mined an invalid block is not worth the time savings?

I have a similar question about verifying/validating blocks, and maybe the answer is similar, too.

Why do miners validate transactions?

Because they want to create blocks, that contain valid transactions. After sending the block to the network, other nodes verify the block for correctness. If the block is rejected, the possibility to "win" is lost...

  invalid transactions

you seem to postulate, that there are many invalid transactions. I am not convinced, this is the case. Yes, everyone can send a tx to the network. This tx would end up in any of the approx. 10.000 nodes. There are far less miners, so the full nodes already filter invalid transactions. A particular wallet is usually not connected directly to a miner. As full nodes validate transactions, the probability that a full node forwards a wrong tx is minimal. If a full node does, there is other nodes, which verify the tx as well, and if this nodes sends faulty tx, he gets ignored by other nodes. I just wanted to state this, to make clear, that malicious crafted transactions have a hard time to make it through to a miner. And yes, the miner himself can generate false transactions, but then again looses all possibilities to win a block.

  Is the reason that there are enough invalid transactions to make this
  an ineffective strategy, because the risk of having mined an invalid
  block is not worth the time savings?

As I tried to explain before, invalid tx are not a common thing. Miners strategy is currently to win a block, maybe with some fees along. So each miner can decide individually, what he puts as "winning strategy". There are often blocks with zero transactions, or very view tx, cause currently the block reward is much higher than fees. This seems to be a valid strategy, not the invalid tx.


My Niece is turning 4 and would like to give her BTC. What is the best way to give/store long-term? My niece turns 4 next month and I'd like to give her a fraction of a Bitcoin for her birthday.  What is a good way to do this so that she can hold on to it for 10 years or so?  Should I just store in a wallet myself and then give it to her later on?  As far as I know, her parents are not familiar with Bitcoin.

As a gift to a child, I'd recommend something more tangible than paper, such as a Casascius coin or gold-plated bar. Yeah, it's more than a fraction of a bitcoin, but the load-it-yourself option might be more affordable.


Simulating -walletnotify option in Electrum When run in daemon mode, bitcoind accepts a parameter -walletnotify=<cmd> which runs <cmd> whenever a wallet transaction changes due to sending/receiving.

Is there a similar feature in Electrum?  If not, how can it be simulated?

The watch_wallet script seems to do something similar but only works on individual addresses, not whole wallets.  In addition, it only prints a message.

An old question - by the time I saw it - but the Electrum daemon - assuming it is running on Linux of some type must be polled from an external source with software or a cron job.

see Checking/polling a balance of an address in Electrum via the command line/RPC


My Bitcoin wallet doesn't synchronize My wallet is two weeks behind in synchronizing with the net. It sais I have 8 connections with the net, however...
On top of my walletscreen it says: "Warning: Shown transactions are possible incorrect! You might need to upgrade, or other nodes need to upgrade."

How to solve this problem?

You may need to upgrade is an indicator that you may be running a client that is no longer viable for use on the network.  Download the current version 0.8.6 at this time.  There was at least one hard fork in the network that caused older versions to be deprecated.


Why bitcoin private key WIF format always be started in K or L? According to https://en.bitcoin.it/wiki/Wallet_import_format,
the bitcoin private wif format key is create by below step.
And it says that the compressed wif key always start with 'K' or 'L',
this mean 80+private-key+01/ mod 58' last result is always 18 or 19.
I know the big number mod 58 will result in 0-57,
why the last remainder of wif key mod 58 always is 18 or 19
Would someone give me Mathematical Proof of this?

 #1 take a private key
 priv='d7c9e36a4d31039d4b94a43246a4a5f0767f2f55ef9a359901c82c41fb1e4bff'
 compressed='01'

 #2 add version
 version='80' #mainnet
 priv=version+priv+compressed

 #3 perform double hash-256 of priv in step#2
 checksum=dhash256(priv.decode('hex'))

 #4 get first 4 bytes for checksum
 checksum=checksum.encode('hex')[0:8]

 #5 add checksum to priv in step#2
 wifhash=priv+checksum

 #6 final bash58encode
 wif= b58encode(wifhash.decode('hex'))

 # compressed --> K or L
 print wif

 #compressed: L4TB9Z3dXeKW4tyF7EVqbczrEA5hjSdjG1QvBd1CeYTQHm2YincA

Base58 check encoding is really just a base conversion. It follows the standard base conversion algorithm in mathematics.

Right before we perform the base conversion, we will have a sequence of 38 bytes. It's 0x80 + 32 byte private key + 1 byte compression indicator + 4 bytes checksum. For the encoding itself, these 38 bytes are interpreted as a very large number, and then a base 58 version of that number is computed.

Let's look at our number in hexadecimal (base 16). The constraints we have mean that the number will be at least 0x0x8000000000000000000000000000000000000000000000000000000000000000000000000000 and at most 0x80ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff. Now in base 58, these two numbers are KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU73NTmk4WB and L5oLkpV3aqBjhki6LmvChTCq73v9gyymzzMpBbhDLjDpKhfJuTe6.

Since every possible value that can be encoded falls between those two base 58 numbers, all possible values that can be encoded must begin with a K or L.


Why is the scriptPubKey required when using signrawtransaction? The signrawtransaction rpc method calls for the following use:

signrawtransaction "hexstring" ( [{"txid":"id","vout":n,"scriptPubKey":"hex","redeemScript":"hex"},...] ["privatekey1",...] sighashtype )

Why is scriptPubKey included in here? It seems from the code that it just looks it up anyway and compared to the value given:

if (coins.IsAvailable(nOut) && coins.vout[nOut].scriptPubKey != scriptPubKey) {
    string err("Previous output scriptPubKey mismatch:\n");
    err = err + coins.vout[nOut].scriptPubKey.ToString() + "\nvs:\n"+
    scriptPubKey.ToString();
    throw JSONRPCError(RPC_DESERIALIZATION_ERROR, err);
}

My best guesses:

Maybe there are some cases where it won't be able to look up the scriptPubKey?
Maybe so this will work offline?
Maybe it's not actually needed, but kept for backwards compatibility?

Ahh, just found the answer. Should have read the help all the way through. It says:

  The second optional argument (may be null) is an array of previous transaction outputs that
  this transaction depends on but may not yet be in the block chain.

So, it's there so that the method can be used even if the transaction it depends on doesn't exist yet. If it does exist, however, the client is smart and does extra error checking to make sure that you don't mess up.


Is difficult hashing algorithm necessary? To avoid GPU/ASIC mining, difficult hashing functions, such as scrypt and scrypt-jane, are proposed as PoW algorithm (However, GPU and ASIC are also suitable for basic scrypt operation). Is it good for the cryptocurrency? Because a difficult algorithm also means CPU needs to spend much more time to find the solution. Although the "difficulty" of the cryptocurrency is dynamic and adjustable, maybe one day a very complicated algorithm scrypt-xXx is proposed, it might be hard to find the nonce even when the difficulty is very low. Will it create some problems to the cryptocurrency?

scrypt and scrypt-jane were chosen not because thay are "more difficult" then SHA-256, they are just different, and less suitable for GPU/ASIC implementation.

Whether using such algorithms is good or not is hard to tell. I'd say, since one can mine scrypt coins with commodity hardware now, while mining SHA256 coins even with decent GPU rig is futile, scrypt helps coin be more decentralized, which is a good thing.

One can of course create very difficult hashing algorithm (I'd say 10^80 rounds of bcrypt will be enough to ensure no one calculates a single hash ever). But cryptocurrency with such algorithm is unusable, and so would be forfeited.


Regarding block validation in blockchain In mining process, miners validate the block based on proof of  work or using some other consensus mechanism.
Miners also validate the block. So in this validation process, miners validate only hash value of current block (or) they validate the entire transactions and then they validate the hash value of current block.
Please clarify this.

Full nodes validate everything. A miner must be running a full node. Not all full nodes are miners, but all miners are full nodes.

A full node validates everything in a block; it validates the transactions, it checks the block header is correct, and checks the Proof of Work is correct. So in the validation process, full nodes (and thus miners) will verify that the PoW is valid (hash of the block header is less than the target), that the block header is correct (contains the correct target, merkle root, etc.). Then they will check that each individual transaction spends UTXOs that exist, check that the scripts validate to true, and check that the output amounts are valid (less than or equal to the input amounts). They will also check that the coinbase transaction pays out the computed maximum payout for the block (subsidy + transaction fees).


Restart altcoin blockchain So, I'm setting up an altcoin for educational purposes and I've essentially forked Litecoin.

It's got a 10% premine on it but this wasn't showing up in my wallet so I deleted the $HOME/.mycoin/ directories on my nodes and my %appdata%/mycoin folder on my wallet host in an attempt to restart the blockchain.

However, the blocks that I have attempted to delete are still reappearing as soon as I start my daemon up again.

Any idea what directories/files I need to delete to completely restart the blockchain. This ought to be fairly trivial as I have complete control of the two nodes and the only machine that's connected to it.

Thanks

You need to delete the data directories entirely with the node software shut down when you do that. If both nodes' data directories have been removed and starting one of them still results in the blockchain being downloaded, that means that there is a node that you are connecting to which did not have its data directory cleared. You can find out what node that is by looking in the debug.log file and seeing the IP address of the node that you are connecting to (or is connecting to you).

Alternatively if you generate a new genesis block, you will not have this problem as whatever blockchain you use with the new genesis block will be different from the original blockchain.


When does client decide to stop/cancel proof of work algorithm? I have been reading about bitcoin and blockchain in the last few days, but I have something I don't clearly understand.

The "proof of work" may take a long time for a simple node to guess, but if we combine all nodes, they guess it in 10 minutes.
Now lets say another node guessed it faster than me, how do I know when I should stop my proof of work algorithm?
Is there any point on keep trying to guess it?
When do you start trying to guess the next proof of work?

Hope the question is clear.

Now lets say another node guessed it faster than me, how do I know when I should stop my proof of work algorithm?
When do you start trying to guess the next proof of work?

Whenever a node successfully solves a proof-of-work it immediately broadcasts it to the whole network. So whenever you hear a block that you are trying to solve you should stop and start mining a fresh block on top of the newly received block


Does the Bitcoin Qt client have a minimum transaction fee? I'm trying to transfer all of my 0.1 BTC located in one wallet to another wallet. I don't care how long it takes to finish, so I'd rather send it without paying any transaction fee. I'm new to this, so I started out by using the Bitcoin-Qt client. I set the transaction fee to 0.0 BTC, and tried to move the funds to the other address. I get the following error message:

This seems like a bug since I set the transaction fee to 0.0 BTC, but since I'm new to this, I want to make sure that I'm not missing something. Do 0.1 BTC transactions require a transaction fee? If this is just a bug, how can I get my money out without dropping a whole nickel $0.05? (I'm very stingy.)

(Update: The client has changed the min fee from 0.0005 to 0.0001)
Yes, the Bitcoin-QT client applies a minimum fee of at least 0.0001BTC to some transactions. Quoting the wiki:

Sending
A transaction may be safely sent without fees if these conditions are met:

It is smaller than 1,000 bytes.
All outputs are 0.01 BTC or larger.
Its priority is large enough (see the Technical Info section below)

Otherwise, the reference implementation will round up the transaction size to the next
thousand bytes and add a fee of 0.1 mBTC (0.0001 BTC) per thousand bytes1. As an
example, a fee of 0.1 mBTC (0.0001 BTC) would be added to a 746 byte transaction, and a
fee of 0.2 mBTC (0.0002 BTC) would be added to a 1001 byte transaction. Users may
increase the default 0.0001 BTC/kB fee setting, but cannot control transaction fees for
each transaction. Bitcoin-Qt does prompt the user to accept the fee before the
transaction is sent (they may cancel the transaction if they are not willing to pay the
fee).
Note that a typical transaction is 500 bytes, so the typical transaction fee for
low-priority transactions is 0.1 mBTC (0.0001 BTC), regardless of the number of bitcoins
sent.

The "priority" mentioned is calculated based on the quantity of bitcoins and the age of the bitcoin inputs making up the transaction (ie how long since you received them). It prevents a user flooding the network by repeatedly sending bitcoins to themself.
Note that this isn't a restriction on the Bitcoin protocol itself though. More details here.
In your case, the only thing you can likely control is the ages of the bitcoins; ie waiting will help meet the third requirement.


What is bitcoin mixing/laundering for? What is the difference if I'm using bitcoins that were given me by somebody I sold product to, or by some mixing bitcoin service?

After all, aren't I using those bitcoin at the same place and ordering what I want with the same name and address?

Bitcoin transactions are traceable, public and are recorded permanently. Although, there are some ways to minimize that, by not reusing addresses and have multiple wallets for different purposes. But even that is not foolproof because there are analysis services that can group addresses through data crunching.

Now imagine you get coins from someone that got them from someone, etc. Nothing wrong with that right? Unless, those coins are part of a bunch that were hacked from an exchange or traced back to a payment for some illegal activity.  And some exchanges start blacklisting them.

A mixing service tries to remove that linkability/traceability.

IMO you would be better off just using a crypto currency with unlinkability and untraceability built into the protocol in way of a mixer.


Does being connected to more peers relay transactions faster? If I'm connected to 500 peers, will I know about transactions faster than if I'm only connected to 8 peers?

No, very little of the time for downloading new blocks is actually related to network transmission.

Most of the work being done is the I/O against your hard drive as the program writes data to the BDB database storage.  If you are on an encrypted filesystem, the problem is exacerbated.  There is some CPU work as the elliptic curve encryption is used when verifying the signature for each transaction so a faster CPU will help as well.

Some people use SSD disk storage and report quite respectable download times

Some improvements are coming in v0.7 of the Bitcoin.org client but the real signficant performance improvement will come from the use of LevelDB and "ultraprune", both of which are expected in v0.8.


Technological contractor for an ICO legal advise I was recently offered to hire my services to create and maintain a cryptocurrency.
My responsibilities would be to create a website and issue the tokens

While I think the project as some merit, I am concerned about any legal liability I could hold.

The contract I want to sign against will be an SLA (as to my understanding it will mitigate my legal risks as opposed to a partnership agreement).

The company that wants to hire me has declared to me that the ICO would be available to US residents and that I shouldn't worry about kyc or aml.

Also, the mentioned company states that its practices are legal and that it has a legal team on board.

I am aware this sounds a bit obscure, but these are all the details I can provide as to the signed NDA.

To what degree will I be accountable if the company breaks any law (not using a kyc to verify residence for example), or if one day the SEC decides that this ICO (or all ICOs for that matter) were illegal?

While I think the project as some merit, I am concerned about any legal liability I could hold.

That's a good thing to think about.

  The company that wants to hire me has declared to me that the ICO would be available to US residents and that I shouldn't worry about kyc or aml.

Do they mean that you shouldn't worry because someone else in the company is handling that, or because they're not going to do either of those things?

The latter is a warning sign, as discussed below.

  Also, the mentioned company states that its practices are legal and that it has a legal team on board.

This means absolutely nothing.

Their legal team might be fictional. Ask for the names of their lawyers. Ask what jurisdiction they're licensed to practice law in. If they can't answer that, that's a bad sign.
Second, there are two reasons that people hire lawyers:

They want an accurate answer to a new legal question.
They want someone who will tell them what they want to hear.

If their legal team is real, and their legal team is unafraid to confront unpleasant truths, that's a good sign.

  To what degree will I be accountable if the company breaks any law (not using a kyc to verify residence for example), or if one day the SEC decides that this ICO (or all ICOs for that matter) were illegal?

The SEC has already issued guidance on this subject. Basically, if the people buying the ICO are doing so for future profit, rather than for some immediate benefit, it's probably a security. (This is a good summary of the legal test.)

So your ICO is probably a security. Why does that matter? There are a bunch of federal laws that govern how securities may be sold and advertised. For example, someone who has $10,000 in total assets can't put all of their money into an experimental new security. Here's another example: securities firms must check that they're not selling to terrorists.

So at a very minimum, you're required to know who your customers are in order to comply with these rules.


Blocks seem to store only txIDs, where does the transaction data come from for IBD? I know that blocks store transactions. After looking into a block, I can see that it only stores txIDs.
Question 1 - Where are actual transaction objects stored?
If you tell me that it's stored in a separate database called UTXO Set, I might say that the UTXO Set only stores an unspent transactions, what about spent transactions?
Question 2 If I join the network and I am new, my node starts syncing with other nodes to download the blockchain. But since each block only contains txIds, how does my node end up validating transactions (to validate, it needs to know if from address has the actual balance).
Does it mean that nodes also broadcast UTXO databases too and if so, how and when?
I'd appreciate a good explanation on this topic.

Blocks do not contain transcation ids at all, they contain the full transactions themselves. If you are using the getblock rpc and seeing txids, that's just because showing the details of all of the transactions is extremely verbose, so only the txids are output. You can see the full transaction details of a block by setting the second argument to 2.


Ethereum - how is the output of a contract computation verified? This may be as simple as a pointer to some place in the docs I've missed, but how/where is the output of a contract's computation checked, or assured against a malicious miner with an intentionally corrupted VM implementation?

Trivial example:
My contract takes two inputs, A and B, and returns their sum.  A disreputable miner wants to collect txn fees and the ethereum for the gas for this contract without doing the work, and hacks his VM implementation to always return "4" to the caller.  Any one who tests with "2+2" will think the function works.

Assume the miner succeeded in mining the block with a request for my contract, and returned "4" (so as to not waste their own compute power, and pocket the gas cost).  Block hashes for transaction accepted and ether transferred are all correct and checkable, the source and opcodes of the contract are all checkable and correct.  But how is the output of the computation checked for correctness?

I feel like I'm missing something obvious.  What stops a miner from short circuiting the requested work (whatever it is), claiming to have finished the job, while only returning something syntactically correct, but semantically dubious or wrong?

Thanks.

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 the block you mined.

But there's a related question: can you gain an advantage by improving the speed of the VM, or skipping computations somehow?

I think you could. For example, you could offload the computations to a GPU. Even though Dagger is GPU-resistant, the VMs require a small amount of memory and could probably be run on a GPU.

The advantage would be pretty slight, though.


How Do I use the prune option on bitcoin core? How Do I use the prune option on bitcoin core ? as it is taking forever to sync

Like so:

prune=550

in your bitcoin.conf in your data directory.

This will not make blockchain sync faster. It will make it take less space, though, which can be helpful.

(I have only 40 gigabytes of storage on my system, so this helps me a lot.)


How do I tweak the bip340_test_vectors to check that signature verification fails for other test vectors? I now understand why some of the bip340_test_vectors fail signature verification.
I would like to tweak these test vectors to check that signature verification fails for other test vectors. How do I do this?

Disclaimer: This is an educational exercise. This Python code is for testing and should not be used in production or with mainnet Bitcoin. A private key of 3 is absolutely insecure.
There are two Python files in the BIPs repo reference.py and test_vectors.py which you can view by cloning the BIPs repo.
git clone https://github.com/bitcoin/bips.git

These two files are in /bitcoin/bips/tree/master/bip-0340.
If you run python3 test-vectors.py from within the bip-0340 directory you will get the output and error messages that are in the CSV file test-vectors.csv.
If you open test-vectors.py with your text editor e.g. vim test-vectors.py
you can edit any of the test vectors' secret key (private key), message, auxiliary randomness.
For example vector0 has the secret key 3.
seckey = bytes_from_int(3)

You could change the secret from 3 to 4.
seckey = bytes_from_int(4)

Save and close your text editor and then run python3 test-vectors.py again.
This will generate an AssertionError.
Traceback (most recent call last):
  File "test-vectors.py", line 253, in <module>
    vector0(),
  File "test-vectors.py", line 31, in vector0
    assert(not has_square_y(pubkey_point))
AssertionError

There is an assert that checks that for a particular public key (X,Y) (calculated from the secret (private) key) the Y coordinate isn't square. This is a check implemented due to a previous design decision to use squaredness as the tiebreaker for two Y coordinates. The tiebreaker is now evenness rather than squaredness. This test is included to catch when an implementer is mistakenly using squaredness rather than evenness. In this case the public key has a square Y coordinate.
Every private key (scalar) maps to a single corresponding public key (point). In BIP 340 we restrict ourselves to public keys with an even Y coordinate. This could lead to only half of the public keys being valid and hence only half of the private keys being valid too. Instead we say that every private key has a public key and if d.G has an odd Y coordinate we effectively sign with -d (the negated private key) instead.
Negated means taking the complement with the group order n
-m = n-m (mod n)
With that change you could say that every scalar is a valid private key but there are two private keys that map to the same public key. Only one private key maps to a public key with an even Y coordinate though. (Only one BIP 340 private key maps to a BIP 340 public key.)
Remember when you are finished experimenting you can use this to reset:
git reset --hard HEAD
This will discard the changes you have made and go back to the state of the code before you started experimenting.
Thanks to Pieter Wuille on IRC for some additions.


Every bitcoin wallet user has one Private Key or every address has one private key? I read somewhere that Private Keys are used to uniquely identify users and one user can have multiple addresses. So how does it work? Each private key derives a user or each private key derives an address ?

There seem to be a couple of misunderstandings that I will try to clarify (briefly).

In public-key cryptography a pair of keys is used; a private and a public. The private is kept secret and the public shared. Assume that Bob has the public key of Alice. Alice can then sign a message using her private key and send the signed message to Bob. Bob can use the Alice's public key to verify that it was indeed signed by that private key. Because of the mathematical properties of public-key cryptography only the owner of that private key could sign that message.

A Bitcoin private key can be used to derive a Bitcoin address.
A HD key can be used to derive several private keys which in turn can be used to derive a Bitcoin address.

So, to answer your question:

A private key does not really uniquely identify a user. It just allows someone to prove that he owns a private key (has control over a specific address)

Nowadays wallets are HD wallets thus use a master key that all private keys (and thus addresses) are generated from.

So one user can have multiple address because they have multiple private keys associated with them. The private keys could be generated from one master key (HD wallets) or randomly (several non-HD private keys). Anyone holding a private key can prove that he controls the derived address without revealing that private key.


I started build my own blockchain based on mastering bitcoin book using git on win7 and i have a problem I started learning how to build a blockchain from Antonopoulos book using Git Bash and i have a problem.
I used commands:
 git clone github.com/bitcoin/bitcoin.git
cd bitcoin
git tag
git checkout v0.11.2
and when i try to use command ./autogen.sh
on the screen appear information:
./autogen.sh: line 9: autoreconf: command not found.

Where is the problem? What i do wrong? i need some libraries?

I believe you have the same problem reported in the link bellow:

https://askubuntu.com/a/490839

Just try to install autoconf. The autoreconf come with it:

sudo apt-get install autoconf


Can bitcoin transaction be signed offline without access to blockchain To make an offline transaction signing we do the following:

[Online PC]:  Create unsigned transaction
[Offline PC]: Select and sign the transaction
[Online PC]:  Broadcast to network

Is it possible to do the following:

[offline PC]:  Create transaction
[Offline PC]: Select and sign the transaction
[Online PC]:  Broadcast to network

If you know the unspent outputs you have the keys for, yes.

Which in practice means that you need to have seen the transactions that have paid you. Once you know that, the actual transaction to spend it can be created offline.