How can I execute `getnewaddress` at my full node from a remote server?

As chytrik said, a better way of generating new addresses on a remote server would be to export an extended public key (xpub) from your wallet and put only the xpub online. Then your private key material would remain offline, and you could generate new child addresses from the xpub using BIP32.

If you still want to execute getnewaddress on your node, you would have to expose the bitcoin RPC by adding server=1 to the bitcoin.conf file on your node in order to accept JSON-RPC commands and call the getnewaddress directly.


Is it feasible to store information in the Bitcoin system?

Storing data on the blockchain is frowned upon. Since the blockchain is replicated on all non-pruned full nodes and downloaded by all full nodes, thousands of people must spend the extra resources to download and host your data on their machines for essentially eternity. This costs money and disk space while also taking up valuable block space that would otherwise be used to confirm someone's money-transferring transaction.


find the maximum possible reward for creating a block using

If I understand your question correctly:

Currently the maximum reward for mining a block is 12.5 Bitcoin plus any additional transaction fees in that block. This reward halves every 210,000 blocks. It does not matter which address is used for receiving the reward. See https://en.bitcoin.it/wiki/Mining#Reward.

For learning references, see What's a good resource to learn how [technically] bitcoin works?


How to verify the signature of a raw transaction

See How to calculate a hash of a Tx? .  The hash that serves as the ID of the transaction is not the same hash that is used for signing.


What are the implications of BIP 12 vs BIP 16 and OP_CODEHASHCHECK?

BIP 12 creates a new Script opcode which allows scripts to execute more script stored in a string (like eval functions in other languages). There's not much debate about BIP 12: it will not be used. It's very complicated, it allows some looping (which Script should not support), and it makes it difficult to analyze scripts without executing them.

With BIP 16, scripts are allowed to execute scripts stored in a string one time (not recursively), and there are also other restrictions that eliminate all of the BIP 12 drawbacks mentioned above.

CODEHASHCHECK does the same thing as BIP 16, but some technical differences make it arguably more elegant.

All of these proposals are designed to solve the problem of how to allow recipients to choose which restrictions to place on coins they receive at an address (two-factor authentication, etc.). Currently senders always define the restrictions on sent coins, which is inconvenient in many cases.


The most important reason is that the original Satoshi codebase was written in C++. A system like Bitcoin has extremely strong requirements about consistency in behaviour: all nodes on the network must accept and reject the exact same blocks, or we risk a fork. The first choice to avoid bugs that risk introducing inconsistency is to not rewrite the code from scratch.

Although all programming languages have flaws, and C++ is no exception, there are various reasons that make it an appropriate choice. An easily-overlooked one is that it provides very tight control over memory usage. Many modern languages (especially those that rely on garbage collection) make it hard if not impossible to reason about tight bounds of memory usage. Since Bitcoin Core is a security-critical application that is directly exposed to the Internet, it is nontrivial to guarantee that there is no way to trigger it to allocate large amounts of memory, thrashing the machine's swap space, or worse, killing the process.

This is in addition to a good balance between high-level where desired but also many avenues for performance optimization. Performance may be more important than is immediately obvious, as the convergence of the network relies on quick validation and propagation of blocks. If blocks take too long to validate compared to their creation frequency, economic factors start to unfairly advantage larger/faster miners (see the Selfish Mining attack, for example). Under extreme conditions, if blocks would take ~minutes to validate, the network may fail to converge at all, as nodes simply don't hear about blocks in time anymore.


How to find private key in blockchain.info account?

There is no way to export your private keys directly unless its an imported address that you imported to your wallet.

To get the private keys for your main wallet addresses:

login to blockchain.info.
Click Settings > Security > Backup Recovery Phrase > write down your phrase with exact order to import it later using Electrum wallet.
Download Electrum bitcoin wallet and setup on your computer.
Start Electrum then choose file > new/restore > click next > choose the option "Standard Wallet" > then choose I already have a seed.
Enter the seed phrase you saved from Blockchain.info then click next you can choose a password to protect your wallet.
Now you control your wallet  click addresses tab then choose the address you want right click and choose private key option.

Dont give your private keys to anyone not to lose your coins


Is there actual consensus on the blockchain's tip or only until the next block?

No, there is no consensus until the next block is found. The network is experiencing a blockchain-fork. It will only mend once one of the tips pulls ahead by adding another block. Then all nodes will reorganize to the longest chain and consensus is reestablished. The losing chain becomes an extinct branch – valid but not part of the longest chain.

There can't be consensus before because from a node's perspective there is no way to tell reliably which one of the two blocks is more popular in the network. They could ask around, but would get mixed answers and could be deceived through a sybil attack anyway. Therefore, nodes accept the first valid block they hear about as the current blockchain tip until proven otherwise – the only valid proof being to be shown a longer chain. They'd still keep the competing block though, and propagate if it is later needed for a reorganization.

In fact, such blockchain forks can even persist for several blocks when competing blocks are found subsequently. E.g. in 2012 there was a blockchain fork with four blocks.

During a blockchain fork, there is a higher risk of doublespends because the competing blocks at same height may confirm different transactions. However, if they occur from natural random chance (instead of an attack), they would be working from the same set of unconfirmed transactions and should contain a mostly matching set. As each blockchain tip considers the other not to be relevant, they do not split transactions to be confirmed, but both try to confirm the whole set.

So, yes. Both are valid blockchain tips, either may turn out to be part of the longest chain in the long run, but a good blockchain explorer should maybe show both until it is clear which one will remain part of the longest chain.


Electrum shows "No FX rate available" and balances show "No Data" and last transaction doesn't appear

I've just had this problem as well. It looks like Electrum gets its currency information by default from the BitcoinAverage website. You could try to select a different source of information. Try and see if this helps:

Go to Tools > Preferences > Fiat > Source > Select something like BlockchainInfo


There is no such thing as a "bitcoin" that can be copied. Rather, there is a list of all the transactions that have taken place on the bitcoin network and the order they have taken place. Every client has a copy of this list. Essentially, the only way to counterfeit bitcoins would be to spend them in more than one place. This is called a double-spend attack. However, because of the design of the bitcoin block chain (the list of all the transactions) and the way that list is secured by mining, this requires a tremendous amount of computer power.

http://en.bitcoin.it/wiki/How_bitcoin_works#Double_spending

See also the question about how mining works

What exactly is Mining?


Double Counting SigOps to Prevent CPU Exhaustion Attacks

There's something unintuitive about Bitcoin transaction SigOp counting. Normally, the signature count of a block is calculated by looking at the scriptPubKey of each transaction and counting how many OP_CHECKSIG operations it contains. In other words, the SigOp count is gotten by looking at how many outputs you create, not how many inputs you redeem.

However, you obviously can't see how many operations a P2SH script does by looking at its hash. Instead, the transaction that spends the P2SH script "pays" for it.

The somewhat awkward thing is that you can't tell if a scriptSig is spending a P2SH output unless you look up the outpoint it's spending.

  Why doesn't CheckBlock() just include the P2SH sig op count to avoid code duplication between the two methods?

I don't think it's for backwards compatibility. While ConnectBlock doesn't count P2SH SigOps for transactions that appear to be P2SH but aren't, that logic could be implemented in CheckBlock instead.

I don't think it's for efficiency. Rejecting blocks with too many SigOps isn't very common, since it takes about seven thousand dollars of electricity to make a block. I suspect that you could remove the SigOp check from CheckBlock for a very minor performance increase.

I think it's partially because it would be irritating to change. Getting the P2SH SigOp count requires access to the CCoinViewCache object, which isn't passed to CheckBlock.


In Bitcoin it is indeed the sender who pays the fees. Also for "real transactions" (with the marginal case of P2SH where one can say that the receiver pays part of the fees upon spending the proceeds of the P2SH transaction).

Indeed, if fees are too low, the transaction is not confirmed. Therefore, the seller typically waits to see whether the transaction is confirmed before delivering anything.

At present the fee is typically less than USD 0.1.

Because the fee necessary for a transaction depends on the length of this transaction (ie its number of inputs, among other things - something determined by the buyer's history), it is hard for the seller to specify a fee that applies to all the expected transactions.The transaction fee can therefore be seen to be only implicitely and approximately included in the price.


Can a blocksize limit be a sustainable way to introduce scarcity?

Your analysis seems to assume unconfirmed transactions will sit in the queue forever.  That's not the case.  When someone realizes that their transaction will never confirm, they can create a double spend with a higher fee.  When the double spend is confirmed, the earlier transaction becomes invalid (barring a chain reorganization).

I think it's an open question about how much we should be restricting block sizes.  The current hard limit of 1 MB seems to be a comfortable place for miners with current technology and for full node operators with current disk space and bandwidth limitations.  As fast block propagation technology improves, block chain pruning technology gets deployed, and higher-bandwidth connections become more common, we will likely see a push towards higher block size limits.

We will also hopefully see technology and techniques developed that allow for alternative ways to pay for block chain security, so we aren't so dependent on transaction fees.


Difficulty of brute-forcing a seed with missing words?

Missing 3 words in known positions and there will be 8.577.355.766 permutations.
Based on the speed of an average PC, approximately 10 permutations/second. This would take close to 9927 years(if unlucky and have to try every permutations) Sorry, I forgot we are not dealing with wallet password encryption here.

Anyway, a computer will have to get the private key, calculate a public key and then check it for balance, this process will take time.
Missing 4 words(17.540.692.561.920 permutations) or more, and I don't think anyone will want to try their luck. So maybe 5 words or more and even the government will let it slide.


In pooled mining, what is pdiff, bdiff and ldiff?

What are the meanings of pdiff, bdiff, and ldiff?

The numbers are the current difficulty of the network(s).

bdiff is the target difficulty of the whole Bitcoin network.
ldiff is the target difficulty of the whole Litecoin network.
pdiff is your pool's target difficulty.

As you may know, the difficulty is a measure of how difficult it is to find a hash below a given target value.

In what way do they differ?

Is bdiff 1 == pdiff 1 == ldiff 1, or how do they relate?

TL;DR: No. That defeats the purpose of having multiple difficulties.

This is a multi-part answer; I'll try to divide it in a manner that it makes sense.

Bitcoin

Difficulty

The Bitcoin network has a global block difficulty (bdiff). Valid blocks must have a hash less than or equal to this target. Mining pools also have a pool-specific share difficulty setting a lower limit for shares (pdiff, usually 1).

Calculation

How is bdiff calculated?

bdiff is an approximation based off of a known hash where the leading 32 bits are zero and the rest are one.

  difficulty = difficulty_1_target / current_target

  (target is a 256 bit number)

  difficulty_1_target can be different for various ways to measure difficulty.
  Traditionally, it represents a hash where the leading 32 bits are zero and the rest are
  one (this is known as "pool difficulty" or "pdiff"). The Bitcoin protocol represents
  targets as a custom floating point type with limited precision; as a result, Bitcoin
  clients often approximate difficulty based on this (this is known as "bdiff").

How is that value stored?

  Each block stores a packed representation [...] for its actual hexadecimal
  target. The target can be derived from it via a predefined formula. For example, if the
  packed target in the block is 0x1b0404cb, the hexadecimal target is

0x0404cb * 2**(8*(0x1b - 3)) = 0x00000000000404CB000000000000000000000000000000000000000000000000

Note that the 0x0404cb value is a signed value in this format. The largest legal value for this field is 0x7fffff, while the smallest is 0x008000. To make a larger value you must shift it down one full byte positive valid value.

How does one calculate (estimate) bdiff?

Say your value is 1 (0x1d00ffff) 0x00ffff * 2**(8*(0x1d - 3)) = 0x00000000FFFF0000000000000000000000000000000000000000000000000000

That would be 0x00000000FFFF0000000000000000000000000000000000000000000000000000 /
0x00000000000404CB000000000000000000000000000000000000000000000000
= 16307.420938523983

Source

Litecoin

Difficulty

Because Litecoin is based on Bitcoin ldiff is calculated the same as bdiff. It is an approximation relative to a known hash (256-bit number where the leading 32 bits are zero and the rest are one).

Calculation

ldiff is calculated in the same way bdiff is.

They both have a maximum of infinity (basically), and a minimum of 1/4096

Because Litecoin takes its roots in Bitcoin, this also means ldiff is an approximation, not a precise value.

Source

Pools

Difficulty

pdiff is relative to the crypto-currency in question. In the cases of Bitcoin and Litecoin pools, it represents the same thing; but in, for example, a Namecoin pool, the difficulty may not be 1, or it may be calculated differently. This is confusing because the 256-bit number in question is 0x1d00ffff. The number was not called anything initially. But once pooled mining started, it colloquially became known as pdiff. But it was around before pooled mining. Pools just happened to use it as their target difficulty, and because bdiff was already a thing, the name pdiff was transposed to the number 0x1d00ffff.

Note that pools usually use non-truncated-targets, and usually use a difficulty of 1. This means that even within the same crypto-currencies there really is no set definition of what pdiff is; however, I know of no pools/pool software that contradict these rules, because they are desirable. Just remember that anyone can make his pool do whatever he wants it to.

pdiff is relative.

Calculation

Assuming this is a standard pool, calculation follows basically the same as bdiff, but with one exception:

Let's say the target value is still 0x1d00ffff. The Wiki says pools usually use "non-truncated targets" So, instead of 0x00000000FFFF0000000000000000000000000000000000000000000000000000 we get 0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

Which, when calculated, yields 0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF /
0x00000000000404CB000000000000000000000000000000000000000000000000
= 16307.669773817162

Source


Is it safe to import my private key into another wallet?

It's safe as long as you're sure that no one else has access to that private key.

For example, you shouldn't import a private key someone else gave you. They could send coins to that key to make it look like they sent you money, and then steal them (since they have the key as well).

If it's just copying one private key on one of your own wallets to another one of your own wallets (both of which only you have access to), then you should be fine. Just be aware that coins given to that key will appear simultaneously in both wallets, and coins spent from that key will disappear simultaneously in both wallets as well. This doesn't sound like an issue in your case, since you won't be using the old one at all.

The alternative is to just do a standard bitcoin transaction to transfer it from one of your wallets to another. Although, I see that this is made difficult by the fact that your Bitcoin Core client not fully synced with the network.

Related: Did I just create counterfeit bitcoins?


BitCoin Miner - Remote Miners with SSH Access only

What you describe is tunneling through SSH. Assuming you can connect to an SSH from the servers (outgoing TCP port 22 is allowed). A is the machine you want to run the miner on, B is the SSH server which we use to tunnel the traffic through (this has to be able to open connections to the mining pool) and C is the hostname of the mining pool you want to mine on, then it's a simple matter of doing the following on A:

ssh -L 8888:C:1234 B

and then pointing your mining software to localhost:8888. What this does is open a connection to B which may open connections to the mining pool and each connection to the local port 8888 will be transparently forwarded to C. Notice that you'll also have to change the port from 1234 to whatever your mining pool uses.


sometimes my miners aren't detected by pools?

Mining pool servers and websites don't actually know your real hashrate. They try to estimate it based on how often you send in proofs of work (aka "shares"). If your hashrate is very low it won't be possible to make a good short-term estimate and it looks to the website as if you have stopped mining. That's what causes this issue.


When I call the blockchain.info API, I an error. What can i do to solve this problem?

The API returns No free outputs to spend when there's no unspent output, you need to account for that case. You can do a simple check on the status code (200: OK, 500: Error).


I use the Newtonsoft.Json.Linq library as shown below to get the data.  Soon, I'll be posting Strongly typed C# client libraries at http://www.coinapi.net

The main trick to getting the JSON error code is to call GetWebResponse() again in the catch method.  Then return and parse the data.  I've debated about including the WebException itself in the return code, but that may require too many changes. If anyone has ideas I'll be glad to take them.

        var ret = InvokeMethod("getblockhash", index);

Here is the definition of InvokeMethod

    public JObject InvokeMethod(string a_sMethod, params object[] a_params)
    {
        HttpWebRequest webRequest = (HttpWebRequest)WebRequest.Create(Url);
        webRequest.Credentials = Credentials;

        webRequest.ContentType = "application/json-rpc";
        webRequest.Method = "POST";

        JObject joe = new JObject();
        joe["jsonrpc"] = "1.0";
        joe["id"] = "1";
        joe["method"] = a_sMethod;

        if (a_params != null)
        {
            if (a_params.Length > 0)
            {
                JArray props = new JArray();
                foreach (var p in a_params)
                {
                    props.Add(p);
                }
                joe.Add(new JProperty("params", props));
            }
        }

        string s = JsonConvert.SerializeObject(joe);
        // serialize json for the request
        byte[] byteArray = Encoding.UTF8.GetBytes(s);
        webRequest.ContentLength = byteArray.Length;

        try
        {
            using (Stream dataStream = webRequest.GetRequestStream())
            {
                dataStream.Write(byteArray, 0, byteArray.Length);
            }
        }
        catch (WebException we)
        {
            //inner exception is socket
            //{"A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 23.23.246.5:8332"}
            throw;
        }
        WebResponse webResponse = null;
        try
        {
            using (webResponse = webRequest.GetResponse())
            {
                using (Stream str = webResponse.GetResponseStream())
                {
                    using (StreamReader sr = new StreamReader(str))
                    {
                        return JsonConvert.DeserializeObject<JObject>(sr.ReadToEnd());
                    }
                }
            }
        }
        catch (WebException webex)
        {

            using (Stream str = webex.Response.GetResponseStream())
            {
                using (StreamReader sr = new StreamReader(str))
                {
                    var tempRet =  JsonConvert.DeserializeObject<JObject>(sr.ReadToEnd());
                    return tempRet;
                }
            }

        }
        catch (Exception)
        {

            throw;
        }
    }


Stable coins differences? (USDC - Coinbase / Circle, GUDS - Gemini, TUSD - Trust Token, PAX - PAXFUL, USDT - Tether)

Indeed, USDC has a backdoor built in to allow for the freezing and/or seizure of funds if it is believed illicit activity is involved. In other words, any address can be blacklisted and funds frozen. Not very stable for a stable coin, right?


Use https://login.blockchain.com/#/recover and note that it says

Recovering your funds will create a new wallet ID.

OR

Read https://support.blockchain.com/hc/en-us/articles/115001298143-Your-Secret-Private-Key-Recovery-Phrase-The-Failsafe where it says

The recovery phrase generated in your Blockchain wallet is compatible with other bitcoin wallets that implement BIP44/BIP39.

So you can go to https://bitcoin.org/en/choose-your-wallet and select any other wallet that supports BIP44/BIP39. Then use that wallet to recover control over your money by selecting wallet recovery at startup and entering your recovery phrase.


How exactly does namecoin work on "low" level?

I'm not an expert on Namecoin, but from what I understand, Namecoin works by introducing a few new types of transactions to the Bitcoin formula used for handling domain registration. After that you just need some mechanism of extracting the domain names from the blockchain and that should be enough for Namecoin to work.


Calculating Hardware Efficiency through Hash Rate per Second

If you have Excel, try:

BTC Per Day = (B3*POWER(10,9)/B1)*(B4*B6)/B5
B1 = 907549524 (Difficulty Factor - obtained from http://bitcoindifficulty.com/ or
http://bitcoinwatch.com/)
B3 = 70 (Hashing Rate in GH/s)
B4 = 25 (Block Award in BTC)
B5 = POWER(2,32) (Is a constant, is the number of integer nonce
values that can be hashed with a 32 bit integer register)
B6 = 86400 (seconds per day)

Answer for #1 is 0.038790162 when the data from B3, B4, B5 and B6.

I add two other fields in my spreadsheet: 1) Difficulty Factor Compound Rate in % per 2048 Blocks (somewhere around 15% to 20%), 2) the value in BTC denominated in USD. The remainder of the spreadsheet I use determines risks associated with late ASIC hardware deliveries in terms of BTC or USD opportunity losses.  Absolutely, don't use any of the online mining calculators to make big Mining H/W acquisition decisions... You must take into account the non-linear difficulty factor compounding rate to make reasonable computations of what your profits are likely to be. Otherwise, your estimated profits are likely to be losses...


Fees usually are around 1% for each side (the person trading fiat for Bitcoin and the person trading Bitcoin for fiat).

Exchanges which directly trade with the user usually have different prices for selling and buying, usually 2% to 3% of by each other (1% to 1.5% from the middle so you're slightly worse off than trading with another person through an exchange).

However, there are exchanges which take much higher fees. Many charge extra depending on the payment option chosen on the fiat side. The most expensive serious one I was able to one has a 10% fee when paying via PayPal and a few weeks ago, someone on this site asked a question about how an exchange with a ludicrously high fee (it was around a third of the value exchanged, like in your case) could exist. Well, its existence of course doesn't mean that it's used a lot ... or at all.

You can easily find exchanges for your country by selecting it here and looking for the fees of a few exchanges listed for it.


Accidentally sent to my own receiving address, will I get back my bitcoins?

Bitcoin doesn't know that the recipient address is also yours. Therefore, while you sent the money to yourself, it looks like any other Bitcoin transaction to any other network participant.

To your wallet provider (blockchain.info) it is obvious that you control both addresses, so they call it a "transfer" instead of a "send".

As you've sent it to your own receiving address, you should be able to see it counted towards your balance. If it hasn't been, get in touch with blockchain.info and request that they help you rectify it.


Server requirements & optimal configuration for Testnet

We're a bit light on experience, i.e. we've never set up or configured a Testnet environment before, so we're looking for any advice or recommendations on the proper procedure or important implementation details that anyone might be able to offer.

There's Testnet3 (the current public testnet) and Regtest (a private, locally generated, proof-of-work-less network. If you want to experiment with consensus changes you can't be using the public network because those changes will be rejected. Regtest is good for quickly testing things, and Testnet3 is more real world and has a small number of other network participants.

  From our university we have the ability to have allocated to our project a server, and we've been asked what are the requirements that our project would need- does anyone know what are the necessary specifications?

Ideally you'll have as much capacity as you can, but you'll get away with any modern Intel CPU and a few gigabytes of memory. The more memory you have the more you can allocate to caching (dbcache defaults to 100MB, but can be set far higher for performance). Testnet is not a great reflection of how the real network operates, the requirements for the full network to run with good performance are higher.


You should keep Bitcoin-Qt up to date since the developers occasionally make changes to some of the rules (such as the minimum transaction fee).  It is easy to update - just replace everything in the Bitcoin-Qt install directory (don't touch the Bitcoin-Qt data directory).


How exactly is Ripple decentralized when OpenCoin has so much XRP?

There are only two known "attacks" you can perform with a large amount of XRP.

First, you can dump a large amount of XRP on the market. This will reduce the value of XRP, which OpenCoin would have to report as a loss. The net effect would be that people who hold XRP as a store of value would be harmed. So if you choose to use XRP as a store of value, you are incurring the risk that OpenCoin might hurt you by hurting itself more.

Second, you can sustain a large flow of transactions that would bid up the transaction fee on the network. This would mean that people who wanted to perform Ripple transactions would have to wait or would have to "outbid" OpenCoin for transaction slots. This would cost huge amounts of XRP for every minute you wanted to keep the network unusable. So this attack could just be waited out.

But really the premise behind this is false. OpenCoin's XRP has the same value regardless of how it was acquired. So worrying about this is really no different from worrying that someone with large amounts of Bitcoins might dump them on the market crashing the price. It's true, but people don't do that often because it hurts them more than it hurts anyone else. So, yes, it's a risk.

But generally speaking, there are many kinds of attacks someone can perform at their own expense to hurt you. Someone could flood the Bitcoin network with transactions with a .2 BTC transaction fee each, effectively knocking out Satoshi Dice. It's not rational to unduly worry about these kinds of things because it's so rare for someone to attack you in a way that hurts them more than you unless they have some clear motive to harm you and otherwise you'd pretty much have to worry about everything. And, of course, OpenCoin has no motive to deter adoption of the Ripple network.

(I'm an employee of OpenCoin speaking only for myself.)


Does the protocol ensures that private keys are unique?

However, what happens when my generated private key matches a private key that is already used?

Then you got lucky, and can spend someone else's coins.

  Does the protocol reject private keys if they are already used?

No, how should it? Keys can be used more than once in normal operation.

Fortunately, it is extremely unlikely that this ever happens. See also these two related questions.


Is every copy of the blockchain the same? If I have an error within file should I be able to copy this file from a backup and reindex chainstate?

So I copied this file again from a backup of the blockchain. This is from a second node. But I would suspect the files are the same, right?

No. Blocks are downloaded out of order, but are written to disk in the order that they are downloaded. So the block index (which states where each block is located) will be different for every node because every node will likely have the blocks stored in a slightly different order.
Furthermore, if your node has received stale blocks, those stale blocks are also stored on disk and have an entry in the block index. Not all nodes will have the same stale blocks, and they may not be stored in the same order. Newly synced nodes will not have stale blocks from before they were synced, and often times stale blocks become stale due to propagation delays, so a node may not even receive a stale block to store.
You can't just copy individual block files from one node to another. You need to copy the entire blockchain and the block index. Otherwise you will probably corrupt the whole thing and need to redownload the blockchain.


importprivkey in bitgold-cli not importing the expected address

Bitcoin Gold uses a different address format than Bitcoin. Even though the private keys can be used across coins, the addresses calculated from them will look different from each other but still encode the same data.


My claim was accepted on MtGox.com - how do I get the cash out?

All information is provided on https://www.mtgox.com/. As you can see, this is going very slow, the latest update was on 8th March and the next update should come after 27th September.

If you read the latest report, you can see that the secured assets are lowering in time (most likely due to payments for investigations and cost of the bankruptcy processing). You can also see that there is a huge gap between assets + bitcoins and liabilities, which means that even if payout was going to happen today, you would get just a fraction of your claim.

The case will likely take many more months (years?) before the payouts are going to happen. And then you should not expect much to get back.


Overclock Antminer U3 running on raspberry pi

I set up my rasp pi b+ and U3 mining rig using the instructions in this forum post, with screen and cgminer.

The command relevant to over clocking the raspi that I used is the following:

sudo ./cgminer --bmsc-options 115200:0.57 -o POOL -u USERNAME -p PASSWORD --bmsc-voltage 0800 --bmsc-freq 1286

Those last two options (bmsc-voltage and bmsc-freq) are what over clocked the rasp pi.  But I think I had to compile cgminer and configure it to include bmsc.  Mine typically runs with a hash rate in the high 50's or low 60's, but maybe not quite 62-63 GH/s.

Also, I did try to push the U3 voltage and frequency higher by playing with the settings as detailed in the U3 manual.  However, I could never get the U3 to run stably at settings any higher than what I gave above.  I'm not sure if it makes a difference, but I'm actually running two U3's on the one rasp pi and cgminer instance.

Update: In the interest of providing a complete answer in one place, here's the full text from the linked forum post:

  Run a fresh install of Raspbian using NOOBS, after the install type ifconfig and make a note of the IP address, so that you can remotely
  SSH into your Pi. Login via PuTTY with the default username/password,
  then raspi-config if you would like to change the hostname, default
  password and so on.

  Now update the Pi:
  sudo apt-get update && sudo apt-get upgrade

  Install dependencies:

  sudo apt-get install libusb-1.0-0-dev libusb-1.0-0 libcurl4-openssl-dev libncurses5-dev libudev-dev screen libtool automake pkg-config libjansson-dev screen

  Clone cgminer from here:
  git clone https://github.com/bitmaintech/cgminer

  Install, configure and also enable bmsc options:

  cd cgminer

  sudo ./autogen.sh

  export LIBCURL_CFLAGS=’-I/usr/include/curl’

  sudo ./configure --enable-bmsc

  sudo make

  Test cgminer is working correctly by running the following (input your
  own pool, username and password):

  sudo ./cgminer --bmsc-options 115200:0.57 -o POOL -u USERNAME -p PASSWORD --bmsc-voltage 0800 --bmsc-freq 1286

  Type Q to exit cgminer...

  Now, add cgminer to start automatically when the Pi is powered on and
  create a screen session:

  sudo nano /etc/rc.local

  Remember, Ctrl-X to exit, then type Y and press Enter to save changes. Add this just above
  exit 0, again enter your own pool, username and password:

  cd /home/pi/cgminer

  screen -dmS cgminer ./cgminer --bmsc-options 115200:0.57 -o POOL -u USERNAME -p PASSWORD --bmsc-voltage 0800 --bmsc-freq 1286


How to compile sources on MAC OS in 2017?

On a Mac Pro with MacOS Sierra 10.12.6 I got a clean compilation by following the instructions in doc/build-osx.md.

The sequence of commands is:

1) First install Xcode and HomeBrew by executing (in Terminal)

xcode-select --install

ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)" < /dev/null 2> /dev/null

2) Then install required libraries with

brew install automake berkeley-db4 libtool boost --c++11 miniupnpc openssl pkg-config protobuf qt libevent python3

(note: I added python3 otherwise there would be errors during "make check")

3) Download and compile

git clone https://github.com/bitcoin/bitcoin
cd bitcoin
./autogen.sh
./configure
make
make check


Do any ETFs purchase Bitcoins? Is that scenario possible?

A Bitcoin Trust fund registration statement was filed today with the Securities and Exchange Commission. If approved it would be the first Bitcoin ETF you can trade in the market.

UPDATE: The Bitcoin ETF was not approved.

  As discussed further below, the Commission is disapproving this proposed rule change
  because it does not find the proposal to be consistent with Section 6(b)(5) of the Exchange Act,
  which requires, among other things, that the rules of a national securities exchange be designed
  to prevent fraudulent and manipulative acts and practices and to protect investors and the public
  interest.
  The Commission believes that, in order to meet this standard, an exchange that lists and
  trades shares of commodity-trust exchange-traded products (“ETPs”) must, in addition to other
  applicable requirements, satisfy two requirements that are dispositive in this matter. First, the
  exchange must have surveillance-sharing agreements with significant markets for trading the
  underlying commodity or derivatives on that commodity. And second, those markets must be
  regulated.


Why are there different mining hardware for different hashing algorithms?

The hardware you are referring to are called Application Specific Integrated Circuits (ASICs), and they are named that for a reason.  It's because they are not general purpose computers like desktops, tablets, and mobile phones.  Instead, they are computers designed to do a very specific thing.  In the case of an AntMiner, that thing is the SHA256 algorithm.  It cannot be reprogrammed to perform other hashing algorithms, such as SCRYPT (used by litecoin).  In fact, it can't be reprogrammed at all.

By hard-wiring these devices to perform one, and only one task, they are much faster and more energy efficient than would be a general purpose computer programmed for the same task.  This is why all Bitcoin mining is currently done with ASICs, and is not feasible to do with CPUs anymore.  It's also why the same miner cannot perform anything other than what it was built for.


Are there any bitcoin communities for women?

There is a Meetup for Women in Bitcoin in San Francisco. It might be helpful to try to get in touch with them as they might be able to point out a meetup near you or recommend an online community, unless you happen to be near there anyway.


Refer to UTXO by output index or output full address in blockchain?

In Bitcoin, it was originally an assumption that miners producing blocks would use a unique address per transaction, making sure that the coinbase of each block had a unique TXID. As this was not enforced, users accidentally made duplicate transactions by setting the same destination address for multiple solved blocks. BIP34 simply adds a new field to be validated to the block, requiring that the height is also part of the hash, ensuring uniqueness for all future blocks.
For the two special cased BIP34 blocks, the outcome is rather simple. The first instance of the TXID creates the UTXO, the second invocation does nothing at all because the output already exists, and if they were ever spent the UTXO can only be removed from the database a single time. The money involved in the second instance of the TXID was destroyed, causing a loss of 100 BTC total.


I have watched addresses in my wallet..how do i use them?

If you do not have the private keys for those addresses, then they are not yours and you cannot do anything with them. Those addresses and their associated Bitcoin do not belong to you, so you cannot use them.

You can delete the watch only addresses if possible; you will not lose any money if you delete just those addresses because there is no money that belongs to you in the first place with those addresses. However be careful of deleting the wallet entirely, it could have addresses and private keys which do belong to you and those you do not want to delete.


any faucet that can give even 1 satoshi of BTC immediately?

A faucet could not pay out 1 satoshi, because it falls below the dust limit that is used by the majority of nodes on the network. Further, the fees required to send a transaction would total far more than 1 satoshi, so even if it was possible to confirm such a transaction, it would cost more to do so than the amount transferred.

If you had a lightning network node with the appropriate incoming capacity, you could accept a lightning network payment on 1 satoshi. It is worth mentioning that if the channel were closed with just 1 sat on your side, you would not be able to receive an on-chain tx for this amount, due to the dust limits mentioned above.

Note that service recommendations are off-topic here, so I won't comment on the current availability of such a faucet.


It would be pretty easy to implement this using the Bitcoin source:

Have the central bank generate a private key K.  Hardcode the corresponding public key into the source.  Modify  the transaction verification code so that any transaction signed by K is allowed to have outputs that exceed its inputs (or no inputs at all).
Modify the verification code further to reject regular "coinbase" transactions.  Miners can still mine, but rather than getting a block reward, they are rewarded only by transaction fees (a la Bitcoin in 2140).  So you still have the decentralized transaction register confirmed by proof-of-work, but mining doesn't create new money.
Change port numbers and version bytes, mine a new genesis block, all the other stuff that any altcoin needs.

Now the central bank can create money at will, just by signing a transaction that has no inputs but does have outputs (paying the new coins to somebody of their choosing).

The central bank can destroy money that it holds, simply by sending to an eater address with no private key.  This doesn't need any changes as it's already possible for anyone to destroy their own Bitcoins this way.  If you want to give them the ability to destroy money held by someone else, you could add a rule that a transaction signed by the central bank's key may spend any output.

In practice it might be better for the central bank to have a relatively large number of private keys, and a system to revoke specific ones in case they are compromised (perhaps with a special kind of transaction).

Of course, the hard part would be convincing people that this is a good idea, that your central bank is trustworthy, etc, etc.


How can i double spend from my unconfirmed transaction for more than 5 days

1. You could try child-pays-for-parent.

Your unconfirmed transaction with the txid 4e19db9b29dffd508073dd5d67ad8096559e28ef92da0eeb28fe85756396858c has two ouputs.
I guess 1CfSS3Q6UxCinGg82gzwm1M6LfaxUFUJh8 (value 0.05739491) is your change output...
You can use that change output as an input for a new transaction where you pay a high fee. Miners will then be interested to mine that new transaction but they can only if they also mine the old one (txid above).

You may use 2x the recommended

2. Double-Spend (harder)

Use -zapwallettxes=1 as Bitcoin Core startup argument.
Use CoinControl (enable it via Bitcoin-Qt settings)
Select your "blocked" input (1KDcKTBTLWnLUED6yMA4Huj5CfzgKfuvJF from 7aa1366669c3c836d7bf7abbc9b934af62bf669a250b66ccd2d72197aeafee35 0.0995BTC) in CoinControl and do a new transaction


What financial instruments are under development for Bitcoin?

Lots of people that we know about and probably many more that we don't know about are developing a diversity of financial instruments for bitcoin. What instruments exactly will depend on your definition of instrument.

Here is an interesting one:

cvToken:
An effort to stabilize the bitcoin price by pegging a token backed by a basket of commodities to it.


Bitcoin transactions cannot be reversed - unless you are sending coins to someone you know by mistake and they are willing to send it back - which in itself is also relatively unlikely.

If someone has sent money from your account without your knowledge, then they have got hold of your private keys. What wallet did you use? Is it local on your machine? Is it online - in which case you may have not set a complicated enough password.

Sorry about your loss but you need to make sure your wallet is secure in order to prevent this from happening again.


Bitcoind clear / reset my testnet to retest some things

Delete the wallet.dat file in your testnet datadir and restart Bitcoin Core. Note that this will destroy all of your coins.


How scalable is the current routing implementation for lightning?

I am not sure if scale is the term you are looking for when discussing potential problems with routing. But I will try to focus on scaling when giving the answer. That being said my answer would probably differ quite a lot if the question was asked differently.

The current routing algorithm is onion routing. The onions contain a path from sender to the receiver (decided by the sender - see below for more discussion on that) and are constructed to support as many as 20 hops. This means that we actually can scale to networks with a diameter of 20. (the diameter is the longest shortest path on the friendship network and is a topological property). Already with 21 nodes I could create a lightning network with the topology of a list and be unable to route a payment from the heads of the list to the tail with the current onion format.
This problem can easily be mitigated though by creating a new payment channel - changing the topology in a a way to decrease the diameter. My autopilot implementation suggests channels that decrease the diameter of the network.

So the problem boils down to how big can a network be to have a diameter less than 20? When looking at the strongly connected component of large networks like the web or the Facebook graph they all seem to have lower diameters which is indicative that the 20 hop limit should not hinder scale. However there is a correlation: the more edges we allow on a network with a fixed set of nodes the lower the diameter. Take a fully connected graph which has diameter 1 by definition in contrast to the "list graph" from above which has diameter n.

That being said the web graph and friendship graph on Facebook are believed too have on average about 150  edges per node (the so called Dunbar number). We already know that without channel factories and with current blocksize limits we would need decades to allow every person in the world to open one payment channel which would most likely result in a graph with a larger Diameter. Allowing people to open 150 channels takes 150 times that much time.

With respect to scale of routing there is not only the 20hops limit of onions. There is also pathfinding and related to that discovery of the network topology (aka the gossip protocol). Path finding boils down to breadth first search or Dijkstra algorithm which is a weighted BFS. Both algorithms have a runtime that makes part finding possible on graphs with billions of nodes on modern hardware in particular when using graph databases like neo4j (currently everything is stored in memory). If the network would grow beyond nodes for humans (e.g with IoT nodes) we might reach the limits of modern hardware to compue those paths.

As for the gossip protocol. Each channel needs to be announced to the peer2peer network. Since channels need to be veryfied / linked to a blockchain tx this should not be a problem. However the gossip protocol seems to be quite noisy. There is currently the million node Challenge run by rusty Russell that tries to stimulate what happens if the network grows.

Also there are potential other issues like the htlc limit of 483 concurrent htlcs per payment channel that might produce traffic jams (though it seems very unlikely and is actually a reason why to avoid these so called centralized hubs and why nodes should work on decreasing the diameter). Also the exact topology of the network is never known (only capacity of channels)

Regarding your second part  (how are the issues mitigated)
1. The biggest issue seems quick opening of channels. There was research by Christian decker proposing the concept of channel factories showing that we can increase the amount of channels we can open per block by a factor of 10 to 100.
2. As for pathfinding: I currently suggested JIT-routing which is a low level backward compatible improvement for path discovery. This path decovery mechanism mitigates the problem of not knowing the balance of channels when selecting a path. My proposal also included the suggestion to have nodes only store a local view of the network and create an overlay addressing scheme which could be used for routing tables (like it is on the internet) this would also mitigate the problem of storing the entire network.
3. The problems with the gossip protocol currently seem to have the highest focus by developers - look at rustys million channel challenge.

There might be more issues which I am currently not aware of.


bitcoin-qt ignored user input for fee calculation

I believe you're confusing units here, and entered a value intended as sat/vB in a place that expects sat/kvB.
Perhaps you intended to use 40 sat/vB (=40000 sat/kvB, or 0.0004 BTC/kvB), which would translate to around 10000 sat (or 0.0001 BTC) for a typical transactions.
When interpreted as 40 sat/kvB, it would be far below the minimal relay fee on the network (1 sat/vB, 1000 sat/kvB, 0.00001 BTC/kvB). The sender software you used may have rounded it up to 1000 sat/kvB instead, and used that - which may translate to 255 sat for a typical transaction. That is far below the current blockspace market rate, and may explain why your transaction hasn't even propagated (blockchain explorer sites don't even show it as unconfirmed).


wallet that does not abstract change addresses?

There are indeed wallets that allow a more manual and granular control of UTXOs, in my experience desktop wallets such as Electrum are more likely to have this feature. Mobile wallets are often more tuned for ease-of-use.

The best way to find something you like is to simply try a few and see what works best for you. Check out the Bitcoin.org wallet page, and always ensure you download wallet software from a trusted source, verify developer signatures, etc.

  I also want to see non-deterministic wallets just for education so that I can understand. When we need to make regular backups in non-deterministics wallets might apply actually making a back up of change adresses?

The backup of a non-deterministic wallet will include every address the wallet has used, including change addresses. This will be true whether or not the wallet shows the user the change addresses.


Is receiving address description public domain?

I don't know why the description cannot be edited, that sounds like an implementation quirk. You could try looking at the Electrum documentation or inquiring on the Electrum GitHub project, if nobody else here can tell you.
The address description is your reference to identify what invoice the address belongs to. Some wallets include the description when sharing the address as QR-codes, or even have separate fields for your reference and a message to the sender. Generally, wallet addresses are neither registered nor gossiped on the Bitcoin network, they are just transferred out of band from receivers to senders when the receivers indicate how they'd like to get paid.


Altcoin - genesis block - TypeError: __init__() takes exactly 2 arguments (3 given)

Run the following command in your terminal:

pip install construct==2.5.2

Then try to run the python script again.


Is it possible to use BitGo's wallet with other software (Electrum or else), what is the used derivation path?

Looking at the BitGoJS code it would appear that the derivation path is m/0/0/derivationChain/*.
Looking further, the derivationChain seems to be a code depending on the address type:
    [0, UnspentType.p2sh, Purpose.external],
    [10, UnspentType.p2shP2wsh, Purpose.external],
    [20, UnspentType.p2wsh, Purpose.external],

    [1, UnspentType.p2sh, Purpose.internal],
    [11, UnspentType.p2shP2wsh, Purpose.internal],
    [21, UnspentType.p2wsh, Purpose.internal],


Problem of colored-coins/assets and other coins with a parent/child relationship of paying for fees with only the parent currency

It's definitely a common problem found in a lot of those platforms that make it easy to create your own colored coin/token. Asking users to acquire the native token, such as Bitcoin with Counterparty and NXT with the Nxt blockchain, is usually not a good way to start off your relationship with that customer. Some people may be fine with it, but it greatly hinders mainstream use.

Ardor solves this problem with child chains that allow child chain creators to have the users on their child chain pay transaction fees in the child chain token. A bundler (could be the child chain creator) would collect these fees and pay the Ardor main chain for transaction processing. So, ARDR tokens would still be needed, but your users wouldn't need to touch it at all.

You would still need to re-distribute your acquired child chain tokens though, but the Asset Exchange that will be on Ardor will be a great way for you to sell them back to your users. If a USD child chain exists (kinda like Tether and USDT), then they could purchase those child chain tokens directly with those USD tokens, much like getting game tokens at the old arcade.


I have considered building a electrum usb-distro but the problem is it would be hard to keep it updated after each new release. However if there is enough interest I might do so.

Your best bet is to simply take a debian live-usb and install Electrum on it; you can follow the instructions for linux on the electrum site.

If you have any specific Electrum questions you are always welcome to join #electrum on freenode and ask your questions there.


Why does the mined block differ so much from the block template?

The version of the mined block is 0x2fffe000 instead of 536870912.

Many miners employ a strategy known as overt Asicboost. This strategy requires modifying the version number like the nonce, so we often see blocks that have strange version numbers.

Only 194 transactions from the block template are in the mined block, e.g. f0fcac28b1dec7b8e67f73229052639c58f7f175bdb87ea068f499a4728bb35d. The other 1257 transactions are missing.

Each node has a different view of the set of unconfirmed transactions that depends on how long they have been running, where they are located, and any custom rules that they are using. It may be that your node has not been running for as long as the miner's node and so it has not seen all of the same transactions that the miner has seen. It may be that your node is using different rules than the miner is, possibly due to different versions of the same software, or possibly because some miners may be using custom software. Additionally, some miners offer a service where they will prioritize transactions after being paid out of band, so such transactions can end up in a block when they do not appear in a block template produced by your node.

What would have happened if a miner found a block hash for the received block template and submitted it? Would the mined block then have a different version and the missing transactions (including the transaction that was not even mined yet)?

There is no "current template" for the entire network. If there were, then there wouldn't need to be a blockchain as that would mean every node is actually in sync with every other node. As such, when a miner finds a block, they broadcast the block in full. When nodes receive a block, they verify it without creating their own block template. There are no requirements that the block contain the transactions a node expects it to contain. The only requirements are that the block contains valid transactions and that the block header is valid. Whether your node has seen those transactions before and whether it would include them itself are irrelevant.


Can Bitcoin mining with my current specs break my PC?

I have no idea what "Windows Store app mining" is, but it may very well be a scam and malware, as it makes absolutely no sense whatsoever to mine Bitcoin on a PC. Malware can harm you and your computer.

If it's not malware, it will run your PC hot, causing more ware and tear and thus harming your PC by causing premature breaking of parts.

If nothing else, it will harm your wallet, as you'll be paying an increased electricity bill, while getting nothing in return.

In short: just uninstall whatever that thing is and check for malware some more. If you want to learn about real Bitcoin mining, you'll have to read up on the subject some more first.


promising 13k a day

It is almost certainly a scam. Stay well away from this.

  I need to play it safe ... I simply cant afford

Don't invest in volatile high-risk products such as crypto-currencies.


Blockchain receive payments API Network propagation

This is a shot in the dark, but perhaps you could get the raw transaction from Blockchain from http://blockchain.info/rawtx/$tx_hash and send it from your client with sendrawtransaction.


Best practice is not to split up your seed words.
There are many different clever ways one can store their bitcoin back-ups and the way you described might be one of those ways. It may work for you and that's great, but it isn't an approach that would be generally recommended or accepted.

The aim is to store the word list in several locations

Generally, it is recommended to use multisig if you want to split up any sensitive data that will be used to sign a transaction.
Alternatively, you can add a BIP39 passphrase that could be stored separately from your seed words.


The mixing service could use various means to obfuscate the mixing - for example:

It can make you send coins to some off-line address, then send you your coins from its own supply of bitcoins before introducing your coins into the circulation again. This way it would appear that the transaction took place before you send the coins to the mixing service, and thus be harder to link
The service could split your Bitcoins into many smaller amounts and launder them each individually
It could deposit some of your money into some eWallets or similar services that use a shares pool of coins
It could use your money to purchase mining hardware and mint you fresh coins
The service could pay your money back to a few of your receiving addresses, making finding the final amount harder

Generally, there are many creative options of hiding things in the Bitcoin network, you just have to use your imagination.


"SPV mining" refers to a bad practice where a miner starts hashing a new block on top of an unverified parent block. If the parent block turns out to be invalid due to a double spend or newly activated soft fork, the new block will also be invalid.

The term SPV in this case is used because the miner only verifies the headers of the incoming block and then immediately starts mining the next block.

This has happened on main net before: when BIP66 activated in 2015, a short chain of blocks was mined on top of an invalid block that did not enforce the new rules.

This question may be a duplicate:

What is SPV mining, and how did it (inadvertently) cause the fork after BIP66 was activated?


stuck transaction despite high fee - will it eventually be forgotten?

Most likely it has yet to be 'processed' by a miner yet. I can't tell you an actual definite timetable besides the usual 3days - 3+ weeks. It could clear sooner, but it just hasn't been cataloged and processed into and solved in the next block.


How public-key cryptography secures bitcoin transactions from 51% attacks and Mining Attacks

Public key cryptography has nothing to do with 51% attacks. The only thing a miner can do with >50% hash power is double spend bitcoins for which he controls the private key or censor transactions by not including them in the blocks he creates. He cannot spend bitcoins for which he doesn't control the private keys.


If you used bitcoin to buy "guns", how can the court legally prove that you, a person, are the owner of the key that made the transaction?

The Ross Ulbricht/DPR trial provides several examples of how you might prove that someone made a transaction:

Being the person who sells the product or service to them. For example, the "hitman" Ross hired to kill Curtis Green was actually an undercover agent.
Grabbing the laptop used to make the transaction out of the hands of the guy who made it, and forensically analyzing it.
Other ways, like having a confidential informant, (like Curtis Green) or getting them to plead guilty (like Carl Mark Force.)


How does bitaddress.org ensure unique address?

I don't know what bitaddress.org does exactly, but just take some numbers into consideration:

There are 2^160 possible Bitcoin addresses. If you generate an address from a key pair generated with a good randomness source, it is fairly impossible to find a collision.

In conclusion, they can ensure uniqueness just by the negligible odds of picking an address more than once.


If bitcoin is indivisible, where does change come from?

I like to suggest a mental model where the network is a metals forge:

You have a 1 oz gold coin stamped with your key on it, with your transaction you send it to the forge to be melted down and re-formed to two new coins, a .22 with Alice's key stamped on it and a .77 with a key of yours on it, and then the forge keeps the remainder for their fee.

You can't spend half your 1oz coin, but you can have the whole thing melted down into multiple, and perhaps many, parts.


What are the mechanics of verifying that an output transaction is not spent?

When the output gets consumed by a later transaction, who and how prevents this output from being consumed a second time? Do we go over all the transactions after to make sure it hasn't been used?

Full nodes keep track of all unspent outputs in the blockchain, known as UTXOs (unspent transaction outputs). This is the UTXO set. When a transaction in the blockchain spends a UTXO, it is removed from that set, and new UTXOs are added for the new outputs from that transaction. This happens every time a new block is received. If a transaction tries to spend a UTXO which isn't in the set, the node sees it as invalid. To that node, there is no difference between spending from a transaction which has already been spent, or one which never existed. Either way, there is no valid UTXO to spend from in the UTXO set, so its an invalid transaction.


Why was noise XK fundamental pattern chosen in the transport layer (BOLT 08) of the lightning network

First of all why not KK? Nodes are announced via gossip and on my tcp socket I should see who connected to me being able to look up the static key of my peer.

It isn't really possible to tell who is connecting to you based solely on the IP information you receive. The public IP information received over the gossip protocol only lists the listening endpoints which you can connect to, but this does not imply that those endpoints will be the ones connecting to you. In fact, they can't be, because the listening port requires a dedicated socket, so any outgoing connections from that IP would be on a different port. The port for outgoing connections is usually assigned automatically, although you can bind it to a specific local port explicitly, this is not common. You can't bind to the same port as the listening socket anyway, and if you're behind a NAT you have no control over the port the recipient might see at their end.

The IP address alone is not sufficient because you could have many nodes behind the same IP on a network, or due to NAT. It would be guesswork which node you think is connecting to you to try and pick the right public key.

Since the initiator's key can't be known for sure, the other options from the Noise protocol are N, I or X. We can rule out N because it does not provide the security guarantees you listed above, and I leaks information in plaintext which could be intercepted. X is therefore the most reasonable option.

For the responder's public key, we can again rule out N, leaving either K or X. We already know the key though, from the gossip network (or DNS), so there is little point on transmitting it also. Additionally, the recipient has a little extra information hiding because their public key is never transmitted.

The Lit project from MIT uses the XX pattern. I believe this is because nodes don't have information about public keys in advance because they use hashes of the public keys to identify nodes instead. Once the public keys have been transmitted, their hashes can be compared to the previously known public key hashes.

  Second of all why not using protocols without static keys? Is the reason that we wanted to have property 2 and 5 for initiator and recipient respectively?

The reasons are as you've listed from the Noise protocol document. The public keys alone are sufficient to have both encryption and authentication without relying on any third party for the security guarantees. Other protocols such as SSL have inherent points of failure - such as the PKI, which has been abused for many real world attacks on security. (In addition to it being a rent-seeking industry.)

  In that case I don't understand why key rotation takes place with HKDF and not a new handshake generating new random ephemeral keys.

The purpose of the key rotation is to prevent the decryption of older messages if the keys are compromised in the future. This could also be done with a new Noise exchange each time, but from a practical point of view it is more computationally expensive to do a handshake (multiple ECDH calls) than to produce new keys with the HKDF. There may be some other risks to it that I'm not aware of though.


I wouldn't use them to mine.

Since GPUs back then couldn't do arbitrary calculations, the only thing you can use are the CPUs. CPUs are relatively better at mining scrypt (e.g. Litecoin) than SHA256 (e.g. Bitcoin), so let's go with that. Based on the oldest CPUs listed (which aren't quite old enough) on Litecoin's wiki, I'm going to guess that each computer can do 5 kH/s, which is probably being too generous. So that's a total of 100 kH/s. Plugging that into a calculator, even with assuming (another probably-too-generous assumption) 500 W total are used (that wouldn't otherwise be used), you're losing money if you have to pay for the electricity and/or cooling. (making maybe $0.14 per day, pre-expenses)

For comparison, a modern GPU can mine around 1400 kH/s for ~500 W ($2.01/day pre-expenses). Or a dedicated Bitcoin miner could actually turn a profit ($4.84/day pre-epenses) in a reasonable amount of time (of course, you're basically betting on/investing in the future of Bitcoin by buying something like that, which involves a good deal of risk/uncertainty).


Is there a deterministic private-public keypair generator without the BIP32 private key revealing issue?

This is accounted for within the BIP32 specification, they are called 'hardened' keys. Hardened child private keys are derived from the parents' private keys, and revealing the hardened child private keys does not reveal the parents' private key.

Child indices 0...2^31-1 are reserved for regular keys (that have the problem you describe), and child indices 2^31...2^32-1 are reserved for hardened private keys.

Notation for a standard child:

m/0

Notation for a hardened child:

m/0'
m/0h


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

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

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


Why is my Bitcoin private key so much shorter than my PGP private key?

GPG keys are usually RSA keys.
RSA keys are based on the difficulty of the factorization. Keys are usually 2048 or 4098 bits.

Bitcoin uses ECDSA (Elliptic Curve Digital Signature Algorithm), where keys are usually smaller. Bitcoin uses the curve secp256k1 where keys are 256bits.

Roughly, an RSA key with 2048 bits offer similar security then a 256 bit ECDSA key.
Both offer more or less 128bit of "symmetric" security.

With newer versions of GPG you can also generate and use EC keys (nist-P, ed25519 or secp256k1)


Can 2 bitcoin-cli's use the same blocksdir

bitcoin-cli simply acts as a convenience interface to the JSON-RPC api of bitcoind - as long as you only have one instance of bitcoind using a given datadir, you can safely use multiple bitcoin-cli calls at the same time.


The order is 1, 2, 3, 5. There is no timestamping; the block itself provides timestamping via the proof of work.

Also, the step 3 is not 'mining', the whole process is what is called mining.


A multisig address is simply a redeem script of the form m <keys> n OP_CHECKMULTISIG.

This redeem script is then wrapped in a P2SH address, which is the HASH_160 of the redeem script presented in the format standardised in BIP16

For instance, a common multisig address is 2of2 (2of3 is also very common). An example redeem script is 522103c9078b8d06d83347b2e7e8cbbdfc24bd50e09ca1a4e5d90d70485a8c4094e5672102d52317afd128305d6fca7bd30b839e821564990c88581ebb432b478cfa95602f52ae, which decodes to:

2 03c9078b8d06d83347b2e7e8cbbdfc24bd50e09ca1a4e5d90d70485a8c4094e567 02d52317afd128305d6fca7bd30b839e821564990c88581ebb432b478cfa95602f 2 OP_CHECKMULTISIG

Producing a HASH_160 for the above redeem script gives us 4aef67ed61d391d6f3d9903ead92386c1efc9925, which when put in the P2SH form is a914(4aef67ed61d391d6f3d9903ead92386c1efc9925)87 (brackets mine).

This finally gives us the address 38XEixUj1QpcqxTWbxvqdbv4Mjre4imw9Z after a Base58Check encode.


how can I run multi wallet on one computer to share same blockdata

On Windows it wouldn't work because of file locking/sharing I suspect and on Linux that wouldn't be a problem but the data would surely get corrupted. There's no advantage to running multiple servers either, if you need to process more transactions than the server can handle then you should probably be doing it a different way or with multiple machines. If it's to help the network then one will do - leave it 24/7 and it will start to provide more than 8 connections if you allow it via config.


Why scriptPubKey is a series of commands?

Therefore, I am not quite understand why we need to save

Because scripting system allows more possibilities. https://en.bitcoin.it/wiki/Script#Scripts


How to get private key and Bitcoin address in pure Python - without modules?

You definitely want to watch this YT video made by Shlomi Zeltsinger:
https://youtu.be/tX-XokHf_nI
It covers the topic of getting randomized entropy and using hashing and RIPEMD to get private/public key pair and corresponding address.


To exchange between Bitcoin and popular alt-coins like Litecoin/Dogecoin you will need to use the first solution ('using revealing secrets of contract').

The second solution is designed around a hypothetical custom altcoin which is designed specifically to support the described exchange algorithm. I don't think that such an altcoin actually exists, but there definitely isn't support for this in Litecoin or Dogecoin.

There is a problem with the refund transactions in the first solution, however, with the current Bitcoin version, due to transaction malleability.

The problem is that refund transactions need to be signed before submitting base transactions to the blockchain, but the base transactions can potentially be mutated before they get to the blockchain, which would invalidate the refund transactions and prevent coin being reclaimed in the event of aborted exchange.

I discuss this issue in some more detail in this blog post, where I also look at a generalised form of the 'pay on reveal secret' transaction semantics in this exchange algorithm, and discuss other ways in which this can be implemented.

Note that it's possible to make this work in an embedded protocol, and then perform trustless exchange between blockchains with the embedded value tokens as intermediary steps. I've made a working version of this setup in the form of SwapBill, and this is set up and can be used, currently, for trustless exchange between testnet Bitcoin and testnet Litcoin.

  If atmoic cross chain trading is possible, are there any transactions in the blockchain where atomic cross chain trading has been used?

There are definitely SwapBill atomic exchange transactions on the Bitcoin and Litecoin testnet blockchains, but this is not really what you are asking. ;)


Who checks if the entire chain in valid?

1- I read somewhere that one of the purposes of blockchain is that you can't change the blocks of the past without recomputing the entire thing. Is that assumption correct?

Yes, that is correct. Each block builds upon (references) the one before it, so changing one in the past would require you to update (recompute) every block since then.

  2- Miner will find a nonce, giving a block data, to generate a hash that matches a certain difficulty. Is that correct?

Yes, a miner will vary the nonce/extra-nonce/transaction order/etc, until a valid block hash is found.

  3- So the miner knows a new block. But not the entire chain.

Incorrect. The valid block hash that the miner finds includes a reference to the prior block's hash. So in effect, the miner knows about the new block, and the entire chain before it, since all prior blocks are linked by their block hashes in this way. Each full node (which includes miners) will store a record of the blockchain so they can reference all new blocks and transactions against the blockchain history.

  4- Where in the flow and by whom in the network the entire chain will be exchanged so they need to decide which chain is better?

The longest valid chain is what the network's nodes will follow, which in practice means the valid chain with the highest accumulated proof of work.

  5- By the way, what is the best chain given two versions of them?

If two valid blocks with the same block height are found, whichever one is built upon first will be the winner. Please look up info on 'orphan blocks' to learn more about how this plays out.

  6- ok, the blocks are correct and the chain is valid everybody agrees with that. Who in the network checked if A that passed 1btc to B had 1btc to perform this action?

Each full nodes will check to ensure that all new transactions and blocks are valid, and they will ignore any that are invalid. Each node keeps track of where all of the bitcoins are located, a blockchain system has extreme redundancy. A full node operator can tailor their node to only store/relay certain types of information if they so desire, but all of the info


Can the outputs of a transaction change over time?

No. A transaction is composed of a sequence of inputs and outputs in a specific order. This data structure is hashed and makes its way to the Merkle root and block header, and thus if the transaction were to change, all the blocks that follow would be invalidated.

It's possible that a fork with a different transaction double-spending the same inputs would usurp the chain you originally observed (less likely the more confirmations it has); and the status of these outputs can of course change from unspent to spent.


Lightning Network Unidirectional Transaction

All channels on the lightning network are bidirectional, even if they are only used in one direction.  However, this does not mean that both parties contribute to the funding transaction.  In fact, in the current spec only a single party contributes to the funding transaction.

That said, your scenario is not a good use case for its own channel.  The overhead of a channel for the purpose of paying for a weeks worth of coffee if probably not worth it.  Most likely you'd simply route the payments over an existing channel and through other hubs and channels.


Do I need to run a full node before the 2X fork?

Your coins are safe on Trezor, you don't need to run full node for coins unless you want to help mine.

If you want to access Segwit2X coin or any other BTC forked coins (in future) asap after the fork, then you should transfer your BTC coin to a lite client and get the private key of that wallet.

Or else, you can wait until Trezor supports Segwit2X coin, in that case, you will get those coins in Trezor itself.


Exact definition of "Liveness" and "Safety" properties in a consensus?

Safety: Any transaction deemed final by one properly-operating node will eventually be deemed final by every properly-operating node. No two transactions ever deemed final by two properly-operating nodes will ever conflict.

Liveness: So long as there is always at least one transaction suitable for inclusion that has not been deemed final by any properly-operating nodes, the set of transactions deemed final by at least one properly-operating node will increase in number.

Note that these are very, very minimal definitions and generally not sufficient for realistic systems. Also, for some systems (where a transaction can produce different results depending on the context in which it executes), you have to understand "transaction" to mean the results of executing the transaction.


Bitcoind server strategy. How much disk space?

Hosting Bitcoind on a VPS is a very bad idea. I cannot stress this enough. The VPS provider will not have adequate security standards. You increase your risk profile dramatically as the combination of software running on the host server can cause a problem for you and your users. Please. Don't.

That said, if you do want to, it all depends on how transactions will be dealt with in the future. As a VPS is usually fairly flexible I'd take about twice the blockchain now, and just upgrade when you're above 80% disk space usage. That gives you some wiggle room.

You may consider using a light client, perhaps with increased connection count (more than 8). That will totally remove your disk space hunger and it's reasonably secure.


Does Bitcoin have inherent value if you can fork the project and create a new cryptocurrency easily?

Yes, this is a real possibility. Effectively, Satoshi Nakamoto created a billion dollar market-capitalization of currency out of thin-air. Of course major corporations are going to attempt their own flavor, it is the nature of capitalism and it is a very healthy reality, which ultimately ends with a satisfied consumer. Progressive companies are forking it, prototyping new designs, and adding improvements. In the end, the quality, scale and technical effectiveness of your product will create the market-demand absent of billion dollar promotional marketing campaigns. BTC is a purely organic, community driven crypto-currency which sells it self.

Currently, the infancy of BTC is very analogous to early 20th century automobile manufacturing. There were hundreds of car companies created in the US only of which 3 major manufacturers survived (Ford, GM, Chrysler). Analogous  to the rise of a myriad of crypto-currencies each of which claims to be better than the previous. How could you trust these crypto-currencies...? That is an unanswerable question which only the market will decide in the coming years.

BTC is the first and most secure crypto-currency; its design and function are superior to many  other proprietary builds.


How to access Bitcoin's transaction database?

The best way to write a parser of your own for the blockchain is to find the source code of one that already exists and from that deduce the precise underlying data structure and how to parse and interpret it.  e.g. here in C++ and here in C# - and there are many others.

The data in the blockchain is stored in a custom binary format that is a little tricky to untangle without some help; this link seems as good as any to get started on the overall structure.

There are many"gotcha's" to watch out for.  For example:

'endianess' i.e. having to reverse binary digits before interpretation and
some of the interesting values associated with a transaction have to be calculated e.g. for addresses
'big numbers' where the numbers used internally are so huge you may need custom code/libraries to deal with them

Comparing your results to those that are freely available via the blockchain and blockexplorer as well as the bitcoind.exe API would be a must.  Otherwise it is easy to pull out seemingly valid transactions that are just nonsense.  I speak from experience.

While writing your own parser for the blockchain is a worthwhile learning exercise you would be much better off IMHO using the bitcoin API and ignoring the underlying blockchain database for any 'real' code.


How to convert Bitcoin cash address to cashAddress Format in PHP?

You can do it by decoding address from base58 then spliting it in version bit and payload and then assemble it into cashAddress and calculate checksum or if you want there is another project on github that claims to do that Har01d/CashAddressPHP maybe you should git it a try


The Mystery: I've mined some BTCs with Bitcoin Core 0.9.0, however the system no longer synchronizes and in the blockchain the balance is zero

As outlined in the comments, there's a couple of possibilities here:

You downloaded a very old version of Bitcoin Core, and managed to end up on a private chain where CPU mining is possible, and the chain is still new enough that the block reward is 50 BTC
The program you downloaded is a Bitcoin clone and gives the illusion of paying out 50 BTC or more, while either stealing crypto keys from other wallets on your computer, or later on asking you to pay some kind of recovery or unlock fee to claim these mined coins.

In either case, there is no Bitcoin. The block reward has not been 50 BTC for many, many years now (it was 12.5 BTC in 2019, and is currently 6.25 BTC in July 2020). Regardless of what method you used to mine, it is simply impossible to have a 50 BTC block reward dated in 2019 on the Bitcoin mainnet.
In short, you're either being scammed, or are mining on a private Bitcoin network with no relation to the public mainnet.
As Murch said in the comments below, you should definitely NOT use any address generated by this software to receive Bitcoin from an external wallet, exchange, or other service. All of these will send you real, mainnet Bitcoin.
As your version of Bitcoin Core is, at best, on a private network, you will not be able to access any externally received coins until you move your keys into a legitimate wallet that connects to the public Bitcoin network.
At worst, you're running some form of malware, and any real coins sent to addresses generated by this software will be stolen by whoever wrote it.


Where is the "New Genesis Hash Generator" code in newest Bitcoin source code?

Problem Solved!

The new genesis generator locates at "chainparams.cpp"


Is a 'seed phrase' independent of the type of wallet?

First of all, some software wallets imports are supporting only 12 word or 24 word combinations.
Some support different BIPs and thus path derivation schemes (32/44/84) by default, and some only single one of them.
Some have additional feature for a specific seed passphrase.
All of the differences you can check on https://walletsrecovery.org/

So to answer your question, you have to install the wallet that uses the same seed format and path derivation as the one you've originally created.


Should a node follow the longest chain, or the chain with most work while syncing?

Nodes follow the chain with the most cumulative work, not the lowest hash of the latest block (which would be most work for the current block).


How does tax work with crypto Debit cards?

Is there a specific rule on this in the EU?

According to https://nomoretax.eu/bitcoin-taxation-developed-countries/

The fiscal treatment of Bitcoin for tax purposes differs depending on EU country.

how do I even know or calculate my taxes?

By consulting material published by the tax authorities in the country in which you are resident (and US as well if a US citizen resident outside the US).
By consulting a tax adviser.
By contacting the local tax authorities and asking them for advice. (In my country at least, they are friendly and helpful to people seeking advice).


How to retrieve all transactions from a public address?

You can't. Bitcoin Core does not index transaction based on address.

If you want to do this, you'll either need an indexing tool/service, or implement the P2P protocol yourself to be notified of all transactions.


Are there any resources for creating your own coin?

I recently heard of www.coingen.io which enables to create your own crypto currency within minutes for minimum fee. (For minimum fee regarding the the you will be spending creating your own coin c. 50 USD)

I would like also to inform you that if you are seeing any investment/profit potential that we already have more than 100 so called altcoins which are all almost the same with minumum differences.

If you are a bit programming skilled the complete guide is on bitcointalk forum.

Commit this code on GitHub


What is the algorithm behind multisignature address and redeem script?

I stole most of the answer from Andreas' book :-)

The bitcoin developer docs provide this link here, which goes over P2SH to multisig. The idea is to create a so called redeem script, which is a ripemd160(sha256(sigscript)).

Example from the book:

Redeem Script:    2 PubKey1 PubKey2 PubKey3 PubKey4 PubKey5 5 CHECKMULTISIG
Locking Script:   HASH160 <20-byte hash of redeem script> EQUAL
Unlocking Script: Sig1 Sig2 <redeem script>

see Andreas' book "Masterig Bitcoin, 2nd edition", page 152ff or in the GitHub version here.
The real book at http://chimera.labs.oreilly.com/books/1234000001802/index.html

  how to create multi-signature address and redeem script without using
  bitcoind? What algorithm is used?

you can use any hashing tools or libraries, Andreas shows with the "bx" library, openssl would do as well.


How does BitPay manage to confirm transactions so fast (less than a minute)?

BitPay takes all the risks of a double-spend and they don't wait for any confirmation to make the user feel good with the purchase. The merchant doesn't care because they'll receive fiat and most of them are not direct access purchases.


Does descendant size affect transaction fees?

While calculating the Transaction fee miners usually take Ancestor size into the account. But does the descendant/Output also effect the transaction fee calculation?

The descendant transaction(s) do not restrict the inclusion of the examined transaction in a block, while the ancestor transaction(s) do. Hence, it would seem rational for the miner to only do extra computation for ancestors (in addition scanning both ancestors and descendants for each transaction means walking through each transaction twice).

  Are Descendants Count correlated to Transaction fee in any way?

"Any way" is pretty broad :

Regarding miner incentive no
Regarding mempool logic and relay policy yes


Is it possible to create a cryptocurrency that has a fixed value?

A fixed value, relative to what? To a fiat currency? In which case, should it be US dollars, euros, yens, yuans...? Relative to a commodity such as oil or gasoline of some quality? Relative to gold, silver, platinum, diamonds? A basket of all the above? All of these have very variable values and both the reasons of their intrinsic volatility and the possible remedies for that are far above your capabilities.

Creating a crypto-coin with a "stable" value relative to whatever you want to track it to (for tracking it absolutely to yield a fixed value is impossible, unless you control the other stuff) depends not on the crypto-coin's algorithms per-se but in the market - you'd be forced to create an exchange of last resort and be willing to spend a lot of money fighting people who'd try to move the price way too up or too down on purpose to cash a quick buck after the distortion, or simply are trying to attack your coin to destroy it or harm you. You'd need very deep pockets, much technical expertise and a lot of luck.


Why did the Mempool suddenly drop to zero

It didn't goto zero. You can look at alternate sources https://core.jochen-hoenicke.de/queue/#2d . What happened most probably is that blockchain.info's node went down/rebooted momentarily.


How do Bitconnect Creators Hide their Identity?

By using services† that either do not ask their customers for identification or which do not adequately verify proffered identification.

By paying for those services using payment methods which are anonymous, or at least pseudonymous (e.g. Bitcoin, pre-pay debit-cards, fiat cash, ...).

† domain-registrars, web-hosting, ISPs etc


How can I speed up payments to my c-lightning server?

Lightning needs very little computing resources so the hardware in use is most certainly not the issue and has very little impact at all.
The described difference in time between the sending and receiving node is normal, to be expected and cannot be changed. The reason is that the payment/routing process works by selecting a path along which HTLCs are tried to be set up to the recipient. As soon as all HTLCs are set up, the money
has arrived from the recipients point of view. However, from the sender's point of view all the HTLCs need to be settled. Setting up an HTLC and settling it takes about the same time within a single channel. Thus in the case that a path with enough liquidity was used the payment is finished in half the time for the recipient as for the sender.
Setting up and settling HTLCs is mainly bounded by a cryptographic handshake that needs 5 messages to be sent over the wire between the two peers. Thus, the wall lock time of a payment on a path with enough liquidity will be faster if it includes fewer channels and if the peers in every hop are network-topographically close, which might yield a potential for optimization. As a rule of thumb, you can assume 100 ms for a single message and since a round-trip takes 10 messages you can expect roughly 1 seconds per included channel from a sender's point of view.
The above mentioned things assumed a path with enough liquidity. However as described in this paper the balance values are unknown so we have a random process.
Currently, nodes try to find the cheapest path. The paper suggests that you can reduce the number of attempts significantly by trying the most likely paths (roughly those that are short and have more capacity).

Overall yes, your position in the network with respect to topology and the method for selecting paths makes a difference and might be used for performance tweaking. As nodes have not implemented probabilistic path-finding yet, this would require custom code. It might even make sense to keep the same number of attempts and instead prefer geographically shorter links though I would focus on selecting paths that minimize the expected number of attempts.


Bitcoin wallet for Symbian operating system?

CuteCoin might help

There is a project in GitHub that apparently provides a Symbian3 Bitcoin client using InstaWallet. See https://github.com/Matoking/cuteCoin for source code.

There is also some supporting discussion about Symbian on the forums here:
https://bitcointalk.org/index.php?topic=26154.0


Since Electrum is a deterministic wallet having a copy of the seed is sufficient to get access to the coins. However if you also want to be able to restore the meta data in the wallet file such as the transaction and address labels and your contacts you need to periodically backup the wallet file too.

You can save a backup copy of your wallet file via file menu > save copy. Alternatively you can have your backup program grab the wallet file from the wallets directory.

If you're worried about your house burning down then do as @willtech says and keep a backup of your seed and/or wallet file in an off-site location. Cloud backups of your password protected wallet file are another option.

Note: Electrum doesn't store your wallet file, seed or private keys on any server.


any way to recover lost qt bitcoin wallet?

Hi is there any way to recover my Bitcoin-Qt wallet with only an address and the wallet password?

No. I can't think of a secure way for the Bitcoin developers to add recovery method like that, either.

  Unfortunately my disk was formatted.

Do you mean that the space containing your wallet was overwritten, or that the space at the front of the disk that tells your computer how to read the disk was changed?

If it's the second one, your Bitcoins might be recoverable.


What is the reason for halving the rewards?

Because the block halving incentives getting into Bitcoin NOW, rather than later. Early birds take more risks and get more rewards. Otherwise the network would have problems getting enough miners involved in the first place.

Asides that, there is a concept of inflation and deflation - we have already experienced the first one, so we might as well try the latter one.


What are the advantages to become a bitcoin node?

There benefit is that you operate a full node in the Bitcoin network. Yes, this is your premise but it's also the consequence of it. You merely seem to not understand what operating a full node means.

If you don't operate a full node, you put trust in others. How much trust you put in others depends on the specifics.

For example, a person who uses a web wallet puts full trust in the operator of that web service. The operators are not only in control of what blockchain is regarded as the effective one but are also in full charge of the user's funds as they hold their private key.

As another example, if you use an SPV client, you don't put as much trust into other. You don't give the privilege of spending (or not spending as you please) your money to a different entity. However, you can be fooled by someone who puts a lot of work into it. That this is going to happen is very unlikely, but it is possible.

Only if you operate a full node, you don't have to trust other entities. You are in full charge of your money. You cannot be fooled by someone sending you an invalid blockchain because you verify everything. You cannot be told that a transaction to you has been confirmed even though it hasn't because you yourself are the authority you get your information about which transactions have and which have not been confirmed.


Issue resolved. I chose to exclude it as it was no real purpose.


Instead of getblockcount, you can call getblockchaininfo and read the headers field.

However, while this may give you a lot more blocks than the local block count, you will still only receive a count up to the point where your node has synced headers (which can be limited by time, network, how well synced your peers are)

There is no way to always get the latest block height reliably from an unsynced node.


Bitcoin Core compiled "bad91-dirty" version

The "51bad91" may be a bit misleading here, it's just coincidence that it says "bad". It's actually just the most recent commit on the 0.15 branch, https://github.com/bitcoin/bitcoin/commit/51bad9195eb435200626beccbaf6b60774a4a894

The -dirty suffix is added during the build here:
https://github.com/bitcoin/bitcoin/blob/master/share/genbuild.sh#L38

I believe that just means that the most recent commit on the 0.15 branch (the 15bad91 commit) was not tagged (i.e. part of the actual 0.15 or 0.15.0.1 release, it is on that branch in preparation for 0.15.0.2).

Thus you should be able to avoid the -dirty suffix by checking out the version tag rather than the branch, i.e. checkout v0.15.0.1


How could you differentiate if the bitcoin address is from master node or derived nodes?

I assume this question is about whether other people can tell whether there is a relationship between these two addresses:
Just from the addresses, third parties cannot tell that the two addresses are related.

Third parties may be able to guess that they are associated by analysing the transaction graph, though.


I'm developing on the Test network. Are there any "rules" or communication methods I should adopt?

Testnet code has been modified to lessen the impact of fluctuations of hashing power mining against testnet:

http://github.com/bitcoin/bitcoin/pull/686

If you wish to test against your own testnet, or think you might interfere with others needlessly, then Testnet-In-A-Box is for you.

Now this doesn't mean you shouldn't use Testnet -- especially if you find something you think might be disruptive to bitcoin.  Feel free to verify your suspicions on Testnet even if it slams it hard.  That's why it exists.


which transactions does bitcoind validate?

1, 2 and 3.

Transactions that arrive through inventory announcements on the network are validated completely by checking the form of the transaction for sanity, executing the script, checking signatures, ensuring that the outputs they are spending actually exist, and that the transaction doesn't end up making negative values anywhere. If they are accepted they are added to the nodes memory pool where they wait for inclusion in a block.

Additionally, non-consensus rules are applied to bare transactions known as IsStandard. On the production network only a small subset of transaction types are "standard", this includes P2SH (pay to script hash) and P2PKH (pay to pubkey hash, or an address), but not raw multisignature and other scripts. Transactions that do not pass are not accepted but relaying a non standard transaction is not a bannable offense.
After validation, IsMine is run to check if the nodes wallet (if it exists) has the keys which own these transactions, of it they have been added as a watching address, if they do they are marked as unconfirmed in the wallet file.

Transactions that arrive in a block are completely validated, along with the rest of the structure of the block. The proof of work is checked, the size and form of the block is checked, the merkle tree is validated to contain all the transactions it claims to and that it connects properly with the header. Every transaction is validated, same as if it had arrived from the network. If they are found to be invalid the entire block is thrown out and the peer who relayed the block is banned from connecting. If the block is valid, it is committed and written to the unspent outputs database, additional undo data is written to file if the accepted block is ever needed to be undone.

IsStandard does not apply here, any transaction that is valid is acceptable when it is included in a block.
IsMine is run to filter out any transactions relevant to the wallet or watch address (if present), and updates the wallet with confirmations if necessary.


I want to be able to control how the different nodes are
interconnected to each other in this network. Is there a way to do
this on Bitcoind?

As per bitcoin.conf I suggest setting up the connect = X.X.X.X flag on your nodes. It will enforce connecting only to the peers specified by you. Not sure if this is the answer you are looking for though?