When a new node joins the network, it will look up nodes from the DNS seeds. It'll reach out to multiple nodes it hears about and ask them for more peers in turn.
The new node asks each of their peers for their best chaintip and then starts sychronizing the headers of the best chaintip it hears about first. A block header is only 80 bytes (tiny in comparison to complete blocks) but already allows checking that all the blocks on that chain are connected and that the blocks are meeting the difficulty criteria.

From then on, the node verifies each block in order to validate that the consensus rules were followed. If the best chaintip they were following is found to be injuring any consensus rules, the first block to be invalid is discarded and the peers that follow this chain disconnected. The best chaintip from that point on is found instead is found by querying the remaining (rule-compliant) peers. Finally, the node will discover the valid chain with the most accumulated difficulty.

Each release of Bitcoin Core sets a default value for the assumevalid parameter to a block that recently preceded the release. When synchronizing up to that block, nodes using assumevalid will assume that the history up to that block is valid. They will still calculate all the UTXO set transitions and check difficulty everywhere, but will not check signatures on transactions up to that block.


Why do we use CLTV instead of CSV in the HTLC output of the commitment transaction?

As you have said yourself, CSV is relative to when the transaction appears in the blockchain, while CLTV is absolute. They just have different meanings, which are useful for different things:

The RSMC timeout is meant to only start when someone pushes a commitment tx to the blockchain. So it needs to be relative.

The HTLC timeout, on the other hand, is meant to actually make an HTLC temporary, even if in most cases if will never hit the blockchain. So it needs to be absolute.


How can I send bitcoins without waiting for at least 1confirmation?

Most markets run a centralized server that keeps track of user accounts, and then only submits transactions to the bitcoin blockchain when a user withdraws their funds (or the move coins internally, etc). This model leaves the user with more risk (the exchange gets hacked and they lose their coins), but they are able to perform a huge amount of trades without paying any transaction fees to the bitcoin network.


Blockchain / Bitcoin / Previous address / Next address

You're confusing a few of the terms here. The "data area" of a block contains transactions. Transactions generally redefine Bitcoin ownership by signing over funds from one owner to another. "Token" doesn't seem well-defined to me, so I'm not sure whether a bitcoin would constitute a "token" in the way that you think of "token".

Blocks are identified with the hash of the blockheader, not an address. A new block points at its parent block by including the parent's hash in their blockheader. The blockheader's hash covers the content of the block by including the Merkle root of the transaction tree which commits the block to specific set of transactions.

I've written a bit more about how the blockchain works here:
Can someone explain how the Bitcoin Blockchain works?


can someone please help me I am lost i transfered coins from paxfull to bitcoin core

You can download bitcoin-core from here
But it's not highly recommended since you may need to download the whole blockchain.
What I recommended as an alternative is Electrum since you can use public bitcoin servers without downloading the whole blockchain


It's not clear what you mean since your address has no transactions and the address of the hacker is censored but I assume that someone transferred the money to that addresses instead.

The sender can send the money someone else with a high fee. It's really important to do this as soon as possible because once the transaction is included in a block, you cannot undo it. It might be necessary to back up the wallet and re-import it because this is double spending and wallets usually prevent it so all your payments can go through and you don't try to spend more than you have (which will not work out for all payments anyway).

However, in this case you want to double spend so the first transaction doesn't go through and the second transaction does. For this, include a relatively high fee in the second transaction so it will be picked by the miners, not the one the hacker made.

Edit: I just saw that you posted this 12 hours ago, so this answer is probably too late. Sorry for your money. But it might be that the sender is trying to rip you off by sending the money to one of their own addresses and claiming they tried to send it to you. Don't pay!


The Bitcoin scripting system is purposefully not Turing-complete - why?

As others have said, there is no real need for Bitcoin scripting to be more complex than it is, as its complexity is more than enough for its intended applications; but the main reason is that not allowing some features (such as loops) in a language makes it completely deterministic: you can know for sure when and how a given program will end; you can't f.e. have infinite loops if you don't have loops in the first place, thus you don't have to worry about programs getting stuck and blocking/crashing the interpreter which is running them (in this case, the main Bitcoin software).

Not having to deal with the halting problem is definitely a plus for a tiny, embedded, purpose-specific language such as the one used for Bitcoin scripts.


Is it possible to reindex specific blocks?

No, to the best of my knowledge there is no user-level command to reindex specific blocks.  It's all or nothing.

If you want such a feature you'll have to write the code.

It seems to me kind of unlikely that the index would be wrong only for one specific block, so I would suggest looking for other explanations for the behavior you're seeing.


I won't go into details of segwit, which in fact allows for bigger blocksize than 1 MB... sticking to your approach:

  Much of a transactions size seems to be caused by Bitcoin's built-in
  scripting system to facilitate complex transactions.

no, not really to facilitate complex tx. It is required for every tx. The logic is to sign a tx, with an output condition. The signature proofs, that data hasn't changed during transfer to the blockchain. When the receiver decides later on to spend the tx, he needs to proof, he has the privkey for the pubkey hash of the previous tx. As a hash function is a one way (as per todays knowledge), this proofs, that he is indeed holding the priv key for this pubkey hash, and as such can spend the funds.

If you take this functionality out of blockchain, then you have a normal ledger, that can be manipulated by the owner of the ledger (aka as it is today with non-crypto financial institutions). This would mean, no need for a blockchain...

Btw: a minimum tx is somewhere around 227 bytes.

The logic is defined at several places, good reading is here:

1.) bitcoin.org - the developper section

2.) the book from Andreas "Mastering Bitcoin" - it is online available

3.) http://www.righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.html


How many bitcoins have been sent to Base58-invalid addresses?

The characters excluded in Base58 are 0OIl. oiL are allowed, making these two valid addresses.

It is impossible to send to an invalid address, as Bitcoin transaction scripts actually include raw 160-bit hashes (which by definition have a one-to-one correspondence with valid addresses), not addresses. Bitcoin clients will simply refuse to do anything if an invalid address is given.

There is probably no problem with 1Boxo846yTDLHgKM94aYseHBnCjJ4eYbzb. The problem with 1BitcoinEaterAddressDontSendf59kuE is that, given an English dictionary, it has very low Kolmogorov complexity, making it extremely unlikely that anyone has a private key (or even a public key) for it.

Likewise, 1111111111111111111114oLvT2 is known to correspond to the public key hash 0, which is so simple it is again extremely unlikely anyone has the keys for it.


Why are all popular crypto currencies deflationary?

There's no technical problem with making an inflationary crypto-currency. For Bitcoin, just changing the block reward schedule would do it. And there do exist crypto-currencies that have perpetual block rewards.

The thing is, the set of people who believe that inflationary currencies are good doesn't significantly overlap the set of people who think that currencies don't need to be managed by central banks. So there's not much of a market for such currencies. It's kind of like a veggie burger with bacon.


The address is invalid because the checksum does not match the provided address. For more information see here: https://bitcoin.org/en/developer-reference#address-conversion


Looking for a tool that gives a score based on the likely hood of a 0-confirm deposit being douple spent

Zero-confirmation transactions are inherently unsafe to be considered as completed payments. It is not possible to create a tool that could give a truly reliable indication of whether or not an unconfirmed transaction will in fact confirm (or not). If it were possible to reliably predict such a thing, we wouldn't need a blockchain record in the first place.


There is no explicit limit on the transaction outputs, however, transactions bigger than 100kB are non-standard and will not be relayed by most nodes. As P2PKH outputs are 34 bytes, you'd be able to create a transaction with more than 2,900 outputs.

Since I don't know what your use case exactly is, note that if the outputs are too small, they might make the transaction non-standard (when they are below the dust threshold), and even above that threshold it could be cost prohibitive to spend very small outputs at current fee levels.


Error code -3 when signing message from gui?

The message signing feature in Bitcoin Core only works for P2PKH addresses (which start with 1...). There isn't an established standard for other ones (a few competing proposals exist, though).


Will Electrum mnemonic seeds be forward compatible with all future versions of Electrum?

In fact, the reason Electrum 2.x changed to a 13-word seed* and is incompatible with BIP39 is because they added a version number to the end of the seed. This has the purpose of allowing future versions of Electrum update the seed format while still understanding how to derive all the addresses from previous seed versions.

  Standard Electrum seeds have 128 bits of entropy, plus 8 extra bits
  for checksum and seed version. Mycelium uses BIP39, which does not
  include a seed version.

https://github.com/spesmilo/electrum/issues/1733#issuecomment-200782966

Other clients rely on the community's formalisation practice through BIPs, where we all agree on a way to describe and encode/decode HD wallets. Years down the line, you should always be able to say "hey this was derived from BIP39" and everyone should still know what you mean. The developers of Electrum believe that including the version number and checksum is more important than adhering to a formal BIP format. There are no plans to propose a BIP for the Electrum convention.

"How do I make sure my cold storage wallet seed will be recoverable in x years?"

The standard answer is that Electrum is open source, and you should be able to find an archived version or at least find documentation on how to recover your wallet should the project shut down.

*It's not actually 13-words, it's just happens to have 13 words right now. In the future this may change to greater or fewer number of words, but it won't matter because the software will know the version/checksum.


What is Mt. Gox's YubiKeys' "configuration protection access code"?

the unlock codes were leaked:

  https://bitcointalk.org/index.php?topic=631044

(source)


When you need to validate a transaction is in a block

All of this info is relevant to the operation of a light-wallet, which does not fully validate the blockchain, but instead validates the longest chain of block headers, and any transactions that are relevant to that light-wallet.

  In what situation you want to validate a transaction is in a block.

Simply: to ensure that a payment you have sent, received, or are otherwise interested in has been included in the Blockchain record. If someone pays you a huge sum of Bitcoin, you'll probably want to be sure that payment was actually legit!

  How you find the block that the transaction could be in.

The text you quoted from Mastering Bitcoin has the answer: a full-node peer will use your bloom filter to provide you with transaction info relevant to your wallet.

  The relevance that specific block has to you. Even if you verify it's part of some block, I don't see why you care it's from that block.

In order to verify the transaction is included, you will need to know which block it is in. This will allow your wallet to calculate the cryptographic proofs (using the merkle root that is in the header) that let it verify a transaction has occurred on the network in a trust-minimized way.

There is no way to similarly know that a transaction is included in the blockchain record, without knowing the specific block you need to check the cryptographic proofs against.

  So you prove that it's recorded in the blockchain. I don't see how this means it's valid.

Only valid transactions can be recorded in the blockchain history, though as a light-wallet, you are trusting that the network of full nodes is otherwise validating all blocks and transactions, to ensure no invalid data is included in the chain. As long as the full nodes are doing their job, invalid transactions cannot be included in the chain. Any miner that attempts to include an invalid transaction in a block, will see that block dropped by the network's nodes for being invalid.


Are there any POS (point of sales) machines that accept BTC?

Yes, depending on what country you are in. A quick check of Big Internet Search Engine for the term "Bitcoin POS" finds me two top of the list answers, once country specific with invoicing, payment and POS and, the other a global.


What is the exact input for the hash function?

I've read that it's some variation of: version, previous block hash,
  merkle root, time, bits, and nonce

This is exactly right.

Manually verify block hash

(thanks to @exmachinalibertas) on this reddit comment

Grab a block (eg. block 3): Block 3 in json or Block 3 in hex
Concatenate (in this order, little endian, hex format) the version, previous block hash, merkle root, unix epoch time, difficulty target (bits), and nonce. You'll see you can copy the first 160 characters from the Block 3 in hex link. 01000000bddd99ccfda39da1b108ce1a5d70038d0a967bacb68b6b63065f626a0000000044f672226090d85db9a9f2fbfe5f0f9609b387af7be5b7fbb7a1767c831c9e995dbe6649ffff001d05e0ed6d
Run the terminal command (unix):

$ echo 01000000bddd99ccfda39da1b108ce1a5d70038d0a967bacb68b6b63065f626a0000000044f672226090d85db9a9f2fbfe5f0f9609b387af7be5b7fbb7a1767c831c9e995dbe6649ffff001d05e0ed6d | xxd -r -p | openssl sha -sha256 | xxd -r -p | openssl sha -sha256
Reverse the output from

4944469562ae1c2c74d9a535e00b6f3e40ffbad4f2fda3895501b58200000000
to
0000000082b5015589a3fdf2d4baff403e6f0be035a5d9742c1cae6295464449

And there's the block hash!

  I'd like to know the exact string I can put into something like this
  and exactly where I can find it

This likely will not work because it looks like it's expecting a string and it will be strange to try and convert the bytes in the block header to ASCII characters.

Note: You will need to install openssl for terminal. Also, the xxd command will convert the hex string to bytes so the hash is not done on the ASCII bytes.


What are the differences between Bitcoin and Litecoin?

Litecoin is exactly like Bitcoin, but:

The hashing algorithm is CPU-friendly, meaning that having powerful GPU doesn't let you mine fast.
The difficulty of the blocks is set so they would be mined about every 2,5 minutes, instead of 10.

Other differences are cosmetic, like aiming to generate more Litecoins than there will be Bitcoins, using different port, etc.


If BTCUSD Price Drops Far Enough Are Transaction Fees Enough Incentive for Miners?

Wouldn't the transaction fees for mining simply go up to cover the cost of mining?

No, it wouldn't. Transaction fees are not related to the exchange rate. They are only related to the supply and demand of available block space. If not many people are transacting and blocks are not full, then there is an excess supply of block space and not a lot of demand for it. This will drive fees down, regardless of the exchange rate.

If the exchange rate were low enough that the block reward is not sufficient (regardless of the block subsidy existing), miners would simply stop mining. This will eventually reduce the cost of mining such that those who are still mining will become profitable again.


The same executable is both the server and the client. Run it as a server, and then you can use it to issue commands like getinfo to the server instance.


P2SH that pays out only to a certain Bitcoin address?

I believe this is possible, but with a subtle difference to how OP suggests.

OP seems to want: funds are first signed off by the multisig address, then a transaction is broadcast moving the funds to [destination].

It's not possible for a destination script to stipulate where the funds can end up. A new opcode could introduce that feature, but we can do this a different way.

I would argue this no weaker than having a transaction between the two destinations (as OP envisioned). In either case the multisig participants could hold the funds to ransom before the end user can move them.

Multisig: 2 [pubkey1] [pubkey2] 3 CHECKMULTISIG
Destination: DUP HASH160 [hash] EQUALVERIFY CHECKSIG

Since we cannot lock funds so they are released to a certain destination, we just merge the two scripts, allowing predefined party to take control only when the multisig is solved. He would propose a spend to the others, they sign, then he signs (it can be done in any order)

The scriptPubKey (or P2SH script) would then look like this:

 2 [pubkey1] [pubkey2] 3 CHECKSIG DUP HASH160 [hash] EQUALVERIFY CHECKSIG

And the scriptSig:

 [sig1] [sig2] [sigA] [pubkeyA]


Could bitcoin be destroyed if an entity cornered the market?

The exchange rate at any one point in time is determined by supply and demand at the markets.

The value of all bitcoins at the current market price is $80 million because the current market price is the point where the demand for bitcoins at a certain price meets the supply.  You are describing introducing an artificial demand that would indeed cause incredible rallies in the exchange rate and cause tremendous exchange rate volatility

While some people cash out in a rally, others are buying.  This government taking this action would be enriching speculators mostly -- certainly not the best use of the governed's tax dollars.

Even in a hypothetical scenario where this party you describe were somehow able to acquire 9.49 of the 9.5 million coins issued today, there are just about 11 million more that will be issued, so this entity would need to continue buying.  But even with just 10,000 coins remember that Bitcoin is divisible down to a Satoshi (0.0000001 BTC).  That 10K BTC gives 1,000,000,000,000 Satoshi trading units.  That allows plenty enough time to get an update out that provides for even greater divisibility.

Of course, the risk then is that those 9.49 million coins are not destroyed but find their way back onto the market, creating again huge volatility and price inflation.  That can technically be done, yes.

I don't think too many speculators are losing even a wink of sleep over it though.


How to get a complete list of transactions?

listtransactions "" 9999999999

The number at the end is the number of transactions to list. Instead of just 9, if you set a number there larger than the number of transaction (I'm assuming you have less than 9999999999 transactions), you'll get all transactions. Here's the API documentation, for reference:

listtransactions [label] [count] [skip]

if a label name is provided, this will return only incoming transactions paying to addresses with the specified label.

count is the number of transactions to return (default 10)

skip is the number of transactions to skip (default 0)

For example to list transactions 100 to 120

bitcoin-cli listtransactions "*" 20 100


It's the transaction (or transactions) that bob got his bitcoins from.


Why is my client saying "A fatal error occured. Bitcoin can no longer continue safely and will quit. "?

That alone doesn't provide enough information to know which database file the error is occurring with.   The debug.log might give a more precise indication.

If it is a problem with the blockchain, that is easily resolved.  If the problem occurred after your computer crashed, that is likely what happened.

First though check to eliminate that the problem is that your hard drive partition is filled with no disk space remaining.  That probably isn't the case on your Mac, but just in case, check first.

So, after making yet another backup up your wallet.dat, then you can do this to get a new copy of the blockchain:

These instructions are for mac.  For Linux and Windows the directory names would be different.

 $ cd ~/Library/Application Support
 $ mv Bitcoin Bitcoin-bak
 $ mkdir Bitcoin
 $ cd Bitcoin
 $ cp ../Bitcoin-bak/wallet.dat .

Then launch Bitcoin-Qt as normal.  It will re-download the blockchain.  This could take 24 hours or more, depending on a number of factors.

You might speed that up a bit by getting the blockchain as-of block 170,000 from here:

http://sourceforge.net/projects/bitcoin/files/Bitcoin/blockchain

After it downloads, extract those files into your new ~/.bitcoin directory.

If after Bitcoin-qt downloads the blockchain to the most recent block and everything works fine (shows your wallet balance and transactions properly), you can then remove the .bitcoin-bak directory:

$ cd ~/Library/Application Support
$ rm -rf Bitcoin-bak

Also, the blockchain download is faster if you are on the most recent release of Bitcoin-Qt, v0.6.3.


To open “MultiBit” you need to install the legacy Java SE 6 runtime

if you are using OS X, you can just double click

/Applications/MultiBit.app/Contents/Resources/Java/multibit-exe.jar

works on OS X 10.10.1, Java 7 Update 71.

guess they need some minor adjust for less strict JVM/JRE version check...


Average coins/day for a miner can be estimated by comparing the miner's hashrate with the hashrate of the network.

where,

Cm is total coins for the miner
subsidy is the number of coins/block a miner gets as a reward
blocktime is the average time per block
Hm is the miner's hashrate (Hash/sec)
Hn is the total network hashpower (Hash/sec)
1440 is minutes per day

Bitcoin

Since the total network hashpower is unknown, it must be estimated based on the current difficulty. This can be done by noting that Difficulty D

Because

difficulty = hashrate / (2^256 / max_target / intended_time_per_block)
           = hashrate / (2^256 / (2^208*65535) / 600)
           = hashrate / (2^48 / 65535 / 600)
           = hashrate / 7158388.055

see Relationship Between Hashrate and Difficulty

So, for bitcoin given a current difficulty of 5,949,437,371,610 an Antminer S9 with a hashrate of about 14TH/s:

Note: This is an average value, so with a large enough pool and enough days, your earnings will average to this formula (this does not account for the difficulty and network hashpower changing, of course).


Is there any way to revoke or update private key?

Generate a new private key, calculate its public key, derive an address from the pubKeyScript and forward your funds protected with your old,  compromised private key to the new address protected by your new private key.

--

Simplified:

Send your funds to a new address generated in a secure environment (HWW, cold storage, etc.)


What information will someone need to give me money?

Bitcoin relies on disclosing as little information about yourself as needed in order to accomplish its functions. In order to receive coins, you only need to provide a Bitcoin address, like such:

1Br7vQZjkrJxhQEALt4ReL9hTqvQj4Xqge

If you are worried about your anonymity, you should generate a new address in the standard client that you will use only once. Should anyone wish for you to confirm that you own a given address, you can use the private key you have to sign some meaningful message.

Note however, that it is possible to try connecting your Bitcoin address to your online identity if you are not careful. It is very unlikely, unless someone REALLY wants to find out who you are.


What part that control coin's total supply and give initial coins to specific wallet?

You will probably not find the number 21,000,000 in the source code. The reason is that there are not really 21,000,000 BTC. It's a bit less. You need to sum up the block rewards. It's 210,000 * 50 + 210,000 * 25 + 210,000 * 12.5 ... < 21,000,000


Is it possible to convert an address from p2pkh to p2sh?

Is it possible to covert a p2pkh adrress to a p2sh adress?

Don't.

Addresses are determined by the wallet. It's the receiver's wallet saying "I will accept payment when it arrives at address X". Sending it to another address may mean the wallet doesn't recognize it. Worst case, if the receiver has some hardware security module that stores the key, it may literally be impossible to even recover the funds when sent to the wrong address.

This is no different from owing a friend some money, and "repaying" them by burying an envelope with cash in their lawn. You may technically consider that a transfer of funds to them, but if it's not done in a matter known or even recognizable by them, it's very hard to consider it a payment.

As a sender, you shouldn't care about what type of address the receiver gives you, and certainly not try to guess how you can modify it.

As a receiver, if you want to give out a P2SH address (presumably because you want multisig security or segwit?), just upgrade your wallet to software that supports said feature and create a new address.

  Also will the balance of the p2pkh address carry over to p2sh address?

No, addresses don't have balances.


How to pass parameters for multisignature addresses from Perl to the JSON::RPC::Client?

The ["key,"key"] part of the documentation means that it expects an array.

You need to call it like this:

$obj = {method  => 'createmultisig', params => [2, ["$key1", "$key2"]],};
$res = $client->call($uri, $obj);


Are bitcoins “stored” on phones? Or we only see data on the blockchain?

You're right, your wallet is only holding your private keys and tracking the unspent transaction outputs that you're able to sign for. The UTXOs are also tracked by every full node on the network, which have digested the complete transactional history of the network to learn exactly which pieces of the currency are currently available for spending.
As long as you maintain control of the private keys, you can regenerate the information of the spendable balance from the publicly available ledger.


Where did https://launchpad.net/~bitcoin/+archive/bitcoin just install to?

Just as all applications you install using Aptitude (apt-get), it is installed somewhere in a /usr subdirectory. However, where exactly doesn't matter because you can run those programs just by typing them in the command line.

Thus, you can launch them by typing in your Terminal either bitcoind for the server daemon or bitcoin-qt for the GUI Wallet. Also, most desktop manager automatically place a shortcut for all apps in their app menu; for Ubuntu Unity, you can just type "bitcoin" in your Dash to find Bitcoin-Qt GUI wallet app.

Just as most apps, it makes a folder in your home directory to save the data it uses. Both bitcoind and bitcoin-qt save all the block chain data in a ~/.bitcoin/ folder. You wallet is thus saved in ~/.bitcoin/wallet.dat.


How to complete install of bitcoin-0.17.1 on linux (fedora 29)

After extraction files from the tar ball you have to install the contents of its bin subdirectory into the /usr/local/bin directory using the the install command. The install command is part of the GNU coreutils available on nearly every Linux distribution, and the /usr/local/bin directory is a standard location for self-installed executables (you may edit the commands below to use a different location).

If you use sudo to run commands as root, use the following command line:

sudo install -m 0755 -o root -g root -t /usr/local/bin bitcoin-0.14.2/bin/*

If you use su to run commands as root, use the following command line:

su -c 'install -m 0755 -o root -g root -t /usr/local/bin bitcoin-0.14.2/bin/*'

See reference here

You can then just run bitcoin-qt to startup the GUI


Update (or is it an upgrade?) from 12.0 to 13.2

Ok it seems you are running on Debian Jessie. No you cannot simply do sudo apt-get .... You can either download the binaries from somewhere, or you can build the binaries from source. I personally would advise you to build the application from source, as it is a great learning exercise. It is also safer in principle to personally ensure the program you are running is really tied to the open source code which has been released.

One of the difficulties of building bitcoin core from source is to make sure all dependencies are correctly installed first. In particular, if you want to use a wallet as part of the software you need to build the Berkeley Database version 4.8.30.

Download the file db-4.8.30.NC.tar.gz from this page. Check the hash of the downloaded file:

$ sha256sum db-4.8.30.NC.tar.gz
12edc0df75bf9abd7f82f821795bcee50f42cb2e5f76a6a281b85732798364ef

Then uncompressed the archive:

$ tar -xvf db-4.8.30.NC.tar.gz

Before stepping inside the newly created directory, create a directory db4 for the sake of installing the Berkeley database:

$ BDB_PREFIX="$(pwd)/db4"
$ mkdir $BDB_PREFIX

So we can now build the Berkeley database as follows:

$ cd db-4.8.30.NC/build_unix
$ ../dist/configure --enable-cxx \
                    --disable-shared \
                    --with-pic \
                    --prefix=$BDB_PREFIX
$ make install

Note that make install does not require super user rights, since the project is configured with a --prefix option which means the binaries
are installed in a file system hierarchy which you own. Once make install terminates, you can check that your db4 directory has been duly set up with bin docs include and lib sub-directories.

Having installed the Berkeley database, you can now focus on building bitcoin core (and its other dependencies which are easier to install). First install the official bitcoin source repository:

$ git clone https://github.com/bitcoin/bitcoin.git

Then move to the bitcoin directory:

$ cd bitcoin

Check the available version tags:

$ git tag

Synchronize your local code with the version you want:

$ git checkout v0.13.2

From this point on, everything is explained in the file doc/build-unix.md I am repeating things here for emphasis, as it may bring light on a few points, but this post will be out of date soon and you should really refer to doc/build-unix.

Add the following line to your file /etc/apt/sources.list with the right mirror:

deb http://[mirror]/debian oldstable main

Then:

$ sudo apt-get update

Then install the packages described in doc/build-unix.md (build requirement). When it comes to boost, hopefully the debian repository version is enough:

$ sudo apt-get install libboost-all-dev

As indicated in the file, also install these packages:

$ sudo apt-get install libminiupnpc-dev

$ sudo apt-get install libzmq3-dev

At this stage, you need to install the GUI dependencies as per file.

Once this is done you can start the build. However, you will need to refer to your db4 directory created while building the Berkeley database version 4.8.30. The simplest option is to create a link:

$ ln -s ~/path-to/db4 db4

Then the build can start:

$ ./autogen.sh
$ ./configure LDFLAGS="-L/path-to/bitcoin/db4/lib/" \
              CPPFLAGS="-I/path-to/bitcoin/db4/include/"
$ make
$ make check
$ sudo make install

Your software should be installed now, and you can check this is the case:

$ which bitcoind
$ which bitcoin-qt
$ which bitcoin-cli

Note: since you already have v0.12.0 running, you should have a directory ~/.bitcoin with your config file, debug file, wallet file,  blockchain data etc. Your new installed version should pick things up from there (in particular you will not need to sync the blockchain again).


Running a public pool comes with the obligation to understand the underlying asset.

Rublik seems to have own proprietary software.

To run a public pool you at least need the following:

Knowledge of linux system administration/security.
A dedicated server.
A coder to write/edit a frontend, reward structure and payout process.
Of course the pool software.

Expect if you run a puplic pool to deal with system exploitation and Ddos.

There is opensource pool software available. However, most are outdated, open exploits or other issues. Either code your own, improve existing software or do DD on maintained software (eloipool by luke-jr --> IRC freenode #eligius for example is maintained).

Just a hint:
https://www.google.com/search?q=bitcoin+pool+software&ie=UTF-8&sa=Search&channel=fe&client=browser-ubuntu&hl=en

There are opensource frontends too but those available last i checked are no out of the box solutions.

Even if you get that far you will face the task to create a reward structure with automatic payout process.

To underline that again: 90% of available opensource software needs workovers, some aren’t maintained for over a year, you hardly will find outofthebox solutions for free.


Watch a BitCoin account for incoming payments

You need a server which indexes by address. Libbitcoin-server provides this index. All tx’s to or from an address of interest will trigger a notification to your subscribing client.

https://github.com/libbitcoin/libbitcoin-server/wiki

Of course you can always build your own address index.


Why did Bitcoin Core switch from wallet.dat, cold.dat, lukewarm.dat, etc., into "sub-dirs"?

The original move to a directory per wallet file was motivated due to an issue with the way Berkeley DB behaved when multiple databases were opened in the same database environment, which are tied to directories containing the database. In particular, the issue is that BDB creates a database environment log which contains data from all of the databases open. This creates issues with backing up and portability as database logs need to be backed up as well.
With the transition away from BDB to SQLite, it is possible that we move back to the old way. However current discussions around that seem to indicate that that move is unlikely.l


Derive the bech32 address from the transaction 'txinwitness' witness data in Bitcoin Core 0.16

I'm trying to extract the bech32 address associated to an input or output using the txinwitness field included in every pure SegWit transaction.

This is not entirely possible unless you're willing to make assumptions that will almost certainly break in the future.  The problem is that part of the data contained in a segwit address is not part of the txinwitness field---specifically, the witness program number that allows upgrading segwit to new script rules in the future is included only in the scriptPubKey of the output being spent.

That means, to be safe, you need to use an RPC like getrawtransaction with the transaction index enabled to retrieve the output being spent in order to get the address.  This is unfortunately slow if you need this information for a lot of inputs.

The unsafe assumption you can make is that the witness program number is 0, as is the case with all standard segwit transactions right now.  Then you can just hash the final entry in the txinwitness per the BIP141 rules, prefix its length (either 0x14 or 0x20), and prefix 0x00 to indicate it's witness program 0.  But if you make that assumption, you will print the wrong address for transactions that use a different witness program number in the future, which could cause users of your system to lose money, so I highly recommend against that.


What new transactions are possible with 15 operations?

It's not exactly "15 operations"...

The Bitcoin address is not really a public key, but a special script that is built from special commands. From those commands you could build really weird transactions, for example the ones mentioned here, that lock funds on an address that can be accessed only if someone manages to break SHA2.

Up until now the miners treated anything besides the basic four or so script kinds as non-standard. It meant that you could add them to the blockchain (because they are valid), but only if you mine them yourself, or convince one of the pools to add them to the block.

Thanks to the relaxed rules, you will be able to create transactions that are redeemable by almost any script built from commands listed here: https://en.bitcoin.it/wiki/Script . As long as they don't contain more than 15 signature checks.

The biggest potential use case for this is probably in oracles / smart contracts, as explained in Gavin's bit-thereum post. Our project - Orisi / Distributed Oracles is right now the only practical implementation of this concept, and it's described in detail in our white paper ( https://github.com/orisi/wiki/wiki/Orisi-White-Paper ). We may be using the extended scripts to perform a 1+M of N multisig check - that is to require a signature of both the transaction sender, and M of N oracles protecting the transaciton. If this explaination is not clear enough, you might want to check our website.

Finally, as for this functionality's ETA - it might appear in the next minor update, but that will happen probably in a few months time.


Do HTLC transactions work today or do they need a new soft-fork?

Both hash locks and time locks exist in bitcoin today.

It looks like the BIP in question relates to wallet support and HTLC transaction structure, rather than changes to bitcoin's opcodes.


How do the JavaScript SecureRandom() vulnerabilities affect me?

What products are effected by these vulnerabilties?

-- Not Sure specific products, but watch out for products(wallets) using javascript lib to generate private keys.

As a user of these products, what should I do to make myself no longer vulnerable?

-- you should immediately move your funds to new addresses, make sure new wallet does not suffer from this known vulnerability.


You need 9X of the 6-pin PCI-e connections to make this work with your miner.  You need about 1350 watts for this to account for the ±10% requirements for nominal running, perhaps more if you plan to overclock it.  They also say not to run it with more than one PSU per board, that may be tricky, because I would have normally said to perhaps get a three CX750s to run or perhaps my juggernaut Evo 1500ewt. If you’re interested I’ve got a couple laying around.  Despite that… you would still need another one as my own PSU only has six available 20A connections.

As @murch points out, if you have 1300 watts per device that means you have at least 450 with zero headroom. So if you split it, you need at least 500 watts with the proper headroom without considering overclocking all the way.


BitPay just payment processor. As buyer in stores you need own only bitcoins in any wallet, exchange or other places. When you make payment to this store, you will need send btc from your wallet or an exchange

In your case BitPay probably help to the store make immediately exchange your btc into usd


How are block rewards claimed in merged mining?

The point of mining is to secure the blockchain. Before you mine, you must compose the block you are trying to find a nonce for. That block will include a transaction to pay you.

If you are merged mining Bitcoin and Namecoin, you do the following:

1) You compose the Namecoin block you are trying to find a nonce for. This includes a transaction to pay you the finder's fee.

2) You compose the Bitcoin block you are trying to find a nonce for. This includes a transaction to pay you the finder's fee and a transaction to secure the Namecoin block.

3) Now you try to find a nonce. If it meets the Bitcoin difficulty, you've mined a Bitcoin block. If it meets the Namecoin difficulty, you've mined a Namecoin block.

You submit a Bitcoin block the normal way. The information from the Namecoin block is ignored by the Bitcoin system.

You submit a Namecoin block along with enough information from the Bitcoin block and Merkle tree to prove that the nonce secures the Namecoin block.


How many transactions have been included into the blockchain?

As of block 210000, the total number of transactions in the chain is 9344662.

Version 0.8 of the reference client keeps track of this number, and reports it for every connected block in debug.log. I just copied the number from the debug.log of a node running pre-release code.


Why isn’t connecting to your own local node a common feature for Bitcoin clients?

This is not an issue related to Bitcoin itself. Rather this is due to the protocols that clients use to communicate and the specific client implementations.

Electrum has defined their own protocol independent of commonly used node software. In order to serve Electrum clients, Electrum servers (nodes with software that can speak the Electrum protocol) have to also maintain more data than just nodes do which requires more computation and storage. Because this information is not readily available to all nodes, Electrum clients can only connect to these special Electrum servers.

You can operate an Electrum server yourself, it is just another piece of software to run. However only people who really know what they're doing and have the hardware necessary to run an Electrum server do so. By running your own Electrum server, you can configure your Electrum client to connect to your own Electrum server (and thus your own node).

The other commonly used protocol is BIP 37. Many clients that use the BIP 37 protocol actually do allow you to connect to your own node. However they typically also connect to many other nodes as well. BIP 37 has various issues and is being phased out in favor of BIP 157/158 Client Side Filtering.

Both BIP 37 and BIP 157/158 allow for clients to configure and connect to users' own nodes. It is just up to the specific clients themselves to allow users to configure this.


Well, all transaction between Bitcoin addresses are stored forever, and so are fully traceable. What this means in your case is indeed that the credit card company can trace the coins you bought from them.

However, there are a few things to note.

Bitcoin addresses don't have a name assigned. F.e. Bitstamp will not know that the Bitcoins are coming from the credit card company because the credit card company does not have a list with all the addresses they use. An exception would be when you used a green address. This also holds in the opposite way that the credit card company does not know you funded Bitstamp with the coins since they don't know that the address you sent the coins to is owned by Bitstamp.
Bitcoins can move around very fast. When your coins end up somewhere the credit card company can link some person to, it is very likely that they are not spend by you anymore. With as few as 2 hops, the coins could have gone through an exchange and ended up by a totally different person.
The Bitcoin change system gives you better privacy as well. When you only spend a part of the Bitcoins in an address, by default, the change - which is the part that is not spent - is send to a new address. So, when you are spending some coins at different places, the coins you still have yourself also made several hops, so it is hard to tell if they are still in your possession.

Then, when you really want to make sure people cannot trace transactions back to you, you could use Bitcoin laundry systems. These are services that take your coins, shuffle them around among many different addresses they own, and let you receive the coins - minus the commission they take - back at another address for you. When you use a sophisticated Bitcoin laundry service, it is practically impossible to trace your coins. But beware, when dealing with very large amounts of bitcoins, this will be harder to achieve. Consider laundring your coins in smaller chunks.


How to handle multiple inflight transactions from same address?

Addresses are a construct of wallets. The bitcoin system itself doesn't know or care about them.  Coins being spent are identified by their creating txid and output-index.

The network verifies that the provided signature is accepted by the required scriptPubKey, but the scriptPubKey (nor the addresses that wallets map to scriptPubKeys) is never used to lookup or in any way reference the coins being spent.

The model you seem to be imagining is more like some other altcoins and can indeed have poor ergonomics.

Normally change goes to a new address and those coins can be immediately spent without waiting for the first transaction to confirm.  It sounds like from your question that you might have thought the change could not be spent before the transaction creating it was confirmed, but this is not the case.

I am not aware of any reason why reusing an old address for change would benefit a user, but the system will let you do it without it causing any problems.

In Bitcoin for privacy and security reasons users are advised to avoid reusing addresses, but this doesn't have any interaction with the kinetics of spending coins.


Set a public node to auto forge / mine / stake in NXT / Ardor without login via the gui?

On your linux box you can type the following:

curl -d requestType=startForging -d secretPhrase="PASSPHRASE" http://localhost:7876/nxt

--

Without curl: wget -qO- 'http://localhost:7876/nxt?requestType=startForging&secretPhrase=sssecrrretPhPhPhphrrrassssse'

https://nxtwiki.org/wiki/The_Nxt_API#Start_.2F_Stop_.2F_Get_Forging

You can use startForging, stopForging or getForging in order to start forging with an account, stop forging, or check that an account is forging.


If Bitcoin transactions require ~10 min to clear, how can payments get recognized within seconds?

When you create a transaction, your Bitcoin wallet broadcasts it to a few full nodes on the Bitcoin peer-to-peer network.  Those full nodes quickly relay it to other full nodes, and it eventually ends up at the full nodes run by the sites you linked to.  That's how those sites know the transaction exists.

The full nodes also relay the transaction to Bitcoin miners.  Each miner may choose to include your transaction in a block of transactions.  (Miners usually choose to include the transactions that pay the highest transaction fees per kilobyte of transaction data.)

Miners have to solve a sort-of random puzzle---whichever miner solves it first can include proof they solved the puzzle in their block of transactions and send that block to full nodes.  Those full nodes relay the block to other full nodes and eventually the block ends up at the full nodes run by the sites you linked to (and to the wallet of the person you paid).

The puzzles are very hard to solve, so a block with proof of a solved puzzle is hard to fake.  This means any transactions in that block are considered hard to undo.  Also, the next block has to point to the previous block, so it would then require solving two very hard puzzles to undo the transactions in the block containing your transactions.  And it keeps getting harder and harder each time a new block is created.

As you may have guessed, it takes an average of about 10 minutes of puzzle-solving by all miners before any particular miner solves a puzzle, so it takes about 10 minutes on average for a transaction to be protected.  Up until that point, you could create a duplicate transaction that steals back the money you spent---so nobody trusts high-value transactions until they appear in at least one block (and more blocks are better).

P.S. Newbie questions are always welcome!


How can I convert a wallet.aes.json file from Blockchain.info to a wallet.dat file?

The way I go about it is as follows:

Login to Blockchain.info and choose export
Export data as BITCOIN QT
Note the private key in the form 5Hxxxx or 5Kxxxx or 5Lxxxxx. Copy and paste this string (or hand write it to be safer; it's case sensitive and has no 0/O, l/I)
Open Bitcoin QT; click help>Console
Type importprivkey PRIVKEY NAME where PRIVKEY is what was copied and pasted and name is the name for the address eg MAIN1
If wallet.dat is encrypted you'll need to type: walletpassphrase PASSWORD 180
Be sure to encrypt your wallet again
Move funds from Blockchain wallets to a new address in case you're concerned about malware monitoring copy/paste


To get started I'd recommend you familiarize yourself with the JSON-RPC API that is built-in with bitcoin-core (https://en.bitcoin.it/wiki/API_reference_(JSON-RPC)).
Once you have installed bitcoin you need to configure it. You do this by creating a bitcoin.conf file and setting our options inside of it.
Create a new file in your text editor and make sure you have a RPC username/password and activate the daemon by setting it to 1.
rpcuser=someusername
rpcpassword=somepassword
daemon=1

Save your text file as bitcoin.conf in your /bitcoin directory. You may need to do sudo apt-get update first. Bitcoin will be installed in ~/.bitcoin
You should now be able to execute bitcoind and let it sync with the network. Navigate to your bitcoin directory and type in bitcoind in your shell.
bitcoind

Give it a few minutes to start syncing but you can verify the status of your node by typing
bitcoin-cli getblockchaininfo

Now you need to wait for the syncing to finish.
If you check the bitcoin wiki JSON-RPC page you will see references for many different languages. The library recommended for PHP is the EasyBitcoinPHPLibarary. The easiest way to get the library is to visit the GitHub page (https://github.com/aceat64/EasyBitcoin-PHP)
The easybitcoin library makes cURL requests to bitcoind's JSON-RPC 8332 port.
Copy the contents of the easybitcoin.php and save it as a new php file called easybitcoin.php. Make sure you place this file in your web server directory as you will need to require(); it in you PHP code.
Now you can start making calls to your bitcoind server through PHP, for example to get the balance of your node...
<?php
require("easybitcoin.php");
$bitcoin = new Bitcoin("someusername", "somepassword");
$balance = $bitcoin->getbalance();
print_r($balance);
?>

You can also create new addresses, by changing getbalance() in the above example to getnewaddress();. If you want to add a label for this new address just include it in the parenthesis.
$info = $bitcoin->getnewaddress("Nakamoto");

You will see a brand new bitcoin address that has been added to your node and can start accepting transactions.


Does the BerkeleyDB-based wallet.dat implementation leak private key data?

If you are using an encrypted wallet, private keys are never written unencrypted to disk.

However, the 0.4.0 release (the first to feature wallet encryption) had a bug where - upon upgrading a wallet from unencrypted to encrypted - parts of the unencrypted where not necessarily overwritten, leaving them accessible for a while.

0.4.1 and 0.5.0 fix this by first rewriting the entire wallet file upon encryption (or the first start afterwards), and invalidating the entire pool of reserve keys that was present before. This means (and has been tested), that if you start with an empty wallet, and immediately encrypt it, it will not ever use any key that was ever written to disk in unencrypted form.

Note that wallet encryption is not a silver bullet, and an attacker may have other ways of extracting the private key, such as keyloggers.

EDIT: only now I read your question correctly. The log files may contain anything that was attempted to be written to the database files themselves, and if you are using (or were using) an unencrypted wallet, that may indeed mean private keys as well. Again, if you start with an encrypted wallet in 0.5.0, no keys will be used that ever touched disk unencrypted.


How to keep my shares when moving a pool server?

If you're the only person using the pool server, it doesn't matter how many shares you have -- all the profits are yours. Who would you be sharing them with?


PlexCard Visa : Would it be legal all around the world?

VISA and MasterCard cards are issued by banks all over the world, that have a valid license. It's not the first time we see cryptocurrency based VISA card. Those cards can be used in every shop (online or physical) that accepts VISA cards.

If this PlexCard VISA card is issued by a bank that has a valid license to issue VISA cards, then the card will be legally accepted wherever VISA cards are accepted.

As for the second question (fast transaction confirmation time), I don't know about PlexCoin but there are other coins with near instant confirmation times, that are using techniques like faster block time and/or MasterNodes.


Why can't we expire two year old transactions?

One big reason against this sort of thing is that it creates a huge incentive for bad people to try to prevent you to do transactions (censor you).

If miners get the "lost" bitcoins they might simply refuse transactions with coins that are almost expired hoping to get a bigger reward later.
If miners don't get them but they are truly lost forever, then there is an incentive for big stakeholders to try to do the same thing: less coins means the value of everyone else's coins goes up.
It gives governments and other mafia huge power: don't want to comply? We'll just lock you up for 2 years and make your coins expire. Or more "humanely" use other censorship tricks (hacking/digital censoring) to prevent you from spending your coins before they expire.

Another reason is that people will en mass set up automated scripts to move all their coins regularly, which is a big security (and privacy) risk. It's much easier to keep private keys safe (on a piece of paper in a vault) than it is to keep an internet connected system powered up and safe 24/7.


What prevents broadcasting of fraudulent transactions

Validation.

You can totally broadcast a fraudulent transaction, but nodes in the network will ignore it as it is invalid.

Furthermore, nodes will also ignore any blockchain which contains any fraudulent transaction. As a result, miners are financially disincentivized from doing so.


Once the connection is established, the communication is completely symmetric-- either end can ask the other anything.


I want to start mining new blockchain (exactly as Satoshi did in 2009) for testing purpose

First, create a directory to store your blocks and configuration:

$ mkdir mybitcoindir
$ cd mybitcoindir

next, you need to create a conf file called bitcoin.conf that has this in it:

checkpoints=0
connect=0.0.0.0
daemon=1
discover=0
dnsseed=0
gen=1
irc=0
keypool=5
listen=0
port=19002
rpcpassword=test123
rpcport=19003
rpcuser=test
upnp=0

Now start up your bitcoin daemon

$ bitcoind -datadir=mybitcoindir

You should have no outbound connections

$ bitcoin-cli -datadir=mybitcoindir getpeerinfo
[
]

Now you can generate coins

$ bitcoin-cli -datadir=mybitcoindir setgenerate true

Note even with the difficulty at 1, generating coins off of a single CPU can take a while. Expect it to take a few hours to find your first block. You're better off getting a really cheap USB miner as they can find about 2-3 blocks at difficulty 1 every minute. But that, of course, requires a bunch of setup as well.

Best of luck.


Where is the bitcoin automatic address generation?

The standard Bitcoin software up to version 0.4.x had a GUI based on wxWidgets rather than QT. For version 0.5 it was merged with the then-separate bitcoin-qt.

The older version allowed you to select an address to be displayed in the overview. If you received funds to an address while it is selected, Bitcoin would automatically generate a new address.

I don't believe this functionality still exists in the QT version. It does however still generate new addresses for change.


What mistakes do first time contributors to Bitcoin Core often make?

The most common mistakes I have seen first time contributors make (and this includes me) is:

Not opening the PR from a topic branch of the forked Bitcoin Core repo and instead opening it from the master branch of the forked Bitcoin Core repo

Not adding the correct label at the start of the title of the PR
e.g. doc: Address typo in file X

Not squashing commits when there is no need for multiple commits

Opening a PR for individual typos without running the linter and finding additional typos
e.g. ./test/lint/lint-spelling.sh

Opening a PR for individual typos but not updating test/lint/lint-spelling.ignore-words.txt to ignore false positives identified from running the linter.


Has anyone tried arbitrage between exchahges?

Yes and still at it full time. I have created a monitor that calculates the spread in % between several exchanges. Sometimes we see 25% spread! Those are the moments and getting fiat back from one exchange to another is bottleneck.


What would happen if mining difficulty would be decreased to almost nothing?

The mining difficulty adjusts according to a specific algorithm. The difficulty adjusts such that, regardless the hashrate, the average time between blocks is approximately 10 minutes. The difficulty also only adjusts when there are changes to hashrate. As miners go offline, it will adjust down to become easier to mine. As miners come online, it will adjust up to become harder.
So in this scenario, a lot of miners will have gone offline and the difficulty adjusted down. This has no effect on the rate that blocks are produced, so this has no effect on the issuance of Bitcoin nor the time it takes for transactions to become confirmed.
What it does have an effect on is the security of Bitcoin. The immutability of the blockchain comes from the fact that it is hard to rewrite the blockchain. It comes from the fact that in order to change blocks in the blockchain, the same amount of work must be done. With a lower difficulty, the amount of work done on each block is lower, so the amount of work required to change that block is lower. Thus with a lower difficulty, it becomes easier for an attacker to change the blockchain and perform 51% attacks.

In a scenario where someone can snap their fingers and magically cause the difficulty to change, the effects would of such a change would be extremely bad. It wouldn't magically cause hashrate to go offline, rather they would stay online at a lower difficulty. This would mean that blocks are found way faster which greatly increases the risk and likelihood of stale blocks. This would, in general, not be good for Bitcoin. Since the difficulty is magically lower, more people would probably start mining because it is easier for them to make money when the difficulty is low. Additionally, the difficulty would just eventually adjust back up to where it is.

It is important to keep in mind that the difficulty has an effect on miners, and that miners have an effect on difficulty. When the difficulty is low, more miners will come online because it is easier and thus more profitable to mine. As more miners come online, the difficulty will increase. Eventually, the difficulty will reach a point where miners go offline because it is now harder to mine so mining is less profitable. So then the difficulty will drop. This will form an equilibrium.


What would happen if there were no full nodes?

Full nodes are more useful than simply for block propagation, and miners are not the only type of user on the Bitcoin network that benefits from validating the whole blockchain themselves.  I would argue that anyone who wants to ensure they aren't being tricked should be running a full node, such that they can be truly trustless.  This group should probably included exchanges, merchants, and even individual users (to some extent).

As for your question about what would happen...well...nothing.  The miner would find a valid hash for a block, and then propagate it to nobody.  Nobody would check it against their blockchain, and nobody would pass it on other nodes (of which there are none).  SPV nodes wouldn't receive block headers, nor would anyone respond to their bloom-filtered requests for transaction updates.  There would be nobody to send them to.

Bitcoin is a network, which consists of nodes and paths.  When you take away the nodes, the paths cannot exist.  You are effectively asking "if there was no Bitcoin network, how would the Bitcoin network operate?"  Simple answer: it wouldn't.


You cannot accept or reject an order. When you place a sell order (for clarity's sake assume 1 BTC for 100 dollar) and there is no-one with a buy order above $100/BTC you end up in the list of buy orders. When someone thinks "hmm, that is a nice price to pay for a bitcoin" he can create a buy order for 1 BTC (or less) for $100/BTC. Cryptsy looks then if there is a sell order for that price (or lower) and his order will be filled, and you get your money. So if you leave an order open while you go away, it can be filled without you noticing it.

If you want more clarity about the filling of orders, you can look at my answer here.

edit: so if you want to close the deal immediately, buy (or sell) at a rate that there is a seller who sells at that rate. Otherwise the market can go up, and your bid will be missed out.


What is EUR to USD conversion rate at bitstamp?

I believe the EUR / USD conversions are preformed by the bank with which Bitstamp works. They have conversion rates which don't appear to be market-driven, but are set to a fixed rate that includes the bank's fees.

The exchange rates link provided on the website leads here:
http://www.raiffeisen.si/pripomocki/menjalniski-tecaj/


How exactly does BIP11 work, and how can it be used, particularly with/without P2SH?

I think the reason you might be getting confused is that there are really two types of multisig, raw multisig and P2SH (pay-to-script-hash) multisig. P2SH multisig is basically just hashing the actual scriptPubKey desired and putting the scriptPubKey in the scriptSig. This stack exchange questions explains them in more detail: What are the limits of m and n in m-of-n multisig addresses?.

  I'm also trying to understand if a 3 of 3 transaction is supported as well.

Yes, you can do m-of-3 multisig transactions with both raw multisig and P2SH multisig.

  the meaning of the parameters "2" in addmultisigaddress

The number provided is the m in the m-of-n. So if you want a 1-of-2, you do:

addmultisigaddress 1 '["1xy..", "1Jm..."]'

The BIP11 (accepted) proposal you mentioned just made raw multisig a standard type of transaction that is recognized and forwarded on by standard clients. BIP16 (https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki) proposes the P2SH addresses, which allow for much shorter scriptPubKeys and support more types of multisig (e.g. 5-of-9, which you can't easily do with raw multisig because m-of-n multisigs with n > 3 are considered non-standard, as shown in the link in the first paragraph).


Can I lose my Bitcoin.com wallet if the company and the website database are destroyed?

I have performed a few tests and it seems that the 12 word phrase is able to recover the wallet from any wallet client that supports this 12 word phrase method.

The 12-word is a human readable alias for a master key that links to each private key of a set of wallet.

I have installed Electrum which is a local client installed on Windows and it did successfully gain access to my Bitcoin.com wallet by using the 12-word phrase.

I deduce that these words are enough to recover my wallet even if Bitcoin.com falls down.

@Toomakesense: the question is not whether or not it is likely to happen but what would happen in case it is. Everything is possible even if it is unlikely!

Anyway thanks for your help


How to speed up initial block chain sync using SSD without wasting space?

Yes, it is possible to load the blockchain binary data off to a bulk storage (HDD), while keeping the Index DB on performant storage (SSD).
The Bitcoin Blocks are stored in the blocks subdirectory in your datadir. The location of your datadir is either %AppData%\BitCoin, or set manually by you during the installation of bitcoin-qt.

I ASSUME you're using BitCoin Core (aka bitcoin-qt) on Windows 7 or higher, C:\ being your SSD, F:\ being your HDD, bot formated as NTFS. The location of datadir is %AppData%\BitCoin\.

Move %AppData%\BitCoin\blocks to the HDD, e.g. to F:\BTC\blocks
OPTIONAL Move F:\BTC\blocks\index back to the SSD: %AppData%\BitCoin\index

NOTE: The blocks folder must not exist in %AppData%\BitCoin now!

Open a cmd window by pressing WIN+R, then type cmd and click ok
Type/Paste mklink /J %AppData%\BitCoin\blocks F:\BTC\blocks and hit ENTER. (This creates a NTFS Junction, creating a link in %AppData%\Bitcoin called blocks, pointing to the existing F:\BTC\blocks folder on the HDD)
OPTIONAL Type/Paste  mklink /J F:\BTC\blocks\index %AppData%\BitCoin\index and hit ENTER (Create new link at F:\BTC\blocks\index pointing to existing %AppData%\BitCoin\index)

Now, the blocks directory is on the HDD for cheap bulk storage, while its index subdirectory and parent datadir is on the speedy SSD. Only binary blockchain data is stored on HDD.

About the index directory (Steps 2, 4): As Pieter Wuille comments below, you don't really need to move the index directory within blocks back to SSD. But since it contains one of the databases, I figured it might help performance when starting up bitcoin-qt. [citation needed]

In my case, this Windows task manager shows read/write speeds 10 times higher than befode (20-30MB/s). Download speed did go up to 2-4MB/s (50MBit Internet), CPU load is up at 85%.

I didn't monitor blocks/second improvement, but the taskmanager values show better throughput of data, which should directly relate to more blocks per second. I synced 15 weeks of blockchain while writing this (30m), versus only 1 week before the modification!

The datadir without binary blockchain data is a little over 2GB, with 25 weeks worth of blockchain still missing. I'd recommend at least 5GB free space on the SSD for the currently 80GB big blockchain.


There is no algorithm for generating compressed pubkeys from private keys keys specifically.  In fact, all internal calculations involving points are done using the both the x and y coordinates of the points involved.  There is no other way to operate on points other than using the (x,y) coordinates.
A compressed representation of the point is useful in data transmission and storage because it only takes 33 bytes as opposed to 65 bytes to convey the point.  It's very easy to go from compressed -> uncompressed when the need arise to perform point related operations, and even easier to go from uncompressed -> compressed representation.
To answer your question, you would generate the public key as you normally would with an uncompressed pubkey, and when you're done, look for even-ness or odd-ness of the y corrdinate.
If it is even, encode only the x coordinate with a prefix 0x02 byte, and if it's odd the prefix is 0x03.
To go back from compressed -> uncompressed (really I just mean find the original y coordinate), you would just solve the curve's equation :

y^2 = x^3 + a*x + b

Specifically for secp256k1, the curve used in Bitcoin, a is zero, which makes this calculation easier, and there is a shortcut: due to a property of the curve's parameter p, where p ≡ 3 mod 4 we are able to derive the y coordinate from an x coordinate simply by calculating:

q = (p+1) * invmod(4)  mod p
y = powmod(y^2,q)      mod p

And there we have the original y coordinate back.


Are both CSV and nLocktime unnecessary in Eltoo?

Anthony Towns' recent draft uses CLTV, which also uses nLocktime.


Why was block # 289791 empty of any transactions?

This is the previous block,

289790
Number Of Transactions  86
Height  289790 (Main Chain)
Timestamp   2014-03-09 23:24:02
Size    43.853 KB

This is the block you are talking about

Number Of Transactions  1
Height  289791 (Main Chain)
Timestamp   2014-03-09 23:30:23
Size    0.183 KB

As you can see by the size of the previous block, there was little activity in that time, only 43 KBs worth of transactions, you can also note that both blocks came less than 5 minutes apart, so perhaps the transaction pool was emptied by the previous block and there wasn't enough time for a new transaction to be broadcasted after that. Since every minute counts, miners won't wait for a new transaction to appear because they run the risk to lose the block reward.


How can someone prevent a sybil attack when connecting through TOR?

Low-latency transmissions over Tor can be defeated with a timing attack if you're connected to several of the attacker's nodes and the attacker is watching your transmissions at your ISP.

The attacker can relay only blocks that he/she creates, putting you on a Bitcoin fork (separate from the main chain). After that you would be open to double-spending attacks.

Monitor the network hash rates closely. If they are unusually low then you should be careful you are not an a fork created by a sybil attacker, targeting Tor users.

https://en.bitcoin.it/wiki/Weaknesses#Sybil_attack

Potential deonimation of metadata is probably a larger threat than a sybil attack if you are waiting for multiple confirmations and monitoring network hash rates

http://arxiv.org/pdf/1410.6079.pdf

"Consider the following case. A client uses the same
computer for sending both benign Bitcoin transactions and
sensitive transaction. For benign transactions the user connects
to Bitcoin directly, but for sensitive transactions he forwards
his traffic through a chain of Tor relays or VPNs. If an attacker
implements the attack described in section III, all client’s
sensitive transactions with high probability will go through
attacker’s controlled nodes which will allow her to fingerprint
the user and record his transactions.
When the client later connects to the Bitcoin network
directly to send benign transactions, he will with some probability
choose an entry node controlled by the attacker (in
section V we show how to increase this probability). Once it
happens, the attacker can query the client for the fingerprint
and thus correlate his sensitive transactions with his IP address.
Note that even if the attacker is not implementing the complete
man-in-the-middle attack on Tor, but just injects Sybil peers
and Sybil hidden services he will be able to link many sensitive
transactions to the real IP addresses of the users."

The risk here can be limited by never accessing Bitcoin over Tor and clearnet from the same computer. Accessing Tor via a virtual machine over public WIFI can also help reduce your risk of being deanonymized.


Able to send 0.2BTC from old to new wallet w/o fee as of 2016?

0.2 BTC to myself without any fees and have a reasonable expectation of timely (within a few days ) processing?

There are no miners today who confirms free transactions.


I want to launch my own simple sidechain pegged to bitcoin for testing purposes. Can it be done?

The seminal whitepaper on sidechains, "Enabling Blockchain Innovations with Pegged Sidechains," describes modifying Bitcoin's Script to support simplified payment validation (SPV):

To use Bitcoin as the parent chain, an extension to script which can recognise and validate such SPV proofs would be required. At the very least, such proofs would need to be made compact enough to fit in a Bitcoin transaction. However, this is just a soft-forking change⁹, without effect on transactions which do not use the new features.
⁹A soft-forking change is a change which only imposes further restrictions on what is valid inside the chain.

However, this is for a "two-way peg."
For a so-called "federated peg," which does not require a modification to Bitcoin, see Appendix A of the whitepaper or circa 15 min. into Greg Maxwell's presentation.


gettxoutsetinfo will return the current supply in total_amount so it doesn't help. getblockstats doesn't return supply info for the block.

Bitcoinvisuals has the supply chart and you can move the cursor over the chart to know supply at any given date in past.

Since we know block rewards (new coins added to supply) and they are reduced to half after every 210,000 blocks, we can also write a simple script to know the supply at any given block:

def btcSupplyAtBlock(b):
    if b >= 33 * 210000:
        return 20999999.9769
    else:
        reward = 50e8
        supply = 0
        y = 210000
        while b > y - 1:
            supply = supply + y * reward
            reward = int(reward / 2.0)
            b = b - y
        supply = supply + b * reward
        return (supply + reward) / 1e8

if __name__ == "__main__":
    block = 1000000
    print(btcSupplyAtBlock(block))

Source: https://github.com/ndsvw/Bitcoin-Supply-Calculator

There are lot of third party APIs available like coinmetrics to achieve the same.

In 3 the script will not include lot of exceptions mentioned in this answer by sipa: https://bitcoin.stackexchange.com/a/38998/


Can I change the bitcoin block-data directory from /home/user/.bitcoin/blocks to something else?

Did you make the files in the .bitcoin/blocks/ directory readable for Abe? You can test this by logging in as Abe (sudo su abeuser should suffice) and typing strings ~daemonuser/.bitcoin/blocks/any.file.


Blockchain.info has a service to list all the transactions which involve a bitcoin addresses generated using a given xpub.How does this work?

BIP-44 specifies a limit to how a wallet should look for public keys. The implementation should consider there's no address with funds beyond 20 addresses without funds.


This probably happened because you updated your node version after your installation of bcoin. You need to recompile the C++ bindings for the leveldown module to fix this. Checkout npm rebuild: https://docs.npmjs.com/cli/rebuild


So far as I know, most store owners just rent floor space to a company that operates the Bitcoin "ATM". The store owner gets fixed monthly rental income and doesn't have to get involved in Bitcoin transactions themselves.

You don't need to invest in the "ATM". Just rent some floor space with power. I would expect the ATM operator (not the store owner) to arrange for Internet connectivity, but that's probably just a business negotiation.

One way to find a local Bitcoin kiosk operator is to search the map at https://coinatmradar.com/ - the operator's name is shown at the top when you click on a kiosk location after zooming in to an individual kiosk location.

As Wikipedia notes:

"Bitcoin machines are not ATMs in the traditional sense". A better phrase might be "Bitcoin kiosk" or "Cryptocurrency kiosk" since they generally deal with one or two altcoins too.

"According to Coin ATM Radar, there are more than 800 Bitcoin ATMs in the United States as of 2017, with small shop owners earning a reported $300 a month for rental space." (my emphasis)


What roles has the TIME information play in the bitcoin header?

the time feature really doesn't play a role in the broadcasting of two simultaneously mined blocks. Those are just handled through broadcasting effect, forking and subsequent blocks mined. Time is started from the moment the miner began hashing to solve the POW. Its used to know how long it took in comparison with recent blocks found for the difficulty re-targeting calculation. It also serves as a record to know when a block was mined.


Block explorer with testnet raw hex data

Maybe too late, but here's an example of using Blockr.io on testnet with raw hex dump:

http://tbtc.blockr.io/api/v1/tx/raw/5bb4f41ad7ac687db5126cb66a4971100f4137a3056d85ee27343ce429dbe4bb


Coinbase has the address of a bitcoin stored on a blockchain account. How do I access it?

I assume you mean that you have a a blockchain.info/.com wallet.
You will have to log into the wallet and initiate a transaction.
If you cannot do that, and you do not have a wallet backup, then you are likely out of luck, the coins would be effectively lost.
You could attempt to contact their customer service to see if they can somehow let you log into the account.


What is the "Bitcoin Address" for standard multisig transaction?

A standard multisig transaction does not have a bitcoin address. This is precisely why it is wrapped as the redeem script of a P2SH bitcoin address.

Raw multisig transactions are not used anymore.


How to transfer funds from Bitstamp to a personal wallet?

Are you asking what option lets you withdraw from BitSTAMP?

Across the top menu is Withdraw, and from there pick Bitcoin as the withdrawal method, which gives this link:

https://www.bitstamp.net/account/withdraw/bitcoin/

Now if you are asking where to withdraw your coins to, then that's a different question.  There is not just one answer because various options regarding security will determine the best way to proceed.

If you are looking to store them for a long time, then a paper wallet, generated from an offline computer using a LiveOS might be the right recommendation.

Armory is another client that can be used offline and be very secure for storing bitcoins.

Or perhaps storing the funds using a hyrbrid EWallet, like the one from Blockchain.info/wallet is a good method because it provides a good tradeoff between convenience and security.

Others feel their coins are safe in a hosted (shared) EWallet provider like Coinbase, Paytunia or prefer to leave funds at an exchange even.  If the exchange has two-factor authentication (done properly) that will help prevent the situation where even if your computer is compromised you EWallet account is not at risk of a replay attack.

Others want to run a full Bitcoin.org client themselves.  This is an undertaking as initial startup can take a day or longer to download the blockchain.  A future release of the Bitcoin.org client will make this initial and ongoing performance issue be much less of a burden.  Other clients, Simplified Payment Verification (SPV) clients, such as Multibit.

http://bitcoinmagazine.net/bitcoin-wallet-options
http://en.bitcoin.it/wiki/Mobile_Payment_Apps


Per the creator of BIP47 (Justus Ranvier), it's RFC2014 notation:

https://en.wikipedia.org/wiki/Hash-based_message_authentication_code#Definition_.28from_RFC_2104.29

https://tools.ietf.org/html/rfc2104


The process to decrypt a password protected .key file exported using MultiBit is explained here: https://github.com/jim618/multibit/wiki/Export%20and%20limited%20import%20of%20private%20keys

To decrypt a MultiBit private key export file use:

openssl enc -d -p -aes-256-cbc -a -in \<ciphertext file\> -out \<plaintext file\> -pass pass:\<password\>


Transactions in a shorter blockchain branch

The transactions on the sort - or orphaned - branch are not considered confirmed. They are considered never having happened at all and are returned to the mempool, unless they were also included on the other, de facto branch.

Any bitcoins mined in an orphan block is never considered to having existed in the first place, to be able to be considered 'lost'. All the effort and electricity spent mining an orphan block is literally wasted.

There's a risk of double spend for every merchant or recipient of a transaction who didn't wait enough time to see the transaction confirmed in a block and several successive blocks. If he or she accepts a transaction in a block A, then delivers the product sold, the another transaction with the same input but other output is included in block B, then block A get orphaned, the merchant delivered the product and didn't receive the money. He or she can contact the buyer to settle this somehow, but that's the definition of a double spend.


There are two major issues when it comes to the adoption of payment channels in Bitcoin. Firstly, we have an interoperability issue, where the implementation of payment channels in one wallet may not necessarily be compatible with the implementation of payment channels in another wallet. Even if interoperability is resolved, there is still an issue with security, how do we safely communicate the parameters required to setup the payment channels between two independent wallets in a trust-less manner?

Secondly, a Jeremy Spillman style payment channel involving one consumer and one producer is still vulnerable to transaction malleability depending on how patient our hypothetical wallet user is. If the usual 6 block confirmation recommendation is adopted, there is a low chance that transaction malleability may affect the service provider of the payment channel. However, if the service provider starts providing services by accepting an unconfirmed commitment transaction to fund the payment channel, the transaction malleability exploit can be used to invalidate all subsequent payment transactions as the consumer of the service can simply mutate her sigScript for the commitment transaction, resulting in a different transaction hash. However, this is only achievable when there's a fork in the blockchain and the mutated transaction has been committed in the winning chain or when the commitment transaction is unconfirmed and the mutated transaction was committed instead of the original transaction.


What is the most expensive part of mining?

Is the solving aspect of the hash the most expensive part, for the
  computer? Or is gathering the transactions and confirming them more
  expensive?

Finding the nonce that produces the correct hash is by far the most computationally expensive part.

  How does one confirm the transactions? Do they have to traverse the
  entire blockchain, or only find the most recent ledger which shows
  both user's balances to confirm?

The blockchain is the only bitcoin ledger. One confirms transactions by confirming each of them. To confirm a transaction is valid it must satisfy certain rules. One of these rules is that each of transaction's inputs must be correctly signed.

Transaction's input comes from an output of some previous transactions. Bitcoin node that wants to validate the transaction maintains a list of all unspent previous transactions (this list updates regularly and contains only small part of the blockchain), so it can easily find the output that the current transaction's input points to. The output must be in this list of unspent transaction's. An output has all information to verify respective input's digital signature.

So the node that checks the block, makes the above input verification for each input of each transaction.


You need to enclose the filename in quotes.
eg:
dumpwallet "C:\output.txt"

As opposed to:
dumpwallet C:\output.txt      (wrong)


What is the difference between BFT and PBFT

BFT is a class of problems where a group of nodes needs to find consensus, where some of the nodes may be malicious. PBFT is an algorithm that generates consensus in one of those environments (specifically with signed messages and partially sychronous network). An good writeup is here: https://medium.com/s/story/lets-take-a-crack-at-understanding-distributed-consensus-dad23d0dc95


How do I get old blocks while running a pruned node?

This is a great question and something I've wondered myself. Since you mentioned JS, I implemented this on a branch of bcoin: https://github.com/pinheadmz/bcoin/commit/ec1f5c95bb76f86aa034ec5a288fc09dd15d9597

$ bcoin --prune --daemon

$ bcoin-cli rpc getblockchaininfo
{
  ...
  "pruneheight": 10823
}

$ bcoin-cli block 1000
{
  "hash": "00000000c937983704a73af28acdec37b049d214adbda81d7e2a3dd146f6ed09",
  "height": 1000,
  "depth": 10112,
  ...

This is untested code and should not be used in production, but it does demonstrate a mechanism by which a pruned node (or maybe even SPV node or any application really) can use arbitrary getdata calls to retrieve full blocks from full nodes on the Bitcoin network.

See details about getdata in the protocol section of the wiki: https://en.bitcoin.it/wiki/Protocol_documentation#getdata

All you really need is a block's hash and a p2p connection to a full node.

In my implementation on bcoin, the headers are required to be downloaded which prevent the user from requesting a non-existent or invalid block. This implementation is dangerous because it breaks the model of the pruned node and does not attempt to validate the block when it is special-requested. It does not record the actual CoinView of the downloaded block and leaves the DB in a bad state that could cause issues if a big enough re-org happened that disconnected the block.

Disclaimers aside, what you're asking is definitely possible. You just need to be careful how you handle the data you retrieve from the network.

Also worth noting that requesting arbitrary blocks from peer is an important component of Neutrino light clients:

https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki


Why does Bitcoin block 526,591 have a 6.25 (instead of 12.5) block reward?

There is a maximum limit on the block reward which is 12.5 BTC but nothing prevents a miner from claiming less than 12.5 BTC. In fact, there have been times when miners forgot to claim any bitcoin at all (claimed 0 BTC), a very expensive mistake. This is probably a mistake from the miner, he could have certainly claimed more bitcoin.

As long as the block is valid, it will be accepted by the network, even if it's unfair for the miner. In practice, this means that the maximum supply of bitcoin is not 21 million BTC but 21 million BTC - unclaimed BTC by miners. People often see this difference by making the difference between sum(number_of_block_i * block_reward_of_block_i) and the total bitcoin counted from the UTXO set.


Only wait for confirmations, the transfer is fine.

Here you can see that have 0/6 confirmations at this time: https://live.blockcypher.com/btc/tx/1b8e3e8064d28e6728212169f1479c1b359a88452854844afa562de1e6d6d800/


How does Nano protect itself from transaction flooding attacks?

From the wiki page, each transaction will be required to do around 5 seconds of Proof of Work, which will only require around 1 microsecond to validate. This means that the attacker will waste a large amount of resources while the nodes waste a very small amount.


You will need to find an exchange that accepts your bank account or method of transferring from your account to the exchange.

A number of exchanges out there not personally sure which would accept your bank, but another option is Local Bitcoins

Here is the link for Iran https://localbitcoins.com/country/IR

UPDATE 1st June 2019: Local bitcoin is now banned due to new sanction.

Iranian can't use localbitcoin in Iran anymore but they can buy and sell here as an alternative:
https://www.keepchange.io/buy/bitcoin/IRR?


How to find your private key with your 12 Word Password Phrase and the depositing Address?

The 12 words encode a seed that can be used to derive bitcoin addresses. There are an infinite number of derivation paths you can take using any one seed, so knowing the right derivation path will be necessary to recover your funds.

A quick google search tells me Mycellium uses the BIP44 derivation path: m/44'/0'/0'/0

So you just need to find some software that allows you to specify the path being created, and point it to the correct one.

  I've been speaking with the Android developer and he's been discussing that I will need to keep creating new accounts and depositing coin to each new account so I can create a new account until I find the account with my bitcoins.

You most definitely do not need to send any bitcoin to any wallet you generate, in order to determine if it is the derivation path you are looking for. Upon being supplied the correct path, the wallet should show you your transaction history as per normal, as long as it is correctly synced with the network.


RPC call gettransaction does not work on bitcoin 0.10.2


How can a programmer contribute to the Bitcoin project?

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.


Mnemonics are the private key separated in 12 words which joined together in the very same order produces the private key

That is incorrect. A mnemonic represents an entropy that is passed to a PBKDF2 key-stretching function with 2048 rounds of hashing to generate a 512 bits seed. This seed then acts like a keychain that is used to generate different keys. Check the last section of the answer to see how private keys are generated from seed.

  How are mnemonics generated?

As said above, mnemonics are representation of entropy along with a checksum. First step involves making a decision as to how much entropy you consider safe for your operations. Assume, for now that you have decided on 128 bits of entropy. Below are the steps that you will follow to convert this entropy to mnemonic.

Use some cryptographically secure entropy generator to generate 128 bits of entropy.
Calculate the SHA256 of the entropy.
Append the first entropy_length/32 bits of the SHA256 of the entropy at the end of the entropy. For example, in our case we will append the first 4 bits of the SHA256(entropy) to the entropy since our entropy is 128 bits.
Each word of the mnemonic represents 11 bits. Hence, if you check the wordlist you will find 2048 unique words. Now, divide the entropy + checksum into parts of 11 bits each.
Match this 11 bit fragments to the words in the lookup table in the wordlist. Since we used 128 bits of entropy our checksum was 4 bits. So our entropy along with checksum represented a total of 132 bits. Thus our mnemonic will be 12 words.

If you had used 256 bits of entropy, your checksum would have been (256/32 =) 8 bits. That would represent (264/11) = 24 words.

One thing to note is that any 12/24 words cannot be used as a mnemonic. Some 'portion' of the last word generally contains the checksum of the words chosen and hence has to be calculated. It is also discouraged to generate words directly from thought and use a secure cryptographic function to do so.

  Why Ledger Mnemonics have 24 words?

That is a design choice of security. More the number of words higher the entropy. 24 words will provide 256 bits of entropy. It is also important to note that a mnemonic phrase cannot be used back and forth between different number of words. For example you cannot convert a 24 word representation to 12 words and vice versa.

  How those words are converted to a private key?

The mnemonic is passed to key-stretching function PBKDF2 with 2048 rounds of hashing. The PBKDF2 function also has the ability to take a 'salt' that can be an optional passphrase. This passphrase provides an additional layer of security and prevents brute-force attack with look-up tables. The output of this function is a 512 bit seed.

This seed is then passed to HMAC-SHA512 with key "Bitcoin seed". The resulting hash is used to create the master private key (m) and master chain code (c). The left 256 bits of that resulting hash represents m while the right 256 bits represents c. The master private key m is then used to generate master public key M (M = m*G).

From here a number of derivation paths existing for different wallets. The most common one is a hardened derivation method as specified in BIP 44. Essentially, hardened keys use the parent private key in the hash function to generate child private key, while non-hardened uses parent public key in the hash function. This improves the security in the generation of child keys. In the below derivation, k and K represents private key and the associated public key respectively.

We would first need to show that we have used BIP 44 derivation path. That can be done with an index number and generate a private key one level deeper from the master private key. The child private key one level deeper is generated by: kchild = kpar + hash(kpar, cpar, i) where i is the index number. For hardened derivation of BIP 44, i will be 0x80000044 (we use the latter 231 half of the index number for hardened derivation). This result will give us a 512 bit number. The left 256 bits will represent the child private key and the right 256 bits will represent the child chain code.

The next level represents the coin. For Bitcoin, that is 0 or 0x80000000 in hardened derivation. You then calculate the child private key and child chain code  one level deeper using the formula above.

The next level represents account. You can use multiple accounts to represent different functions and help manage your funds better. You can use the above logic to generate the account private key and chain code. Again, this is hardened derivation so the first account will have index number as 0x80000000.

From here onward we do not use the hardened derivation. The next level represents receiving address vs change. This allows you to have different bunch for receiving private keys and different key bunch for change private keys. The function we will use to generate the child private from parent will be: kchild = kpar + hash(Kpar, cpar, i). Now i will be 0x00000000 for receiving and 0x00000001 for change. Also note, now we have public key in the hash function rather than private key which shows this is not hardened derivation.

Now, at the next level we use these receiving and change key bunch to generate individual private keys. Use the above generate private keys and chain code and pass them to the above mentioned function kchild = kpar + hash(Kpar, cpar, i) to generate individual keys. Every increment of i will give you a different private key.

Now use these private keys to generate bitcoin addresses.


How is the target section of a block header calculated?

The target section of the block header is called nBits in the code.  nBits is a 32-bit compact encoding of a 256-bit target threshold.  It works like scientific notation, except that it uses base-256 instead of base-10.  For example, if nBits is equal to 0x181b8330, you would calculate it like this:

Or, more simply, you'd use the same shorthand you use with regular scientific notation:

At a re-target point (every 2,016th block), Bitcoin Core adjusts nBits according to the rules described in this answer except that it is important to note that when difficulty changes by p percent, nBits is adjusted by the inverse (-p percent).  That's because a lower target is harder to reach the way Bitcoin is implemented.
It's also important to note that you can't just adjust the exponent part of nBits in the obvious way because when Satoshi first wrote the code, he inherited from a signed type---so extra care must be taken not to create a negative nBits value.  The Bitcoin.org Developer Reference has more details (but be careful, I haven't yet had an expert review that section).


What would a new exchange need to be better than the rest?

A popular opinion in the Bitcoin space is that transparency is key for Bitcoin businesses. Bitcoin and it's pseudonymous nature make it very suitable for scams and corruption.

Competitive fees or additional payment options are no longer the key to the success of an exchange. There are so many exchanges that you can almost certainly find what you need feature-wise. However the important question that remains is whether the exchange you found can be trusted with your money.

Proof of Reserve

Fortunately, the nature if Bitcoin's technology also has a positive side with regard to transparency: the Bitcoin block chain is public and everyone can verify it.

This allows for the possibility of exchanges to verifiably proof that they hold all the money of their customers. CoinDesk explains this here. Some exchanges like Kraken have recently published such proof of reserve.

An ideal situation would be for an exchange to provide a method that allows users to constantly verify of their money is still there. F.e. by keeping every customer's coins at a fixed address (this could be quite costly) or publishing a proof of reserve on a weekly or daily basis (this could be done automatically).


What would happen if one person mined all unmined bitcoins?

Then all those bitcoins would belong to that person.  There's nothing in the current Bitcoin protocol that prevents this.

I don't know what you mean by "would 'they' confiscate it".  From the point of view of the Bitcoin protocol, nobody has the authority to confiscate bitcoins.

Of course, if this happened, it would mean that miner would be able to unilaterally decide which transactions would be confirmed, and they could also reverse past transactions by re-mining part of the chain.  They would be able to allow people to double-spend.  This might well cause other people to lose interest in using Bitcoin, since its security would be undermined, and this could cause the currency's value to fall, perhaps to zero.


How does the network apply credit for created blocks?

Miner has to supply the Bitcoin address for block reward. Then, when the block is mined, the special "credit" transaction is permanently stored in found block, creating given amount (25 BTC, was 50 BTC) to given address.

Some pools (Eligius or P2Pool) use this feature and create a lot of credit transactions, so that when block is found, all participants will receive their respective share.


https://en.bitcoin.it/wiki/OP_CHECKSIG

99% transactions use SIGHASH_ALL


Converting raw scriptPubKey to readable format

I figured it out.

setps:

Get the transactionID
RPCCall getRawTransaction transactionID - copy the rawTransaction
RPCCall decoderawtransaction rawTransaction - copy the scriptPubKey
RPCCall decodescript scriptPubKey


Can one node receive two transactions from the same user (doublespend)?

No that would not be valid, the node would reject the second transaction it saw, because it would know the UTXO was already spent by the first one. If a miner tries to include both in a block, that block would be invalid too for the same reason.

The exception is if the first transaction signalled to opt in to Replace-by-fee and the second transaction had a high enough fee to replace the first one. (BIP 125)


Where can I learn how to build a blockchain from scratch?

There was a recent presentation by Portia Burton going over some of the basic steps in creating your own custom blockchain based on Ethereum, however it is in Node not Python as you are requesting.

It's not incredibly detailed, but still it could be useful: https://youtu.be/QWHjp_nzxaY?t=14m11s

There's also this guide on bitcointalk using C++ and the litecoin source code. https://bitcointalk.org/index.php?topic=225690.0