How could the dogecoin increase the limit of money supply?

The amount of bitcoins is not set by a hard coded limit, but indirectly through the rules of Bitcoin's reward schedule.
Bitcoin's reward started out at 100 bitcoins per block, and halves every 210,000 blocks (approximately four years) until the block reward drops to less than a satoshi when it just stops.

On the other hand, Dogecoin's reward will only halve five times.
Then instead of halving again, it will go to a flat reward of 10k dogecoins indefinitely starting from Block 600,001. Therefore, it will continue to grow slowly without limit.

Also see my answer here: Reward schedule and maximum number of dogecoins?.


Save state to the disk at abrupt bitcoind shutdowns

I think bicoind save the state of the last block because it can access to DB and read the last block stored into DB.

also, I have noted when running bitcoind, it runs some previous bock (I don't know the motive)
This is the log of the bitcoind

2019-08-22T10:51:33Z init message: Rewinding blocks...
2019-08-22T10:51:36Z init message: Verifying blocks...
2019-08-22T10:51:36Z Verifying last 6 blocks at level 3

ps: If you kill the process bitcoind without stop command you can corrupt some file blk and inside it, the client bitcoin can store trash data


Are Namecoins obsolete with the upcoming Bitcoin 0.9?

Well, the fact that it will be possible to implement features similar to Namecoin that it will become obsolete.

Bitcoin is intended as a currency and a payment system, while Namecoin is designed specifically as a DNS provider for .bit domain names.

The fact that Namecoin would be able to handle .com domain names, doesn't mean the currently employed centralised DNS would become obsolete either. (OK, some may argue it does, but Namecoin is not going to replace centralised DNS providers.)

Namecoin is intended for a very specific goal. Be a decentralised DNS for .bit domains. Existing proxy applications exist to map .bit domain names to IP addresses using the Namecoin network. The fact that it would be possible to replace all those programs with an alternative program using Bitcoin makes little sense. Why would a payment system take over the functions of a DNS system?


The transaction spends an output which itself is unconfirmed, it means there's a chain of requirement back two transactions which may or may not be completed. In this case, one previously must be confirmed before this one can enter a block.

  If this finally process will it transfer to my wallet or reverse to sender account?

It may be confirmed, it may never be confirmed, or it may be invalidated by a double spend, there's no way of knowing this in advance. In general this is why the advice is to never give payment for an unconfirmed transaction, until it has a reasonable number of confirmations there is no assurance it will ever confirm. With LocalBitcoins in particular there is an internal escrow tool which you can use to avoid this in the future.


If the transaction has been confirmed there is nothing to do and that is probably your situation. If not (due a small fee) then you can pay yourself with a higher fee to "block" the previous one.


Bitcoin Torrents lets you use their uber-fast servers to download a torrent.  Then you can stream it from there at a consistent rate.  Very nice idea!


If I buy crypto on a third party site, such as Coinbase or any other sites, how do I safely transfer my wallet into an external 'cold wallet'?

The coins are not stored on the USB drive, they keys that can spend the coins are.
An 'encrypted USB' would likely not constitute a 'cold storage' device, that term is usually used to describe keys which have never existed on an online device. If you use your (online) computer to generate keys, and then store them on a USB drive, that would not constitute 'cold storage'. Generating and storing keys offline is a best practise, because it reduces the risk of an attacker stealing your keys over-the-wire.
So a lot of your security comes from how the keys are generated, as well as how they're stored. 'Hardware wallets' are devices that are built to provide a mix of security and convenience that many users find appealing, if you are new to all of this, they might be a good choice. For the more technical user seeking extreme security, there are more advanced setups possible (sanitized general-purpose hardware, multi-sig using multiple devices, etc).
Once you've purchased coins, you should be able to initiate a withdrawal from the exchange service, by copy/pasting your 'receiving address' from your wallet software, into the 'send/withdraw/etc' field on the exchange service's website.
Note that some services do not allow you to withdraw your bitcoin (eg, paypal, robinhood), so these are obviously terrible places to purchase bitcoin, that should be avoided at all costs.


What Software Patterns does the Bitcoin source code use?

i don't think you can find many Object Oriented Design Patterns in the btc-source-code. but there is one example i know:

the blockchain itself is like a composite pattern:
you have a general type called Block. two types inherits Block: MinedBlock inherits from Block and GenesisBlock inherits from Block. A MinedBlock has one attribute of the type Block called PreviousBlock.
(here you can also find the singleton pattern: you need exactly one GenesisBlock-object.)


will the shorter chain still be published?

Published -- no. However, if the stale tip was previously the best tip, it will be stored in a Bitcoin Core node implementation according to the source and other nodes can retrieve it up to a certain point in time. The time limit is imposed to avoid fingerprinting.

  Does the network still synchronize the shorter chain.

No, the node only ever extends the active chain.


Pros / Cons of using the new bc1xxx segwit address vs the 3xxx segwit address?

Properties of the address format (Bech32 vs Base58Check):

Pro: Better error detection (up to 4, and sometimes 5, characters can be wrong and the sender software will always detect it)
Con: Longer
Con: Not all software supports sending to such addresses

Properties of the output type (native segwit vs P2SH-wrapped segwit):

Pro: Slightly cheaper to spend money received on such an address (no P2SH overhead)
Pro: Very slightly cheaper to send to
Con: Not all software supports creating such addresses


What is the point of downloading the blockchain?

Some good reasons to download the whole blockchain:

You can verify the entire blockchain and confirm the longest chain. This means you literally have to trust nobody. You can verify everything.
Along the same lines, you don't have to trust anyone about the actual balance in your wallet. It's impossible to know for certain unless you have the entire blockchain.
You contribute to the bitcoin network by being a relay node that verifies transactions and passes on only what's standard or has enough fees for the age/size of the transaction.
If you run SPV wallets elsewhere, this will mean you have a trusted place where you can find out about various addresses and transactions.

Basically, it comes down to, do you want to trust someone else or do you want to see it for yourself. Trusting others works if you have a big enough pool of other people, but it doesn't work if there's only a few, so that's why you would have the entire blockchain on your computer.


Is there a decentralized zk-SNARK (zero-knowledge Succinct Non-Interactive ARgument of Knowledge)?

Here's Zcash's multi-party parameter calculation code, which...

  ... used a multi-party computation protocol with the property that the resulting parameters are secure unless all of the participants were dishonest or compromised during the ceremony.

By the way, you might find Bulletproofs more interesting which is newer and doesn't require a trusted setup.


How is proper fee rate got on Bitcoin Cash

The minRelayTxFee (which despite the name is a feerate) on BCH is 1000 satoshis per kilobyte or 1 satoshi per byte.

BCH has a blocksize limit of 32 MB and has generally had only a very small portion of the blockspace used. The current 7-day average is 27 kB blocksize. It rarely even peaks to 400 kB.

 via fork.lol

Given that BCH is currently using about 0.1% of its available blockspace, there is no need to pay a higher fee rate than minRelayTxFee.

Hence, I would recommend not to spend more time on research, but instead simply hardcode a fee rate of 1000 satoshis/kB. If you want to play it safe, you can go with 1500 or 2000 satoshis/kB. In the unlikely case that BCH traffic picks up enough to fill blocks, software support should probably improve at that time and you'll be able to reevaluate then.


This appears to be a problem with the way Blockchain.info measures the network propagation. Blockchain.info is not connected to all nodes in the network, it just connects to a random sample of the nodes.

So if during the propagation new connections to more nodes are opened then they may also inform Blockchain.info of the existence of the transaction, so they will be counted as well. The same goes for clients that disconnect after the announcement, they will be counted towards the announcements but no longer to the sample size.

A practical example would be that Blockchain.info has 100 connections open. Now a new transaction shows up, the nodes will start informing Blockchain.info about this transaction. While this happens 20 new nodes connect and also inform it about the transaction. So in total it gets 120 announcements, and if BC.info uses the number of connections when it first saw the transaction we get 120% nodes that saw it.

The same is also possible for disconnections. If BC.info starts out with 120 connections and while it measures the propagation of the transaction 20 nodes disconnect after they informed BC.info about the transaction it has 120 announcements, for only 100 open connections at the time it calculates the propagation.

My guess is that the second method is used. Also BC.info had some connection issues lately so a 20% fluctuation in the number of connected peers is not surprising.


Can an account define conditional tags to blockchain

Not directly.  The Bitcoin protocol doesn't allow you to place restrictions on how a transaction can be spent.  The input script doesn't get to see the output script.

However, the net effect of what you describe would be as follows: after B decides to send the funds, they are in the control of C, who can spend them as desired.  In other words, the approval of both B and C is needed in order to move the funds onward.  You can get this effect with a 2-of-2 multisig transaction that requires signatures from both B and C, and can then be spent in any way they agree to.


You could check https://github.com/Blockstream/esplora
I think it ticks all of the boxes, I am not sure about the NBitcoin though.


How to create a receiving address using the Bitcoin Core client?

Click "Receive" tab >>> Click "Request payment" button

Note: "Label", "Amount" and "Message" fields are optional

View Receiving Addresses: "File" >>> "Receiving addresses..."


0 connections now, but I had been using Bitcoin QT for a while without problems

By using process of elimination , I would do something like this.

First, I would reinstall your Bitcoin wallet and see if it works. If it works properly, there was probably a Bitcoind configuration file that was messed around with in your original installation or you were using an outdated version.

If it still doesn't work, install a Bitcoin wallet on another computer on your network and see if it works. If it works, than probably there was something wrong with the Windows configuration (maybe firewall or antivirus program is blocking access). If it doesn't work, there is something wrong with your network (may be problem in your router, or internet provider)

On a side note, I wouldn't recommend running a wallet on Windows XP if you plan to keep any Bitcoins on it, due to it being incredibly insecure since Windows stopped supporting it.


What are some valid ways to obfuscate the scriptPubKey?

You can insert two OP_HASH160 after the OP_DUP and then push the hash of your pubKeyHash. Nobody can tell the recipient address this way.

Example:

OP_DUP OP_HASH160 OP_HASH160 double_double_hash OP_EQUALVERIFY OP_CHECKSIG

Where

double_double_hash = RIPEMD160(SHA256(RIPEMD160(SHA256(pubKey))))


Are you aware how much hashing power you need to stand a chance to solo mine? In case you don't the rest of the answer is moot and you'll need to study the topic of mining some more.

Yes you'll need a full node. You don't necessarily need port-forwarding though. Full node means you validate the full blockchain and has nothing to do with network connectivity.

A full node is more like 60GB disk space at the moment and will likely be >100GB within a year.


1) Click Finder.

2) Press CMD + SHIFT + G

3) Paste this and press enter:

~/Library/Application Support/Bitcoin

Your wallet.dat should be there.


Why does bitcoind (0.7.2) give an error when trying to issue getrawtransaction over RPC?

That particular API client library does not yet implement all calls that are exposed by bitcoind. See the API documentation for a list of calls that are implemented.

The problem is that your Bitcoin client knows about getrawtransaction but the python library you're using to connect to it does not know what to do with it yet.


Are there any non-Java, web-based, embeddable miners?

Some quick Google searching uncovered these:

Bitcoin Plus Bitcoin Miner for Websites
Hamiyoca
jsMiner

The general feeling, though, is that it is impractical.


The amount of memory that scrypt uses can be adjusted to get the desired behavior. If a particular CPU has enough L2 memory to hold all that's needed for a particular scrypt use case, then the performance of system memory will not be relevant. Scrypt-based coins can increase the memory requirements dynamically as one way of increasing the mining difficulty.


The transaction doesn't seem to have propagated through the network, meaning that not many nodes know about it.  I personally am not sure what to do about that, if there is anything you can do about it.

You could try having the person who sent you the coins restore their wallet from a backup, rescan the blockchain, and send you the coins again.  I think you might be able to get them through like that.  I would recommend having them put a transaction fee on it, though.  That should help it get put into a block quickly.


How come this formula predicts more than four years to the next halving?

The formula is correct - a halving occurs every 210000 blocks. If the average time between each block is exactly 10 minutes, you wind up with a total time of about 3.995 years.

However, if blocks are mined slightly slower, you will take slightly longer than 4 years - if they are mined faster than 10 minutes, it'll take less than 4 years to get to the next halving.

Predicting the next halving's date right now is pretty much impossible, as it would vary immensely based on hashrate and difficulty changes over the next few years.


Does bitcoin / blockchain provide any protections similar to credit cards such as chargebacks?

Does the system record and link the record of my bitcoin spend to the product I'm buying? If so, how?

No. But entities (like governments, secret services, companies, or individuals) my attempt to do so.

  Does bitcoin/blockchain at least record the total transaction such that I have at least a contractual right to the product I've purchased?

Total transactions: Yes. As in "total number of transactions in the blockchain".

As in "total transactions you ever made": Your wallet records this. Bitcoin does not provide a way for you to prove that you purchased something (Does anything actually provide a way to proof this? I don't think so.) but you can prove that you're in possession of the private keys necessary to have made a certain transaction.

  How can I be sure I will receive the product I purchased in a timely fashion (or at all)? Why wouldn't the vendor just keep my bitcoin and tell me to get lost?

You can only believe in promises or have a contract assuring you that (e.g. a promise by or a contract with the trading platform you're using). The currency you're using doesn't matter at all for this.

  Consumers use credit cards BECAUSE they are protected against such ripoffs via chargeback and other rules. I gather bitcoin/blockchain doesn't provide such protections. Are we talking about 'caveat emptor' aka let the buyer beware? If so, that's fine for small purchases but sounds hopeless for any purchase where I can't afford to be ripped off.

You seem to confuse currencies and payment methods a lot. Have a look at this answer.


Why there are blocks with single transaction in blockchain?

No, it isn't any kind of abuse. You don't have to worry (well perhaps a bit) about 'transaction starvation' (i.e. transactions that get never included because miners refuse to include them), as it is unlikely that one person (or more cooperating) will obtain 51% of the hash power. And even when they obtain 51%, they will be basically cutting themselves from the potential fees involved (and huge investment is required in something that could become worthless after abusing the system, because as a result the trust in bitcoin and therefore its price will fall). Only very large organisations like governments or international banks could potentially pull such trick to bring bitcoin in discredit and recover the loss. To counter this, several solutions have been proposed, such as proof of stake (in contrast to bitcoin's proof of work).

As for why these particular blocks do not contain any transaction at all: I don't know. I don't think there is any special reason for it, but I could imagine that by chance some of these blocks have less or no transactions (don't think that's the case here) or that some independent miner simply did not bother to include any transaction because of the low fees involved.


How are newly created bitcoins are validated?

The first transaction of each block is special according to the Bitcoin Protocol, and people give it a special name: generation transaction (because it can generate new bitcoins) or coinbase transaction (because it's the only transaction to contain a field called the "coinbase" [the company Coinbase is named after this field, but is otherwise unrelated]).

Generation transations have the following rules (among others not relevant to your question):

One, and exactly one, generation transaction must be present in every block.  (If you've ever heard of "empty blocks", that just means a block with nothing besides the generation transaction.)
They can only have one input.
That input "spends" an output (outpoint) of all zeroes.  This doesn't correspond to any actual transaction output.
That all-zero outpoint is considered to contain the newly-generated bitcoins (subsidy) for this block as well as the transaction fees paid in this block (fees), which are collectively known as the block reward.
The special input has a field called the coinbase field where the signature script (scriptSig) would go in a regular transaction.  Anything put in this field is validated like in a normal transaction, but in the original Bitcoin protocol, miners were not required to put anything in this field at all---they didn't need to provide a signature since the only person who could've created this transaction as the first in the block was the miner themselves.  Since them, BIP34 and BIP141 have changed the rules somewhat, but not in a way relevant to your question.  Also not particularly relevant, the coinbase field is limited to 100 bytes in length.

Actual validation works like this:

When a node receives a new block, it starts by looking at all of the transactions besides the generation transaction.  It calculates how much transaction fee they all pay.
Then the node calculates the amount of new bitcoins (subsidy) the miner is eligible to claim, for example 50 BTC for the first 210,000 blocks or 12.5 BTC as of this writing (blocks 420,000-629,999).
The node adds these two numbers together.  This is the maximum amount of block reward the miner can claim.
Now the node looks at the generation transaction, makes sure it follows all of the other rules, and validates that its outputs spend a total of less than or equal to the block reward computed above.

Of interesting historical note, the generation transactions in over 1,000 blocks did not claim all the block reward they were eligible to claim.  This seems to have mostly occurred early on.  What happened to those bitcoins?  They can't be claimed by the miners of those blocks after the fact and nobody else can claim them, so they're permanently lost.


What does the transaction version byte mean?

Firstly, the version number is actually 4 bytes. It is a 32 bit little endian integer.

The version number is used to signal specific support for some technologies. Specifically, a transaction must be version 2 in order to use OP_CHECKSEQUENCEVERIFY. Otherwise the transaction is exactly the same as a version 1 transaction. Only transaction versions 1 and 2 are considered standard.


In the current version 2.8.3 of Electrum it's very easy to import Multibit wallets (meaning, migrating from Multibit to Electrum). An important reason to migrate is because Multibit (not HD but the classic one) does not allow to change network fees, which makes it very hard or even unreliable to move funds.

Select wallet in Multibit and choose Tools > Export Private Keys and export without password to a .key file.
Open the .key file with a text editor (e.g. Sublime Text) and copy the private key(s) from the text file.
Create a new wallet in Electrum from menu File > New/Restore, give it a name, a location to save and create as Standard Wallet (other options may also work but haven't tried).
When asked for Keystore, choose Use public or private keys. In the next screen, you can paste your private key(s) from step 2.
You now have a Electrum Wallet with the addresses previously used in Multibit and you can send/receive BTC from this wallet.

Note: The addresses will still be accessible from Multibit, since you can use the same wallet (private keys) from various apps/wallets. I use Multibit now as 'watch only' and not transfer anymore from it.


Has someone compared the cost of mining vs. that of brute-forcing addresses?

The chance of generating the key of a very rich address is effectively zero. That is, in the entire history of humanity, nobody has come anywhere close to accomplishing such a feat.

Let's consider 1 Bitcoin a score. Since there can never be more than 21 million bitcoins or so, you need to hit on one of at most 21 million accounts. Let's say you could try 2 trillion accounts per second. Your odds of matching an account in a hundred years are approximately one in 11 billion billion.

Good luck.


Why does BIP141 define both virtual transaction size and weight?

The transaction limit under segwit is derived solely from the transaction weight and the block weight limit of 4,000,000 weight units.

Virtual transaction size was not used for the limit calculation because it is fractional when computed accurately. Bitcoin Core only uses integers in the consensus code and thus transitioned to transaction weight.

Virtual transaction size is merely provided as a convenient way of comparing segwit's effective transaction size to current transaction sizes.

Adding a quote of the section to clarify: BIP141 specifies the following terms in regard to transaction size:

  Transaction weight
  is defined as Base transaction size * 3 + Total
  transaction size (ie. the same method as calculating Block weight from
  Base size and Total size).

  Virtual transaction size
  is defined as Transaction weight / 4 (rounded
  up to the next integer).

  Base transaction size
  is the size of the transaction serialised with
  the witness data stripped.

  Total transaction size
  is the transaction size in bytes serialized as
  described in BIP144, including base data and witness data.


Most private keys are essentially just random numbers, so if all you want is a private key, you just need to use a high-entropy random function to generate your private key that's 256 bits.

Converting those bits into something a normal bitcoin wallet can understand (like WIF) is a little trickier, but the process is spelled out here. I'm recapping the actual process here so you can use the Java library java.security.MessageDigest for SHA256 and you can use this code snippet to convert to Base58.

1 - Take a private key

0C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D

2 - Add a 0x80 byte in front of it for mainnet addresses or 0xef for testnet addresses. Also add a 0x01 byte at the end if the private key will correspond to a compressed public key

800C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D

3 - Perform SHA-256 hash on the extended key

8147786C4D15106333BF278D71DADAF1079EF2D2440A4DDE37D747DED5403592

4 - Perform SHA-256 hash on result of SHA-256 hash

507A5B8DFED0FC6FE8801743720CEDEC06AA5C6FCA72B07C49964492FB98A714

5 - Take the first 4 bytes of the second SHA-256 hash, this is the checksum

507A5B8D

6 - Add the 4 checksum bytes from point 5 at the end of the extended key from point 2

800C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D507A5B8D

7 - Convert the result from a byte string into a base58 string using Base58Check encoding. This is the Wallet Import Format

5HueCGU8rMjxEXxiPuD5BDku4MkFqeZyd4dZ1jvhTVqvbTLvyTJ


Is there a way to remove or edit Blockchain.info public notes?

You should ask this question to blockchain.info support. Nobody here can predict the near and far future. Nobody here is responsible for third-party service like blockchain.info


I'd actually like to see a reference to someone saying that it's illegal.

...because it's legal.

FinCEN guidance establishes who must register with government and when one must pay taxes (sell bitcoin for USD, pay taxes on gains).


I'm assuming you've already tried caps lock, the intermediate passwords you used etc.

Ideally you would backup your wallet before making changes such that you have a library of them: wallet.dat.1jun2018, wallet.dat.2jul2018 etc. Then if something goes wrong, you already know that the previous copy of the wallet is still available.

I can't tell what's gone wrong for you from your description above, but OSX Mojave does offer some facilities. First, you MUST copy your wallet as it currently stands - even though you don't have the password - to an external disk, date it as above. Then use Time machine even if you haven't been using it to have a look at the folder ~/Library/Application Support/Bitcoin. Mojave stores local backups on your computer "even when your Time Machine backup disk isn't available." You're hoping to see that wallet.dat is available from a date prior to the encryption.

If it is, then you might try restoring it. Also copy it under a new name to your external disk. You might be lucky enough that bitcoin-qt works straight away without the password. If you can restore a previous version but cannot seem to use it, things start to get a lot more tricky, very quickly.

If you don't have the local backups, or the wallet isn't within it, I would turn the computer off and sleep on it. When you get up, write down everything you did, every password you tried, in the hope that something jogs your memory.


Key derivation in HD wallets using the extended private key vs hardened derivation

There's a lot of confusion here, mostly bits and pieces of the whole scheme that is Hierarchical Deterministic derivation, and finally two questions that seem to indicate missing some point about it.
The answer to the first question is No.  The second question is more interesting :

Let's start from extended keys, specifically BIP32 keys.
Like private keys and public keys, extended keys can be either "private" or "public".  I put both in quotes becaus both types of extended keys do contain private information.
At least enough to track key use. This mechanism is used by hardware wallets and "watchonly" software wallets on a PC.

An extended key is just a base58 encoded serialization of a few pieces of data :

[ magic ][ depth ][ parent fingerprint ][ key index ][ chain code ][ key ]

Where key can be either a public key or a private key.  Private keys are prepended with a single 0x00 byte, so the length of this blob stays the same.
An extended key is usually derived by "traversing" some path, meaning you would start your derivation at some parent extended key, and consecutively derive child keys with specific indexes until you finally derive the final extended key in the path.
I'll stop using "extended" in this answer.  From now on I'll refer to an extended private key as xprv and to an extended public key as xpub, and just "keys" sometimes.  Non-extended are just "private key" or "public key".

An xprv or xpub's magic are 4 bytes to indicate the network it belongs to: testnet or mainnet (t or x respectively), and the type of key it is (pub and prv respectively).
The depth is a byte that indecates how deep an xpriv or xpout is in a path, starting from 00 as the depth of the master key, and incremented by one as the derivation of more child keys is done along the path.
Note that up until now, the only difference between xprv and xpub keys that I mentioned is the prv or pub part in the magic.
It also should be clear that an xprv and xpub can be in the same path, and in the same depth.  This means that for such pair of xprv and xpub, the [ key ] part of the will have a 32 byte private key (prepended with one 00 byte) in the xprv, and a 33 byte public key which is the public key which which you get from the private key in the xprv.

A parent's fingerprint are the first 4 bytes of the hash160 of the public key of the parent.  This means that even if a parent xprv was used to derive a child xprv, it would have the same parent fingerprint as if a parent xpub was used to derive a child xpub.
A parent-child relationship between keys means that they are adjacent in a path.

A path is an n-tuple of indexes, usually in base 10, separated by /.  The range of an index can be between zero and and 4294967295 (or 2^32-1), where anything in [0,2147483647] follows non-hardnened derivation, and indexes in [2147483648,4294967295] follow hardened derivation.
You can see that each half of the range of indexes is used for a different method.  We can say that there are two ranges.  [0,2147483647] for non-hardened keys, and [0h,2147483647h] for hardened keys.  The h indicates that the index (we'll call it i) should be treated as i + 2147483648.
You're probably more likely to see the h notation as a caret ' instead, so 1' == 1h, but I don't think it's very pretty so I'll stick with h for now.

An example of what a path looks like is :

m/0h/1/2h/2/1000000000

The m means that the key at this index is a master xprv or master xpub.  A small m means that this extended key is a master xprv, and big M a master xpub.  Following the previous definitions, you can tell that m is the parent of the key at 0h, and the key at 2h is the child of the key before it at index 1.
To make this easier to follow, we'll annote the different keys in the path with letters {a..e} if we mean that these are xprvs and {A..B} if xpubs.

m / 0h / 1 / 2h / 2 / 1000000000
m   a    b   c    d   e

A path is usually given with indexes in base10, but in the key itself they are encoded in hex (base16), so a [ key index ] is always 4 bytes with zeros prepended if needed.  The depth and index of a master key are both alwasy zero, so 00 and 00000000, and they can get to a maximum of FF and FFFFFFFF respectively.
So m and a are parent and child, and so are d and e.  The depth of b is 02 and its index is 00000001, and the depth of c is 03 while its index is 80000002 (80000000 + 2).
The last child key to be derived is e.  We can say that we followed a path starting at m, from it we derived the key a at index 0h, then from a we derived the key b at index 1.. and so on.  But what does it mean to derive a new key?

The remaining two elements in the extended key format, the parent's [ chain code ] and [ key ] are used together with what would be the child key's index to derive it.
That means that to derive c from b, we'd feed some function with b's chain code and key, and c's index.
A specific example of our b and c would be :

b :

0488ADE4
02
5C1BD648
00000001
2A7857631386BA23DACAC34180DD1983734E444FDBF774041578E9B6ADB37C19
003C6CB8D0F6A264C91EA8B5030FADAA8E538B020F0A387421A12DE9319DC93368

c :

0488ADE4
03
BEF5A2F9
80000002
04466B9CC8E161E966409CA52986C584F07E9DC81F735DB683C3FF6EC7B1503F
00CBCE0D719ECF7431D88E6A89FA1483E02E35092AF60C042B1DF2FF59FA424DCA

The fields are ordered as in the structure above.  On both, the magic says xprv, the depth is incremented between the parent and child, the fingerprint at c is the hash160 of the public key that you would get from the private key at b, and b's index is in the first, non-hardened half of the range while c's is the second, hardned half.  Finally the chain code and keys of each of the xprvs are encoded.

Deriving the chain code and key for c from b is done with a process called CKDpriv, which means deriving a child xprv from a parent xprv.  In this process we used the chain code and key from b, and the index from c.
The important point to make: We only encoded c after deriving its chain code and key from what would be its index.

Any xprv can be used with CKDpriv to derive a child xprv at any index.  The specific way CKDpriv will act on the input depends on the child's index being in the hardened range, or the non-hardned range.  Basically, a CKDpriv function runs an HMAC-SHA512 on the parent's chain code and key, and the child's index.  This hmac function takes two values a key* (not to be confused with our occurences of key, will be refered to as hkey), and text.
The parent's chain code is used as the hkey, while the text is made up of the parent's key in the private key form if the the child's index is in the hardened range, [0h,2147483647h], and in the public key form if the index is in the non-hardened range.  It is then concatenated with the child's index.

c's index is in the hardened range, so CKDpriv's hmac-sha512 runs with the inputs:

HMAC-SHA512( 2A7857631386BA23DACAC34180DD1983734E444FDBF774041578E9B6ADB37C19,
             003C6CB8D0F6A264C91EA8B5030FADAA8E538B020F0A387421A12DE9319DC9336880000002 )

Which returns a 64 byte hash :

8F6154A0A82D0F68B9E5B586EA66D951DAAA071BEBD390097CC516285C791A6204466B9CC8E161E966409CA52986C584F07E9DC81F735DB683C3FF6EC7B1503F

The 32 bytes on the right half of this hash, 04466B9C...C7B1503F become the child's (c here) chain code, and the 32 bytes on the left are used to "tweak", meaning just "addition mod n" to the parent's key, in this example :

  8F6154A0A82D0F68B9E5B586EA66D951DAAA071BEBD390097CC516285C791A62
+
  3C6CB8D0F6A264C91EA8B5030FADAA8E538B020F0A387421A12DE9319DC93368
=
  CBCE0D719ECF7431D88E6A89FA1483E02E35092AF60C042B1DF2FF59FA424DCA   mod n

I didn't write the 00 prepended bytes in the keys here because this is just adding numbers, but those zero bytes are very important for the hash function, so I purposely included them there.

Now that we've got c's chain code and key (in private key form), we would want to actually encode c for it to be a usable xprv.
To get the fingerprint from b, we need to know the public key of the key from b.  Since it's in private key form, we'll have to do multiplication:

CBCE0D719ECF7431D88E6A89FA1483E02E35092AF60C042B1DF2FF59FA424DCA * G
= 03501E454BF00751F24B1B489AA925215D66AF2234E3891C3B21A52BEDB3CD711C

Take the hash160 of this public key, and the returned hash is BEF5A2F9A56A94AAB12459F72AD9CF8CF19C7BBE.
The first four bytes are b's fingerprint : BEF5A2F9.
Encoding the rest of c is easy.  Start with the magic xprv since we derived a child xprv, increment the depth of b by one, then the fingerprint.
Next c's index is encoded.  We derived index 2h, so this would be 80000002, and then the new chain code and key that we got from CKDpriv.

This is basically what hardened derivation is.  The parent's private key and chain code are used to derive the child key at some hardened index.
What if we want to derive d?  It's at index 2, so a non-hardened index.  This is the second case of CKDpriv.

The difference is in what is used for the text parameter of the HMAC-SHA512 function.  Instead of using the parent's key in private key form, we use the public key form, so to derive d at index 2 from c, we first find the public key of c :

CBCE0D719ECF7431D88E6A89FA1483E02E35092AF60C042B1DF2FF59FA424DCA * G
= 0357BFE1E341D01C69FE5654309956CBEA516822FBA8A601743A012A7896EE8DC2

Then continue following the same steps as the above:

HMAC-SHA512( 04466B9CC8E161E966409CA52986C584F07E9DC81F735DB683C3FF6EC7B1503F,
             0357BFE1E341D01C69FE5654309956CBEA516822FBA8A601743A012A7896EE8DC200000002 )

                            tweak                                                            chain code
437984D45C4A2F5840C65B3DC6D7274E2859AD25D092DB032C49AA4D006A426B|CFB71883F01676F587D023CC53A35BC7F88F724B1F8C2892AC1275AC822A3EDD

* note that 00 is not prepended to the text, since this is a public key.

  437984D45C4A2F5840C65B3DC6D7274E2859AD25D092DB032C49AA4D006A426B
+
  CBCE0D719ECF7431D88E6A89FA1483E02E35092AF60C042B1DF2FF59FA424DCA
=
  0F479245FB19A38A1954C5C7C0EBAB2F9BDFD96A17563EF28A6A4B1A2A764EF4   mod n

hash160( 0357BFE1E341D01C69FE5654309956CBEA516822FBA8A601743A012A7896EE8DC2 )

finger
   print
EE7AB90C|DE56A8C0E2BB086AC49748B8DB9DCE72

The rest is easy, and we can encode :

d :

0488ADE4
04
EE7AB90C
00000002
CFB71883F01676F587D023CC53A35BC7F88F724B1F8C2892AC1275AC822A3EDD
000F479245FB19A38A1954C5C7C0EBAB2F9BDFD96A17563EF28A6A4B1A2A764EF4

The difference between these two methods of deriving child xprvs is subtle but important.  It enables CKDpub, which is a function to derive child xpubs from a parent xpub.  CKDpub works almost the same as CKDpriv's non-hardened derivation, but it does the derivation using point addition,  so rather than adding up integers to make child private keys, we're adding up points to make child public keys.
Notice how in the non-hardened derivation we used the parent's public point for the HMAC-SHA512, we used the tweak as the added value to the parent private key to derive the child private key, specifically, we derived d's private key.

To understand CKDpub, it helps to first know about yet another BIP32 function called Neuter.  It's purpose is to convert an xprv to an xpub.
Let's "run" Neuter on our xprv d.  We'll call the resulting xpub D.  Neuter does two things to an xprv:
1. Replace the magic from 0488ADE4 to 0488B21E (replaces xprv with xpub)
2. Replaces the private key in the key field` with the public point of the same private key

for our xprv d, the public point is:

0F479245FB19A38A1954C5C7C0EBAB2F9BDFD96A17563EF28A6A4B1A2A764EF4 * G
= 02E8445082A72F29B75CA48748A914DF60622A609CACFCE8ED0E35804560741D29

(this is just normal process of private key -> public key)

so the result is:

D:

0488B21E
04
EE7AB90C
00000002
CFB71883F01676F587D023CC53A35BC7F88F724B1F8C2892AC1275AC822A3EDD
02E8445082A72F29B75CA48748A914DF60622A609CACFCE8ED0E35804560741D29

Now d is "neutered", D has the public key encoded, but see how the chain code, depth, fingerprint and index persisted.  The xpub D is at the same position in the path as the xprv d.  We will be using the chain code and key (public key) for CKDpub, same as CKDpriv with non-hardened derivation, but as for CKDpriv, we derived the child private key using:

tweak + (parent private key) = child private key

for CKDpub we will be using:

tweak*G + (parent public key) = child public key

This works because parent public key is really just (parent private key)*G, and child public key is just (child private key)*G.  That is, if we take the CKDpriv tweak equation and multiply all elements by G, we get exactly the CKDpub tweak equation.
CKDpub can only derive child xpub keys in the non-hardened index range.  This is because the information present in the parent xpub, specifically the public key in the [ key ], only applies to the non-hardened range.
Where in CKDpriv we could use the private key to know the public key, we can't go the other way.  the HMAC-SHA512 round that uses public keys in CKDpriv applies to the non-hardened index range.

Now that we have neutered d to create the xpub D, next in the path is e's with index 1000000000 (or 3B9ACA00), which is in the non-hardened range, so we should be able to derive E the child xpub from D using CKDpub.  We start with hmac-sha512 of the parent chain code as hkey and parent key (public key) concatenated with the child E's index :

HMAC-SHA512( CFB71883F01676F587D023CC53A35BC7F88F724B1F8C2892AC1275AC822A3EDD,
             02E8445082A72F29B75CA48748A914DF60622A609CACFCE8ED0E35804560741D293B9ACA00 )

                            tweak                                                            chain code
37D3E49D8ECB854CC518BBA096F46795A9707860BF0FC95E5B19278C997098D4|C783E67B921D2BEB8F6B389CC646D7263B4145701DADD2161548A8B078E65E9E

Multiply the tweak by the generator G so we can tweak the parent's public key using point addition :

37D3E49D8ECB854CC518BBA096F46795A9707860BF0FC95E5B19278C997098D4 * G
= 0327E992F68217BC3E88CFFC3FEAB475880145413CBE008DB22B496DF4E1C3F864  <- tweak*G

Add the tweak to the parent point.  The result is the child's public key :

  0327E992F68217BC3E88CFFC3FEAB475880145413CBE008DB22B496DF4E1C3F864
+
  02E8445082A72F29B75CA48748A914DF60622A609CACFCE8ED0E35804560741D29
=
  022A471424DA5E657499D1FF51CB43C47481A03B1E77F951FE64CEC9F5A48F7011

Get the paren'ts fingerprint :

hash160(02E8445082A72F29B75CA48748A914DF60622A609CACFCE8ED0E35804560741D29) = D880D7D8....

Finally we can encode E :

0488B21E
05
D880D7D8
3B9ACA00
C783E67B921D2BEB8F6B389CC646D7263B4145701DADD2161548A8B078E65E9E
022A471424DA5E657499D1FF51CB43C47481A03B1E77F951FE64CEC9F5A48F7011

Neutering d to make D then deriving E, we can say that our path now looks like :

m / 0h / 1 / 2h / 2 / 1000000000
m / a  / b / c  / D / E

Or we can use the N() notation (for Neuter) to show where CKDpub was used, but I think it's less pretty.
m / a  / b / c  / N(d / e)

So to recap on your question, there are 3 different derivation methods, two using private keys and one using public keys :

CKDpriv to derive a child xprv at a hardened index
CKDpriv to derive a child xprv at a non-hardend index
CKDpub to derive a child xpub at a non-hardened index


Multiple outputs and different amounts on blockchain explorer when I sent BTC from Crypto.com to Coinbase

I then went on the blockchain explorer to view the transaction and I am seeing an input that is not my address

I am not familiar with this particular site, but this is not unexpected. When custodial services hold user funds, they don't necessarily keep the funds in a separate wallet per user. Instead, they have one giant wallet with all the user's funds, and a database to keep track of how much of it is owed to each user. For example, this could be a viable scenario:

User U wants to make a deposit, so the service creates address A, stores it in the database as "A is receive addr for U", and hands A to the user on the website.
User U deposits 1 BTC on A. These funds are now controlled by the service, but it credits U with 1 BTC.
User V does the same; the service creates address B, stores it in the database, and hands it to V on the site.
User V deposits 10 BTC on B. The service now controls 11 BTC. The service credits V with 10 BTC in its database.
Now V wants to withdraw 1 BTC to address C. The service looks at its entire wallets, which contains a UTXO worth 1 BTC and a UTXO worth 10 BTC. It decides that it is most economical to use the 1 BTC when withdrawing, and does so - despite the fact that this 1 BTC UTXO is actually the result of a payment crediting another user.

When V now looks at the blockchain, they will observe a transaction that seems to come "from" address A, which is unknown to V. This is misleading. The general advice is not to pay attention to "from" addresses, as they have very little meaning except to the wallet that actually creates the transaction. It is also none of V's concern - they get the funds, and that's what matters.

as well as various outputs which include my address as well as other addresses that do not belong to me.

This too, is expected. Transactions are cheaper when they batch multiple payments together. The website may have queued up your request for a withdrawal for a short period of time, during which other users also made withdrawals. It then constructed a single transaction that performs all these withdrawals in one go, saving fees and wallet fragmentation for the service. One of the outputs may also be "change" going back to a new address belonging to the service, if the input amounts do not exactly cover the total amount intended to be withdrawn.


Their homepage advertises them as:

  WORLD'S BEST RISK FREE FOREX, BINARY AND BITCOIN INVESTMENT

Any entity that advertises any form of trading as risk free is a scam. Essentially all binary options, mining investment, "automated trading" platforms are scams in the crypto space.

The only legitimate way to make money here is to (correctly) speculate yourself, invest in mining hardware that you operate directly, or build profitable services around the crypto ecosystem. Anything besides that is a scam.


Now that the hard fork is coming Will replay attacks if not dealt with destory the coin's value?

I think that breaks down to a few questions, both difficult to answer, so here's my thoughts:

1) Are there going to be issues relating to replay attacks?
Possibly, which is why people have been pushing 2x to implement replay protection (it's not possible to do this on the current version without making your own fork).  Core have attempted to mitigate this by rejecting BTC1 nodes in the latest release of Bitcoin Core.  But now we have the possibility of BTC1 nodes pretending to be something else so they will be recognised by the Core nodes (which makes little sense as far as I am concerned).  Replay protection may be as simple as waiting for the fork to happen, then transacting with a specific node type you want your transaction on (some light wallets allow you to effectively "pin" trusted nodes), if the network is already segmented then your transaction shouldn't be broadcast on both.
Another option is to get some freshly minted bitcoin post fork (either one will do), move your coins and include this post fork bitcoin, this will be rejected as invalid on the other chain (those coins don't exist there).  You can then safely move the coins on the other chain as the first chain would have those coins as spent (and therefore the transaction would be rejected also).
As to "destroying value", maybe, for some people it could be an issue, however any coins sent on the wrong fork would still be recoverable by the receiving party as the address format hasn't changed, so they could just claim the coins on that fork.  It's a massive hassle though, more confusing than technical issues however.

2) How will the fork affect price?
Hard to say, some expect it to increase the price (as it appears to have done in the run up to the fork) as people will be getting 2 potential tokens, however once it's live, one of the forks may drop in value, with the money migrating to the other fork.  It's safe to expect some volatility, with one side emerging on top, how long this takes, who knows?  As long as one side doesn't have all the hashing power, difficulty will adjust (will likely be slow on the Core chain as most big miners support NYA) and the coin will become usable again.  One of the chains will be slow though, as there's no "EDA" as implemented for BCH.


What is the Alert system in the bitcoin protocol? How does it work?

TL;DR:

  As @Alex Waters has stated, it's a centralised alert system to allow
  people to shutdown their clients in response to a threat to the
  overall Bitcoin network, pending a client patch to resolve the issue.
  This was intended as a short term measure to counter-act perceived
  problems in growing the software.

This thread on the forum has some interesting information about it (I've fixed the links to cover the moved forum):

  Yes, it appeared in version 3.11. Here's the thread discussing it:

  "Development of alert system"
  https://bitcointalk.org/index.php?topic=898.0;all

  But I think Satoshi took it out of recent builds, to avoid accusations
  that he was a point of central control (because his key would be used
  to sign the alert). If I can find the reference to that announcement,
  I'll post it.

  edit: here's the announcement about the removal of "safe mode". It's
  not clear to me whether the alert itself was removed, or whether the
  ability to have the alert shut down transaction processing was
  removed:

  Removed safe mode (0.3.19)
  https://bitcointalk.org/smf/index.php?topic=2228

Clearly, Satoshi intended it to be a centralised mechanism to issue alerts that would result in clients stopping transactions (not block generation). This would act as an effective mechanism to cause clients to upgrade as a result of a bug, but a naive interpretation is that it is also a good way to shutdown an economy.

Anyone can build a standard client and replace the key requirement with one of their own, thus negating the efficacy of a system-wide shutdown due to a compromised key. Essentially, this would cause a fragmentation of the standard client as nodes seek to protect themselves from external compromise.

Satoshi notes this himself in this comment:

  It can't do arbitrary actions remotely.  Maybe some of you are
  responding to other posters who suggested the alert system should do
  more?

  If there is an alert, the following json-rpc methods return an error:
  sendtoaddress getbalance getreceivedbyaddress getreceivedbylabel
  listreceivedbyaddress listreceivedbylabel

  The remaining 14 methods function as normal.

  I believe the safer option should be enabled by default.  If you want
  your server to keep trading and ignore an alert saying the money its
  receiving might be like the money from the overflow bug, then you can
  use the switch and not blame anyone else if you lose your money.

  Worst case if you leave alerts enabled, your site stops trading until
  you upgrade or add the -disablesafemode switch.

  Getting surprised by some temporary down time when your node would
  otherwise be at risk is better than getting surprised by a thief
  draining all your inventory.

  Someday when we haven't found any new bugs for a long time and it has
  been thoroughly security reviewed without finding anything, this can
  be scaled back.  I'm not arguing that this is the permanent way of
  things forever.  It's still beta software.

Given the ongoing backlash of misunderstanding over the concept, it appears that it was decided to remove the feature and rely instead on detecting a dodgy blockchain that is longer than the longest valid one:

  Removed "safe mode" alerts "safe mode" alerts was a temporary
  measure after the 0.3.9 overflow bug.  We can say all we want that
  users can just run with "-disablesafemode", but it's better just not
  to have it for the sake of appearances.  It was never intended as a
  long term feature.  Safe mode can still be triggered by seeing a
  longer (greater total PoW) invalid block chain.

  Builds:
  http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.19/


How do I search for a hidden and disguised (extension changed) wallet file on damaged hard drive?

Try searching words fromaccount or timesmart. Wallet.dat is binary, so there should'nt be too many words accessible, but these should.


Based on your example it looks like you are signing the same sighash twice, so it only looks like one key signed.

This example might help: https://github.com/magmahindenburg/MultisigExamples/blob/master/src/se/moar/bitcoin/multisig/MultisigPresentation.java

    // Sign the first part of the transaction using private key #1
    Sha256Hash sighash = spendTx.hashForSignature(0, redeemScript, Transaction.SigHash.ALL, false);
    ECKey.ECDSASignature ecdsaSignature = key1.sign(sighash);
    TransactionSignature transactionSignarture = new TransactionSignature(ecdsaSignature, Transaction.SigHash.ALL, false);

    // Create the sighash2 using the redeem script
    Sha256Hash sighash2 = spendTx.hashForSignature(0, redeemScript, Transaction.sighash2.ALL, false);
    ECKey.ECDSASignature secondSignature;

    // Take out the key and sign the signhash
    ECKey key2 = createKeyFromSha256Passphrase("Super secret key 2");
    secondSignature = key2.sign(sighash2);

    // Add the second signature to the signature list
    TransactionSignature transactionSignarture = new TransactionSignature(secondSignature, Transaction.sighash2.ALL, false);
    signatureList.add(transactionSignarture);

    // Rebuild p2sh multisig input script
    inputScript = ScriptBuilder.createP2SHMultiSigInputScript(signatureList, redeemScript);
    spendTx.getInput(0).setScriptSig(inputScript);

    System.out.println(byteArrayToHex(spendTx.bitcoinSerialize()));


Why does the mainline client limit the number of outbound connections to 8?

This is a legacy issue.

When the network was first implemented, there was a severe shortage of servers that could reliably accept inbound connections. Many people started running the client behind NAT and they could not accept any inbound connections. Meanwhile, they were consuming the available inbound connection capacity of the more limited number of machines that could accept them. The client now enables uPNP traversal by default.

Second, there were problems with the client code that caused it not to be able to support as many connections as it should have been able to. Many nodes could not even support the default 125 connections, even though their CPU and network usage was nowhere near maxed.

These days, it's just kind of stuck. My 'hub mode' patches make it easily possible for clients to support 1,500 connections. But they almost never see more than 200 clients because the network capacity limitations are long gone.

You need a healthy number of outbound connections because a malicious adversary can consume all your inbound connection slots by repeatedly connecting to you, and staying connected, from a variety of IP addresses. The Bitcoin client actually has code to try to get IP diversity in its outbound connections to protect against some entity creating a million servers and having a high chance of getting all 8 of your outbound slots.

If you're paranoid, turn this up. You can still configure for 32 outbound connections if you can also add at least 64 inbound connection slots in exchange. You'll be helping the network. You can use my hub mode patches to do this.


Upper bound on the Bitcoin transaction size

Typically people will store arbitrary data in a separate output in a transaction beginning with OP_RETURN.

Any output with this OP code will be considered invalid or provably unspendable, but will still exist as part of the blockchain.

As mentioned in this thread Bitcoin-core options will allow for up to 80 bytes of arbitrary data by default. It is worth noting that 80 bytes is simply a default value. Nodes can change the -datacarriersize parameter to manually adjust the limit for the acceptance of larger or smaller amounts of data. For example, this transaction is 1155 bytes with 983 bytes of arbitrary data and has still been validated into the network.

The history of the default value is actually quite interesting and has been switched around a few times throughout Bitcoin's existance.


All services that deal also with fiat money, apart from cryptocurrencies, must comply with specific AML (Anti Money Laundering) and KYC (Know your customer) rules, which can be more strict depending on their jurisdiction.

AML/KYC Explained: https://bitcointalk.org/index.php?topic=454795.0


What advantages does Armory have over Bitcoin-Qt?

Some obvious reasons:

Deterministic wallet (only need to store the seed, bitcoind's wallet uses a random number per address).
Multisig support with lockboxes.
Paper backups with SecurePrint.
Fragmented backups (you need m of n pieces to get back your wallet)
Offline signing for additional security

There's also a lot more features that are on the way that we'll be announcing (Disclosure: I work for Armory)


Do I understand correctly that mnemonic seeds are specific to individual wallet software and its versions?

There are standards.  You would have to check that your particular wallet program conforms to them.

The standard for converting a mnemonic passphrase to/from a seed is BIP 39.  The standard for generating keys from a seed is Hierarchical Deterministic Wallets, BIP 32.


Does the block reward comes from a bitcoin treasury? If yes, then how is it issued?

There is no treasury. The Bitcoin is generated out of nothing. The coinbase transaction has special rules. It is allowed to have only one input which has no previous output and really no value. It is allowed to create outputs which have a total value of the block subsidy (currently 12.5 BTC) plus the transaction fees from that block. Those coins aren't issued by any entity; the miner just creates the output(s) and is allowed to do so. This rule is enforced by all of the full nodes on the network who will reject that miner's block if he pays himself too much money.

Simply put, the miner is allowed to just pay himself money that is produced out of nothing.


How can we receive hashtx and hashblock from bitcoind by zmq subscribe?

The PPA you have installed (https://launchpad.net/~bitcoin/+archive/ubuntu/bitcoin/+packages) is not compiled with ZMQ support (It should in future).

You need to self-compile bitcoin v0.13.0 or use one of the "official" binaries: https://bitcoin.org/bin/bitcoin-core-0.13.0/

EDIT: since 0.14, ZMQ support is available via the PPA


Isnt it supposed to be 2. The above is a really large number in big endian.

It's a small number in big endian. Think about it; big digits at the end.

  Now the previuos hash block

I don't know why Bitcoin does this, but block hashes are stored in normal order internally, then byte-reversed before displaying them.

>>> s="e965bfc2111c7a63a12b5c95ff9b5cc44f2d32ad9e52d9a04301000000000000"
>>> import binascii
>>> s=binascii.unhexlify(s)
>>> s=s[::-1]
>>> s=binascii.hexlify(s)
>>> s

'0000000000000143a0d9529ead322d4fc45c9bff955c2ba1637a1c11c2bf65e9'

  Time:
  a77ead51

Use big endian. I got 1370324647 using this tool, then converted to 04 Jun 2013 with this tool.


Nate is right.  But there is this tool:

http://fiatleak.com/

which can help you see a particular currency's exchanges in and out of Bitcoin.

Euro, USD and Yuan are usually the most predominant.

It could be somewhat helpful, it is open and javascript based so you can see how it works.

That could possibly give you additional ideas on solving your problem.


What can a person do with special private keys?

As far as I know, the alert key is the only special one with a public key hardcoded in the client.

Technically, the public key of the genesis block's output is also hardcoded in the client, but it grants no special privileges. The genesis block cannot even be spent.


Is the hash of the coinbase transaction needed for the merkle root?

You make your list of transaction hashes(without the coinbase transaction, as you haven't mined the block),

This is where the problem in your understanding lies. The coinbase transaction is generated before the block is mined, not afterwards, because it must be included in the list of transactions just like all the others. It is the first transaction in the block, and its hash is used in exactly the same way as all the others when constructing the merkle root.

Once the coinbase transaction is created and the merkle root calculated, then the nonce is varied and the block is mined.

  Does a1+b1 mean that you perform addition of the hash values or that you just append the two hashes together?

Append the hashes, not add them


How does bundling as a bundler in Ardor work?

Maybe this post can help:

https://thewiring.com/2017/05/19/ardor-fees-child-chain-fees-bundlers-forgers-lets-clarify/

Hope it helps a bit

  The idea behind Ardor is brilliant. And sometimes brilliant ideas
  require some time to be fully understood.

  One of the great features of Ardor is that there can be many child
  chains running under the blockchain infrastructure built on the Ardor
  nodes (main chain). At the release of the live Ardor software in Q3
  2017, all the functionalities of the current NXT will be implemented
  in the first Ardor child chain called Ignis.

  But one thing that is apparently not clear to everybody is how the
  fees structure looks like in the child chains and in the Ardor main
  chain. So let’s clarify.

  Let’s start from the Ardor main chain.

  Forging blocks on the Ardor main chain will work as today’s NXT
  forging. The Proof of Stake protocol allows the forging node with more
  tokens to have better chances to forge a block. Forging is the
  equivalent of mining in the NXT/Ardor world. The reward of a forged
  block is the sum of the transaction fees within that block.

  These blocks will contain transactions from the main chain and from
  the child chains. The Ardor main chain will be the only one forging
  and providing the blockchain infrastructure to all child chains.

  So that’s clear. Ardor’s forging process works as today’s NXT forging
  with the exception that there are also transactions from the child
  chains packed in the same blocks.

  Let’s now move to the child chains. Let’s take for example Ignis, the
  first child chain of Ardor.

  Users doing transactions within Ignis do not have to worry about Ardor
  fees. They can simply transfer Ignis from one account to the other,
  issue an Asset, send a message, etc by just paying a fee in Ignis. The
  child chain fees can change because they will be defined by the
  “bundlers”.

  So what is a “bundler”? A “bundler” is the link between the child
  chain and the main chain. It’s the one that collects the child chain
  fees and then pays the main chain (Ardor) to pack those transactions
  in a block.

  There will be bundlers for each child chain and anyone can setup a
  bundler as long the account holds some Ardor.

  Here is how the Bundler setup page looks like (example for Ignis):

  The field “Minimum Rate” is a multiplier for the defined Ardor fee for
  that specific transaction. The result of that multiplication will be
  the minimum transaction fee in child chain token users will have to
  pay so that the bundler will bundle their child chain transaction.

  “Fee Limit” is the total amount you want to spend in Ardor fees.

  “Overpay” is the extra you want to pay more in case of competing
  bundlers. This is a multiplier of what you will pay in terms of Ardor
  fee.

  Let’s hypothetically assume that these are the fixed prices for a
  couple of transaction in Ardor (still in development so let’s not be
  too picky with the exact amounts):

  Basic transaction (money transfer, sending message, etc): 0.1 Ardor
  Asset issuing: 1000 Ardor Now lets assume a bundler is set with these
  parameters:

  Minimum Rate: 10 Fee Limit: 200 Overpay: 0.1 Someone now sends a
  message to someone else in the Ignis child chain. The client will
  automatically set the fee to the minimum fee offered by the bundlers.
  Let’s assume that our bundler is the only one, then the fee that will
  be applied will be:

  0.1 Ardor fee x 10 Minimum Rate = 1 Ignis

  So the message will be delivered with 1 Ignis fee.

  The bundler then has to pay 0.1 Ardor + (0.1 Ardor x 0.1 Overpay) =
  0.11 Ardor

  Let’s set another bundler with these parameters:

  Minimum Rate: 1 Fee Limit: 5000 Overpay: 2 Someone issues an Asset on
  the Ignis child chain. Here is how the fees will look like:

  1000 Ardor fee x 1 Minimum Rate = 1000 Ignis

  So the Asset will cost 1000 Ignis to the user.

  The bundler instead will pay 1000 Ardor + (1000 Ardor x 2 Overpay) =
  3000 Ardor

  As the bundler has set a Fee Limit of 5000, it can afford to pay the
  3000 Ardor mentioned above and still have 2000 Ardor budget for the
  following “bundles”.

  Keep in mind that the bundler gets the child chain fees, and this is
  where it gets interesting. The bundlers will then have to follow the
  exchange rate between, for example, Ardor and Ignis and define the
  Bundler in a way that he/she can recover the expenses.

  Let’s assume that 1 Ardor = 1 Ignis in terms of value.

  Let’s suppose that we have a Bundler set in the following way:

  Minimum Rate: 1 Fee Limit: 1000 Overpay: 0 Someone sends a message and
  pays a fee of 0.1 Ignis (0.1 fixed Ardor fee multiplied by Minimum
  Rate 1) to the bundler.

  So the bundler received a value 0.1 Ignis and pays a 0.1 Ardor as the
  value of Ardor and Ignis, in this example are the same, then there is
  no loss and no gain for the Bundler.

  Assuming the same Bundler defined above, but the value of Ardor is 10
  times the value of Ignis, so you need 10 Ignis to buy 1 Ardor.

  In that case there would be a loss for the Bundler as it will receive
  0.1 Ignis fee but will pay 0.1 Ardor fee which is worth 10 times more. So in that scenario the Bundlers have to adjust their Bundler settings
  to be more reasonable financially, in this case a 0 gain/loss would be
  achieved by setting Minimum Rate to 10.

  This is where more Bundlers will have to compete to be the most
  attractive but also to make a little gain maybe. This will be defined
  by the market.

  I hope this example helps to understand the fee structure in Ardor,
  but please be aware that Ardor is still being developed so things
  might be different when it will go live.


structure of communicating with bitcoin DNSs to get list of nodes

"Bitcoin DNS" is a bit of a misnomer.

It appears that hostnames such as dnsseed.bluematt.me are not actual DNS servers - you cannot communicate with them using DNS protocols. However they are valid domain names in the normal public Internet DNS system and have multiple "A" records associated with them. You can therefore query the DNS seed hostnames in the normal way (i.e. send DNS queries to your local DNS servers) to get a list of IP addresses that are presumably Bitcoin full-nodes.

You can then, I guess, communicate with any of those IP-addresses using the appropriate Bitcoin peer-to-peer protocols.

Note that some of the returned addresses are IPv6 and some IPv4.

C:\> nslookup dnsseed.bluematt.me
Server:  xxxxxxxxxxxx
Address:  192.168.1.nnn

Non-authoritative answer:
Name:    dnsseed.bluematt.me
Addresses:  2607:fea8:80a0:a1f:b1dc:86a4:62a1:ff7d
          2001:0:9d38:6ab8:1c01:270:bff9:f75a
          2a01:4f8:c0:1328::2
          2a01:4f8:171:d4a::2
          2002:bc7c:110::bc7c:110
          2001:41d0:d:221d::
          2a02:a441:7147:1:70dc:dbc7:fcfe:c605
          240d:1a:124:5300:2cb0:2c4d:b748:3853
          2001:13d8:1c01:2000:2470::1
          2a03:4000:6:416c::43
          2600:1f14:6ae:d900:6550:3fc5:e074:a72c
          2a02:8106:22e:9d50::227
          123.5.48.235
          80.61.148.155
          159.65.33.252
          138.68.93.0
          13.78.125.30
          138.68.174.249
          171.124.53.172
          159.89.25.106
          148.251.83.196
          24.99.150.25
          192.3.11.24
          111.206.188.112
          88.198.39.205
          87.122.81.82
          96.27.129.94
          218.75.140.43
          218.75.158.185
          46.167.117.12
          195.43.141.28
          13.209.0.41
          95.216.26.158

This is confirmed by Bitcoin.org's developer guide which says

  When started for the first time, programs don’t know the IP addresses of any active full nodes. In order to discover some IP addresses, they query one or more DNS names (called DNS seeds) hardcoded into Bitcoin Core and BitcoinJ. The response to the lookup should include one or more DNS A records with the IP addresses of full nodes that may accept new incoming connections.

It goes on to describe the protocols that can be used to communicate with these nodes.


The number of nodes in the P2P network is unrelated to scalability. Due to the entire validating network operating in lock step, they all do identical work independent of their peers no matter how many of them exist in the system. One node, a thousand nodes, a million nodes all operate at the same effective speed (and the limits of the network are the same). Adding more peers actually worsens the load somewhat, as you increase the total bandwidth necessary to get the transactional data to everybody in the network quickly.


Need help understanding how to profit from bitcoin trading (like forex?)

Pretty simple. You just make money on the differences when you buy/sell (taking in to account fees).

In your example, you start with 1 BTC purchased at $100 USD.  Assuming no fees, you would:

Sell at $110 (Profit: $10)
Buy at $85
Sell at $102 (Profit: $17, total: $27)
... and  so forth

Now, you could get even more creative, since you can purchase fractions of BTC.  In this case, you could:

Sell at $110 (Profit $10)
Buy 1.294 BTC at $85 each for $109.99
Sell at $102 for $131.98 (Total Profit: $31.98)
...


Satoshi did start the blockchain.  The first block, known as the genesis block, is embedded in the source code of the reference bitcoin client.  The rest of the blockchain is built on top of this block.

The genesis block contains the headline "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks" to prove that the genesis block was created on or after Jan 3, 2009, and that Satoshi was not working on mining a longer blockchain in secret prior to this date.


My Bitcoin Transaction is Unconfirmed from last 10 days Please Help

Use RBF (Replace By Fee) to increase your fees and expedite your confirmation time.


What happens to my Bitcoins if I leave them at Coinbase after the hard fork?

This is what Coinbase says about the November 2017 expected hard fork:
Customers with bitcoin balances stored on Coinbase at the time of the fork will have access to bitcoin on both blockchains. There is no action required from customers and bitcoin can be securely stored on Coinbase before, during, and after the fork. Read more about it here:
https://blog.coinbase.com/update-on-the-bitcoin-segwit2x-hard-fork-69426f14bc85


Stuck duplicate transaction in BitcoinQT

Bitcoin Core (bitcoind and Bitcoin-Qt's new name) v0.9 will deal much better with these conflicting transactions within one wallet.

It will keep showing both, but the non-confirming one will be marked "conflicted" with -1 confirmations, will not be rebroadcasted, and won't be considered to have spendable outputs.


Is there developer documentation for the Bitcoin Core source code?

To understand Bitcoin Core, the best resource is probably the source code itself:

https://github.com/bitcoin/bitcoin

To help understand what is going on in the code, try the developer documentation and the Princeton Bitcoin Book.  Keep in mind that the code gets updated faster than the documentation, so the code should be your source of truth.

Some interesting places to start:

https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp - this is the source file that contains the code for interpretting script, and therefore checks for transaction validity

https://en.bitcoin.it/wiki/Protocol_documentation - the docs for the network protocol, such as message definitions and data structures

https://bitcoin.org/en/developer-reference#transactions - transaction reference describing the content and construction of transactions

For any clarifications and questions, I highly recommend this very StackExchange site :)


What actually caps Bitcoin's supply at 21 million?

Consensus rules
The supply is capped by the so-called consensus rules that every Bitcoin node enforces.
New coins are minted as block rewards by miners. Every node that receives the new blocks checks that the block reward is not greater than the current limit per block. Any block that exceeds this limit is deemed invalid by every node that receives it and is discarded and not passed on. Any node that passes on a block with an excessive mining reward is in danger of being ostracized by other nodes.
Nodes are made to distrust any other nodes that seem to be acting contrary to the established rules.
One of those consensus rules is the halving of mining rewards every four years approximately and it is this halving that causes the total supply to converge toward 21 million.

Note that many Bitcoin terms are arguably poorly chosen and misleading. This is one of them. These rules are Bitcoin rules or hard rules. Don't get hung up on the word consensus or dictionary definitions of that word.

Is this modifiable?

Rule changes can result in a fork. This can result in the creation of an altcoin. An altcoin is a cryptocurrency that is distinct from Bitcoin and seen by some as an alternative to it (hence the alt in altcoin). One example would be the altcoin "Bitcoin Cash" (BCH) which is the result of rule changes made by a small faction of Bitcoin (BTC) users. The proponents of this change had originally hoped that almost the whole Bitcoin community would adopt their rule changes. If they had succeeded, Bitcoin would now be using the rules of Bitcoin Cash and Bitcoin Cash would not exist. They failed in that original goal.
It is possible to make some rule changes in a way that doesn't trigger the distrust of other nodes that are still using the older rules.
This is a bigger topic than I can cover here but there will be good answers to existing questions on this subject:

What is a soft fork?
Would it be possible to create a soft-fork for reducing miner reward?
How do we know which soft-forks were implemented using User-Activated Soft Fork or Miner-Activated Soft Fork?

Tangentially related questions

Why was the upper limit of 21 million bitcoins put in place?


Why can't a transaction be redirected after it is signed?

The signature corresponds to the transaction it signs. You can't use the same sig to send the money to another address, because that would require a different transaction for which the signature would not resolve to valid.


Rise difficulty in code, still no changes after rebuild

What am I doing wrong?

Not setting the difficulty high enough. A standard computer can do 1 MH/s SHA256d hashes, or about 2^20 hashes. That means in your scenario, solving a regtest block will take about 1 second. If you want it to take longer, increase the difficulty.

Also, note that if you're using an 0.9.* version of bitcoin, then setting the regtest difficulty to below ~uint256(0) >> 16 won't really do much, as the mining code won't even check a result that doesn't hash to below that difficulty.

If you're using the most recent code, though, then rather than adjusting the regtest parameters, you could also just add your own set of parameters.


What does the sixth line in the output of the Bitcoin Core GUI RPC command "gettxoutsetinfo" mean?

It is a hash of the entire serialized UTXO set. You can use to verify that a node's UTXO set is uncorrupted (by comparing it with another node that runs the same command, at the same height).
The _2 prefix is to indicate the hashing algorithm that is used. Earlier versions used a different algorithm that became very hard to support efficiently. It's just there so people don't expect the hashes to be comparable between old and new nodes.


How to broadcast a non standard transaction?

You generally don't - there are likely to few nodes on the network that will forward it far enough to reach a miner.

What you can do is find a miner yourself, contact them, and see what mechanism they offer to include your transaction (perhaps for a fee). In this case, the transaction will not propagate through the network directly; only as part of the block after mining.


How do I specify many utxo in a bitcoin cash transaction?

const bch = require('bitcoincashjs');

const privateKey = new bch.PrivateKey('L1uyy5qTuGrVXrmrsvHWHgVzW9kKdrp27wBC7Vs6nZDTF2BRUVwy');
const utxos = [{
  'txId' : '115e8f72f39fad874cfab0deed11a80f24f967a84079fb56ddf53ea02e308986',
  'outputIndex' : 0,
  'address' : '17XBj6iFEsf8kzDMGQk5ghZipxX49VXuaV',
  'script' : '76a91447862fe165e6121af80d5dde1ecb478ed170565b88ac',
  'satoshis' : 50000
}, {
  'txId' : '115e8f72f39fad874cfab0deed11a80f24f967a84079fb56ddf53ea02e308986',
  'outputIndex' : 0,
  'address' : '17XBj6iFEsf8kzDMGQk5ghZipxX49VXuaV',
  'script' : '76a91447862fe165e6121af80d5dde1ecb478ed170565b88ac',
  'satoshis' : 50000
}];
const transaction = new bch.Transaction()
  .from(utxos)
  .to('1Gokm82v6DmtwKEB8AiVhm82hyFSsEvBDK', 15000)
  .sign(privateKey);

console.log(transaction.toString())

  from: A high level interface to add an input from a UTXO. It has a series of variants:

  from(utxo): add an input from an Unspent Transaction Output. Currently, only P2PKH outputs are supported.

  from(utxos): same as above, but passing in an array of Unspent Outputs.

  from(utxo, publicKeys, threshold): add an input that spends a UTXO with a P2SH output for a Multisig script. The publicKeys argument is an array of public keys, and threshold is the number of required signatures in the Multisig script.

Details: https://bitcore.io/api/lib/transaction#adding-inputs


What happens when the 21 million cap is reached?

Miners (who will no longer be mining, but will be validating transactions in the blockchain) will earn transaction fees. What those fees amount to or are to be interpreted as are hypothetical at this point, but might be imagined to be a transaction cost that ensures the security of the ledger.


Adding an external key pair to a local bitcoinj wallet

After searching for a while I found this type that takes a private key (in base58), required network parameters, and constructs the public address. Please refer: DumpedPrivateKey. This was enough for me at least. I construct an address from the key so formed using the toAddress method exported from the type key.

DumpedPrivateKey vanityKey = DumpedPrivateKey.fromBase58(networkParameters, "5JXFsJEAiqtTv95rSmw3KSJeAZ97SsmKWTQq5yqBzioSJ1guUHK");
ECKey ECVanityKey = vanityKey.getKey();
Address vanityAddress = ECVanityKey.toAddress(networkParameters);


Correct way to convert a 256-bit private key to WIF?

You're performing a SHA256 on an ASCII string, not on the actual number. That ASCII string is actually the hexadecimal representation of the actual number.

This is a little code snippet that uses a hex2bin function to turn the hexadecimal representation (from your question) into an actual number before performing the sha256 on it.


Why does the amount of sats in a lightning payment channel amounts vary if no txns are occuring?

Without detailed log files I can only guess the exact reason why you see this behavior. Two likely things come to my mind:

1.) Your node might have routed smaller payments. So in case you have outgoing capacity on one channel and incoming on another one someone might have used that to rout a payment. which would move some satoshi from one channel to the other

2.) If you opened the channels you are responsible for paying the fees in the case of a force close. These fees are taken away from the amount of satoshis which you own in your channel. Everytime you make a channel update (for example with a routing attampt - even if routing was not successfull) the fee estimator of your node and your peer try to estimate the onchain fees that your node would have to pay in case of a close.

Since your node seems to be fairly new and since the onchain fees have been fluctuating a lot recently I am almost certain that my second guess is the reason for the behavior that you observed.


The getbalance command shows an empty balance

You can query the balance only of address you own.

  I sent bitcoins to an address and blockcypher says the transaction has
  done but as I try to know the balance using bitcoin-cli -testnet getbalance the address, the address hasn't received yet.So why
  couldn't the address receive bitcoins or couldn't I send ?

The getbalance RPC method(and related bitcoin-cli command) accept two arguments, first is a string and it isn't an address, it's an account name, second is a confirmation coint To get the balance of whole wallet use:

bitcoin-cli -testnet getbalance

Or use getreceivedbyaddress:

bitcoin-cli -testnet getreceivedbyaddress 'the address' 0


How to import multi sig using importmulti correctly?

createmultisig is likely giving you the p2sh-segwit address, not the p2sh one. This means that the "redeemScript" you get from it is actually the witnessScript and the real redeemScript is the p2wsh script for your witnessScript. You can tell createmultisig to create just a p2sh address by setting the address type parameter to legacy.

Alternatively, you can get the redeemScript for your witnessScript by usingdecodescript.decodescript` will first decode your script, then it will give you the various possible addresses for it (for each address type available) along with the scripts for them.


Why was Bitcoin designed with a decreasing production rate?

The main issue with Bitcoin is not attracting late developers, but early developers. At its infancy, Bitcoin was an interesting curiosity - people would play around with it but not necessarily use it as money. But due to its scarcity and many benefits, Bitcoin came to be recognised as a digital currency.

At that point people could either wait and see if it gets bigger, or start using it. If Bitcoin's reward wasn't decreasing, probably a lot of people would put off getting into Bitcoin until it is more stable. If everyone decided to wait, Bitcoin would be going nowhere and fade into obscurity. Nobody would then care for late adopter's benefit. This is why getting early adopters on is so crucial - with them comes incentive for late adopters anyway.


What is the BTC address I could use for creating a transaction?

Any valid testnet address. You can get one from Bitcoin Core using the getnewaddress command.

  How do I "unlock" it to be able to send a transaction?

Use the walletpassphrase <passphrase> <timeout> command where <passphrase> is your passphrase and <timeout> is the amount of time you want the wallet to be unlocked for. The wallet will automatically lock itself after the number of seconds specified in <timeout>.

  How do I add some BTC to it to be able to send it and/or pay for the transaction?

To get regtest coins, you need to mine them yourself. Bitcoin Core can quickly and easily mine a bunch of blocks, just use the generatetoaddress command. Note that newly mined Bitcoin only become spendable after the coinbase transaction that produces them has 100 confirmations. So if you mine 101 blocks, you will be able to spend the 50 Bitcoin from the first block mined.

For help with the RPCs, there is a help command. You can use that to get a list of available commands. Their names are pretty self explanatory. You can then do help <command> where <command> is some command you need help with. This will give you a more detailed description of the RPC, the parameters it takes, and what the result it returns will look like.


How to run Bitcoin Core behind corporate proxy?

Bitcoin doesn't use HTTP for its communications - it has its own specific protocol that runs directly on top of TCP.  So an HTTP proxy like squid won't help.

If you aren't able to make outgoing TCP connections through your firewall (mainly to destination port 8333) then you'll have to contact your corporate IT people about adding appropriate firewall rules.  The same if you want to be able to enable listening.


Solo mining: gen=1 needed when using minerd?

In the case of bitcoind (as you say, maxcoind should be the same), setgenerate only affects whether bitcoind itself will mine.  It does not need to be on in order for an external mining program such as minerd to work.  All minerd needs is an RPC connection to bitcoind in order to find out what work it needs to do - and bitcoind will happily provide this regardless of the state of setgenerate.

Likewise, getmininginfo and its hashespersec number only reports the status of bitcoind's own mining - it has no way of knowing what other mining programs are running, or getting statistics from them.  minerd reports its own statistics directly to you.

bitcoind's internal mining code is not very well optimized, and isn't economical to use.  I don't know whether maxcoind is the same, but my guess is minerd is better, so just use it instead.  There's no point in using both as they will just compete for CPU resources.

Your final question should really be asked in a separate post, but anyway: there should be no problem with having many minerd instances fetch work from the same bitcoind, within reason.  (If you have millions of minerd's, bitcoind might not be able to keep up.)


Namecoin - How to Find Block Height via Block Hash?

At the time of asking, this functionality wasn't supported in Namecoin. I've written a patch that adds this and a few other properties to Namecoin's getblock RPC call.

https://github.com/namecoin/namecoin/issues/87
https://gist.github.com/ryancdotorg/5e610e9ee546beed367d


The original bitcoin client created by Satoshi was coded in C++, and is maintained here, now known as Bitcoin Core: https://github.com/bitcoin/bitcoin/


Can A Raspberry pi mine bitcoin without an ASIC miner?

You certainly can compile a Bitcoin node on a Raspberry Pi, and it will act as a fullnode relaying transactions for the network.  For mining, while it probably would work technically, the chances of you ever mining a bitcoin are so low that its probably a waste of time.

You can run other coins based on PoS on a Raspberry Pi though and make money that way, I personally use Raspberry Pis as my Gridcoin and SolarCoin staking nodes.


Why does Bitcoin charge per transaction?

Because it is in fact "almost free". The transaction fee charged by the bitcoin protocol is so small that it basically doesn't matter when compared to standard banking fees.

This measure is in place for several reasons, including:

Promoting mining. Mining requires expensive hardware and miners
expect to receive some sort of compensation for contributing to the
network. This is necessary to keep the bitcoin network decentralized,
secure, reliable and fast. This is where this fee ends up: in the
hands of miners that confirm your transactions.
Avoiding spam. Anybody could decide to write a bot that sends very, very
small fractions on a very short delay in order to spam the network,
as a form of DoS. This fee makes these kinds of attacks very
expensive, because if you transfer, let's say 30 euros, the fee could
be 0.01 cents. But if you transfer 1 cent, the fee is still 0.01
cents, making the fee not a percentage but a fixed quantity which
gets more expensive as the amount to transfer decreases.

Watch this to learn more: https://www.youtube.com/watch?v=X_hz7TyQ_bs


How much inflation does Bitcoin have, year by year?


Isn't bribe smearing possible because no payee signature is required?

The victim could send any "shady" or unauthorized donation back to the originating address, and the refund would be just as public as the initial donation.
The process could also be automated with a custom wallet software, so that, for example, all donations above a certain amount which are not explicitly approved are automatically refunded after x days.


Validation Error: Error #-26: 258: txn-mempool-conflict

This error means that you're trying to spend the same transaction output more than once.

More specifically, when you submit a transaction, a check is done (on the node) against the previous outputs of your new transaction to see if they are already trying to be spent by a transaction in the memory pool.

The check is in validation.cpp in the bitcoin source:

// Check for conflicts with in-memory transactions
std::set<uint256> setConflicts;
for (const CTxIn &txin : tx.vin)
{
    auto itConflicting = pool.mapNextTx.find(txin.prevout);
    if (itConflicting != pool.mapNextTx.end())
    {
        const CTransaction *ptxConflicting = itConflicting->second;
        if (!setConflicts.count(ptxConflicting->GetHash()))
        {
            // Allow opt-out of transaction replacement by setting
            // nSequence > MAX_BIP125_RBF_SEQUENCE (SEQUENCE_FINAL-2) on all inputs.
            //
            // SEQUENCE_FINAL-1 is picked to still allow use of nLockTime by
            // non-replaceable transactions. All inputs rather than just one
            // is for the sake of multi-party protocols, where we don't
            // want a single party to be able to disable replacement.
            //
            // The opt-out ignores descendants as anyone relying on
            // first-seen mempool behavior should be checking all
            // unconfirmed ancestors anyway; doing otherwise is hopelessly
            // insecure.
            bool fReplacementOptOut = true;
            if (fEnableReplacement)
            {
                for (const CTxIn &_txin : ptxConflicting->vin)
                {
                    if (_txin.nSequence <= MAX_BIP125_RBF_SEQUENCE)
                    {
                        fReplacementOptOut = false;
                        break;
                    }
                }
            }
            if (fReplacementOptOut) {
                return state.Invalid(false, REJECT_DUPLICATE, "txn-mempool-conflict");
            }

            setConflicts.insert(ptxConflicting->GetHash());
        }
    }
}


CPU and GPU mining costs more in electricity than it rewards in BTC at the moment.
You need special equipment with ASIC chips to mine at a profit.
These chips are designed to perform many hashes at low power consumption.

I suggest you ask your boss if he agrees with the negative efficiency of your current setup.


How do you access the NXT testnet to test out new features of the system?

Download the latest NXT, and goto your conf folder and there is a nxt configuration file there. Open it with a text editor and find the line that mentions "testnet = false" - Change that false to true and then launch the NXT application. (run.bat on windows) Once its booted up you'll see in "NXT server started" message. Then you goto:

http://localhost:6876

NXT testnet is port: 6876


Do mining clients affect efficiency of mining?

The mining clients does heavily affect the efficiency of mining.

Different mining software has a various developer fee, some are better written than others, and some are working better for nVidia while other are better for AMD.

The GUI miners are usually just a GUI wrap up for console miners, so different GUI miners also perform differently on different algorithms and hardware.

The loss you can experience if mining with wrong software can be from 0.1% to as much as 100%+.

That's why you should:
-have updated drivers(or best if latest aren't the best),
-do a research on your mining hardware potential,
-test as many compatible mining clients as possible.


Regarding block validation in blockchain

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

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


Is it safe to share bitcoin address and signature generated from electrum wallet

My question is if one shares bitcoin address and signature is there any risk of a attacker to compute the private key with this knowledge

While signing, the public key becomes exposed. The primary assumption is "It's impossible to find the private key which relates to a known public key", and this assumption isn't likely to be disproved (in other words, cracked) in the next 10 years.

The process of signing a message to claim airdrops is absolutely safe, as you can move your coins to a different address after claiming your airdrops.

The only risk is your privacy: They'll know how much money you have. If that's an issue, you can just mix your coins after you're done.


Do bitcoin exchanges own the bitcoins they trade with?

Traditional Bitcoin exchanges hold their customers' funds, both Bitcoins and counter-currencies. So when a trade is actually made, the exchange just adjusts their own balance numbers. Prior to being able to buy Bitcoins, you must deposit some other currency into your account at the exchange. Prior to being able to sell Bitcoins, you must deposit Bitcoins into your account at the exchange.


How can I know that a full node has finished the initial synchronization process?

You can check three factors in the getblockchaininfo RPC call:
The result contains a count of the blocks in your chain, and the headers your node has received from peers. For a fully synchronized node, the number of blocks equals the number of headers.
Additionally, there is an initialblockdownload boolean in the response, which will be set to false once the node has caught up with the main chain.


Is there a chance that bitcoin will be use as the Universal Currency around the Universe?

Steering clear of political and speculatory arguments and roadblocks, I think the following holds:

Aliens: not really. Not with the current 10m block time. A Mars colony would already have problems there. I guess some sort of two-way pegged Marscoin could be possible. For more remote aliens, I'm not sure how far you'd be able to stretch that. Confirmations come with time, but having to wait 10 lightyears before you're safe against double spends doesn't sound all that great.

All the other groups you mentioned: yes possible and already being done.


Difference between crypto coin vs crypto block?

I am not able to understand the difference between a bitcoin
transaction block and a bitcoin as a coin. Aren't bitcoin currency
also a bitcoin transaction block in case of a newly minted bitcoin?

A bitcoin block contains the most recent transactions, i.e. Person A sends Person B 10 bitcoins. It works like an old fashioned record book, where all the transactions are written out.
The first record in a next block is a transaction that awards the winning miner (who completed the previous block) the newly minted bitcoins.

Bitcoins are mined after solving cryptographic puzzles, but in the
initial days did the author(s) had to create lot of unnecessary
transaction to solve the puzzles to create new coins until the general
public picked it up (Or how did they create currencies without any
transactions in initial days)?

The initial block does not contain any transactions, it only contains the reward to the miner of this block. The first block is also called the Genesis block.
Watch this video ("But how does bitcoin actually work?" from 3Blue1Brown), it explains it really well with more details.


Am I safe if 16 words in my 24 word seed are leaked?

Ideally you shouldn't share any words and brute forcing with one paper in your case may take time but still possible. Also if someone gets one paper he can try social engineering to get another. Below links might help in understanding things involved in brute forcing.
https://medium.com/@johncantrell97/how-i-checked-over-1-trillion-mnemonics-in-30-hours-to-win-a-bitcoin-635fe051a752
https://twitter.com/JohnCantrell97/status/1274024510786883584
TLDR:
With 8 known words there are 2⁴⁰ (~1.1 trillion) possible mnemonics
To test a single mnemonic we have to generate a seed from the mnemonic, master private key from the seed, and an address from the master private key
Usage of GPU for brute forcing
Tx fee is normally high during such attacks
Open source code that was used:
BIP39-Solver-CPU: This is the CPU benchmark tool he wrote in Rust to get an idea of how long it will take do solve on a CPU for certain number of unknown words.
https://github.com/johncantrell97/bip39-solver-cpu
BIP39-Solver-GPU: This is the actual GPU version he ran on each worker GPU to solve this problem.
https://github.com/johncantrell97/bip39-solver-gpu
BIP39-Solver-Server: This is the actual server he ran that handled distributing the work to all the workers.
https://github.com/johncantrell97/bip39-solver-server
It would take the same system that brute forced the last 4 words of his mnemonic 837 quintillion millennium to brute force all possible 12 word mnemonics.


Retrieving BitCoin Payments, Confirmation Question

Yes, you can do that. Yes, it will eventually stop sending callbacks.

Expected Response
In order to acknowledge successful processing of the callback the server should respond with the text *ok*. If the server responds with anything else the callback will be resent again every new block (approximately every 10 minutes) up to 1000 times (1 week).

https://blockchain.info/api/api_receive


From the comments on the question, here is the one that Nick ODell created:

And another with the accepted moved a bit to the right, I just created:

For comparison, the original: