How does Proof of Stake prevents dishonest behaviour compared to PoW?

First of all, proof of stake is not a single algorithm. There are many different implementations. For example, the algorithm that is used in Cardano is completely different from the one that is used in Peercoin, which is quite close but still different from e.g. Blackcoin algorithm, which has been derived from Peercoin. Qtum, for example uses Blackcoin algorithm. And again, all this is very different from what Ethereum plans to do.

So, your question cannot be answered in general. We can only talk about concrete implementations of proof of stake. The largest family of PoS coins is based on Peercoin, but many different modifications have been implemented.

So let's talk specifically about family derived from Peercoin. This includes coins like Qtum, Emercoin, Navcoin, Stratis, NovaCoin, Blackcoin, PIVX, Neblio, ABBC Coin, Particl, ...

As mentioned already, there are many different flavors of the algorithm among these coins. But in general, they work as follows.

They implement a special kind of transaction called coinstake (CS) transaction. This transaction is used to prove that the block was created correctly accordingly to the used PoS protocol. Just as with proof of work, in prove of stake there is the adjustable difficulty and the target that each block needs to satisfy. Just as in Bitcoin, the target is 256 bit number. The coinstake transaction's first input is called kernel. And usually the rule is something like this:

SHA256(SM || PT || KH || KN || T) <= WT

where

SM is StakeModifier - There are several flavours on how this is actually calculated. One example is that SM_n = SHA256(SM_(n-1) || KH), where n is block number (height);
PT is time of the block where the coin (UTXO) used as kernel in CS was created,
KH is prevout hash of the kernel,
KN is orevout N of the kernel,
T is block time,
WT is weighted target, calculated as WT = Target * (value of kernel UTXO).

So if you are PoS block producer, you have wallet with all your coins and what you do is that you periodically check whether one of your coins cannot satisfy the rule above. If you have such a coin, you are allowed to create a block. You can observe that is the time passes, T changes, so you get new and new hashes on the left side with every new coin, so eventually it happens that some coin on the network will pass the rule for the given target.

The longest chain concept is very similar to Bitcoin again. chain work is again sum of block difficulties, and the longest chain is the one with the most chain work. However, due to stake grinding attack, there are limits to the application of the longest chain rule. In some coins, so-called maximal reorganisation length is introduced, in others it is called dynamic checkpoints et cetera. This prevents a node to switch to a better chain if it would need to replace too many blocks from its currently best chain.

There are many other technical details and subtleties, but this is the basic concept. Note that in this family of PoS algorithms, you cannot lose the stake. I'm actually not aware of any finished implementation of PoS in which you could lose your stake. The idea here usually is that rather than taking the stake away from dishonest nodes, the protocol is attempted to be designed in a way that cheating is not possible. However, this attempt is very hard to meet perfectly because of certain properties such as nothing at stake.


Maximum number of inputs per transaction

No, the number that can be represented by the varint has no effect on the maximum number of inputs. That number is far too large. Rather the maximum number of inputs is constrained by the block size.
If it really matters to you what the maximum number that a varint can represent is, it's just the maximum value for a 64-bit integer. That's 0xffffffffffffffff. There's really no constraints on what a varint can represent. A transaction with such a number of inputs would not fit in a block, nor would it fit on any existing single storage medium as that transaction would be at least 664.1 Exabytes in size.
The maximum number of inputs that can fit in a valid transaction is 24386.
Such a transaction would not use segwit, so we use the maximum block size without segwit of 1000000 bytes. Subtract the 146 for the header and coinbase transaction to get 999854 bytes for the transaction. Subtract 4 bytes for the version, 4 bytes for the locktime, 1 byte for output count, 8 bytes for output value, 1 byte for output script, and 3 bytes for input count. This leaves us with 999833 bytes. With 41 bytes per input (32 previous txid, 4 output index, and 1 for script length, 4 for sequence number), there can be 24386 inputs.


Is it possible to see how much trust a certain wallet/user has extended in Ripple?

My understanding of trust in ripple is that it is public - Finding the web of trust that links two people needs to be fast, and it also needs to work when the intermediaries aren't connected to the ripple network. However, while you might know that account rWIOWNDKALJOWIOWDKLj trusts rWOIASIOISDKLFJALSKF for 100 dollars, you don't necessarily know their name/location.

Another important point is that you don't have 'Balance' in Ripple, you have somebody who owes you money. So just knowing that this hypothetical person is owed 30 dollars doesn't mean much - they could be deadbeats, or a bunch of accounts operated by the same person. (If you had a list of trusted IOU issuers, you could mitigate this.)

Also, in your example, they might not be overextended; they could have 300 dollars in their mattress, and be entirely capable of paying off IOU's.


Pros & Cons of Self Hosting Bitcoin Node vs using a 3rd Party Service?

The truth is somewhere in the middle. Your colleague is correct to point out that there is an ongoing cost for maintaining your own full nodes. Beside the employee cost, there is also the cost for the actual server infrastructure, which may be higher than you think if you consider that you will need to maintain high availability,  redundancy, testing instances, and that you should sequester each foreign software from your own network and other nodes.
Overall, you can probably get away with having fewer infrastructure engineers than the count of supported cryptocurrencies, as maintaining a full node should not be a full-time effort. For example, the maintenance work between Bitcoin and bitcoin-derived altcoins such as Litecoin and BCH would have large overlaps. Cryptocurrencies with unrelated codebases and more strongly deviating APIs and data structures will be significantly more work. Frankly, the reference implementations of some "top 20" cryptocurrencies are inadequate for production use. If you deploy your nodes in the form of infrastructure as code, you have more development effort up front, but significantly less work later on.
However, the biggest cost difference is the time and effort you will need to invest to build out your own integrations with each different full node. The wallets packaged with full nodes usually do not scale to the needs of an enterprise, so you will likely need to invest in custom blockchain indexing, wallet software, address management, key management, transaction building, balance tracking, user management, etc. This is where the mentioned services can provide a lot of the heavy lifting. If you do end up developing your own integrations, I would definitely recommend having at least one engineer per supported cryptocurrency that is passionate about it specifically.
Even if you decide going with one of the mentioned service providers, I would heartily recommend that you run your own full nodes to reconcile the information the service provides with the corresponding blockchain data. This will still save you from doing your own wallet management, address management, transaction building, multisignature setup, simplify scaling, and let you focus on getting your business off the ground more quickly. You may even consider using a service provider intermittently, and then transition to self-hosting as you finish work on your own integrations.
Just to be clear: you fully entrust the future existence of your company to such a service provider. I hope that makes you at least a little bit uncomfortable and that you thoroughly take their approach to security and your counterparty-risk to them into account for your decision.
In the past few years, I have observed a few companies being extremely successful and rapidly leveling up their UX by focusing just on Bitcoin and sidestepping altcoins altogether. You may even consider a hybrid approach where you build your own Bitcoin solution and use a separate service for whatever alts you must support to limit your exposure.
Disclosure: In my previous job I was the UTXO Coin lead at BitGo.


What does 'signal' and 'lock-in' mean in a BIP?

Signalling simply means the miner of a block has set a bit in the version field to say that they support something. BIP 8 and 9 discuss this, it allows the miners to let the network know they are ready for the change or not. The version field of a block is 32 bits long, and if the top 3 bits are set to '001', 29 bits are free to be used for signalling.

After a certain start time defined for a particular proposal, miners can set the bit specified to signal their support. It is during this time that if at least a certain percentage of blocks are mined with the bit set in one difficulty retarget period (2016 blocks), specified as the threshold needed, that proposal becomes LOCKED_IN. Once it is locked in, it is ready to become active in the network. Locked in just means that it gained enough support to proceed.

This can all be found in BIP 9.


How long does a payment take to appear in my wallet, If not how do I reacieave it?

Most wallets will show you incoming/outgoing transactions as soon as they appear on the network. If you are not seeing a transaction, it is possible that your node (if you're using Bitcoin Core or a similar full client) is not fully synced yet, or that the node your light wallet connects to isn't fully synced. You can fix this by either waiting for your node to sync, or connecting to one that is synced.

During times when the mempool is full, nodes might drop transactions with low fees depending on how large their mempool is. At the time of writing, the mempool is quite empty, so this should not affect you.

If you are using a hosted wallet such as blockchain.info or an exchange, their systems may have not been able to detect your transaction, and you should reach out to their customer service.

You can also ask the sender for the tx id and use a block explorer to verify that the transaction has been confirmed successfully.


Reading your question, I suspect the cause for your confusion is around the setting in which Merkle trees are used. I think you are right that in the Bitcoin world, the setting is taken for granted and is not usually explained clearly.
Here's my two cents. To understand the efficiency aspect of Merkle trees, consider the two parties that are actually involved in the protocol:

A Bitcoin full node who has full blocks.
A Bitcoin thin node who has headers but wants to verify that a transaction is in one of the full blocks.
(It might be worth mentioning that the current Bitcoin protocol does not allow a thin node to efficiently verify that a transaction is not in any of the blocks.)

First, recall that when receiving a new block B with block header H and transactions T, the full node does the following:

computes h = SHA256(H), verifies the proof-of-work in h and checks the timestamp in H, etc.
for each transaction t \in T, verifies t's signature(s), verifies t does not double spend, and appends t as the rightmost leaf of the current block's Merkle tree. (Recall that a different Merkle tree is computed for each block. Of course, appending the transaction has to be done in a canonical order, so as to obtain the same root hash as in the block header H.)
after all t \in T have been verified and appended, computes and stores the Merkle tree, of course computing all interior node hashes and the root hash r (as depicted in your Merkle tree figure).
Crucially, verifies that the computed root hash r equals the root hash in the block header H.

Moral of the story: Yes, you are right that to prove membership of a leaf with respect to a Merkle root r, the prover (in this case, the full node) needs the interior node hashes: he can cache them or recompute them (there's some literature on trade-offs here). (I think) Bitcoin full nodes simply cache all hashes, as detailed in Step 3. Importantly, the interior hashes are not part of the 1MB block B: it would be a waste of space, since full nodes can simply recompute them from the leafs (i.e., the TXNs) and match the recomputed root hash with the one in the block header. Note that this prevents network adversaries from tampering with the transactions.
Second, recall that when receiving a new block header H, a thin node just does step (1) from above.
Now, here's the setting in Bitcoin:

The full node has all the blocks, including the interior node hashes computed in Step 3 above.
The thin node has all block headers. Recall that each header includes the Merkle root.
The full node wants to convince the thin node that some transaction t is in some block B with block header H (which of course the thin node has)

Thesis: Merkle trees allow the full node to convince the thin nodes of this efficiently, preventing the full node from changing t into t' (which would allow a full node to trick a thin node into thinking it got paid).
Proof: Let r denote the Merkle root in H. The thin node has that same H and r. The full node has the interior nodes "under" r cached (recall Step 3 from the full node). The full node fetches the (already cached) sibling path starting at the leaf containing the transaction t and going all the way up to the root r, sending it to the thin node. The thin node recursively hashes up t with the received siblings, obtaining a root hash r' (hand-waving here, assuming you understand Merkle proofs). The thin node checks that r == r'.
Efficiency: The full node (i.e., prover) only has to send O(\log{n}) siblings in a Merkle tree of n leafs to the thin node (i.e., the verifier), who only has a 256-bit root hash r. (Of course, the prover needs to have all the leafs and all the interior nodes, as discussed before.)
Naturally, this protocol guarantees the full node cannot "lie" about any transaction "under" the root r. Informally, if a transaction is there, the full node cannot change it to a different transaction and forge a proof for it (i.e., a sibling path). Also informally, if a transaction is not there at all, the full node cannot forge a proof for it being there.
To answer your questions:
Question A seems to be about how membership of a transaction t works. You say,

To do this, wouldn't you just look at the list of leaf hashes to determine whether H(D) is there? Why do anything with the Merkle root?

I think you're misunderstanding the setting. Keep in mind, that when discussing cryptographic protocols, it's quite necessary to refer to the parties by name, rather than using ambiguous pronouns like "you" and "I." "Prover" and "verifier" can be terse and boring, but is precise.
The thin node cannot "just look at the list of leaf hashes" because it only has the root hash and no leafs but wants to be sure that a leaf is there. The full node could send the thin node all the leafs and have the thin node hash them, obtaining the same root hash. However, that would be inefficient: O(n) bandwidth for n leafs. In contrast, a Merkle proof for a leaf under a root hash is much more efficient: only O(\log{n}) hashes + the leaf itself.
Question B should be answered by now: the full node has all interior node hashes. It sends the sibling path to the thin node, who simply recursively hashes up from the leaf being checked. The thin node verifies the root it obtained matches the root in the block header.
Question C:

Does Bitcoin persist the Merkle tree hashes for not only the leaf nodes but for the entire tree all the way to the root?

Not in the blocks themselves: it would be a waste of space as mentioned before. Full nodes compute the interior hashes and the root hash and cache everything locally on disk (presumably, I haven't actually looked at the source code). Then, they are ready to serve proofs for any transaction in any block to any thin node.

Where exactly and how exactly does it store this information? All I ever see is the Merkle root in the block...

Presumably, on disk in the database of the full node. But not in the block: they are redundant info because blocks contains leafs => can compute hashes of interior nodes and root node.

I think I once saw a Merkle value for a transaction node but I never saw any meta data related to non-tree Merkle nodes in the Bitcoin blockchain...

Ugh, I want to say "Yes, because it would be a waste of space to store interior node hashes in the blocks." but reading closer I don't actually know what you mean by "Merkle value for a transaction node" and "metadata related to non-tree Merkle nodes."
Hope this helps!


Where is the code that sends generated Bitcoins from mining to the wallet?

Each new block starts with a "coinbase" transaction, which specifies the generated coins for the block.

The code at the top of CreateNewBlock in main.cpp adds the coinbase tx to the new block, and later on calls GetBlockValue to determine the number of generated coins.

The coinbase transaction uses the scriptPubKey parameter of CreateNewBlock to specify the recipient of the generated coins.


Can two outputs from the same transaction be spent separately?

Short answer
Your questions, in order: Yes. Yes. No.
Long answer
When spending the output of a transaction, it is not enough to know the txid. You also need to know the index of the output. (In other words, whether it is the first, second, third, etc. output.)
The hash of the transaction you're spending and the index of the output you're spending is collectively known as an outpoint.
Quoting the Bitcoin wiki:

The OutPoint structure consists of the following fields:

Field Size: 32
Description: hash
Data Type: char[32]
The hash of the referenced transaction.
Field Size: 4 bytes
Description: index
Data Type: uint32_t
The index of the specific output in the transaction. The first output is 0, etc.

See also the bitcoin.org docs.


Can I use my "chainstate" folder for anything?

The chainstate directory stores publicly available data, specifically unspent transaction outputs and some metadata at the time it was saved. It doesn't contain any private key material and so it can't be used to claim or send any funds.


Are there algorithms that could be used for mining that resist acceleration with ASICs?

You are missing botnets of GPUs.

Honestly, I do not think botnets are such a big problem. Botnets succeed because they are invisible to the victims (some trojans even include an anti-virus to clean the system). If an infected computer has 100% CPU usage, it will not stay infected for long. Stealing credit card data is still a lot more profitable than running a crippled mining botnet.

So I would say that the scrypt key derivation function, from nealmcb's answer at your other question, is be a pretty good choice.


Does an OP_RETURN script always need another output within the transaction?

If you want to retain any change, yes you will need two outputs to return unspent Bitcoin to yourself. If you are spending for example a 0.0001 BTC output, 0.0001 to fees, then a single 0 BTC OP_RETURN output would be valid.


Generating Public & Private key pairs for cracking Bitcoin

It will take significant resources (probably more electricity than can be generated by all fossil fuels on Earth) and time (orders of magnitude greater than the age of the universe) to generate a complete Bitcoin address "rainbow table".

See these answers for more details.


Help needed with PyWallet and wallet dump using MacOS

Install Xcode

Install MacPorts from https://www.macports.org/

Run these commands:
sudo port install python27 py27-twisted py27-pip py-bsddb python_select
sudo port select --set python python27
sudo easy_install ecdsa


How are Bitcoin generated in Video Games?

These games do not actually generate any Bitcoin. No Bitcoin is being mined in these games; that's not how Bitcoin works.

The Bitcoin comes from the service running the game. They are doing something other than running the game that is earning them Bitcoin. They then use that Bitcoin to give small amounts to their users. The Bitcoin is typically earned thread advertisements that are on the website.


Can I interrupt the initial blockchain download without losing progress?

Ok, I just open anoter terminal window and do:
bitcoin-cli stop


Logging into Binance.com via VPN gives: "Network unavailable,please refresh and try again"

To bypass that check goto: hw_login.html instead of login.html when you are on the binance login page. Just replace login.html with hw_login.html


How to decode very huge (!) raw transactions?

try this:

bitcoind getrawtransaction 2f50fdf7adbf58e91d738869948f4b191eb3cafa016c6df7e9182c06e4513852 1

note the 1 at the end, which instructs bitcoind to operate in verbose mode.


Is hashing an optional step to use with public key cryptography for blockchain

Questions like this cannot be answered without specifying the digital signature scheme you're using.

In general

In general, a digital signature scheme consists of 3 algorithms:

KeyGen() -> (PrivKey, PubKey): generates a private key and a corresponding public key.
Sign(PrivKey,Message) -> Signature: signs a message with a given private key.
Verify(PubKey,Message,Signature) -> Bool: verifies a signature against a public key and a message.

What the data types involved are depends on the specific scheme.

ECDSA

In ECDSA, the digital signature scheme used in Bitcoin, the private key is a number, the public key is a point on an elliptic curve, the message is a byte array, and the signature is a pair of two numbers.

ECDSA does require a hashing step. In fact, without the hashing step, it is completely broken.

However, nowhere is there any encryption involved. There is simply a signing algorithm, and a verifying algorithm.

RSA

The mistake you're making, calling signing "encrypting with the private key" is a very common one, because it is often how digital signature schemes are explained.

It is true for some specific signature schemes, but not all. Most notably it is true for RSA. The private and public keys are interchangeable there, so indeed, by swapping them, the encryption scheme turns into a signature scheme.


Would it be possible to create a blockchain that uses only X+ active blocks?

Full anonymity: Yes, you could save 1001+ blocks but if you need only 1000 blocks, you can delete the others. So at a specific point in time, you could create a real 100% anonymous cryptocurrency because the other blocks would no longer exists.

No, that is not true at all. Someone, somewhere will store the entire blockchain and make it publicly available. This does not guarantee anonymity, and some people, even if they don't have all of the historic data, will still store the blocks from when they came online. Nothing about deleting blocks can help anonymity unless it is somehow enforced by consensus that you can only keep X number of blocks, but even then people have backups and such which means the data is not actually gone forever. You cannot achieve anonymity by trying to delete all data.

  But wouldn't it be possible to have a blockchain or a coin, where only the last 1000 blocks are saved and 1001+ get deleted automaticly?

It is certainly possible to make it so that nodes do not have to download the entire blockchain. All a node really needs is the UTXO set, so each block can contain the hash of the UTXO set so a node can download the UTXO set from somewhere else and just start with the block that contained the hash of that UTXO set. However, this method has flaws and is vulnerable to various attacks and introduces a lot of trust into the system.

For example, an attacker could create a false UTXO set and commit it into his own short blockchain. Because you do not have the entire blockchain history, you cannot verify that the UTXO set that the attacker provided is actually correct. Furthermore, you cannot determine whether that short blockchain is even the right blockchain. The attacker could have mined it with a low difficulty and you wouldn't know that the difficulty is incorrect because you don't have the full history. This method thus introduces trust because your node has to trust that the nodes around it are giving it the correct data.


Can we detect contentious soft forks created by the miners?

Because a soft fork by definition follows stricter rules than the normal chain, you would have to make assumptions based on the block data. For example, if a soft fork no longer allows certain scripts, you might be able to determine that by noticing that those scripts are no longer present in any blocks from that miner. However, it would be a guess since it is still a valid block, and just might happen to not contain those scripts.
There might be other changes that would be more obvious, but still a guess because the blocks will remain valid according to consensus rules.
Edit:
Regarding Segwit (BIP141), the block indeed contains extra data regarding the witness data, specifically the commitment structure which contains a witness root hash:

A witness root hash is calculated with all those wtxid as leaves, in a way similar to the hashMerkleRoot in the block header.
The commitment is recorded in a scriptPubKey of the coinbase transaction.

However, without knowing what to expect (and without the witness data, which was not sent to old nodes), this data is meaningless. One thing that does give away data that may appear to be extraneous is the use of the OP_RETURN script code, since this allows arbitrary data to be included in a transaction, and this is used in the commitment structure.
It is also interesting to see how BIP141 handled older nodes, by simply not sending witness data, see Backwards Compatibility. The segwit transactions appear to be anyone-can-spend scripts to older nodes, so the only thing they lose out on is the ability to validate segregated witness transactions, since it will assume such transactions are always valid. They don't know about or propagate witness data.


Why do so many Bitcoin websites have such bad reviews

There are indeed a lot of fraudulent online exchanges and wallet providers. The same is true for displeased customers.

I suggest you take a tour at https://bitcointalk.org and get to known which providers are trustworthy.
For trading cryptocurrencies, I'll suggest you start with Coinbase/GDAX or blockchain.info. Then based on what coins you are interested in, find another exchange that support them.

This page is also very helpful, it list the biggest online exchanges.
https://coinmarketcap.com/exchanges/volume/24-hour/


What is short pseudocode for determining the total number of bitcoins mined?

With a\b representing integer division and a%b the remainder of this division:

  blocks_per_epoch = 210000;
  initial_reward = 5 * 10^9;

  current_epoch = current_block_height \ blocks_per_epoch;
  blocks_in_current_epoch = (current_block_height % blocks_per_epoch) + 1;
  current_reward = initial_reward / 2 ^ (current_epoch);

  total_coins = 2 * blocks_per_epoch * (initial_reward - current_reward) +
     blocks_in_current_epoch * current_reward;

Note that this can be off by a few satoshis due to a different rounding.

If you work with integers for the reward, the division for current_reward can be replaced with a bitshift. If not, you can change initial_reward to 50 to give result in BTC instead of satoshis.


Do confidential transactions produce an UTXO

In Confidential Transactions (as used in Blockstream's Elements and Liquid), there are still identifiable UTXOs.

The only change is that instead of the amount, a homomorphic commitment to the amount is stored. While not technically correct, you could see it as a form of encryption that is compatible with addition and subtraction. So if a+b=c+d then E(a)+E(b)=E(c)+E(d) (where E() is the encryption function). This lets the verifiers still ascertain that the amounts in input and outputs match up.


Problem integrating Bitcoin daemon with PHP

Howdy?

Ok I was searching for tutorials all over internet on "how to integrate bitcoin daemon with php" I came up with many and none of them helped me to get it working flawlessly, some of them threw unexpected and strange errors after 90% completion and some of them good enough to throw error in starting only which saved my time and efforts. Now that I have done what I was looking for why not create a step by step tutorial to help fellow members. So let's get started.

Before we start you should install tmux which helps you save your work even if you are disconnected from the vps. To install tmux:

sudo apt-get install tmux

to start tmux simply type tmux and to get back on mai screen press ctrl b and then d to restore the session again type tmux attach.

I am expecting you have a Ubuntu 12.x or later because that is what i used for installation. Log in to your VPS or your computer's terminal and install python software properties by typing following command :

sudo apt-get install python-software-properties

then add repository ppa:bitcoin/bitcoin by typing following command

sudo add-apt-repository ppa:bitcoin/bitcoin

In my case this didn't work and threw an error stating that add-apt-repository command not found. In ubuntu later version versions this command is not found under python-software-properties package, like in previous versions, but available in software-properties-common. So I had installed it by running these commands :

sudo aptitude install software-properties-common

To find in which package the command we are looking for exists the following will be of help:

sudo apt-fille update

Unfortunately in my case this was also not installed so I had installed it by running following command :

apt-get install apt-file

Now I got the message "The file is up to date"

Now run
    sudo apt-file search add-apt-repository

You will be prompted to confirm this installation, press Enter key to confirm.

Now run

sudo aptitude update

and then
    sudo aptitude install bitcoind

Make a new directory by typing :

mkdir ~/.bitcoin
cd ~/.bitcoin

Create a new file inside this directory named bitcoin.conf by typing:
    nano bitcoin.conf

insert the following code in the text file:

server=1
daemon=1
rpcuser=any_username
rpcpassword=any_password

Exit by pressing ctrl+x to confirm the changes press Y and then press return key. Start the bitcoin daemon by typing:

bitcoind

Bitcoin daemon is now installed and runing you can check it by running the following command

bitcoind getinfo

Now we will install apache and php on our server

To install apache we will run th following code:

sudo apt-get install apache2

once apache is installed verify it by typing your ip address in the browser it will say It works!

now we will install php by following command:

sudo apt-get install php5 libapache2-mod-php5

now navigate to var/www folder and download jsonRPCClient.php with the following command:

wget http://pmtocoins.com/JSON-RPC_PHP_light.zip

once downloaded unzip it by typing:
    unzip JSON*.zip

no move to the directory by:
    cd json*/includes

and move jsonRPCClient.php into your www folder

now create a new index.php file in www folder with following code

<?php
include_once('jsonRPCClient.php');
$bitcoin = new jsonRPCClient('http://your_username:your_password@127.0.0.1:8332/');
print_r($bitcoin->getinfo());
?>

and you are done navigate to your ip address on the browser e.g 161.232.12.1/index.php

You can have a look on API call list here : https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_Calls_list


Getwork and GetMemoryPool - why is previous block hash different?

The value of previousblockhash in getmemorypool output is the block hash in big-endian order.

The value of data in getwork output is formatted as I described in this answer to your question about how hash1 is calculated.

This byte order reversal on 4 byte words is done by a function called FormatHashBuffers in main.cpp.  It's only done for the data and hash1 fields of the getwork output.  There's no comment explaining why it's done.


Do pool servers communicate with bitcoind, and in what capacity?

getwork is for all intents, completely deprecated due to it's inefficiency. At this point a single ASIC device can completely swamp a bitcoind with requests as they're able to exhaust the 32bit nonce in a fraction of a second. The situation is severe enough that pools like BTC Guild have extraordinary large (6%+) fees on clients using getwork in order to get them to switch to more efficient methods.

Internally, pools like Eloipool use getblocktemplate to generate work for the clients, and then use stratum or getblocktemplate to communicate with the workers depending on the request type they make. getwork is not involved at any stage. In fact, it's currently pegged for complete removal at some point.


I am not aware of BitPay providing that service.

The most well known company that specializes in what you describe is BitWage:

https://www.bitwage.com/

Maybe that is what your friend meant since they have similar names,


What hash rate can a Raspberry Pi achieve? Can the GPU be used?

There is a nice wiki page here: https://en.bitcoin.it/wiki/Mining_hardware_comparison

The raspberry pi is listed by its processor in the arm section: ARM1176JZ(F)-S. It gets 0.2 Mhash/s when clocked at 800 MHz.


Does my bitcoin multiply with every fork?

Note that the word "fork" can have several meanings. The more common one is a protocol change (either a soft or hard fork) where everyone switches to the new protocol. In this case there will still be only one type of coin.

You are talking specifically about a scenario where both the new and old versions are being used. In this case the network and the currency will split into two separate networks, blockchains and currencies. I will refer to such a scenario as a "split".

In essence, if the split is done properly, then the two networks will be incompatible and not recognize each other. Each will believe it is the one true coin, and will treat any transaction on the other network as invalid garbage.

The two networks do share a common blockchain history up to the point where the split happened. So if you have a bitcoin in address X in cold storage prior to the split, each network will recognize that there is a bitcoin in address X, so you will indeed have a coin of type A and a coin of type B. If there are several splits while the coin remains in the same address, you will have a coin in each of the resulting currencies.

You can "see the new coin" the moment there are block explorers for both networks. You can examine the block explorer for network A and see that you have a bitcoin, and you can examine the block explorer for network B and see that you have a bitcoin. Once you've installed wallet software for both network types, you can import your private key to both and have each display that you have 1 bitcoin.

This means that you are now able to create two transactions - one that sends a bitcoin to an address C of your choosing, which will be recognized as valid by network A; and one that sends a bitcoin to an address D of your choosing, which will be recognized as valid by network B. (This requires that there will actually be software available for both networks A and B, and that it will be careful not to create transactions that might be mistakenly picked up by the wrong network).

What happens next involves interaction with the real world, and the real world is messy. There's no absolute answer to what will happen as it depends on what kind of software and services you are using.

If you "have 1 bitcoin in an exchange", remember that you do not really have a bitcoin, the exchange has a bitcoin and is contractually obligated to give you 1 bitcoin when you demand it. This becomes messy when a split happens and it's not universally agreed what "bitcoin" means.

The exchange will, technically, definitely now have both a bitcoin A and a bitcoin B. What will it do about its contractual obligation is up to it. The exchange could treat both coins as legitimate, support balances of both Bitcoin A and Bitcoin B (the same way it has balances of any other currency), and credit you with 1 bitcoin in both (since your pre-split bitcoin really is equivalent to a bitcoin on both). Then you can either withdraw both, sell both or any other combination.

Or it could decide that only one of the coin types is legitimate. So it will run only nodes of Bitcoin A, recognize only transactions of Bitcoin A, and list a balance only for Bitcoin A (which it will just call "Bitcoin"). When you ask to withdraw your bitcoin, it will send you only a bitcoin A. It is technically capable of sending a bitcoin B as well but it ignores this possibility. The bitcoin B will probably be lost (or at least kept by the exchange).

So, it's in your best interest to keep your coins only in exchanges / hosted wallets that recognize the importance of handling splits properly. (Or, preferably, not keeping your coins in exchanges or hosted wallets at all).

I've analyzed the contingency of a split in more depth at https://fieryspinningsword.com/2015/08/25/how-i-learned-to-stop-worrying-and-love-the-fork/.


They really don't have any similarities, so I'm not sure that there's much point in comparing them or talking about their differences. If you understand what PoW is and what it does and you understand BFT algorithms and what they do, there's no much else to know.

Both algorithms are algorithms designed to get eventual agreement on how to make forward progress in systems that can make forward progress in more than one valid way where agreement on which way to go forward is needed for the system to be useful.

PoW algorithms are slow and expensive and don't provide any actual finality but eventually provide practical finality. They're vulnerable to majority attacks and require honest participants to actually spend, on a continuous basis, to protect the network more than any attacker is willing to spend to harm it.

PoW algorithms are dangerous on blockchains that have non-native tokens. For example, Ethereum's security comes from PoW and the value of its native token, Eth. But it also has an ERC-20 ecosystem of non-native tokens. Things get scary if the value of Eth doesn't remain high enough to keep this ecosystem secure. Ethereum is a secure platform to build DeFi on so long as all these DeFi projects together don't get too valuable for Eth to secure.

BFT algorithms are fast and cheap and can provide actual finality. You get to choose who you trust, rather than having to trust whoever has money and cheap power as you have to do with PoW algorithms.

One very important thing to understand about Libra is that it cannot possibly ever be decentralized. Whatever legal entities control the assets that back Libra are parties without which the Libra currency will lose its value. That means that for any proposed hard fork, those custodians get to decide which side of the fork keeps the economic value. Because any rules change can be imposed by a hard fork, that means that the custodians get to choose the rules, period. That means no real decentralization ever, period.

Suppose, for example, that someone proposes adding respect for a government-provided censorship list to Libra. If the custodians say that they will issue and redeem on the censorship side of the hard fork, then that's it. The censorship wins, and it doesn't matter what anyone else wants or says. The censorship side of the fork will have the backing which is what gives Libra its value. By design, Libra cannot ever possibly be decentralized so long as it is backed.


Why does the initial blockchain download get stuck part way through?

Restart OS, restart Bitcoin, try forwarding port 8333 on your router to your machine.  If there is no progress after that, you might consider deleting all the files in your Bitcoin data folder except wallet.dat (if you have made any transactions, deleting wallet.dat will make you lose your Bitcoins). If you just want to use Bitcoins casually, or don't want to wait for the client to sync, you can consider using an eWallet.


If I reuse the same address can a previously used transaction be reused?

Can somebody take the transaction tx0 I signed and publish it in order to spend the new coins with the old transaction?

No.

Firstly, the transaction inputs are already known to have been used. Any node examining the block will know that the rerun transaction has invalid inputs.

Secondly I expect (but haven't checked) the inputs to the signature include both addresses. This prevents the signature being misused in the way you suggest. (See Murch's clarification in comment below)

It may help (if not you, some other readers) to remember that bitcoins don't exist outside or inside the blockchain. The only thing that exists are transaction inputs and outputs. You can't use a signed transaction with inputs A,B and C to use inputs D and E. The signature prevents you altering the signed contents without invalidating the signature.

  how is it that address reuse is not directly forbidden? if not, can you detail why?

Addresses can be reused. The most obvious problem is one of privacy. If you give someone an address so they can buy $0.01 of tent-pegs from you, they can then see on the blockchain that you also received $300,000,000 recently to that address and go buy a big hammer and come to visit you at 3 a.m.


What testnet environment and configuration for Bitcoin?

You can run your node in pruned mode if storage is your concern. Reduce Storage

If you want to try to use bitcoin on testnet you can use Electrum wallet.
Be sure to download it from their official website https://electrum.org/. (Do not download Electrum from another source than electrum.org, and learn to verify GPG signatures.)


Problem in understanding other miners validating puzzle solving miner's claim

I understand that miner's role is to validate the block of transactions by calculating nonce based on difficulty level and finding hash of {block + nonce + hash of previous block} .

More accurately: the miner's role is to confirm the block of transactions. Each and every node (and miner) will independently verify the validity of all transactions and blocks. 'Validation' is not just the job of a miner. As mentioned by JBaczuk, the POW blockhash is actually computed on version, previous block hash, merkle root, unix epoch time, difficulty target (bits), and nonce.

  My question is, what if a node decides to change transaction data in a block and goes throught the process of calulating nonce and then finding hash and adding this block to chain. Other node will see that this node has correctly solved the puzzle and should allow the newly created chain. Right?

Not quite. Once a transaction is confirmed in a block, any new subsequent block that spends the same UTXO will be invalid (since that UTXO was already spent).

If the miner attempts to re-mine that original block (ie. a new block with the altered transaction, at the same blockheight), this will likely fail and be a waste of their resources. Even if they do find a valid block, the rest of the network will already know about the first version of that block, and the other miners will be working on the next block already (or they will have already found it). So even if your altered block is valid, the network will still ignore it since the network has already accepted a longest (most work) chain, that does not include your block.

  I don't know and it is not written anywhere that at the point when a node broadcasts that it has solved the puzzle and found hash of tampered transactions, is it the case that the other node has also solved the puzzle and hopefully with the untampered transactions?

Transactions generally can't be meaningfully 'tampered with'. Transaction malleability is an edge case that could be considered, but otherwise changing the contents of a transaction will make it invalid. When a node verifies the validity of a block, it would catch any invalid transactions, and thus drop the block for being invalid.

Other ways you could change a block's transaction content would include adding or removing certain transactions from the block, changing the ordering of the transaction in the block, or substituting one transaction for another (that spends the same UTXO, see double spend attacks).

In short: Since the miners are always incentivized to mine at the chain tip, having a miner work on re-mining an old block to introduce an 'altered' block in some way ultimately doesn't really matter to the rest of the network participants. The network just ignores the altered block, meaning the net outcome is that the miner that made the altered block just wasted their resources.


Is bitcoin mining itself compromising the security of SHA256

With a look up table you can avoid calculating the hash of a given input twice. Indeed, the block chain can be considered as a giant look up table, but one with very special forms of inputs: It links blocks and transactions to their hashes.

Though, why should someone choose a transaction or block as her password? Further, why would an attacker even try to look up a hash of a password in the block chain? He would have to assume in advance that the password is a transaction or a block (don't forget that even looking something up consumes some resources).


Can I get confirmation time from txid (tx_hash)?

Is it possible? or Do you have any better ideas?

No. You can predict with probability, but you cannot know for certain. Because block generation is a Poisson random event with an average discovery time of 10 minutes.


Why mining pool has different connections ports for different difficulty

I feel sorry for you that no one had replied, so i'm gonna join in and try to think together with you, cause i was wondering the same.
Out of pure guessing, i think that when you have a mining farm, you mine a block very fast.
When you are finished with the block, the server needs to affirm it and send you a new job, which makes a small delay. This delay can decrease the profits over time.
Now the next question is, why isn't everyone using the highest difficulty? I'm not so sure about this, but i believe it has something to do with having to finish a block before you log off or your software crashes. I don't know what happens to a block that gets half mined. I think the block has to be mined in a whole for it to be confirmed.
When you mine with low difficulty, the block is split in pieces so everyone has a part they can complete in a block.
Hope this helped. It's probably not the correct answer, but it sounds obvious.
This was my first post btw. lel hah, never sell, HODL!


What is a correct extranonce2 value in the stratum protocol?

Turns out that there was a bug in my code and not the invalid extranonce2 value!


Does every full node verify every transaction TWO separate times?

It is an accurate abstraction.

However, the most computationally expensive part of transaction verification is ECDSA signature verification. And the results of verification are cached and reused when they're done a second time. We don't cache the rest of transaction verification as it is subject to many parameters (new softfork rules can have been activated, height, locktime, ...), and it's relatively cheap anyway. We do however cache transaction verification failures.


What if Bitcoin gets to the point that all the coins have been mined?

From the bitcoin wiki:

  It is envisioned that over time the cumulative effect of collecting transaction fees will allow somebody creating new blocks to "earn" more bitcoins than will be mined from new bitcoins created by the new block itself. This is also an incentive to keep trying to create new blocks even if the value of the newly created block from the mining activity is zero in the far future.

When you make a transaction and set a TX fee, that goes to the bitcoin miner.


Best way to calculate difficulty of generating specific vanity address?

So things turned out to be a little bit different. But now i have a solution, that seems to be workable and adequate.
Original task was to calculate difficult of finding specific vanity address (like vanitygen does).

Difficult is basically
number_of_all_possible_addresses / number_of_addresses_with_vanity_prefix rate.

So, for example if we have only dec addresses between 0 and 9999, difficult for finding vanity address, that starts with "1" will be 10, because 10000 is the number of all possible addresses and only addresses from 1000..1999 will match, so there are 1000 of them.

With bitcoin addresses things are little bit more complicated, but principal is the same.

First let's find out how bitcoin address is formed: in a nutshell there is a couple of steps, that are important for  our task:

Take one 0x00 byte (that will be first byte of address to represent it's version)
Take ripemd160 result (20 bytes, 160 bits).
Take first four bytes of sha256(sha256(ripemd160)) as checksum
Concatenate 0x00+ 20 bytes of ripemd + 4 bytes of sha256 of sha256 of ripemd
Now you get a 25-byte long something which you must treat as a long integer. We will call this number a "proto-address".
Base58Check it (but this is not very important now) and result will be the bitcoin Address.

However, what is important is understanding of the fact, that we can change only ripemd part. That leads us to two conclusions:
first is that there are only 2^160 bitcoin addresses and second is a little bit more complicated.

Let's find answer to an important question: If A and B are numbers that starts with the same digit and there is an X such as A < X < B does it mean that X starts with the same digit?
If A is 1000 and B is 1999 - yes it does. X can be any number from 1001 to 1998. But what if A is 100 and B is 10000? X can be any number between them and it must not start with the same digit. So A, X and B must have the same digit in the beginning only if they have equal number of digits. Keep it in mind, it is important.

Let's  figure out, what is vanity address and what is base58 encoding.

Base58 is like base16 and base2 and base10 and like every other base.
Symbol "A" for example is "A" in base58 and 0x09 in base16 or 9 in base10. That is a good point to start.

Let's decide that our address starts with "1A". We know that address is basically an integer of 25 bytes. What is "1A"? It is a "1A" in base58 and 0009 in base10. Or just 9.

That means that every number, which can be divided by 58 and will have a quotient equal to "9" will give us an "A" symbol during base58.
For example 522/58 == 9. 30276/58/58 == 9. But not only those numbers will end up with 9, but these ones too:

9*58 + 58 -1
9*58^2 + 58^2 - 1
9*58^3 + 58^3 -1
or just any (9 + 1)*58^N -1 number

So the formula is for the beginning of the range:

prefix*58^n

for the end of the range:

(prefix + 1)*58^n -1

Here comes an idea: we must find all ranges of numbers that will meet those requirements:

Number in the beginning of range and number in the end of range have equal number of digits
Lengths of these numbers must be equal to the length of proto-address. This is important because we must have an integer 25 bytes long that starts with a zero byte, it is the law!
Their values must be less than 2^192, because leading byte is always 00 and we have only 25 bytes, which leaves us with only 24 bytes or 192 bits which value we can change.

When we find all these ranges, we can find, how many numbers there are in the range by simply subtracting beginning of the range from ending of the range.
The sum of all lengths of our ranges will be how many possible proto-addresses we can get.

But this is not the end. As we remember, proto-addresses are just all possible big numbers so not all of them can be converted to valid bitcoin addresses. But it is very simple to calculate how many of them can. Answer is 1/256^4. Why?

Because when we are generating bitcoin address, all we can change is the result of ripemd which gives us 20 bytes. Other 4 bytes are just checksum. Easy way to think about it is that we can have 2^192 proto-addresses and only 2^160 of them will be valid, because we can have only 2^160 valid bitcoin addresses. This gives us a 1/256^4 rate.

Final part: take sum of all our ranges lengths, divide it by 256^4 and this will be number of all possible bitcoin addresses with given vanity.
Just divide 2^160 by this number and this will be the result.

Lets illustrate it by finding difficult of A prefix.

A is just 9. Ok, lets find out all ranges, that will give us 9 as a quotient.
522 - 579
30276 - 33639
1756008 - 1951119
.......
we must go and go until length of our numbers will not reach 24 bytes (mind the leading 00 byte)
........
41735950621193504130037849728691446275009901558579068928 - 46373278467992782366708721920768273638899890620643409919

Both this numbers have length of 24 bytes.
This is our first range.
Next is

2420685136029223239542195284264103883950574290397585997824 -
2689650151143581377269105871404559871056193655997317775359

This numbers also are 24 bytes long.

Next pair will be
140399737889694947893447326487318025269133308843059987873792 and
155999708766327719881608140541464472521259232047844430970879

Both are larger than 2^192 so now we must stop.
lets sum our results:

46373278467992782366708721920768273638899890620643409919 - 41735950621193504130037849728691446275009901558579068928 + 2689650151143581377269105871404559871056193655997317775359 - 2420685136029223239542195284264103883950574290397585997824 = 273602342961157415963581459332532814469509354661796118526

This is how many possible proto-addresses we can have. But do not forget to divide it by 156^4 and get:
63703009616853067642911677093369144589991624155

And this is how many possible bitcoin addresses we can have.
Now just divide 2^160 by this number and the result will be 22

This is difficulty for prefix "A" or "1A".
Now let's talk about some special cases. What you must check, when working with ranges is:

length. Length of range must be equal to the length of proto-address and you must count all suitable ranges.
2^192. if end of the range is more than 2^192 you must cut this range from the top by value of 2^192 - proto-address can't be larger than 2^192. Also remember that beginning of the range must be always less than 2^192 (if not that does not make any sense).

What about special cases? Like patterns that start with more than one "1"? it is a little bit tricky, but not very complicated. "1" is a special case in base58 cos it is equal to 0. That means, when there are some "1"s in the beginning - all this bytes must be zeroed and can not be used. So our proto-address, if we want to start it with two "1" must have two zero bytes in the beginning. Like 0000XXXX....
if we want to have 111 we must leave 3 bytes as zero bytes in the beginning and so on.

What does it mean? Each 1 will cut one byte from our proto-address, so it will cut length of our possible biggest proto-address number by 8 bits or by one byte. That will make it 256 times harder to find and one byte shorter.

Like if we want to have 11 in the beginning we will have only 23 bytes to generate our ranges and if we want to have 1111 it will give us only 21 byte. So our ranges will be much smaller and difficult will be much higher. And obviously it is not possible to find any address if we have more than 19 "1" in the pattern, cos we must leave something to the ripemd result :)

If pattern starts only with 111, just count number of  "1" and assume that beginning of range is 0 and end of range is 2^(200-8*number_of_1's) because we have only 200 bits for proto-address and some of them must be zeroed in case of our 111(1)-like pattern.

if we have pattern like 11(1)X(X) where X is non-zero symbol, just short max possible proto-address by number of bytes equal to number of 1's and do ordinary calculations.


Is it possible to write a transaction of bitcoins, having only pen, paper and a private key from the address with some unspent outputs?

The transaction digest alone would take around 2 days of non-stop work:

http://www.righto.com/2014/09/mining-bitcoin-with-pencil-and-paper.html

That's before you even start the 32-byte multiplication required to compute an ECDSA signature.

It might be humanly possible if the UTXO you are spending does not require a signature. An "anyone-can-spend" transaction would only take a few minutes to assemble since they require no input script. But then of course anyone could steal your coins before your TX got confirmed.


Find recipient of a bitcoin transaction?

Since the blockchain doesn't store user's IPs or any useful person tracking information, it's hard to track down the recipient of a transaction.

But I read on few forums how Bitcoinstore owner tracked down a scammer to get the fraudulent refunded bitcoins back. You may come across a solution by studying this type of stories.

The details of the track down can be found Here


If you have just a pair of private and public keys, you would need a little more information.

A single public key can control Bitcoin in a number of ways:

A direct p2pk output
A p2pkh output paying the hash of the public key
A p2sh output paying a script controlled by a set of public keys that may include keys other than the one you have
A p2wpkh segwit output paying the hash of the public key
A p2wsh output paying a script controlled by a set of public keys that may include keys other than the one you have

Without knowing which type of output you are looking for, the public key alone is not sufficient, especially for p2sh and p2wsh outputs where other keys are required to construct the address.

Once you know which output type to look for, you can use the scantxoutset RPC method of a node, or construct your own index similar to an explorer or Electrum server and query balances.


A transaction's input parameter has to include the outpoint (txid and vout) of the transaction from which you have got the bitcoins. These outpoints helps nodes verify that the transaction is consuming inputs that have not been spent before. Full nodes maintain a UTXO set of all such outpoints so that they can easily verify the transaction when they get one. Since you are claiming that you have received a double spend transaction, I am assuming it means that there is another transaction that is consuming the same outpoint as the transaction from which you have got your bitcoins.

In a general case, when a chain re-org happens, transactions that were in the blocks of the previous version of the chain but not present in the current active chain are removed and moved to the mempool (provided it is valid), where it will wait until it is confirmed. But since the transaction from which you got the bitcoins is consuming the same outpoint as the transaction that is confirmed in the active chain, the double spend transaction will be discarded by the nodes as it will be invalid. Since, your spending of the double spend is pointing to a transaction that is invalid, your transaction is invalid as well.

That is the very reason it is recommended to wait for a few blocks (6 blocks ideally) before considering that you have got the bitcoins from the other person/machine. If the amount is really sizable, it would be prudent to wait for tens of block confirmations.


No.

The block that Alice mined includes the mining rewards going to Alice's address. If Eve alters the block data to output the rewards to her own receiving address, then the nonce (and other variable values, I think "extranonce" and timestamp) that Alice used to solve the block will almost certainly no longer solve the block.


Where can I find the backlog of Bitcoin transactions?

Yes, there are some (in order of preference):

https://jochen-hoenicke.de/queue/#24h
https://blockchain.info/unconfirmed-transactions


An address is not a wallet, and a HD wallet is only locally relevant to your storage and is not reflected at all in the public ledger.

Bitcoin works on a UTXO model where funds are paid to an output which can be spent by the owner of the private key for a given address. There is no direct links between any addresses and no hierarchical structure in the public ledger.

So if you pay to address 17fPG6yJujgzysrAozHM5FTEytBvWzF2gS, then the public ledger will only see the payment to that address, and nobody else will have any idea that address 1CGM9zBt885ccKg6j1aqbBESsdPju4aj2m is even part of the same wallet.

A wallet is simply a collection of key pairs, where each key pair has an address for its public part. BIP32 describes a method of deterministically generating addresses from a root seed, so that you may regenerate the addresses rather than have to store them individually.

To access the funds spent to 17fPG6yJujgzysrAozHM5FTEytBvWzF2gS, you need to regenerate the key pair for this address by using the same index you used to derive it in the first place.

Locally, a wallet software will be able to aggregate the funds from all of the addresses it generates, so it appears as though there is an aggregated total balance for the wallet, but in the public ledger, these UTXOs are scattered and uncorrelated. Only you will know your actual balance, and nobody can learn it from public information, although some of your addresses may become linked if you have to spend several of them in the same transaction.


visit
https://blockchair.com/bitcoin/blocks

since transaction fees went up to $35   Fee/kB (USD)

or open
https://blockchair.com/


Are memory pool and transaction pool the same thing?

That is referring to what is now called the mempool.

The wiki is unmaintained, and contains mostly outdated or incomplete information. I would suggest you use the bitcoin.org documentation instead.


In the very early days of Bitcoin blocks were typically mined by one individual person, often referred to as "solo mining"). This made sense because with only CPU mining each person pretty much had the same probability of solving a block as the next person (unless they had several CPUs). Eventually as mining expanded, became more distributed, and hardware such as FPGAs, GPUs, and ASICs came along, the idea of pooled mining was developed. This allowed a group of people to put their computational power together and share the rewards across each "pooled" miner in accordance with their contributions once the pool had solved the block. Each pool is different, and will use different reward algorithms such as PPLNS, PPS, etc.

  why bother mining, if there is no prize for second place?

Mining has very profitable rewards, especially if you are lucky enough to solve the block while solo mining. If you do not have to share the reward among others, 12.5 BTC will likely be more than enough to pay for the electricity used to mine the block depending on location, etc. For smaller miners, pooled mining will give them a portion of the rewards depending on how much hash rate is directed to the pool, regardless of whether they have personally solved the block themselves.

  does the randomness still ensure the smaller pools get lucky just enough to keep them interested in mining BTC?

Exactly. Imagine you and a friend were the only people mining in a pool you have created. Lets say you both have one 14Th miner. If the pool solves the block, you will split the reward because you have both agreed to work together and share the rewards.


How to set the sequence number in a coinbase transaction?

There are no special requirements for the sequence number in coinbase transactions. It is subject to the normal sequence number rules, but for coinbases, those largely don't matter. While it can be set to anything, miners generally just leave it as the maximum sequence number rather than using it as another nonce.


Why does Blockchain.info's My Wallet tx volume seem to exceed to total bitcoin network volume?

The estimated transaction volume chart is processed in a way that it removes any change and send-to-self values inside a transaction from its total value. If you want to see the raw chart then you should be looking at the output volume chart instead.


electrum wallet: is recognizing the seed a problem?

I guess there are ways to improve this, like storing just the position of the words etc, but still

Well, don't store it in a place where someone else can find it. No matter what. Not even inside a bigger list of text to obfuscate it. It is trivial to verify which combinations of words might be a valid seed.


Would it be possible to make Trophys / Achievements from bitcoin experience

Yes, that could be done, if you use Tor to connect to the website and if you don't spend the coins from those addresses at places where your identity could be tracked (i.e. tumble them first).


Is there an RPC command that checks for hardforks

There is no way to explicitly know that your node is on a minority-hashrate fork because to do so would mean awareness of all the new rules that makes the majority-hashrate fork valid, and then determining that more proof-of-work is accumulated on that chain. For that to be possible, you must be running an upgraded node already.

There are a few warning signs though: If your node hasn't received a new block in over two hours for example, you might want to manually check it - does it still have a good number of peers? Does log activity look OK?

High-volume Bitcoin merchants and exchanges usually simultaneously run several Bitcoin nodes, even a few different versions (0.19, 0.18, 0.17) and maybe even an alternative implementation (bcoin, btcd). This is how BitMex' https://forkmonitor.info operates.

There is rpc getchaintips: https://chainquery.com/bitcoin-cli/getchaintips

...but this is doing the opposite of what you asked: it will reveal to the user known chain forks (stale blocks, etc) but of course they are all lesser-work than the node's current tip which is always on the most-work valid chain.


Addresses and private keys are encoded using Base58Check Encoding. The prefix bytes are chosen such that once whatever you are encoding is actual encoded with Base58Check Encoding, you will end up with a string that has the intended prefix character.
The process of creating a Base58Check encoded string is described on the bitcoin wiki:

A Base58Check string is created from a version/application byte and payload as follows.

Take the version byte and payload bytes, and concatenate them together (bytewise).
Take the first four bytes of SHA256(SHA256(results of step 1))
3.Concatenate the results of step 1 and the results of step 2 together (bytewise).
Treating the results of step 3 - a series of bytes - as a single big-endian bignumber, convert to base-58 using normal mathematical steps (bignumber division) and the base-58 alphabet described below. The result should be normalized to not have any leading base-58 zeroes (character '1').
The leading character '1', which has a value of zero in base58, is reserved for representing an entire leading zero byte, as when it is in a leading position, has no value as a base-58 symbol. There can be one or more leading '1's when necessary to represent one or more leading zero bytes. Count the number of leading zero bytes that were the result of step 3 (for old Bitcoin addresses, there will always be at least one for the version/application byte; for new addresses, there will never be any). Each leading zero byte shall be represented by its own character '1' in the final result.
Concatenate the 1's from step 5 with the results of step 4. This is the Base58Check result.

The resulting prefix character is also dependent on the size of the data being encoded.
The only way to get a prefix byte that you want to use that has a specific character is to guess and check. The data you are encoding must be of a fixed length, and even when it is, you may still end up with multiple possible prefix characters for a given prefix byte.
A list of prefix values and the characters they produce for 20 byte values are also available on the bitcoin wiki


What do I need to consider, when I chose media to store a cold/offline wallet?

I wouldn't recommend CD/DVD or USB sticks. CD/DVDs don't actually have that long of a lifespan. Googling around I found various different estimates and no exact number, but the consensus is that they will probably last less than 10 years. Finding an estimate for how long a usb drive will last is a little bit more hazy, but the numbers I saw for that were around aboutish 10 years as well.

There's a bigger reason why you shouldn't use CD/DVDs or a usb drive: accessibility. If you plan on locking this thing into a deposit box and forgetting about it for a while, there's a pretty decent chance that when you come back to get it you won't be able to read it. CD/DVD drives are already used less and less, and there's a pretty good chance that 10 years from now you won't be able to get your data because your computer can only read hyper-bluray disks and the USB 12.0 connector is shaped like an octagon instead of a rectangle.

I'd actually recommend printing it out. A paper wallet printed on good archival paper with archival ink can last a very, very long time. If you do this at home, it will probably cost you some money since printers that can use archival ink aren't especially cheap, but there are some online services that can do this for you too if you are willing to trust them. You could also probably find some archival paper and archival pens and actually write out your paper wallet for not too much money.

If you really, really want to go crazy, you could have your address keys machined into a piece of steel or aluminum. If you pick a material that doesn't rust easily, and store it out of the elements so it can't erode, your wallet will essentially last for ever.


What is the most accurate Classification Of Bitcoin?

Bitcoin is a digital currency. It is described as a "Bitcoin: A Peer-to-Peer Electronic Cash System" in the Bitcoin Whitepaper.

Bitcoin Core is a software application that implements Bitcoin.

Anyone can implement a software application to interact with the Bitcoin network (network of computers that all agree on the same protocol rules). So perhaps it is most accurately described as a network that follows a strict protocol similar to email. There are many email clients, but they can all communicate with each other.

  Bitcoin is an experimental digital currency that enables instant payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer technology to operate with no central authority: managing transactions and issuing money are carried out collectively by the network. Bitcoin Core is the name of open source software which enables the use of this currency.

See https://github.com/bitcoin/bitcoin/#what-is-bitcoin


Strange LockTime values in Electrum transactions?

The locktime value is deliberately set to discourage a subtle attack known as "Fee sniping" and randomly set to an earlier block height to improve privacy (eg for CoinJoin users that need more setup time).

This is also done in Bitcoin Core with the nLockTime.


I wrote a very basic webshop using Armory that does a lot of what you're talking about, though in Flask:

https://github.com/goatpig/BitcoinArmory/blob/master/webshop/server.py

The sensible way to go about doing this would be to run your own bitcoin node so you can be notified whenever payment is sent to the address. You can, of course, use an SPV server (like an Electrum server) or even a public block explorer (blockchain.info, blockcypher) to get notified of payment to an address, but then you start risking customer (and your) privacy.

As long as the private key(s) are held offline, there's no actual risk of losing bitcoins. The big risks are from a privacy perspective and the way to combat that is to run your own node so you don't leak information.


No, it is not true. Both are impossible due to math. The mnemonic is just an encoding of a number that is randomly generated (i.e. just like a private key) so it has the same security properties of that 256-bit number.

If you ignore that it encodes a number, consider this: a seed phrase encoding a 256-bit number needs 24 words in the mnemonic. There are 2048 possible words which means that there are 2048^24 = 2.964... × 10^79 possible mnemonics. There are 2^256 = 1.157... × 10^77 possible 256-bit numbers. There are actually more possible mnemonics than there are values to be encoded in the mnemonic. Thus the mnemonics are just as secure as a randomly generated private key (256-bit number) itself.


How to make concurrent calls to bitcoin core rpc?

I would assume the issue is not Bitcoin Core, even with default RPC settings I do see noticeable increase in client performance when using async/await (C# library). My suggestion is to investigate how the client code handles the RPC request/response + block parsing.


How to establish connection for mining testnet blocks?

The -connect option overrides -listen; if you specify -connect then the daemon does not listen for connections.  So both your hosts are trying to connect to the other, but neither one is accepting connections.

If you use -bind, the daemon will accept connections on a particular interface, even if -connect is also specified.

So let's suppose the two hosts have IP addresses 192.168.0.1 and 192.168.0.2 respectively.

On host1:

 mycoind -bind=192.168.0.1 -connect=192.168.0.2 -testnet -server

On host2:

 mycoind -bind=192.168.0.2 -connect=192.168.0.1 -testnet -server

I have tested this with bitcoind and it works.

Note that other machines on the 192.168.0 network will be able to connect to either host.  If it is a local network, this should not be a problem.  You will want to make sure that your router will not do port forwarding to port 8333 on either machine.

You should also check firewall settings on both machines to make sure each will accept incoming connections from the other on port 8333.  (Actually, if just one of them will accept connections from the other, that should be sufficient.)


How do I properly paytomany using electrum via script?

WOW....so this never got answered by anyone else....okay let's share the answer for you all as I eventually figured it out but had forgotten that I wrote this question:

electrum paytomany "[[\"17Umi7fbYuKixnr8nRq16kMESWgJVc66s\", 0.05], [\"17Umi7fbYuKixnr8nRq16kMESWgJVc66s\", 0.05], [\"17Umi7fbYuKixnr8nRq16kMESWgJVc66s\", 0.05], [\"17Umi7fbYuKixnr8nRq16kMESWgJVc66s\", 0.05], [\"17Umi7fbYuKixnr8nRq16kMESWgJVc66s\", 0.05], [\"17Umi7fbYuKixnr8nRq16kMESWgJVc66s\", 0.05], [\"17Umi7fbYuKixnr8nRq16kMESWgJVc66s\", 0.05], [\"17Umi7fbYuKixnr8nRq16kMESWgJVc66s\", 0.05], [\"17Umi7fbYuKixnr8nRq16kMESWgJVc66s\", 0.05], [\"17Umi7fbYuKixnr8nRq16kMESWgJVc66s\", 0.05]]"

So each address to be paid must reside within its own array which is itself enclosed into a parent array of all those payout requests...the slashes are simply there to escape the quotes so they're included within the string.  I actually ended up doing something other than bash but utlimately this is the string you need to format in order to paytomany using electrum.  Still don't know what the -v nor the -h are for (op...nevermind they mean Help and Verbose)...-P for portable wallet (meaning it can be put onto something like a usb drive (a portable filesystem essentially)... Hope this can help some other fellow web traveller in the future ;)


Why are `update_add_htlc` and `commitment_signed` separate messages?

The  commitment_signed message is also used at other places to move forward channel state. The entire process is not only described in BOLT02 but also in Mastering lightning
https://github.com/lnbook/lnbook/blob/366a65b33045cbb9e95a3d4060005c240f1f1778/channel-operation.asciidoc
There you can see that after Alice sends and update_add_htlc message and a commitment_signed message Bob will later in the protocol also send a commitment_signed message so that Alice can also move forward her state. Remember Bob and Alice both have an asymmetrical version of the commitment transaction for each state and both need a signature from the other side. It would be strange if Bob replied with an update_add_htlc message to send over signatures even though he does not want to add an htlc.
So yes while signatures could have been included in the update_add_htlc message we still would have needed the  commitment_signed for Bob to reply. Also when stetteling htlcs the commitment_signed messages are needed again. I guess in that way it seems more reasonable to make the exchange of signatures explicit with its own message instead an reusing it. But of course that was a choice that could have been taken differently.


Is there any risk associated with using the same passphrase on two different wallets both hosted on blockchain.info?

The risk is that, if a hacker gets a hold of one, then they've gotten a hold of both. Or at least If I had one passphrase, it would be my first guess for the second.

However I dont think there is any inherent technical problem for blockchain.info.


What are the optimal cgminer settings for a AMD Radeon HD 6670?

So far I have been using

-I 18 -g 1 -w 256 --thread-concurrency 2400

Getting ~71k/h with clock at 820 and mem at 852

I hope this helps


According to Ripple: Ripple for Financial Institutions
Financial institutions, network operators and regulators play critical roles scaling and providing stability to payment systems. Ripple enhances the existing payment stack, offering real-time settlement infrastructure at the foundation."

https://ripple.com/integrate/

Given that financial institutions, network operators and especially "regulators" are part of this equation then in this instance of "Financial Institutions" when considering the totality of human involvement it perhaps could not be considered decentralized, which in the context described makes it centralized.

Ripple also states "Jurisdiction or network specific rules, governance, standards, and other critical functions are intended to be provided by existing systems and operators."

With respect to your second question Ripple is a system for exchanging the Internet of Value (many different assets digital and physical) in which they also offer their own XRP digital "currency", whereas Bitcoin is simply another digital currency.


If a single private key of the HD bitcoin account is compromised, is the whole HD account compromised?

With just the private key, no.

However, if the attacker knows both a child private key and the xpub of the chain it is derived from, yes.

From BIP32:

  One weakness that may not be immediately obvious, is that knowledge of a parent extended public key plus any non-hardened private key descending from it is equivalent to knowing the parent extended private key (and thus every private and public key descending from it). This means that extended public keys must be treated more carefully than regular public keys. It is also the reason for the existence of hardened keys, and why they are used for the account level in the tree. This way, a leak of account-specific (or below) private key never risks compromising the master or other accounts.

This means you should either never give out private keys, or treat xpubs are highly sensitive secret data.

When using hardened derivation, this problem doesn't exist, but they lack the ability to publicly derive addresses.


Why don't Bitcoin Full Nodes who are not Miners get compensated?

I don't think Satoshi ever answered this question so we can't be 100 percent sure on the rationale but it was clearly the right decision. Firstly, at least today (if not when released) it is orders of magnitudes more expensive to mine a block or contribute material hashpower to a mining pool than it is to run a full node. Secondly, it would be extremely difficult to locate all the full nodes on the network to distribute what would be a miniscule reward. The full nodes would need a way of telling the network what Bitcoin address they wanted to receive their "full node reward" to. Thirdly, it would cost a lot in transaction fees and take up a lot of limited block space to create an output for every single full node (tens of thousands exist) on the network every block to distribute the reward. Fourthly, many full nodes connect and disconnect to the network regularly. So you would need a way of monitoring all connections and disconnections to work out whether the full node deserved a "full node reward" for a particular block.
I'm sure there are many other reasons not to do this but hopefully the above convinces you that this is not a viable idea!


Got the Bitcoin Wallet. How do I transfer money into it?

It is not possible to buy bitcoins from inside the client. What you need to do is this:

Find someone that you can buy bitcoins from. One way is to use an exchange, such as Mt.Gox, that let's you deposit USD (or some other currency) and then buy bitcoins.
In the Bitcoin client (assuming you use the original client from bitcoin.org), get a Bitcoin address from the "Receive coins" tab ("New address..."). Using a new address for each transfer will increase your anonymity.
Transfer the bitcoins you bought to your new Bitcoin address. If you use Mt.Gox you would use the "withdraw" option. The bitcoins will then show up in your client.


Difficulty to Hash Validation Correlation

Difficulty is not the same as target hash (target in short).

They are inversely related, so minimal possible difficulty (of 1) gives maximal target, by definition given as (https://en.bitcoin.it/wiki/Target):

  0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

  Because Bitcoin stores the target as a floating-point type, this is
  truncated:

  0x00000000FFFF0000000000000000000000000000000000000000000000000000

The current difficulty is calculated as maximal target divided by the current target. For example (https://en.bitcoin.it/wiki/Difficulty):

  0x00000000FFFF0000000000000000000000000000000000000000000000000000 /
  0x00000000000404CB000000000000000000000000000000000000000000000000
  = 16307.420938523983

So in your example the Difficulty = 1,347,001,430,558.57 would give the current target of:

  current_target =
  0x00000000FFFF0000000000000000000000000000000000000000000000000000 /
  1,347,001,430,558.57

If you calculate this (take care as one number is hexadecimal and other decimal), the comparison should give that this current_target is higher than the mined hash of:

  0x000000000000000000cf3620d570d08d1799a1cafbbfae512fdba2124665eca0

EDIT: Pen and paper calculation gives me that the current target is around:

  0x000000000000000000FFFF000000000000000000000000000000000000000000

How I got this. 1,347,001,430,558.57 is around 1.225 * (16^10). As the target is in base 16, this means that dividing by 1 * (16^10) is like shifting the digits 10 places to the right. To get precise result after digits shifting I should divide by 1.225, but I ignored this in this pen and paper calculation.

EDIT2: To be even more precise I take 16/1.225 is around 13 (D in hex), so the target is around:

  0x000000000000000000D000000000000000000000000000000000000000000000


Is there a way to create a transaction that it can only be confirmed after another unrelated transaction has been confirmed?

I assume A spending the UTXO of an intermediate transaction C, which spends a UTXO of B doesn't count as 'unrelated', as that's just two degrees of separation instead of one.

Here are three partial-solutions:

To state the obvious, you could simply wait until B is confirmed to publish A.
You could publish A with a lock time in the future and then update it at a regular interval with increasing sequences and extending the lock time each time, but that doesn't eliminate the possibility that earlier versions of A will get mined when their lock time expires. Then when B is mined you publish a new version of A without the lock time enabled.
If you only require that it doesn't affect the coins moving around in transaction B, You could add an output to B that doesn't have any coins in it, and is used only for the dependency tracking of transactions. This requires that you know that you plan to publish a dependent transaction, A, ahead of time though.

I think you'll find that there really isn't a good way to do what you are asking. Transaction dependencies are usually handled by referencing outputs of the previous transaction.

In terms of the scenario where you are trying to bribe miners to confirm transactions that they have been censoring, this is essentially trying to do Child-Pays-For-Parent with transactions that cannot reference outputs. While this is still not possible, you might be able to do something like this:

The community realizes that many transactions are being censored, and they want to pay miners to include their transactions. So everyone starts appending an extra OP_TRUE output to their transaction, with 0 coins in it. Then if you want to reward a miner for mining the transaction with an OP_TRUE output in it, you spend that output with an empty scriptSig and spend another output to provide some fees.

One downside to this is that a miner will only be able to accept one person's bribes, as there is only one OP_TRUE UTXO added. But, I think if Bitcoin gets to this point, then it will likely have failed.

You could also do an escrow, where you put coins into a 2-of-3 with you, the miner, and a trusted third party. If the miner mines B, then you sign the release transaction to take the coins out of escrow and give them to the miner. If the miner doesn't mine B after a certain amount of time, then you request that the trusted third party help you release your funds. This is a lot of work for a simple task, though.


It sounds like your wallet.dat file is still intact, but some of the environment data has gotten corrupted (possibly due to moving wallet files).

Try doing

db_load -r lsn wallet.dat

This will reset the LSNs in the wallet.dat file which should cause the errors in the db.log to go away. Once you do that, delete the database/ folder and start Bitcoin Core.


Building an blockchain address monitoring service. Best way to monitor an address for bitcoin and other altcoins?

Since you mentioned PHP you can install a Bitcoin Node on your server and then use EasyBitcoin-PHP: https://github.com/aceat64/EasyBitcoin-PHP

Then use the Bitcoin API:
https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list

To list all transactions associated with an account:

echo $bitcoin->getreceivedbyaddress($btc_address);

"Returns the amount received by  in transactions with at least [minconf] confirmations. It correctly handles the case where someone has sent to the address in multiple transactions. Keep in mind that addresses are only ever used for receiving transactions. Works only for addresses in the local wallet, external addresses will always show 0."

So you could run this and compare with your DB to see if a new transaction appears that isn't already in the DB.

--

To monitor a balance of an account you can just check on each page load (and update your DB if you wanted to):

echo $bitcoin->getbalance($user['id'], 1);

Get one of your users addresses:

echo $bitcoin->getaccount($user['id']);

To check transactions:

echo $bitcoin->gettransaction($trans_id);

--

You could also use an API:
How to get the list of transactions of input/outputs for a bitcoin address in JSON format?

--

I'm not 100% sure what you're asking for but I hope what I provide helps you.


You can try this (disclaimer: I wrote it) and do the following:

from btctools import Xprv

>>> xprv = Xprv.from_mnemonic('impulse prize erode winner pupil fun off addict ...')
>>> xpub = xprv.to_xpub()
>>> xpub.encode()
'xpub661MyMwAqRbcFJwcugErEvzSgeKwGgHeLyzWKKK4C3edVRDbCU8o2pueJ5S26cXgPQQVRxQXyuoKrScnNKzohc4YNefs4zXg8tAhSLfnFo7'

>>> xpub/0/0/1
Xpub(path=M/0/0/1, key=039ec9190c3469b70f55a50466c7514b881ebe83b6215e94ed727854e1724ca811)

>>> xpub.address('P2PKH')
'1Fh2JwDc87R2BSXmcRYQPgRR5ntn5LuabK'


Solving a block and share relationship [pool mining]

When your share is better than the difficulty you have solved a block. Other than that, the best share is only for your information/amusement. Although, some pools only count shares above a certain difficulty towards the work one has provided.

Even succeeding at the difficulty, you could still not be discovering a block for one of the following reasons:

The difficulty you were looking at was the difficulty at which the pool is accepting shares as work, instead of the networks difficulty.
You were working on a stale block chain.
Another block was found at the same time and was accepted right before yours.


Why include the Segregated Witness Merkle Root in the input field of the coinbase transaction?

Why a witness commitment is necessary at all: Enabling DoS prevention for validating nodes

Block validation is expensive. It requires hashing all data in a block, building Merkle trees, looking up all inputs from the UTXO database, running script and ECDSA validation, do various consistency checks, and updating the UTXO database. If random peers could make us do that amount of work, we'd be exposing ourselves to denial-of-service attacks.

Thankfully, producing blocks is expensive - it requires spending hash power. An attacker could take a valid block, and modify it before relay to turn it invalid. However, since all data relevant for validation directly or indirectly affects the block hash, doing such an attack will invalidate the proof of work. Thus, we can simply make sure that a block's proof of work is valid before doing any of the more costly checks, and that way we make sure that every attacker needs to spend new hash power for each block we try to validate.

Segregated Witness adds more data to blocks that is relevant for validation. In order to make sure that the protection outlined above still works, we must make sure that the new witness data affects the block hash. Otherwise, an attacker could simply take a valid block, make a gazillion modified copies, each with a different invalid witness, and broadcast them. Nodes would need to validate every version.

Why the witness commitment uses a Merkle tree: compact witness proofs

Some outputs (e.g. 1-of-2 multisig) can be spent by different combinations of signers. Certain wallet software may be interested in knowing which party/parties signed off on a spend for display or forensics purposes.

Lightweight nodes can currently request a compact proof for the existence of a transaction (see BIP37). As the witness does not contribute to the txid, the normal Merkle structure does not permit creating such a proof for the witness data. While there is currently no available protocol for requesting such witness proofs, using a Merkle tree for the witness commitment enables this.

Why the witness Merkle root is stored in the coinbase: easiest deployment for miners

Lastly, we need a place to embed the witness Merkle root hash that affects the block hash. Using the block header would have been perfect, but there is no way to add data there without breaking every piece of Bitcoin infrastructure.

The only place flexible enough for storing that data is in a transaction. A special transaction could have been added which contains the commitment, but transactions bring extra overhead. They need inputs and outputs, which need to come from somewhere and go somewhere.

Because of that, the only choice remaining was to embed the commitment in an existing transaction. The coinbase transaction is the logical choice - it is already created by miners anyway, and adding a dummy output to it has low resource costs (due automatic removal of OP_RETURN outputs from the UTXO set).


If you purchased Bitcoin a long time ago, and it's on an exchange, and that exchange still exists, and you can recover your username and password to that exchange, then you should be able to transfer your money off of there.
If you used your own Bitcoin wallet software such as Bitcoin Core, then you will need to have your wallet.dat or other wallet file to recover the coins. Without this file, the coins are gone for good.


Since the v0.8 release Litecoin is developed using patches to the Bitcoin code base.


Since you're using a local wallet, read these instructions on obtaining your BCH. For safety, you can transfer all your bitcoins to a new wallet first, then no longer use the old wallet for Bitcoin transactions. Also, installing BCH wallet software on a separate machine is a good idea as otherwise the Electron Cash wallet may sweep the machine for Bitcoin wallets and put your new wallet at risk.

There may be simpler methods, but at this point in time I'd expect they would increase your level of risk substantially.

To sell your BCH for BTC, you'll need to find an exchange you trust that handles both.

If you're interested, there was a fork into "Bitcoin Gold" too, on 24th Oct 2017, though it hasn't gone live just yet.


Yes, there is no nothing preventing you to doing that as long as you use different private key, but usually your mobile wallet will generate an HD wallet for you so you wont have to deal with that problem.

Just be sure to use recognized mobile wallet like those here https://bitcoin.org/en/choose-your-wallet?step=1

Also notice that some mobile wallet will offer you to have separate wallet inside their own software, like electrum


Might AML regulations have to be applied to unofficial currencies sites in EU?

In the EU AML regulations do not apply to currencies, they apply to financially registered entities and a couple of other ones.

The entities required to ensure AML-compliance are :

Banks,
Payment Service Providers,
Latin notaries (think about laundering money through real-estate transactions for example)
Licensed currency exchangers,
etc.

Legally compliant Bitcoin exchanges are not subject to AML regulations directly, since as of today, none of them is a registered PSP or bank. But, if they partner with such an entity they can get a delegation to perform AML-related duties such as KYC, under the legal responsibility of the delegator entity.


Is it possible to append new blocks to a block of arbitrary age?

For example, could I simply append a new block to the genesis block

Yes, you can. You can actually do this if you start your node offline and begin mining.

  or are there any other restrictions than just the validity of the block itself?

There are, but only for legacy reasons. There are a set of checkpoints where, at a specified height, the block must have a specific hash. These were added to provide a performance boost, but have the side effect of locking in the blockchain to specific blocks. The most recent checkpoint is at block 295000. So unless you are able to find blocks that have the same hash at all of the checkpoints, you actually cannot produce an entirely different blockchain and have the Bitcoin network accept it.

  And if this is the case, would the "Bitcoin network" really accept a completely new blockchain starting from the genesis block, if I really managed to make a blockchain with higher difficulty, than the current chain? (Like a 99,999% attack :) )

If you were able to produce such a blockchain and produce blocks which have the correct checkpoint block hashes (or if you forked the blockchain after the most recent checkpoint), then yes, the Bitcoin network would accept your alternative blockchain as it has more work.


When building bitcoind from source, how to specify stable build?

If you got the source via git, you can checkout on the latest stable release tag, currently v0.8.1 using the git command git checkout v0.8.1.

When you did not setup git, you can simply download the source from that tag version from the webpage you suggested using either the .zip or .tar.gz link underneath the tag name. vX.X.X releases are stable ones, while the vX.X.XrcX releases are release candidates, meaning that they can still contain a few bugs.


How much anonymity do mining pools provide?

Eligius is the most anonymous pool I know of, as it doesn't require registration. Quoted from the Bitcoin wiki: "To use it, a miner merely needs to be directed to mining.eligius.st on port 8337, with the username set to a valid bitcoin address (which receives the payout). No registration is needed."

Pools I'm aware of that have been hacked include nofeemining.com (userids, passwords and emailed were published to the web - the administrator didn't actually notify users of the extent of this. The pool has since closed), ozco.in (this was treated very seriously), and abcpool.co (some balances stolen, but treated seriously). However, if anything, the likelyhood of a being hacked again is probably less than some of other mining websites that haven't yet been compromised.

Given that most pools require little more than an email address (and you can create an anonymous email address easily enough on various websites), a user can choose to remain reasonably anonymous with minimal effort.

Perhaps the biggest risk to user anonymity is through your IP address - if you provided personal details to an untrustworthy website, say dodgyexample.com, and then mined "anonymously" at a theoretical site dodgymining.com, your IP address could be used to link the accounts details as being owned by the same person.

Further to the above, the payouts you receive through a pool may be linked back to you through the Bitcoin blockchain, depending on where you spend your bitcoins and whether you have shifted them between wallet addresses before you spend them. This is unlikely though, as you will most likely spend your bitcoins somewhere that the malicious individual cannot link back to you.

See also: How can one remain relatively anonymous while using Bitcoin?


Bitcoin mining - is it a race and how to not waste resources?

Yes and no:
Yes, the first one to find a block gets the whole reward and the others have wasted their effort. But there is no progress in mining, so every attempt to build a block has the same chance at success. Therefore, your chance at finding the next block is equal to the percentage of mining power you contribute to the network.

Also see:

How is it that concurrent miners do not subvert each other's work?
What exactly is Mining?
In the ASIC-age, is it worth starting mining Bitcoin at home?