What is the relation between the bitcoin address and the corresponding private key?

A Bitcoin address is a hash of the public key. The Bitcoin wiki explains the exact (complicated) procedure in great detail. In brief, it involves hashing the public key and includes a checksum. The private key and public key are mathematically related.

If you have the private key, you can easily calculate the public key and address.
If you have the public key, you can easily calculate the address, but not the private key.
If you have the address, you cannot calculate either key.


Bitcoin mining process-the leading zeros before the hash-how is the mining puzzle solved exactly?

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

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

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

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

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

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


Can legacy wallets with 1xxx addresses send to segwit 3xxx and bc1xxx addresses like mycellium that only does 1xxx addresses?

Can I send out from my mycellium 1xxx address to my segwit 3xxx or bc1xxx address that I generated from a paper wallet?

The 3xxx addresses are P2SH addresses, and they have been around since 2012. They're usually for multisig policies, and only recently can also be used for segwit outputs. However, as the sender doesn't know or care what kind of script the hash is for, any wallet that can send to P2SH will support sending to such segwit address. This is the reason why segwit can be encapsulated in P2SH in the first place: to be compatible with old wallets.

bc1xxx addresses are new, specific to segwit, and likely only available in software designed to be compatible with segwit.

The best way to know what software supports what style addresses is to try, of course.


Why should I keep my coins in an exchange?

There is a difference, from a security perspective.

When you deposit your bitcoins to MtGox they credit your website account with what are essentially MtGox-bitcoin-credits. These are not bitcoins. If they chose to operate with a fractional reserve system (find out more here), they may have even spent some of the bitcoins, and you wouldn't know unless there was a run on the exchange (like a run on a bank).

Further, MtGox may or may not be able to reimburse you if they somehow lost all your bitcoins. They probably wouldn't reimburse you if someone managed to obtain your login details and withdraw your balance.

However, storing bitcoins yourself has risks too; they can be stolen if your computer is hacked (through malware or a virus). You can however reduce the risk of that to essentially zero by generating an address from an offline computer, printing the details, destroying all electronic traces of it, and transferring your balance there. Of course, then you need to protect your piece of paper...

There is also a difference when it comes to liquidity. If you have the balance stored with MtGox, you have the ability to trade it immediately (provided the website is online).


Block Validation: who does it? How much it costs? And is it present in all protocols?

When you become a full-node (NOT miner, you just downloaded the full
  blockchain with a wallet or smilar), are you automatically a
  validator? Meaning that every new block will be validated by you (and
  the rest of full-nodes) in order to publish to everyone else whether
  is trusted or not. Or it does not exist someone that can be only a
  "validator", and only miners can be also validators?

Yes, all full nodes validate all transactions before putting them in their mempool and all the blocks they receive. You do not publish to anyone if it's trusted or not, everyone checks if it is valid by themselves.

  Does block validation process spend too much energy? Or validate
  blocks is not a "big deal"?

No.

  In protocols that use PoW and PoS/DPoS (Bitcoin, Ethereum, Cardano,
  EOS...), once a block has been constructed using one of those
  consensus methods and included into the chain, will be always being
  involved this "second" validation for the rest of the full-nodes in
  that particular blockchain network? (I suspect that this second
  validation could be work slightly different in each of them, but
  always including this validation for the rest of the nodes)

Not sure what exactly you mean here. Every full node will validate all blocks once.

  And finally: what happen if one full-node start to rejects new blocks
  (he/she considers that are not valid), but the rest of the nodes says
  that is correct? Imagine a troll/hacker that starts to say that all
  the nodes are invalid, can that people be banned? Or will be that
  person just ignored?

If someone rejects valid blocks he will be left behind as the other nodes will continue to build their chain. No one asks anyone if "other nodes are valid" or "other blocks are valid", they ask each other for blocks which they verify themselves when they receive them. If he tries to provide an invalid block when asked for one he will be banned by other nodes. That's the whole point of bitcoin, you don't have to trust anyone, you check yourself.


In order to create a transaction, you need the blockchain, or at least the transactions in the blockchain that belong to a particular address (technical term would be unspent transaction outputs or UTXOs for a particular script). There are three ways this can happen:

You have a local bitcoind or btcd installed which would let you query for transactions, at the expense of downloading the entire blockchain.
You use an electrum or some other SPV server to query for transactions, at the expense of connecting to these nodes.
You use a centralized service such as blockchain.info to gather all transactions at the expense of having to trust the centralized service to be up all the time and to not be corrupt.

Any way you slice it, you cannot get the transaction data from a python library that doesn't connect to some other service. Hence tools like pybitcointools or pycoin will not get you what you need. sx has some tools to look up utxos using method #3.

You can install Armory or bitcoind and import the private key and use method #1 above or use something like pi-wallet and use method #2.


I co-founded Bitbond.net for purposes like yours. It's a peer to peer lending website where you can earn interest on your Bitcoins. However, the loans are unsecured and you need to decide which projects you like to lend to.

One of the reasons we had and still have a financial crisis is because many people did not really care what other people were doing with their money. Then they found out that some of the banks they trusted put their money to work in products the bankers didn't even understand themselves.

Low effort is always a double-edged sword as it might create much more work later.


No. ASICs are Application Specific, so they can't do anything else. Not password cracking either.

You can use them as an electric heater.


Unable to get private key for Blockchain wallet

You have to have that private key already. You cannot derive it from the public address. A watch-only address is an imported address.

If you've imported it from a paper wallet, check for the private key that should be printed on the same paper. You can scan the private key and upgrade the watch-only address to one that you can spend from as well.

If you imported some address you do not have the private key of, it will remain a watch-only address for you forever.


What is the point of a soft fork when it's backwards compatible?

Seems you answer the first question yourself :-).  Yes, it's a fork as it enforces new rules. But it does allow you to run an older version of bitcoind (not recommended though, but supported) and still be part of the Bitcoin network.

is there any active "soft" branches in the network that I can transfer on ?

This would mean there was a network split, what a soft fork is trying to avoid.
There are still old clients running that for example do not enforce the last soft fork that occured (Segwit), but they are part of the Bitcoin network and not an alternate one because the change was backward-compatible.


What do "support" and "resistance" mean?

By 'support' and 'resistance' assume you mean in the context of trading an asset. If so, then, simplistically, support means a level at which the value of the asset could become attractive for incremental buyers. Resistance means the value which the asset may be having a hard time breaking out of (likely due to people selling at those levels)


how can i get data from GDAX Bitfinex using API and show like bottom

They are just using websocket to connect to the exchange and then outputting the lives trades to the page by appending it to an element.

Here's a simple example using bitfinex:


Where/How does Bitcoin-qt check for receives to it's addresses?

the Blockchain contains all necessary info to know the balance of every address, including "it's own". When it downloads the next block, it updates all known balances by adjusting them based on every transaction in the block. This repeats.


What happens to transaction once all the blocks are mined?

Note that there are not 21 million blocks but 21 million bitcoins generated through mining.  As for your specific questions, the difficulty of a block is independent of its reward so that would continue to match the hashing power of the network.  And the reason that people will continue to mine is, as you state in the question, because they will receive the transaction fees for their effort.


Restore Block.io multisig wallet in Electrum

I knew that but I hadn't enough reputation to comment.

I have found a solution. I've got my BCH today from block.io which was already empty but it had a BTC on the day of fork.
So what you have to do is:

First of all you should get from security settings of you block.io profile: "Redeem Script Hex", and two private keys. (actually you will have some more strings and values but only these three required to claim your BCH).

After that:

Go to http://www.motelmaya.com/BCH/BCH.html

I know this seems strange and may cause doubts and believe me I wasn't sure too. But the real deal was: getting BCH (I had 0,5 of BTC at block.io wallet) or getting nothing.

So, then:

Click +TX
Enter the redeem HEX that you received from block.io in the first box (Address, WIF key or Redeem Script)
Click on "Advanced options" -> "Network" -> Settings and change the network to "Bitcoin Cash (mainnet)"
Click New -> Transaction or +TX once more.
Put in the amount you want to transfer and the address you are sending to (your new BCH wallet I guess - I've used my blockchain.info wallet address), make sure that the fee is not too high (I've entered something like 0.000317
Click "Submit", you will get a long HEX string. copy it
Click "Sign", paste the copied string, paste the first private key from the  block.io to the "Private key" field, click "Submit", copy the string.
Paste the string into the second box (below the "Private key" field), paste the second private key from the block.io, click Submit, copy the output
Go to "Broadcast", paste the string and click "Submit".

That's it. You will recieve TXid which you will be able to check at https://bitcoincash.blockexplorer.com

Actually all regards should go to ohad serfaty but I can't comment the post where he advised this method because of low reputation.

Good luck!


Can full node with only IPv4 connect to another full node with only IPv6?

No. IPv4 can not connect to IPv6. They’re almost completely disjoint networks except for the fact that some nodes can be dual stack with both, or many of each type routed.


Requested wallet does not exist or is not loaded

If you are trying to load a wallet, then you do not need to be using a wallet specific endpoint. loadwallet is not actually a wallet RPC so it does not need the wallet specific endpoint.
If you are trying to access a wallet that has already been loaded, then you have the wrong endpoint. The endpoint does not include the wallet.dat file. Bitcoin Core gives wallets names based on the directory that contains the wallet.dat file, and when it creates wallets, it puts them in directories of the name that was provided. The wallet RPC endpoints work similarly - they use just the wallet name. So the URL to access a particular wallet should actually be
http://127.0.0.1/18332/wallet/another_wallet

Note that this URL does not have a trailing slash (/). If you have a trailing slash, then Bitcoin Core will incorrectly determine the wallet name to be another_wallet/ where it is actually another_wallet.


The parameters you need to calculate this are:

E - the mining efficiency, measured in MHash/J. Data on this for various hardware is available in Mining hardware comparison (though this take into account only the card's power and not of the system it is in). Or you can calculate it for a given system by dividing the total hashrate (in MHash/s) by the power consumed (in W).

c - the cost of electricity, measured in $/KWh.

B - the bitcoin reward per block.

D - the difficulty.

The cost to generate 1 BTC is:

c*D/(838*B*E)

For example, if E=2, c=0.1, B=50 and D=1,500,000, this is
0.1*1500000/(838*50*2) = $1.79

The 838 "magic number" comes from the various unit conversion factors - 2^32 hashes per difficulty-1 hash, 3,600,000 Joules per Kilowatt-hour, 1,000,000 Hashes per MHash.


How are different Addresses generated from the same Private key?

Private and public key correspond to a point on the secp256k1 curve. They have a one-to-one relationship.

The address is derived from the public key by performing a ripemd160 hash after a sha256 hash on the public key. Multiple public keys hash to the same address, as the address space is only 160 bit, while the public key space is 256 bit.

Since both derivations (private key > public key > address) are deterministic, you cannot derive more than one address from one private key.*

What you can do, is derive additional private keys from a "master private key" with a given derivation rule. These additional private keys obviously correspond to new addresses. This type of address management is called "hierarchical deterministic wallet".

*Strictly speaking, you can create multiple addresses by differentiating between compressed and uncompressed keys. See Sven's and skaht's answers for details.


How do I identify my IP address on bitnodes?

If you are on a NAT network (192.168.****  or 10.*******) then use port forward in your router/modem and open 8333 in your firewalls.

Not behind NAT? Check all your firewalls and add a 8333 exception when needed


Those types of transactions are not desirable on the bitcoin network.   Each transaction takes up bandwidth and storage on each of the tens of thousands of nodes that exist.

If there were no fee, people that would like to harm Bitcoin would send those "spammy" types of transactions nonstop and the system would not be sustainable.

So the Bitcoin.org client takes a look at the transaction and if it is "spammy", it requires a minimum fee of 0.0005 BTC.

You can take the Bitcoin.org source and modify it so that no fee is ever required (or build from the branch that does this already), however your transaction will be rejected by most nodes and mining pools, and thus will likely not ever make it into a block.

You can, however, include many payment addresses in a single transaction. That way one small-ish fee will cover lost of small transactions, though as the amount of data the transaction consumes increases the fee may need to increase proportionally (0.0005 BTC per KB of data).

Be realistic though ... 0.0010 BTC is worth about a U.S. penny.  You are asking to send 0.00001 BTC -- an amount worth 1/100th of a penny.   There are very few reasons to ever need to send a payment to someone for a fraction of a penny.

In instances where earnings occur a fraction of a penny at a time (e.g., for each ad impression, or for each mining share earned), an EWallet account with that service where they are earned (e.g., mining pool) can be used to accumulate those earnings until a payout threshold (e.g., 0.1 BTC) is reached.  Then the payout can be sent without paying any fee.


How do i trade bitcoin with an altcoin if my wallet doesn't support that altcoin?

Your coins will be held on the exchange site itself until you choose to withdraw them to your own wallet. If you want to withdraw them, you will have to create a wallet for the currency you have purchased, and use it to generate an address to withdraw to.


Background info:

In a double spend attempt, how is the valid transaction chosen?

As Nick mentioned, transaction replacement using nLockTime and the sequence numbers isn't currently enabled by the network. In practice, this means that any transactions with an nLockTime in the future and at least one input with non-max sequence number won't be broadcasted because it is not a 'final' transaction.

So, if you:

broadcast TX1 with nLockTime 3 days in the future and then TX2 with nLockTime 2 days in the future, neither will be propagated by the network.
broadcast TX1 with nLockTime 3 days in the future and then TX2 with nLockTime not in effect (or in the past), TX2 will be accepted and broadcasted even though it wasn't the first TX spending its input.

Essentially, the network 'accepts' the first final (ready for inclusion in a block) transaction spending that input that it sees. There are some proposals to alter this method, such as relay-first-double-spend and replace-by-fee.


Do miners check whether a transaction is segwit or non segwit?

The miner only determines if it is valid. Miners do not, in a sense, "discriminate" between Segwit or Legacy.


What happens to the bitcoin network when the miners all stop in the future?

Bitcoin becomes very insecure if miners stop mining. Think of how easy a 51% attack would be to pull off.

However, I disagree with your assumption that miners will stop. And certainly that if Bitcoin dies it would be because miners stop. I would instead think that miners would only stop if something else already killed Bitcoin. Bitcoin is designed to always give miners an incentive to keep mining and secure the network. If miners don't have an incentive to mine, then Bitcoin has already failed.

Many mining pools don't pay out income from transaction fees and the whole thing is often glossed over. But mining income is newly minted coins PLUS fees from the transactions you include in the blocks you generate.

Have a look at the tx fee statistics at http://blockchain.info/no/charts/transaction-fees

As I write this at the end of march 2013, it looks like tx fees were about 4 BTC per day a year ago and are now about 50 BTC. At the same time the newly minted coins in each block has dropped from 50 BTC to 25 BTC.

With 6 blocks per hour this means one year ago we mined 7200 BTC in new coins and 4 BTC in fees per day. Now we mine daily 3600 BTC in new coins and 50 BTC in tx fees. So tx fees went from being 0.00056% of the income a year back to the 1.39% of mining income they are today.

I'm sure you can see where this is going. No, mining does not stop when the minting of new coins stops.


Did pools verify constantly the ouput of createrawtransaction when they build their coinbase transaction?

With the Stratum V1 protocol in use today (and the Stratum V2 protocol as it is currently proposed), mining pools actually send the parts of the coinbase transaction to their miners for those miners to modify. Specifically, they reserve space in their coinbase transactions for miners to use as an extra nonce. Those miners will construct the coinbase transaction, insert their extra nonce, compute the merkle root (they are given merkle branches to be able to complete the merkle root), and then create the block header.
However when the miner submits their work, they are only submitting the pieces that they added - namely the nonce, the timestamp, and the extra nonce. The pool will then reconstruct the coinbase transaction with the given extra nonce, reconstruct the merkle root, reconstruct the block header, and verify that the block header meets the PoW requirement for that miner. If the coinbase transaction had been modified by the miner, or by an attacker who sits between the pool and the miner, then it is unlikely that the block hash they calculate for that submitted share will meet the PoW requirement for that miner.
It is unlikely that miners are using createrawtransaction for creating their coinbase transactions as it is unable to do so anyways. createrawtransaction does not allow the caller to set an input's vout to be the right value for a coinbase transaction. So mining pool software are most likely creating the coinbase transaction internally rather than outsourcing it to bitcoind. In that case, they will be using the correct outputs. If they aren't, then either something is manipulating the coinbase transaction after the pool sends it but before the miner receives it, or the attacker is able to directly modify the pool software's memory.
In the first case, the PoW checking I described earlier is the protection. In any case, the pool can't really do much about an external entity (by external, I mean external to the pool software, it could still be running on the same compromised machine) modifying the coinbase when they send it out. In the second case, the pool can't protect against that as the attacker can just always make the software think that their coinbase is correct.


How to create an omnilayer transaction by myself?

A was able to do that. I posted a small snippet:

https://gist.github.com/caffeinum/f64a51ce55d5ac9075bb2f5f2f439c0d

If you're familiar with bitcoinjs-lib, the omni-specific piece of code for tx creation:

  const simple_send = [
    "6f6d6e69", // omni
    "0000",     // version
    "00000000001f", // 31 for Tether
    "000000003B9ACA00" // amount = 10 * 100 000 000 in HEX
  ].join('')

  const data = Buffer.from(simple_send, "hex")

  const omniOutput = bitcoin.script.compile([
    bitcoin.opcodes.OP_RETURN,
    // payload for OMNI PROTOCOL:
    data
  ])

  tx.addOutput(recipient_address, fundValue) // should be first!
  tx.addOutput(omniOutput, 0)

  tx.addOutput(alice_address, skipValue)

If you're insterested in working towards publishing small library, feel free to tap me at https://bykhun.com


"command not found' while installing dependencies

Not

libdb++-dev libboost-all-dev libcrypto++-dev libqrencode-dev libminiupnpc-dev

but

sudo apt-get install libdb++-dev libboost-all-dev libcrypto++-dev libqrencode-dev libminiupnpc-dev

Those are dependencies. install tells apt-get to download and install those dependencies. sudo gives apt-get admin permissions.


Cheapest way to switch from Exodus wallet to something else

Exodus eventually answered this questions themselves, with a similar answer to that given by @McLeodX but specifically discussing import of BTC private keys rather than sweep or transfer.

In short, export BTC private keys from Exodus, import them into Bitcoin.info wallet, then use bitcoin.info to do future transactions with fees that can be adjusted.

I am sure there are other wallets for which this method will also work.


Why does the beginning of `git log` for the Bitcoin source on github say 'sirius-m' was the first committer?

The source code was originally hosted in a rar file on Bitcoin.org. It did not use any Source Control Management. Later, when more people began working on it, one of the earliest developers, Sirius, moved everything to SVN on Sourceforge. That was later moved to the current Github repository and switched to using Git.


How is the bitcoin price affecting other crypto currencies

Agree that it's a broad question, but here is the specific answer to the parts you mentioned directly: yes, the price of bitcoin does directly affect the price of altcoins, and there is usually no calculation to avoid this, as the price of altcoins on exchanges are usually given as prices in bitcoin. Then to convert to USD, the current bitcoin/USD rate is used. Keep in mind that you can always use the bitcoin/altcoin exchange rate instead of the calculated USD/altcoin rate because that isnt affected by the bitcoin/USD rate directly (although it is, because the markets are related in other ways too, such as investor confidence in cryptocurrencies in general)


Does anyone have a formula for dynamic block durations?

Block duration is only controlled by difficulty (although indirectly) and network hashrate, so you'd want to increase difficulty when there are very few transactions in the last X blocks, and vice versa, decrease difficulty when blocks become too full, but also decrease difficulty when there is a low hashrate, and increase difficulty when there is a high hashrate.

At the same time, you'd need to incentivize mining, so you might want to have a reward relative to target time, instead of constant per block, as otherwise miners could spam the network in order to increase revenue.

A draft

Let's say, we are aiming to adjust from looking at the last 100 blocks for blocks that are 50% full.

findNewBlockTime():
  newTimeTarget = (avBlockInterval100)*(0.5/averageFullness); //shorter interval with many transactions, longer with less

setReward():
  newReward = newTimeTarget*totalIntervalReward/rewardInterval; //rewardInterval could be four years like Bitcoin, or some other interval, with four years totalIntervalReward would be 11.5M coins for first interval

calculateDifficulty():
  newDifficulty = sumDiffLast100/last100BlocksTime*newTimeTarget;


Getting current Bitcoin Fees from Command LIne?

If you have a running instance of Bitcoin Core, you can use estimatesmartfee to get a fee rate estimate.


How could BTC be used and transacted on a daily basis without physical theft?

Just to elaborate on the comment by Diego Basch:

Of course, Bitcoin has no solution for the fundamental problem that the threat of force can compel a person to do something they don't want to.  (Maybe that bug will be fixed in the next version of civilization.)  But street robbery should ultimately be less of a risk than you think.

Although it's possible to carry unlimited amounts of Bitcoin around with you (say, in a wallet app on your mobile phone), it's not envisioned that most people would handle their life savings that way.  Instead, just as with cash, you would carry with you only as much as you need for routine day-to-day spending.  The rest of your savings could be kept in "cold storage", with the private keys physically stored in a safe place that you access only when you need to replenish your wallet.  So a street robber couldn't steal all your coins, only those you had chosen to carry with you.

You could imagine other protections, too.  For example, a mobile wallet app would normally keep the keys encrypted and require a password to access them, so a thief who simply stole your phone wouldn't get your coins.  (They could try to crack the password, but by that time, you could use a backup copy of your private keys to move the coins to a new address.)

Now, a robber could try to force you to enter that password.  But you could imagine an app with a "duress code", an alternate password that when entered causes the app to delete the keys (assuming you have a backup in a safe place).  It could even do something like silently delete most of the keys but leave a small amount available, so that the robber thinks that's all you had, takes it and leaves you alone.  Kind of the Bitcoin equivalent of keeping $2 in your wallet and your other $500 in your shoe.


Why aren't miners filling up Bitcoin Cash blocks?

At the time of the question, Bitcoin Cash mempool had 917 transactions, and the Bitcoin mempool only had 8.1k.

  yes from ABC getinfo says "version": 140400

You're running an outdated version of Bitcoin ABC. 140400 translates to Bitcoin ABC 0.14.4, but the current release is Bitcoin ABC 0.14.6. Mandatory two-way replay protection was introduced either with 0.14.5 or 0.14.6. Your older version still considers Bitcoin transactions to be valid, so you're collecting both Bitcoin and Bitcoin Cash transactions in your mempool. Obviously, Bitcoin transactions aren't leaving your mempool though, because they are not being included in blocks. Thus, eventually your node's mempool will consist solely of Bitcoin transactions, assuming that Bitcoin transactions generally have a higher fee level.

Updating to the current version of Bitcoin ABC should resolve the discrepancy.


Janina Lowisz of Bitnation's BlockchainID project became the first "World Citizen on the Blockchain" by making a sort of blockchain passport:

Something similar could be done for identifying pets.

For instructions on how she did it, see:
https://github.com/MrChrisJ/World-Citizenship


How to 'pick' transactions to include when attempting to add a new block?

Basically, you can include whichever transactions you'd like.

Currently most miners simply include all valid transactions they know of. It is cheap to do so.

There is currently a limit of 1 MB per block, so as transaction volume reaches these levels, miners will typically want to include transactions that have the best ratio of fee / data size.

As a more mature transaction fee framework evolves, miners will choose transactions to optimize for it.

Playing with transactions included is not needed to extend your work scope, as you can extend it indefinitely by changing the extraNonce.


Can we do Multisignature transaction for bitcoin_cash?

Yes, Bitcoin Cash supports exactly the same script opcodes as Bitcoin (as of this writing), so multisig transactions can be created and spent in exactly the same way.


Can Taproot be used to commit arbitrary data to chain without any additional footprint?

Yes, you can commit to data this way, but there is nothing special about Taproot here.
The Pay-to-Contract construction used to tweak the root key in Taproot is generally usable, and has in fact been used for exactly this purpose. In fact, it is one of the mechanisms used in OpenTimestamps to commit to timestamped data (including a variant sign-to-contract which makes a signature commit to data rather than a public key). It is also used in Blockstream's Liquid pegin mechanism, where transfers from Bitcoin to Liquid pay to an address derived using a tweaked key of the federation, which commits to the transfer information.
In fact, using an additional leaf in Taproot for this is overkill, and would inevitably increase the depth in the Merkle tree for at least one other leaf - resulting in increased spending cost. Just using pay-to-contract or sign-to-contract directly on one of the public keys involved can be done with zero cost to on-chain spending policies.

Would this not significantly reduce the cost of services like colored coins, timestamping services, etc, which commit their data directly onto the chain?

Decent timestamping services already use better techniques.
For colored coins it depends whether they just need timestamping or actual publication of data. My understanding is that it's generally the latter (as otherwise, they need another censorship-resistant channel to transfer the actual data, which could then probably be used directly).


Bitpay/Copay use Hierarchical Deterministic wallets so you can find all the adresses that has been generated from your root private key (seed recovery phrase)

Here is a guide with more information: https://github.com/OmniLayer/omniwallet/wiki/Finding-and-Exporting-your-private-key-from-Bitpay-Copay


The hash that identifies a block is calculated from the block header. This hash must fulfil the difficulty requirements. Every node will check any block that they receive for validity. Since it requires a lot of proof of work to create a block whose hash fulfils the difficulty statement, it's infeasible to fake blocks and trivial to verify valid blocks.


Is the merkle root random? (Crytographically secure?)

000000000000000004f0cc322f551e39676f781186441614da3281bbc7d373e0 is not the merkle root, it's the block hash. It seems that's what you are asking about, so I'll answer that.

It's not random, nor cryptographically secure random.

Not random: As you can see, it begins with many zeroes, which a random hash is VERY unlikely to have. The right-most bits are random for the most part, but the value as a whole is not random because of the requirement that the block hash begin with so many zeroes to be a valid block.

Not cryptographically secure: A miner could, although it would be expensive for them to do so, mine many blocks and only submit ones that end in 'FF' for example. So, miners have the option to publish or not publish any blocks they solve. As such, since miners are producing these blocks, it is not cryptographically secure random.


Where are you choosing testnet network?
In bitcoin.conf should it really be telnet=1?
Maybe you meant testnet=1?


Sending very big amount with sendtoaddress RPC call

you are trying to send amount as string. Sprintf returns string.
You need to send amount as double (in PHP double == float).
Try this way:

$payment_tx = $ifc->sendtoaddress($account['address'], (double)$to_send);

If it doesn't work, use move at first, because sending can fail under many circumstances, while move always works.

Once you are done with that, please read my question about further problems with precision: Can I force json_encode in PHP to output 8 digits after dot for RPC?


What is causing "Network not available" error in rippled RPC call and how to fix it?

This error indicates that your server is not synchronized to the Ripple network and thus doesn't have current information. It's perfectly normal when your server first starts up -- it can take ten or fifteen minutes to sync up, depending on your bandwidth and hardware.

You should make sure you're actually connected to a few servers and have your validators correctly configured. The server_info RPC command can help.

The following config entries should help:

[ips]
23.23.201.55 51235
184.73.226.101 51235
54.225.112.220 51235
54.225.123.13 51235

[validators]
n9KPnVLn7ewVzHvn218DcEYsnWLzKerTDwhpofhk4Ym1RUq4TeGw
n9LFzWuhKNvXStHAuemfRKFVECLApowncMAM5chSCL9R5ECHGN4V
n94rSdgTyBNGvYg8pZXGuNt59Y5bGAZGxbxyvjDaqD9ceRAgD85P
n9LeQeDcLDMZKjx1TZtrXoLBLo5q1bR1sUQrWG7tEADFU6R27UBp
n9KF6RpvktjNs2MDBkmxpJbup4BKrKeMKDXPhaXkq7cKTwLmWkFr

[validation_quorum]
3

You can resolve r.ripple.com for a list of server IP addresses recommended by Ripple Labs. Currently the list is 54.225.123.13, 54.227.239.106, 107.21.251.218, 184.73.226.101, 23.23.201.55, and 54.225.112.220.


Transaction with slightly changed script is never relayed

The standard client will not relay non-standard transactions. However, if you get them directly to a miner that accepts them, clients will process them correctly and the transaction will work.

You can send your transactions to 173.242.112.53. This is a server run by Eligius that will relay all valid transactions and they will include even non-standard transactions in the blocks they mine. Others who are willing to relay or include free and non-standard transactions also tend to link to this node, so it can get your transaction included in blocks mined by other pools as well.


Coimarketcap api data different from coinmarketcap.com

This is likely due to the update frequency of the API and website.

They certainly use the same source to get data for their website and API.

One might be lagging a few minutes sometimes. I'd assume the API data is the most up to date and it's safe to rely on it.


Is it possible to get Node Id that paid an invoice?

This is not possible. The buyer has privacy by default. The only information sent in a payment is the payment_hash, the amount and a CLTV value.


Can I use Multibit private key for paper wallet?

Yes, writing your MultiBit (non-HD) private keys on paper should work.

You definitely need to write down the private keys corresponding to public addresses that have a positive balance.

You also need to write down the private keys for public addresses that are present in your MultiBit wallet but have not been used yet. This is because they are considered to be on standby, and may be used in the future for receiving change or incoming payments.

As long as you carefully back up all your private keys and don't generate any new ones, you can always restore your wallet just from the private keys alone (with no other metadata, etc.).

Be warned that whenever you create a new wallet in MultiBit, it will generate one random key for you by default. So even if you import your old keys into the wallet, you will still have that new fresh key which needs to be backed up, otherwise you risk losing coins.


how do devs upgrade bitcoin core without affecting the live active network?

Most network changes are totally backward-compatible. When two Bitcoin nodes first contact each other, they tell each other the latest protocol version they support. They then use the oldest version of the two. In this way, even really old clients can connect to the network because all other nodes will switch to the old protocol version when talking to them.

Occasionally, it's necessary for all miners or (extremely rarely) all Bitcoin users to change some network rule at the same time to prevent the network from splitting in two. This is done by adding the change to the code, but only activating it at some particular time some weeks/months/years after the change is added. After the time has elapsed, most people will have upgraded to the new version of Bitcoin, and doing the change will cause minimal disruption. Instead of updating at a particular time, changes can sometimes also be activated when nodes detect via info inserted into the block chain that most other nodes have upgraded.


In my Bitcoin Core Wallet I see peers identified as "BitcoinUnlimited" why?

BitcoinUnlimited is fork of Bitcoin project, maintained on github.

People using BitcoinUnlmited instead of Bitcoin-core are showing that as User Agent

BitcoinUnlimited offers two builds one for Bitcoin and other for Bitcoin Cash.

So what you are seeing is people using BitcoinUnlmited client for Bitcoin.

You don't have to BAN them, as they are not on BitcoinCash network but on Bitcoin Network.


When, if ever, will "peak bitcoin" occur?

At the beginning of Bitcoin, every newly mined block (about every 10 minutes) creates 50 bitcoins. This is called the block subsidy. About every 4 years, this number cuts in half. Therefore, the peak extraction rate was about the first 4 years of Bitcoin's existence.
In fact, it was from 3 January 2009 to 28 November 2012.
The block reward includes both the block subsidy, and the transaction fees of transactions included in the block, so miners still get bitcoins, but they are not newly "extracted" bitcoins, they are bitcoins that someone else has paid.
Note that one block is mined about every 10 minutes. The number of miners is irrelevant. The speed of the miners is irrelevant. The system automatically adjusts itself so that one block is mined about every 10 minutes. That is the only reason why mining requires a lot more computational power than it used to - you are competing with a lot more people.


How do I generate a SegWit address using Bitcoin Core CLI?

You can use addwitnessaddress addr, where addr is an existing P2PKH or P2SH address of yours. It will construct a P2SH-P2WPKH or P2SH-P2WSH address with the same key/script, if known to be valid.

Note that this command is not available until SegWit is active on the network, as before that time, such outputs would be spendable by everyone.

Since Bitcoin Core v0.16.0, P2SH-P2WPKH addresses are the default, and the addwitnessaddress RPC is deprecated.

  Also will I be able to redeem those outputs and send them to a "legacy" address?

Yes.

  If so, will this second transaction be accepted by older, non-SegWit clients?

Yes, it is a softfork. Every new transaction is valid according to the old rule. If not, a chain split would occur. Older clients may not see the transaction until it is confirmed, however.


The code isn't optimal especially not on the merged mining side.  Currently there is no optimal method to handle both block chains without a more advanced miner-pool communication protocol.

Excluding merged mining issues, latency is a large factor.  When a block change occurs every single miner's effective hashing power is zero until they begin working on updated block header.  Thus a pool's effective hashing power goes from total hashing power down to 0 and then rises as miner's are updated. So pool's long term effective hashing power depends on how quickly it can deal with a block change.

This involves three components.

Detecting block change.  A good pool should have large number of connections to the Bitcoin network to minimize the delay in learning of block chain. A good pool operator will ensure they maintain connections "close" (within 1 or 2 hops) of every major pool.
Recalculating block headers.  During a block each miner will complete their work at differing times and thus getwork requests are staggered.  However when a block changes the pool needs to update every miner's block header at once. A pool lacking sufficient processing power to quickly compute block headers will have miners working on stale work longer and thus have a higher average stale %.  Updating miners in the order of their hashing power could reduce the pool's overall stales slightly.  I don't know if any pool currently does that.
Update miners.  The latency of the miner's link is beyond the control of the pool but a pool can improve efficiency by having multiple pool servers reducing the number of hops to all miners.  Pool servers should be located as close to miners as possible.  A pool consisting mostly of miners in Asia shouldn't use US East Coast datacenter for example.

NTimeRolling reduces the number of communications (getworks) required for a given number of hashes.  this makes the pool more efficient as a given amount of hardware can support more clients however it doesn't reduce load at a block change.

Implementing Long Polling ensures that miners are notified when a block change occurs (minus latency indicated above) rather than continuing to work on stale data until complete.  Completing one nonce range takes roughly 10 seconds for a 400MH miner.  Without long polling on average the miner will waste 5 seconds per block change working on data that can never produce a valid block.  Given block changes occur every 600 seconds that is roughly 1% of CPU time wasted hashing invalid block headers. Slower miners have longer period between getworks and thus waste a greater % of GPU time.  No pool can be efficient without a good Long Polling implementation.

Both NTimeRolling and Long Polling (LP) require a miner which properly understands these commands.


How many bitcoins are there currently in circulation?

If you are running Bitcoin Core, you can see the total amount in circulation using the RPC call gettxoutsetinfo (in the Bitcoin-Qt debug console, or using bitcoin-cli if you run bitcoind).

At the time of writing, the output is:
{
  "height": 517245,
  ...
  "total_amount": 16965398.58586455
}

which means there are currently ~17 million BTC in circulation. This number takes into account certain types of destroyed coins.

See also this answer of mine about how many there will eventually be.


Your coins should be safe.

No need for a brainwallet:

open the new client and create a new address
backup this new wallet
open your old clients and send your coins to that new address

Never delete the old wallets anyway, just in case.


Solar Flare wipes all hard drives... What happens?

All hard drives are wiped clean and with them all records of the Bitcoin blockchain.
Would we be able to recover?

Recover what? You stated all hard drives are wiped clean, so obviously we would not have a backup to recover the network from.

Is there some alternate backup of the blockchain?

Perhaps someone has printed the blockchain out onto paper. In an event like the one you've described, we should hope that there are many copies of this paper format blockchain, so that we don't have to trust that one person to have provided us with a copy of the blockchain history.

Do we hope that at least one computer is protected beneath ground?

If there was, then your premise of all hard drives being destroyed would be violated. Same as above, we should hope for many independent copies to surface, stored underground (or whatever) all around the world.

I assume everyone's personal wallets would be lost unless they used paper wallets.

Even if you used a paper wallet, if every record of the blockchain history was destroyed, your paper wallet would be useless. A paper wallet simply holds the private key capable of spending the bitcoin stored at it's corresponding address. If the blockchain record were lost completely, there would be no network to agree upon how much bitcoin is stored at that address. So a paper wallet that held 100 BTC before the catastrophe would be no different than one that held 0 BTC. With no blockchain to make a claim against, they would both be effectively worth 0 BTC.

Certainly a big blow to the Bitcoin community.

Sure, but any event catastrophic enough to knock the bitcoin blockchain out would be devastating FAR beyond that. Bitcoin is highly distributed, to destroy it would take an event of unbelievable magnitude. While I believe Bitcoin is important, there are many other systems more critical to our everyday life that would be affected also.


Why does the length of a bitcoin key vary?

The length of a key doesn't vary. Private keys are always 32 bytes, and public keys are always 65 bytes (or 33 bytes for a compressed public key). Public key hashes are always 20 bytes.

The length of addresses vary because in Bitcoin's base58 encoding, leading zero bytes are expressed as a single "1". Other bytes require more than one character in order to be expressed in base58.


What if a multibit classic private key is decrypted into garbled codes?

I think what you are seeing is binary data being viewed using a program (or command) that expects ASCII or UTF-8 encoded character data.
I would add -base64 to the openssl command and see if that produces the results you expect.
If you need the key in a different encoding (like say base58 or WIF) you might have to do that as a separate step using a second command/program.

Decrypting keys from Multibit
I found some instructions for decrypting Multibit keys which don't say if they are for Multibit Classic, Multibit HD or for both. It may be they only work for one and not for the other.

This is the format of the MultiBit private key file
Keys are saved in an ASCII encoded text file.
There is one key per line (empty lines and lines starting with '#' are ignored).
\<Base58 encoded private key\>[\<any number of whitespace characters\>[\<key createdAt in UTC format\>]]

To decrypt a MultiBit private key export file use:
openssl enc -d -p -aes-256-cbc -a -in \<ciphertext file\> -out \<plaintext file\> -pass pass:\<password\>

Note that this command lacks the -md md5 option you used. I would try this version.
The OpenSSL manual page says

-md digest
Use the specified digest to create the key from the passphrase. The default algorithm is sha-256.

so this would affect decryption.
The results you are reporting suggest that either the instructions you used don't apply to the particular version of Multibit you used or that you don't have the correct data file or perhaps don't have the correct password.

Importing keys into Electrum
According to instructions for importing keys into Electrum, Electrum needs the key in Wallet Import Format (WIF) so you'll need to convert your exported Multibit key into that format. It looks like it is easiest to start with a hexadecimal representation rather than the Base58 Multibit and others use.
Note that you can't just import a private key into Electrum at any time. You can only do that when you first initialise and create the Electrum wallet, not subsequently.


How do I view the "change" addresses in my wallet? listreceivedbyaddress 0 true doesn't work

The standard client always sends your Bitcoins back to a new address. If you want to figure out which address it went to, you can use gettransaction to view your transaction details (you got the ID when you issued the transaction), and check its outputs. The output that is not one of the addresses that you sent money to is your change address.


Yes you are correct. The signatures are produced separately, by each signer and then combined into the final input script. When an individual is signing, he/she is not signing the a transaction with the signature of others, only the transaction sighash, where no signatures are committed yet.


Basically as fast as a regular payment. The encrypted onion is being transported from node to node and will most likely leave the TOR network pretty quickly as many connections in lightning happen with direct IP connections.

The path calculation is happening locally on your node and does not need communication with your peers at the time when the payment is sent (before to download gossip information you need to talk to your peers)

And then of course the first hop sending the onion to your partner will now happen via TOR and go trough a couple of TOR nodes taking potentially a more complex path than a direct IP package to your peer would take.

I would argue that this extra IP traffic from TOR can be neglected in comparison to forwarding the onion and probing several paths.


Why increasing block size increases centralisation?

He seems to be saying that if the block is too big, he might need more time to validate it than the time the network takes to solve a new block. This would mean he loses time with every block, and therefore can't validate at all.

Bitcoin blocks are solved every 10 minutes on average. He suggests that if blocks take him 11 minutes on average to validate he would lose a minute every block, therefore he would be unable to validate every block, which defeats the purpose.

With the assumption block sizes will increase, I'm unconvinced this problem is even on the horizon. In answer to the question "how long does it take", this excellent answer refers only to seconds, not minutes. For validation to snowball into an 11 minutes long process, we'd have to willfully neglect it's long predicted coming. I doubt that would ever happen.

But that's an extreme example. In reality, going from 5 seconds to 15 seconds really seems insignificant at first, but it does have advantages for larger miners over smaller miners.

A significant portion of blocks are found within seconds of the previous block. If you found the previous block you can skip validation and begin working on the next block immediately. This means you will get lucky every now and then and shove the next block within a few seconds, allowing you to claim the reward and fees. Comparatively, if a different miner solves the next block within a few seconds, he will submit it without any transactions because he was still validating the previous one. Naturally, large miners find more blocks, so they are more likely to benefit from this.


Where can I get a list of all the 72 initial NXT stakeholder addresses to see distribution?

All 73 initial stakeholder accounts are included in the genesis block of the blockchain.

You could write a script to extract the detailed information you are looking for from the block chain, using the NXT API. However, even if you follow the money trail, there is no way to know who owns the destination accounts -- some may be owned by the original stakeholders.

Perhaps a more useful study is to analyze the blockchain to determine the amount of NXT concentrated in large accounts vs. small accounts. This has been done in a graph here. Notice that much distribution took place during the first month or two and continues at a slower pace since then. You can click along the horizontal axis to remove selected bands in the graph.


Keeping the blockchain index after Bitcoin-Qt upgrade

Version 0.8 of the reference client changed the database format completely, in order to scale better. That meant a one-time rebuild that everyone had to go through, as converting the old database would have been error-prone.

With that change, the transaction index was made optional, and off by default. This is because for normal operation (verifying and processing blocks and transactions, and maintaining a wallet), such an index is not necessary.

An option -txindex (or txindex=1 in bitcoin.conf) was introduced to re-enable this transaction index (which is necessary for the getrawtransaction RPC call). It has to be specified when the database is created though, so at first run of a post-0.8 version, or when explicitly rebuilding the index (with -reindex).

This type of database format change is not expected to happen frequently.


Why can't any transaction be simply "move X BTC from key K to key I signed by private key K"?

Then you couldn't (easily) do the P2SH stuff being implemented right now without getting everyone to upgrade. You also couldn't do escrow, multisig, secure cross-chain trading, secure high-frequency trading, etc. These features are very valuable; Script-based escrow, for example, will be the first escrow system ever which requires no trust in third-parties.

Script is, in my opinion, one of the greatest innovations in Bitcoin. I would prefer a much more powerful, Turing-complete version of Script in Bitcoin, actually.


What's the difference between a wallet and an address?

Addresses are public-key hashes of an asymmetric key pair
An address represents a hash of a public key of an asymmetric key pair.¹ The owner of the key pair can use the private key to sign transactions or messages (for example in order to prove ownership). Only by using the correct private key a valid signature may be created, which then anyone can verify as valid by using the associated address (which, again, represents the public key).
Wallets are an abstract concept, a "keyring"
A wallet is an abstract construct, which contains the set of public and private key pairs randomly generated for the user. In a deterministic wallet, the keys are derived from a passphrase (a specific seed, masterkey or password) instead of a random seed. Essentially, it corresponds to a keyring in the cryptographic sense.
The Bitcoin client software abstracts the wallet for the user such that it checks each of the addresses contained in the wallet, whether there are any balances (transaction outputs) associated in the blockchain with them. It sums the funds up and presents them as a single total balance. Underlying, however, these balances are stored publicly in the blockchain (that's right, the wallet doesn't contain your coins, it just allows you to spend them). They are split up to numerous addresses and transaction outputs:

Address #15521² has
3 BTC in transaction output 1
Address #23414 has
1.2 BTC in transaction output 1
0.7 BTC in transaction output 2
...

Everyone can see them, however, usually can't determine the identity of the owner.

¹ To be more accurate an address is a Base58-encoded hash of the public key.
² Of course, real addresses actually are alphanumeric strings with up to 34 characters.


Full node storage requirements for new 2MB block which is only 10% full

Full nodes are not required to store blocks (they can be pruned). So the answer is 0.

If a 200 kB block does get stored, it takes 200 kB to store it.


Why I have some many address when I only created two wallet address in Electrum?

Electrum will generate a certain number of addresses in advance. It doesn't really matter since it will always generate the same addresses in the same order thanks to using Hierarchical Deterministic (HD) wallet, but you can modify the number of addresses generated if you want, it's called the gap I think.
The gap can sometimes matter though if you're using some software like Electrum Personal Server or BTCPay, if you received a payment on an address that is outside of your gap (for example, Electrum only generates 20 addresses and you've got a payment on the 34th), Electrum won't see this payment and it can make you believe it's not there. If it ever happens, relax and augment the gap until you find all your payments.
receiving are the addresses you will use to receive payments, change addresses are automatically used by the wallet when you spend bitcoins to send your change to. In theory nothing prevents you to directly send bitcoins to your change address (I mean those addresses have nothing special from a protocol point of view), but it's pointless and bad practice don't do that.


How does one document Bitcoin investments for tax and other legal issues?

What legal documents to keep?  That's really a question for your accountant and/or attorney. One could reasonably expect to need about the same level of documentation as would be required for an investment in stamps or coins.

Most likely the exchanges comply with AML (Anti-Money-Laundering) statutes in their own jurisdictions, but the onus is probably on the individual to obtain documentation of all transactions.


The keypool is how Bitcoin Core achieves the lookahead functionality when you restore a backup. It is effectively the "gap limit". While BIP 32 does mean that one backup should be sufficient, it is possible that the keypool is too small (if you somehow hand out thousands of addresses but never receive at them) so backing up routinely is still a good thing to do. Also, backing up routinely allows you to keep metadata like labels when you restore.

The keypool is also useful for encrypted wallets as it allows getting new addresses to give out without having to unlock the wallet every time.


who is the "owner" of a newly mined BTC before its first transaction?

The amount for the block reward is what is created, there is no additional created for any reason. If the block reward is 6.25 BTC, that is exactly what the miner is paid, and nobody else.


Does the amount of the transaction fee affect the priority of a transaction?

Currently no.  Any "required fees" are enforced only by the client not the network or protocol.

It is up to each individual miners which transactions to include in a block.  If forced to make a choice a miner would choose a paying transaction over a nonpaying one however current transaction volume is so low that all transactions (paying and otherwise) can fit into next block with significant room to spare.  If you used a modified client with no fees most miners would simply include your fee transactions.  Some pools (Eligius) will exclude free transactions that "should" (based on mainline client rules) have a fee.

As for what fee is the minimum to guarantee access to the next block.  Most miners and mining pools prioritize transactions by fees and then priority.  If you include any fee (even 1 satoshi) even if it is less than what is required by mainline client it likely will be included in the next block. Paying more is likely of negligible value as paying anything almost guarantees access to the next block.  The block size limit isn't much of a capacity constraint to warrant higher fees (and move further up transaction list ordering).  I can't see any miner excluding a valid paying transaction from any block at current transaction volume.

The current fee structure (or lack thereof) brings up some scalability issues when block reward aproaches zero.  The development team has indicated an improved fee structure is something planned for later releases.  It is an issue which will need to be addresses as left as it is now one could simply include 1 satoshi fee with every transaction and it would drive block fees down to ~ (transactions per second) / 166,667 BTC per block.  Even at high volume of say 1,000 tps it would be a tiny number and thus network hashing power would fall to a tiny fraction of current hashing power leaving the network vulnerable.


SPV clients are thin clients that do not need to hold the full blockchain. They use other nodes on the network to validate transactions. SPV clients are available for Android and require a lot less disk space.
Of course it is more secure for you and for the network to run a full node.


Is it possible to specify a default change address?

Yes you can. Although it is discouraged.

Place the following in your bitcoin.conf file

changeaddress=yournewchangeaddress

Unless you have a real need to keep the address count in your wallet low than you shouldnt use this as it opens up security risks and destroys anonymity.

You should be using a new address for every transaction you make.


If you want to create your own implementation using the Bitcoin Client, you ought to look into Accounts. This concept would allow you to have complete control over your users' payments, but it would also mean that you have to implement your own solution that would be communicating with Bitcoind.

There is also a more complete solution from StrongCoin in PHP, but I have no experience with it.


How to develop an ownership tracking service based on bitcoin blockchain

There are a lot of different projects that are looking to solve this problem. Almost all of them use something like colored coins to track an asset on the blockchain. Essentially, what your plan is missing are clear rules that prevent double spending.

Check out coinprism.com, colu.co and chromawallet.com for just a few different implementations of what you're trying to do.


What is the precise definition of "witness program"?

Thanks for your comments. This is the proposed fix: https://github.com/bitcoin/bips/pull/416


Bitcoin Core sync very slow

Bitcoin Core is capable of full sync in a relatively short period of time depending mainly on the hardware.

Most of the work done is not actually downloading the blocks, it is validating them and every transaction that they contain. It not only depends on downloading the blocks but also on the quantity and complexity of every transaction. The downloading of the blocks themselves is usually not an issue if you are connected (outbound) to several nodes. I am able to download blocks generally in forty-five seconds each (which includes the request time etc. and validation as well as the transfer) when I have been offline and am catching up on my restricted local 256Kbps link. My upload speed is low, and latency is high. At the rate of one block per forty-five seconds, it would currently take over two-hundred-and-sixty-three days to complete the whole blockchain as there are more than 506822 blocks as of writing.

From my personal experience, the initial sync actually took over five days to complete on a 2.5GHz Core i5 notebook with 4GB of RAM running Fedora with Bitcoin Core v0.15.1. For that, I used ADSL2+ and never perceived the actual downloading of the blocks to be the issue.

Performance of initial sync

Performance of initial sync largely comes down to the individual performance of your computer, provided your internet is fine.

Always use the latest release version of Bitcoin Core (includes bitcoin-qt and bitcoind) downloaded from the official site at www.bitcoin.org. An upgrade is safe and easy, just safely exit Bitcoin Core first and make a new secure backup of your wallet.dat before you upgrade.

Adjusting parameters

There are some parameters that you can look at and consider depending on your system. Always make a backup of your wallet before making any changes. The parameters can be entered at the command line or generally in your bitcoin.conf file, which you would need to exit and restart Bitcoin Core in that case to see the effect. Some things to consider that could make a difference:

I am presuming here that you are running bitcoin-qt which is the GUI version and not bitcoind.

If parameters are used in the bitcoin.conf file, omit the leading -.

-datadir= You could have your datadir on a fast drive. If you move your whole .bitcoin folder you will need to specify this parameter on the command line. Note that if you change your datadir and do not copy the .bitcoin folder over to the new location first, it will create a new wallet and begin downloading the blockchain again from the start.
-dbcache= The default for this is 450. If you have 8GB of RAM, you could easily set this to 4096
par= The default for this setting is auto, but I do not know what the automatic setting does. You could try setting this to -1 which leaves one core free.
-banscore= You could try setting this to 10 to kick off misbehaving nodes sooner.
-listen= You could temporarily set this to 0 to disable incoming connections while you get the initial sync done. Your busy node does not need the additional work.

After the initial sync, you can revert these settings to their defaults but probably leave your datadir wherever you put it.

Some of these parameters are available as options in the bitcoin-qt Settings > Options menu.

TLDR; The short answer if you want it fast is, get a fast computer, loads of RAM, a fast HDD and, fast internet. The same as anytime you want anything fast on a computer.

In the real world, and from personal experience, using an SSD increased sync speed more than 10x on my example system from the performance noted above.

Anecdotes

Real life example of varying system performance: I know someone personally who had to work on a quite large, but not extraordinarily large, Illustrator file. He opened it on his ~12-month-old upper spec Mac which usually performs great and, it was virtually unusable (slow to respond). Just for kicks he thought he would try the same file on a bog standard PC, opened it in Illustrator and it was completely normal. Some hardware/software builds have bottlenecks for some processes. The opposite result is probably true for some operations.

Also note, I have observed that exiting and restarting Bitcoin Core during initial sync seems to speed it up a bit for a while once it connects to nodes again.

Referencing again personal experience, syncing on Windows 10 64-bit seems to be orders of magnitude faster than syncing on Linux on the same hardware - even if Windows is running in Gnome-Boxes, it easily churns through 100 blocks per second during the initial stages of download.

Alternatives

If you are in serious trouble waiting to sync Bitcoin Core (a full node client) and you do not need the additional features that Bitcoin Core provides then, you may consider trying Electrum (not a full node client) which does not need to do the initial sync. On Fedora 27, getting Electrum is as simple as sudo dnf install electrum.


What if I backup my wallet from a client that is not fully synced with the blockchain?

1) Yes. You will have access to your funds. Every wallet.dat stores the "best block" (~newest block the wallet was synced with). When you start a bitcoin-core together with your old wallet.dat it will automatically rescan for wallet transaction down to the "best block" stored in the wallet.dat.
If you funds are not available, try starting bitcoin-core with the -rescan argument.

2)3) A keypool does contain pre generated keys. The keypoololdest is a timestamp of the oldest (unused) key in your keypool. If you have not generated addresses (also happened when you send funds; change address!), this timestamp can be really old and doesn't matter in your case.


What happens if your bitcoin client generates an address identical to another person's?

If this happens, then Person B will be able to spend person A's bitcoins. However, there are only two ways this can happen:

a) Person B generates the same keypair (private key) as person A

or b) Person B generates a different keypair, which (public key) hashes to person A's address (a hash collision)

Take a look at the specification for at bitcoin address: https://en.bitcoin.it/wiki/Technical_background_of_Bitcoin_addresses

  A Bitcoin address is a 160-bit hash of the public portion of a
  public/private ECDSA keypair

For "a" to happen, person B would need to break "secp256k1".
I am no expert on this field, but from what I can find on bitcointalk.org, then the "strength" of this is 2^128 bits. And if you're wondering how strong that is, then look for the video "Exhaustive search attacks" from Dan Boneh. 11 minutes in the video he says "anything that's bigger than 2^90 is considered sufficiently secure" (its about attacking 3DES, which is a symmetric block cipher so I'm not sure it actually apply to secp256k1, but I really have no better argument for why 2^128 is "so secure that you won't never, ever, ever generate the same key as someone else"

And for "b" to happen, you would need to find a collision on RIPEMD-160(SHA-256(pk)). As far as I know, then neither RIPEMD-160 nor SHA-256 is known to have any vulnerabilities to hash collision attacks. So somehow breaking both or randomly generation a key which hashes is exactly the same as another bitcoin address, is highly unlikely.

There is also a chance for you computer to catch on fire, and some of the materials to melt together into a lotto coupon with winning numbers on (and a valid barcode), but it just won't happen because of the chance is so unbelievably small (it's the same with the "click and generate another persons bitcoin address").

EDIT Woops, one important thing: This all assumes that all bitcoin addresses are properly generated using "true random". All brain-addresses and addresses generated using a bad PRG, might be easy to find by either using a flaw in the PRG or exploit the (flaws in the) human brain.


Is there a transaction propagation delay built in?

Yes, there is what is called transaction trickling. This is a mechanism to select a random peer for immediate forwarding of all transactions, while others receive the transaction after a random timeout. This is done in order to reduce the chances of fingerprinting the origin of a transaction. Similar to the proposed dandelion paper, it forwards a transaction through a conduit of peers before spreading it widely in the network, and observers cannot identify the origin by simply timing the time peers announce the transaction's availability.


Where can I see an input that will hash to a solution?


What happens if I fork an older block chain and rejoin the network later?

How can it be longer if you don't have more computing power than the entire network? Remember that the network converges on the chain that was hardest to generate, not the one with more blocks.


Why did repeated "R" values occur in Bitcoin transactions before?

The R value is the result of EC point multiplication between the k value (known as the nonce) and the secp256k1 curve's generator point. It is effectively the public key for k. The only way that an R value can repeat is if k is also the same. Given that k is a 256 bit number and is supposed to be chosen completely randomly, k should not repeat unless the random number generator is broken.

Considering that k is generated at signing time and should be random, we can conclude that whoever chose k for those transactions has a faulty random number generator which is either outputting a fixed value or a small value which increases the probability of k being repeated. There is no good reason for this to happen, so this error comes from either a faulty RNG or a completely misunderstanding of how ECDSA works.


Yes.

When you initialize your Trezor, it generates a private and a public key. Private key never leaves the device (that's the core value proposition). That means you can't sign transactions (spend coins) without Trezor plugged in. However, the web wallet can remember your addresses (derived from the public key). Even without the Trezor plugged in, you can check your balance and send coins to your addresses from elsewhere.


Can anyone help me understand why my transaction won't confirm

Your transaction is confirmed now. The blockchain link shows it took 214 minutes to be confirmed.


mSigna: Signed, send, but 0 confs despite high fee (0.001 BTC)

You can use another wallet to test your network. Don't worry about the fee, it's enough. Mostly one tx will be confirm in 2 hours.


CheckProofOfWork() Linux error on old altcoins

That error simply means that the block is invalid as the proof of work is incorrect. That has nothing to do with OpenSSL versions. The difficulty of a block is specified by the nBits field of the block header, and the block header must hash to a hash that is less than nBits. What is happening here is that the block hash is not less than the nBits, so the block is invalid.


What should I do to increase bitcoind sync speed?

First, make sure you have listen=1 in your bitcoin.conf file, and that the P2P port is open on your VPS so that it can make more than 8 connections.

Then you'll want to make sure you have a high disk speed or IO specified (definitely not HDD - I have a feeling you meant SSD). The faster the SSD the better. 2GB RAM should be fine, but you may want to up it to 4GB and 4 CPUs, at least while syncing. bitcoind will use the most resources while syncing, then you can downgrade once it's synced.


Can you use the same seed for normal BTC and Lightning wallets?

A lightning network wallet can be compatible with a Ledger Nano generated wallet, but doesn't have to be.

Ledger nano generates seeds (the 24 words) using BIP 32/BIP 39/BIP 44.

I checked to see what format eclair uses, and it seems to use BIP 49 instead of BIP 44. This seems to suggest that the seeds are incompatible, but I haven't confirmed this.

If you want to do so, you can try importing your Ledger seeds into eclair, which is a non-descructive action (i.e. it won't affect your wallet/funds).


How to use deriveaddresses via a curl command

I figured it out, just need a comma after the descriptor param.

let descriptor = "\"wpkh(xpub6Dy2ikUu5mXbDdhw2vAP1C4eiQM8rTz1NiWQt2BzGi83iHC2gEgTSD54JveyuHF9VLAqNkCGnee1jdBL7nA3JNorbqjSSS8DEV6Hn3PuNBt/*)#mn5jvyc3\""

    let command = "curl --data-binary '{\"jsonrpc\": \"1.0\", \"id\":\"curltest\", \"method\": \"deriveaddresses\", \"params\":[\(descriptor), 99] }' -H 'content-type: text/plain;' http://user:password@127.0.0.1:8332/"

    var error: NSError?

    let queue = DispatchQueue(label: "com.FullyNoded.getInitialNodeConnection")
    queue.async {

        if let responseString = self.ssh.session?.channel.execute(command, error: &error) {

            guard let responseData = responseString.data(using: .utf8) else { return }

            do {

                let json = try JSONSerialization.jsonObject(with: responseData, options: [.allowFragments]) as Any

                print("json = \(json)")

            } catch {

            }

        }

    }`


Calculating Z value in a tx with 1 input and 2 outputs

Seems to me that it is not correct

Sorry, I do not have a tool rigth now, and creating data manually is a little bit difficult and I may create errors also See update below

There should be something like this

01000000
01
e3dbc4fada0034ad8581cb429af4953d7d092b137ebd9e193344db376314ab65 00000000
1976a914 f65d5c02866b8cea5840b2f9fb739f2e6ee6c8f4 88ac
ffffffff
02
1004df0200000000 1976a914 7e7fe35e49f0e8a920780c00d40b7171d8808119 88ac
c05f3b0400000000 1976a914 942920e041353162b0d8bd006d09c2ca25cdc278 88ac
00000000
01000000

Update: Here is a piece of my checking code.

const QByteArray xx ( QByteArray::fromHex ( "01000000"
"01"
"e3dbc4fada0034ad8581cb429af4953d7d092b137ebd9e193344db376314ab65 00000000"
"1976a914 f65d5c02866b8cea5840b2f9fb739f2e6ee6c8f4 88ac"
"ffffffff"
"02"
"1004df0200000000 1976a914 7e7fe35e49f0e8a920780c00d40b7171d8808119 88ac"
"c05f3b0400000000 1976a914 942920e041353162b0d8bd006d09c2ca25cdc278 88ac"
"00000000"
"01000000" ) );
const MyKey32 digest ( xx.constData ( ), xx.size ( ) ); // construct object of sha256 (sha256 ( xx ) )
_trace ( digest.toStringRev ( ) );                      // print result
const QByteArray pubkey ( QByteArray::fromHex ( "036a6d9c781613b2f07607b240e019fb2344704258e63df4802a436302942e73d3" ) );
const QByteArray signature ( QByteArray::fromHex ( "30450221008f1bcf2624da3b423ca19eb9eb6c8fb84e6614cd603cbf9f2f1d8c7103534138022038190065341fd3cd4a697ee1ca02f5b1f1131a5268ba9df5d976e782a5edc379" ) );
_trace ( QString ( "verify=%1" ).arg ( digest.verify ( pubkey, signature ) ) );

and the result is

"f71aa6b6127ce9229d9607c0ee133d8195f91b14fe7d554ef8a6a40d99338426"
"verify=1"


Why is Bitcoin Core using LevelDB instead of Redis or SQLite?

Redis and LevelDB solve very different problems. We tried using SQLite and its performance was abysmal.

Bitcoin Core needs a database to store the set of unspent transaction outputs (UTXOs). This means we need fast simple reads, and fast batches of random updates.

We don't need a server/client architecture, as we can't have multiple applications accessing the database at once anyway: inconsistencies in the database would lead to forking risks (every node in the network needs to make exactly the same judgement about what is valid and invalid).


Move money/address from watch only wallet

In electrum there is an option to sweep private key , dump your private key from bitcoin core and then sweep it into electrum. Then you can spend your coins in electrum


How to get public and private keys by giving seed explicitly?

By "bitcore" I assume you mean Bitcoin Core as the commands you are using are Bitcoin Core commands. There are other things which are called "bitcore" which is confusing.

  I want to explicitly send a seed to generate a new address. Could anyone tell me how to do that?

You cannot. Bitcoin Core does not allow you to seed the random number generators with custom values as that is a security vulnerability.

You can import a private key (which some may call a seed) which will then add that private key and its associated address to the wallet. That may be what you want to do.

In Bitcoin Core 0.17, there will be an option to set the HD wallet seed. Bitcoin Core generates private keys deterministically using BIP 32 which has its own seed value. In Bitcoin Core 0.17, a new feature has been added which will allow you to set the seed used by the wallet for key generation.


Mining Bitcoin heats up my Computer. why?

All of the energy that is used in any computation eventually leaves the hardware as thermal energy. Bitcoin mining is an energy intensive computational process, so one of the by-products of it is thermal energy (heat). If you want to stop generating heat, you'll have to stop mining (or figure out how to dissipate the heat more efficiently).
Keep in mind that bitcoin mining is only profitable using specialized ASIC hardware (that generates a lot of heat). Mining bitcoin with your laptop/PC will just use up electricity (and generate heat), without any real chance of doing enough work for you to receive a reward.


How to secure new public proof of work blockchain?

how someone can start a new public blockchain

This is impossible to secure PoW blockchain without "work". No work by honest nodes - no security. Point.


This is a nice chart on the average transaction confirmation time: https://blockchain.info/charts/avg-confirmation-time that will give you a better estimation on how often you should check.

Also related: What keeps the average block time at 10 minutes?


How to build a portable bitcoind binary for macOS?

macOS portable binaries are uploaded to bitcoincore.org. On the download page, under Mac OS X is a link to tar.gz. That tarball contains the macOS portable binaries.

Bitcoin Core's release process using gitian does produce these portable binaries. So you can replicate the same process to build your own portable binaries. You can read about how to do that here.

There is a script, contrib/gitian-build.py that should do everything for you. It should work on Ubuntu. It will install all of the necessary dependencies and setup the gitian environment before doing the build when you run it with the --setup option.

Your build command with this script would look something like

bitcoin/contrib/gitian-build.py -Dnb -o x <name> 0.20.0

Use the -h option to get usage information

-D tells the script to not try to sign the resulting .assert file that contains all of the build hashes.

-n tells the script to not try to commit the .assert file that is created.

-b means to do a build

-o x tells the script to specifically do a macOS build (-o means operating system, x for OSX)

<name> that's where you would put your username. This is just for identifying signers who participate in the gitian build process. You can just set this to be whatever you want.

0.20.0 is the version to build, in this case, 0.20.0. You can put whatever other version you want.

The script will create a directory named bitcoin-binaries. Inside of that will be a directory with the version name. And inside that directory will be 2 files - a .tar.gz file and a .dmg file. The .tar.gz file contains the portable binaries that you can use.

Additionally some gitian builders (like myself) upload all of their gitian build results so you could just download those files.

Personally, I upload my results to github. The macOS portable binaries are named bitcoin-<version>-osx64.tar.gz.

Jonas Schnelli also uploads the results of his builds. You can find them at on his website.

In both cases, the files that you download should have hashes that match those of other gitian builds. The gitian builders commit their hashes to this github repository so you can go there to check that the file you download has the same hash that the gitian builders computed.


Was libbitcoin a part of bitcoin core in the past?

libbitcoin is not, and was never a part of Bitcoin Core. Both are standalone implementations of the Bitcoin protocol.

Bitcoin Core, in its build process, will create a number of files named "libbitcoin_...". These are just locally generated files that are unrelated to the libbitcoin project.

Bitcoin Core does not have any files with the "hpp" extension. So are you sure you're actually trying to build Bitcoin Core?


Are the blocks in blkxxxxx.dat files ordered by block height?

No, they are in the order by which your node received the blocks. This can be in any particular order as nodes receive blocks out of order during the initial sync. Furthermore, some nodes will receive and store blocks that become stale, while other nodes (particularly ones that come online after that block has been found) will not. So the blk*.dat files between two nodes are likely to differ.


-rpcwallet takes the name of the wallet, not the path to the datadir (as you appear to have done) or the path to the wallet file.
To get a list of the names of the wallets currently loaded, you can use the listwallets command.


Why the bitcoin address is not valid in any of the testNet faucet

Testnet uses a different address format than the main network. Testnet addresses start with an "m" or "n".
The address you are using starts with a "1" and is therefore for the main network. This is why the testnet faucets say the address is invalid.

From the documentation of BitcoinJ, it seems that you can configure your code to use the testnet with:

  params = TestNet3Params.get();


How to install and run an official Bitcoin wallet on Ubuntu?

I'm not sure if this package is official Bitcoin-com-wallet-3.6.0-linux64.tar.gz. I suggest you to download from https://bitcoin.org. There are several wallet programs for desktop, web, mobile, etc. Here is an list.


I want to use another wallet.dat file with bitcoin-qt. Is this possible?

You're on the right track -- in fact you're already using the correct command line switch, which is "-rescan".  But your mistake is thinking this is a quick solution.  It's not.  Rescanning the blockchain will take hours, depending on your processor speed.

This is a task you'll want to leave running overnight.  If the problem persists even then, record the error message you get once the rescanning has completed, and ask another question with that error message.

Your next option would probably be to actually transfer the Bitcoins using a tool like pywallet, but I'd wait until you've left this rescanning overnight before you try that, and seek guidance on how to use pywallet.


BTC/hashes/second rates for various pools

This is an interesting question, but also a very difficult one to answer.

No, all pools don't pay exactly the same.

But looking at how much a pool paid out over a few days is pointless due to variance. Another mistake common with beginners is to try to find some magic ratio between your hashrate and the pool's hashrate that will let you earn more. In reality this ratio has zero influence on your earnings. I will try below to tell you what actually influences your mining income in the real world.

The best data currently available is probably the BTC Mining Pool List at Bitcointalk. Note that the profitability graphs at the bottom do not (at the time I write this) take into account pool fees, merged mining and rejected work (the last one being very individual).

Which pool is most profitable to mine for you depends on a lot of factors. I'd say there are two main influences on how profitable a pool will be for you: variance and expected average income.

Variance is determined by pool hashrate and reward system (PPS, DGM, others). The more variance the more luck will influence your profits. The variance tells you how far the income is likely to vary from the expected average over the short term.

Expected average income is determined by a lot of factors, which many miners probably don't realize:

Which ratio of rejected work are you getting? Some pools have a higher average reject ratio than other pools. On some pools your individual reject ratio may be especially low. Some pools artificially lower your reject ratio by paying rejected work. This is not actually an improvement. It means people with low reject ratio (good setup) are forced to give some of their income to people with high reject ratio (bad internet line, bad equipment).
What ratio of orphaned blocks does the pool have? (ignore for pps pools)
What's the average income from a block in the pool?  (ignore for pps pools) Some pools will have a higher income from transaction fees. Some pools keep the transaction fees and don't pay them out to miners.
How much of a bonus do you get from merged mining? This depends on which other coins are merged mined, their difficulty, their current value compared to bitcoin, in addition to all the factors listed here but for the merged coin (average income per block for the pool, orphan ratio for the merged coins, etc.)
What is the pool fee?

I don't include pool hopping in this list, since most Bitcoin mining pools are not vulnerable to pool hopping. Things may differ in the altcoin world.

There are some factors that are the same for all pools, like bitcoin difficulty, bitcoin value and your expenses, like electricity. Bitcoin mining calculators seem to cover these well, but they don't cover most of the factors above that are individual to each pool.

All of that being said, there's a lot of other reasons for picking a pool than a small difference in mining income.


I am looking for a reliable and low cost way to make loan repayments from Asia to the US. Are there any banks in the US that will acept Bitcoins?

"Translating" a Bitcoin to a US dollar is selling it. There are plenty of services that will sell your Bitcoins, including Coinbase, Kraken, and Bitstamp. You just need to find one that will do what you want with the US dollars after they've sold them.


Yes be more patient. In the future you can use this app or others like it to determine an appropriate fee for faster confirmation:

https://bitcoinfees.21.co/

"Which fee should I use?

The fastest and cheapest transaction fee is currently 50 satoshis/byte, shown in green at the top.
For the median transaction size of 226 bytes, this results in a fee of 11,300 satoshis (0.04$).

What are the fees shown here?

The fees displayed here are Satoshis (0.00000001 BTC) per byte of transaction data. Miners usually include transactions with the highest fee/byte first.
Wallets should base their fee calculations on this number, depending on how fast the user needs confirmations."


Varying mempool statistics across multiple sources

Nodes have different policy about accepting transactions to mempool. Some nodes accept all transactions, others accept only transactions with a fee greater than 10 satoshi per byte for example.

Nodes have different policy about droping transaction from mempool. Some nodes drop one-day-old transactions, other nodes drop three-days-old transactions.

Nodes have different policy - this is the answer.


How can I make transaction output time locked?

Yes, you can use OP_CHECKLOCKTIMEVERIFY opcode in the locking script of the output. This opcode takes either blocks or Unix Epoch Time (seconds since 1-Jan-1970) as the parameter to lock. If the parameter is non-zero and below 500 million, it is interpreted as a block height, if it is greater than or equal to 500 million, it is interpreted as a Unix Epoch timestamp. When you would reference this UTXO at the time of spending, you need to set the transaction nLocktime equal to or great than the OP_CHECKLOCKTIMEVERIFY. The nLocktime parameter while spending should be same as what was specified in the CLTV; i.e. if the CLTV locking parameter was in blocks, it should be specified in blocks, otherwise in Unix Epoch timestamp.

Since you want it to be spendable after 1st Jan 2030, that is equivalent to timestamp of 1,893,456,000 (or 0x70dbd880). So your locking script will be concatenation of:

OP_DATA (size of CLTV_expiry): 0x04
CLTV (little endian): 0x80d8db70
OP_CLTV: 0xb1
OP_DROP: 0x75
OP_DUP: 0x76
OP_HASH160: 0xa9
OP_DATA (size of address): 0x14
Address: <address>
OP_EQUALVERIFY: 0x88
OP_CHECKSIG: 0xac

Two things to note: (1) When you are spending this transaction, the input referencing this UTXO needs to have nSequence value between 0xF0000000 to 0xFFFFFFFE. (2) Median_time (time of last 11 blocks) is used to check nLocktime when the script is evaluated which is generally about hour behind the actual time on your wall clock.


How does Bitcoin currently mitigate Sybil and Eclipse attacks?

A sybil attack is prevented by using proof of work. Overwhelming the network with nodes cannot substitute for the hash power required to create the proof of work that must be presented in order to get the network to accept a new block.

An eclipse attack is more difficult to prevent:

  Bitcoin Core only makes an outbound connection to one IP address per
  /16 (x.y.0.0). Incoming connections are unlimited and unregulated, but
  this is generally only a problem in the anonymity case where you're
  probably already unable to accept incoming connections. See
  https://en.bitcoin.it/wiki/Weaknesses#Sybil_attack.

As far as I'm aware there is no such logic implemented to equalize the network resources between nodes.


For what purposes do we need "Sign message"?

You can sign a message to prove ownership of a particular private key, without sharing the private key or spending any funds. For example, you could sign a message that says "My name is John Doe". You could give this signed message to anybody, and they can verify it with your public key. This proves that whoever has your private key claimed to be John Doe at some point.

Somebody might sign a promise to deliver funds in the future, to prove that they have access to the funds (if the address associated with the private key has the amount of money promised), without actually sending the money. Basically proving the ability to send money, without actually sending it.


Is there a graph of Namecoin value over time?

It's possible to see historical Namecoin's price chart on NMC Watch, the link provides price chart from June 2 to current date.


Does 'simplified payment verification' work?

Simplified payment verification can't help much with 0-confirmation transactions. But once the payment has several confirmations, this fact alone (which the SPV client can verify) implies that the transaction is accepted by the network, so the payment is secure.

SPV can also be used in conjunction with a server node that has the blockchain and can verify against double-spending. The client will still want the block headers and the Merkle branch of the transaction to keep the server node honest. Without this, the server can falsely report that the client received payment; with the simplified verification, the server would have to collude with the sender.


This is an interesting question from a blockchain perspective. Will the transaction block data ever outstrip the ability to store it ?  Or at least put it beyond all but the largest corporation's budget? It seems like storage capacities are still growing at a very fast pace, so I don't think this is an immediate problem.

But from a device standpoint, there are many schemes to create meta-volumes to the which physical devices may be added without affecting the ongoing operation of the system. Linux's Logical Volume Manager (LVM) is just one of these.

There are also any number of disk-array schemes and commercial network attached storage (NAS) units. The Drobo name is just one that comes to mind.

To specifically answer your question: if the external 1TB storage unit you are using is approaching its capacity, it would be time to upgrade. Acquire a larger unit, or move to a different system (perhaps one with the ability to add hardware storage on-the-fly, such as server able to operate an array of multiple storage units.)

Briefly stop your coinservers, attach the new, larger storage, copy the original blockchain data to the new storage unit, reconfigure the coinserver to operate from the new unit, and voilà.
You would add a line similar to this in your ~/.bitcoin/bitcoin.conf file:

datadir=/new_array/bitcoin-data

Multiple disks can be arrayed in different ways depending on the competing priorities of redundancy vs. data access speed. SSD's are plenty fast, and even rotational hard disks with enough cache memory are sufficiently fast. I would suggest a mirrored array (RAID-1) of rotational HD's as the best option.


I use bitcoinwisdom which in the market section has multiple exchange ratios for BTC/LTC/DOGE and for fiat money like USD/EURO/RUB.

Another option is this page in cryptocoincharts which also has many market prices for cryptocurrencies.


Why does the hash come before the signature?

Because it would not have a function. The hash listed in the picture of the original whitepaper is just to make the signature shorter (and possibly the process of creating it faster) without losing security, its only function is the authentication of a transaction, it is not used for anything else (or even stored).

To clarify, this is the diagram mentioned in the question:


How to retrieve extended private key from extended public key + master seed / root private master key

If you already have the seed phrase (aka mnemonic) then all you have to do is import that into Electrum.

Click File > New/Restore (ctrl+N)
Set a name
Select Standard wallet
Select I already have a seed
Enter seed phrase then click option and select BIP39 seed and the other checkbox only if you had used a passphrase to extend this seed
Choose the address type that were created by this seed and modify the derivation path if needed

Now if you want an individual private key, simply go to Addresses tab and select any address there, right click and choose Private key.
If you want to know the underlying methods used to derive the keys then check out BIP-39 and BIP-32.


Why I don't need to specify public key to import paper wallet

The analogy that you suggest isn't quite accurate because a private/public key pair have a very exact mathematical relation, whereas a username/password have no real relation (except maybe an entry in a database somewhere).

A private key is essentially a 256 bit number. Using this private key, and an Elliptic Curve library that supports the use of the secp256k1 curve, you can deterministically calculate what the associated public key is. Since a bitcoin address is a hash of the public key, all you really need is the private key and you can calculate everything else to be able to see what transactions resulted in the address being credited/debited coins. That's why coinbase only has you give your private key.