Is there any way by which we can see when was last time or which was the block that was created just before bitcoin adjusted its latest difficulty?

I don't know a way to get this directly through the RPC without looking at multiple blocks and comparing them, but the math formula is easy:

floor(current_number_of_blocks / 2016) * 2016 - 1

The floor function rounds a number down to an integer value; it's available in most programming languages, although it's sometimes named something to do with integers (e.g. int()).  The number 2,016 is the number of blocks in a retarget period (the time between difficulty changes).

Here's an example command:

bitcoin-cli getblockchaininfo | jq '.blocks / 2016 | floor * 2016 - 1'
524159

As requested, as of this writing, block 524,159 is the last block before the difficulty change.  To get the first block with the new difficulty, remove the -1 (so block 524,160 in this example).

The command used in the above example is jq.


After a sleeping client comes online again which technique it uses to find the last common ancestor in a blockchain?

Your node will just ask its peers for blocks. It actually does the same thing it does for the initial sync. It starts with what it currently considers to be the chain tip (in initial sync, that's the genesis block). From there, it connects to other nodes and asks those nodes for more block headers starting with the block at its own chain tip. Typically, that block will be part of the current best blockchain, so the other nodes will just give further headers and then blocks from your node's tip.

If there has been a fork (e.g. the tip is a stale block) and the other nodes happen to know your node's current tip, then those other nodes will find the common ancestor between that block and their current tip. Once they find that common ancestor, they send the rest of the blockchain from that common ancestor. The important thing here is that the other nodes find the common ancestor, not your node.

If the other nodes don't know your node's current tip, your node will also send other, older block hashes in its headers request. So the other nodes should be able to find a common ancestor given those other headers too.


The idea is to sell the bitcoins in India and wire him back the money from the
  sales proceeds in India.

Translate: The idea is that he commits tax fraud because he will not report the sale as income. Which is about the only way this makes sense, given that instead of selling them in an Exchange anywhere worldwide he goes through the trouble of sending them to SOMEONE who will sell them (manually?) and then change the funds to USD and send those over (because somehow I doubt he will have an account in whatever currency the use in India in his US bank).

Result: Possibly jail time if they find out. Like all tax fraud. At least it gets ugly. And unless the amounts are small - I am not sure you or he are aware, but "wiring the funds" leaves a bit trace for the government to ask where the money comes from.

Simple like that.

If he gets income from the sale of bitcoin, that is income. Which is taxable or not as any other income. From which he can deduct the cost of getting the bitcoin (if he mined them for example).


Yes, you can and should transfer your bitcoin to a wallet you control after purchasing them from a web-based wallet.  Never leave a substantial amount of your bitcoin on an exchange or a web wallet.

Coinbase is a company that runs both an bitcoin wallet service and an exchange for purchasing and selling bitcoin for USD.  Armory is a wallet that you run yourself on your own computer, and therefore store your own private keys.  In the case of Armory, it is a deterministic wallet, meaning that it can regenerate all it's private keys from a single seed.

To transfer between wallets, you generate an address on the receiving wallet, and send bitcoin to it from the sending wallet.  The process will be different from wallet to wallet, but this is the typical use case of Bitcoin, and you should become comfortable with it regardless of interface.

If you are new, you may want to read some other questions/answers from this site to give you a better understanding of wallet options:

What options does one have to manage Bitcoins?

Secure way to store BTC over a long time - and its risks?

I am new to Bitcoin, how can I get started?

How do you obtain bitcoins?


What is the magic number used in the block structure?

The magic number is not something specific to bitcoin.

Magic numbers are used in computer science for both files and protocols. They identify the type of the file/data structure. A program receiving such a file/data structure can check the magic number and immediately know the supposed type of that file/data structure.

This is what the Unix/Linux command file uses to quickly identify the type of file. It only requires to check only the first bytes of a file to determine its (supposed) type. A list of files and their magic numbers can be found here.

Protocols like bitcoin use data structures to talk to each other (e.g. propagating blocks through the network). Nodes check the first bytes to identify the type of data structure.

Another use of magic numbers is that you can check the type of the file or data structure on a text editor. E.g. while a png image is binary if you open it with a text editor you will notice that it starts with .PNG..... Another example, the SMB protocol replies start with FFSMB. Note, however, that this is not always the case.

Other files/structures have magic numbers that do not make much sense; they may be some geeky code or inside joke of the developers that chose it.

So that is what it is used for. As far as I can tell 0xD9B4BEF9 is quite arbitrary... but maybe there is some meaning for its creator.


Bitcoin address with money need help getting it?

If Bitcoin hasn't synchronized ? export the private key to other wallet and spend the funds on private keys' addresses.

Follow steps here to get your private keys
How do I export my private keys from my Bitcoin-Qt client?


What is preventing me from simply constructing a hash that's lower than the current target?

Hash functions are unpredictable.

You can't simply find an input to the hash function that produces such an output. The only way to accomplish that is by trying lots and lots of candidate blocks as input. If the target is 1000 times smaller, it requires 1000 times as many tries.


When user 'A' creates a transaction using scriptpubkey, do they also sign a message with their private key?

No, the scriptPubKey doesn't require 'A' to sign anything. It only asserts what B must do to spend the output.


What is the canonical way of creating merkle tree branches?

Edit: Have a look at MSG_MERKLEBLOCK. Included information is: Block Header, Transaction Count, Hash Count, hashes, flag byte count, and flags.

hashes include everything from the leaf to root, and flags
gives the positions of the leaf in the Merkle tree.

Since the index of the transaction gives it’s position from the left among the leaves in the Merkle Tree, in addition to the transaction count it is sufficient to deduce whether it is the left or right partner in each concatenation.

(Old answer below.)

The leaves of the Merkle tree are left to right in the same order as the transaction list of the block. Each layer above is formed by concatenating the children and then performing ad double SHA-256. When only a single entry is left in a layer, we call that the Merkle root.

If a transaction does not have a partner, it is paired with itself instead.

    HASH(Hash(AB)Hash(CC))
       /              \
Hash(AB)              HASH(CC)
 /    \                /    \
A      B              C      -

Legend: A,B,C are txid; Hash is short for SHA-256d.

This means that each transaction’s position in the tree is completely defined just by it’s index in the transaction list. Therefore, the position of its partners on each layer is deductible from that alone: If you write the transaction indices (starting to count with 0) out in Binary, you get the following:

A: 00
B: 01
C: 10

Reading from back to front, each 1 stands for "right position" and each 0 stands for "left position".

Example: B(01), B’s last position is 1 and B is the right partner to A. B’s second to last position is 0 and HASH(AB) is the left partner to HASH(CC).

Therefore it is sufficient to add the index in the transaction list and the number of transactions in the block to your proposed "Leaf, Root, Nodes".

Unfortunately, I don’t know what standard is being used to transfer this information. Maybe you can find it in the Bitcoin Core code catering to the requests of the SPV clients polling nodes for information.


Why do most trading platforms require ID Verification?

In the US, these are called "Know your Customer", and "Anti Money Laundering" (KYC/AML) laws and is enforced by FINCEN (financial crimes enforcement network) in the US for any businesses that qualifies as a "Money Service Business" or "Money Transmitter".

This guidance published on March 2013, http://fincen.gov/statutes_regs/guidance/html/FIN-2013-G001.html , makes it clear that Bitcoin exchanges must comply with existing regulation for KYC/AML.


How to get pending balance using bitcoin client/ bitcoin-cli?

Apologies for answering my own question, but I just found the answer.

The RPC command to get pending/unconfirmed balance is getunconfirmedbalance


Bitcoin addresses aren't meant to be reused as this significantly reduces privacy.  This was known to Nakamoto before the initial release of Bitcoin (see section 10 of his Bitcoin paper) and his original software was specifically designed not to reuse addresses.  That means any mechanism that turns easily-understandable string X into address Y should only be used once, which is not what most people want from a recognizable code word.

There have been a few described ways to work around this problem.  The first is simply having the easily-understandable and reusable x be a program somewhere (e.g. myaddress.example.com) that returns a different address each time it's used.  The problem with this is that it requires the receiver run a server, which most people don't want to do.

An alternative mechanism is called Stealth Addresses, which allows the receiver to create a static public key which the spender combines with a random number they select to create a secondary public key that nobody but the spender knows about but which only the receiver can spend from because it uses the same private key as before (basically).  The problem with this mechanism is that the spender needs to communicate the random number they used to the receiver in order for the receiver to recognize and be able to spend the payment, which adds extra data to the block chain and costs the spender more money in transaction fees.

Both of the systems above have been tried but neither has caught on and so when people have put in work into creating decentralized persistent registries (e.g. Namecoin or Blockstack), they've not really ended up being used to facilitate payments.


Yes, the auditing functionality relies on the non-hardened derivation.


Where can I find more information about Litecoin ASIC miners?

Just search for "scrypt asic miner" and you should find some.
https://www.google.ca/?gfe_rd=cr&ei=VFzxWJPGCuHs8wek4pPIBg#q=scrypt+asic+miner


Bitcoin transactions have a transaction id (txid) formed as a hash over the data involved in the transaction. That suggests that it is a unique identifier for a transaction.

However, the tx-id of a transaction is only unique once the exact data in the transaction has been finalized by being incorporated into the blockchain (and confirmed). Until then, there are hacks that allow altering the underlying data and hash. This is not a security issue because it is not possible to alter how many bitcoins are transferred from what input to what output. But details such as what format the cryptogaphic signature confirming that the input authorizes the transaction takes, or the exact signature script used, can be changed: They are malleable, making the hash or transaction id malleable as well.

This should not be a big issue at all. But it is if you built your Bitcoin handling on the assumption that transaction ids are not malleable, as MtGox may have. You also need to be careful about spending unconfirmed transactions, because this only works if nobody changes the intermediate transaction ids. None of this is an issue in the standard Bitcoin client, but if you roll your own, especially if you wish to use only a single Bitcoin address to handle many individual transactions, rapid-firing transactions directly building upon the unconfirmed previous one is an easy mistake to make. If people altered transaction ids from MtGox withdrawals, and MtGox adopted such a rapid-fire approach, this may explain why there have been many complaints of never arriving withdrawals: Altering one transaction id in the chain of unconfirmed transactions invalidates all successor transactions, until the originator resynchronizes with the blockchain rather than its own idea of which transaction ids it has sent.

EDIT: A much more elaborate explanation can be found in this Quartz news article


"lastDealPrice": 5040,

"sell": 5040,

This means that the last price exchange happened is at 5040 and sell is at the same price, i.e. a sell order at that price has been executed and registered as "Last Deal Price", shich is acutally higher than the buy orders price.


Are there any stochastically dependent proof of work algorithms?

Miners using one might have no idea how close to a discovery they are, but they would know that they are "getting closer".

Yes, this is possible.
Instead of requiring one block header with difficult A, you could require 16 block headers with difficulty A/16. This would make it possible to figure out how far along you are in the process.

In contrast, stochastically dependent proof of work could allow for efficient implementation of parallel confirmations; thereby greatly reducing transaction waiting time, since rediscoveries could be expected to follow shortly after the first discovery of a block. Assume a cryptocurrency using such proofs to reward not just the first discovery of a block, but also the first X of its rediscoveries.

That's possible too. You could do this by having each block in Bitcoin have 1 or more parents. You'd need some sort of way rule to decide which transactions to keep in a merge block (since some would inevitably conflict).
Drawbacks of the previous two changes:

Normally, a miner includes transactions as soon as they hear about them. Including a transaction doesn't mean that you lose any progress. But if you were getting closer, you wouldn't want to abandon that.
Only the X strongest miners and mining pools would stay in business. Everyone else may as well not bother with mining.
Full nodes would need X times more bandwidth to verify blocks. Once the blocks were verified, it would also take extra storage. If the blocks were very different, it could take X times more storage space. If the blocks were identical, it would be only an extra ~350 bytes per block (coinbase and block header).


What's the difference between bitcoind and bitcoin-qt? Different commands?

You can either run bitcoin-qt or bitcoind, not both at the same time (the Qt part is not just a frontend on top of the RPC code, it uses the core directly).

You can however run Bitcoin-Qt with the -server command-line switch, in which case it will also expose an RPC service (essentially functioning like bitcoind in addition to the GUI interface). The RPC console inside the GUI has the exact same functionality as the bitcoind RPC client.

PS: bitcoind is both an RPC server (when started without RPC command on the command-line) and an RPC client (when started with RPC command on the command-line), while Bitcoin-Qt only optionally runs an RPC server (when started with -server).

Update: In version 0.9, bitcoin-cli was added with just the RPC client functionality from bitcoind. In version 0.10, this functionality will be removed from bitcoind. This means that the following ways of interacting will be possible:

bitcoin-cli or an external RPC client talking to bitcoind.
bitcoin-cli or an external RPC client talking to bitcoin-qt -server.
Using the RPC console in bitcoin-qt.


Just open TCP incoming/outcoming connection for 192.168.2.21 & 192.168.2.22 for port 8333 in you router configuration page.


How much would you need to remember to store bitcoins in your head?

This is called a brain wallet. You need to remember only the generator for the private key, which can be anything you choose. You just have to remember something (anything) that is complicated enough that other people could not guess it, even if given trillions of guesses.

This is actually surprisingly complicated. If you write the passphrase down, it's not really a brain wallet anymore. If you don't, and you forget any bit of it and cannot precisely remember it, your funds are lost. If you make it simple enough to ensure you can remember it, the risk that someone else will find it is high. Lastly, the tools you use to convert the passphrase to a Bitcoin address can be flawed or sabotaged.


Is it okay to chain multiple unconfirmed transactions?

In principle this will work, but Bitcoin Core by default limits such chains: a transaction will not enter a Bitcoin Core node's mempool if it has more than 25 ancestors, or more than 25 descendants.
There are downsides to long transaction chains in the face of swinging feerates. Firstly, if the feerates rise, you cannot simply bump a single more urgent transaction—you'd have to bump it and all of its ancestors. Secondly, transaction chaining is somewhat incompatible with RBF—bumping any of the prior transactions breaks all the later transactions because their inputs cease to exist and you have to pay enough fees to replace the fees of all the descendant transactions to get admitted to the mempool. Thirdly, if a node's mempool runs out of space, it'll drop low feerate transactions first. If one of your prior transactions gets dropped, the entire chain following it will be inadmissible to (default) mempools until we get something like package relay, or the mempool relaxes to a level where the transaction can be rebroadcast.
Ways to work around this are to always bump the parent transactions to the targeted feerate of follow-up transactions (which is not trivial to calculate and may lead to overpayment in the case of two children to the same ancestors), or to always have exactly one output from which you chain.
In the case that you have enough transaction volume to warrant transaction chaining, I would recommend that you rather use payment batching: delay withdrawals (or other payments) by a few minutes, but then do multiple in a single transaction. Payment batching has a much smaller blockweight footprint per payment (and thus lower fees per payment), makes UTXO management much easier, because you need fewer inputs per payment, have less funds in flight because you only create a single change output per batch instead of per payment, and can maybe forgo using unconfirmed inputs altogether, which allows you to use RBF and CPFP to bump transactions when they get delayed even when you start them off with much lower feerates.
Additionally, while chaining of transactions would start to break down due to the limits on ancestry sizes, payment batching just gets more efficient with higher volume.

Secondly, will the chained transactions be mined at the same block?

Yes, if the child transaction pays a higher feerate than its ancestors, they would likely be picked as a package based on the descendant feerate. If later transactions pay the same or a lower feerate, a parent may be included without children.


Does synchronization takes such long time for first time or every time when syncing?

The initial sync only needs to happen once, launches after a full synchronization will just catch up on the data that you've missed.


If running a full node is in fact distinct from mining, what incentive do people have to run full nodes if they aren't able to earn the reward as a miner would. Is it just for bitcoin supporters who want to help bitcoin grow?

Incentives to run and use a bitcoin full node:

Not trusting anyone, verifying everything.

Privacy. Not sharing information about your transactions with others.

Enforce consensus rules.


To use Dwolla with Mt. Gox I need to become Verified. Do I need Apostille?

An apostille is only required for level 2. Their original announcement of the change was confusing, but they have since clarified it on the forum - https://bitcointalk.org/index.php?topic=60074.msg716245#msg716245.

Edit: You also need a bank account linked to your Dwolla account that has been verified over 30 days.


Does Bitcoin's high price make payments in stores less viable?

Bitcoin for Point-of-Sale

Bitcoin is inherently ill-suited as a form of instant payment. This is due to transactions needing confirmations before they become reliable which even at best times can take between several minutes and an hour. Before a transaction is confirmed, it is merely a declaration of intent open to replacement by another transaction sending to a different recipient, i.e. a doublespend. This is in crass conflict with the requirements of a quick payment, e.g. at a super market with a line forming behind you or when purchasing hot food.

Value of transactions and fee market

Fees in Bitcoin are paid for the blockchain space that a transaction occupies, not relative to the amount of value that is transferred. As the data-wise smallest possible transaction could transfer $1 or $1,000,000 of value, it is obvious that a more valuable transaction can afford to pay a higher fee for the same blockspace while remaining economically viable. It is therefore inevitable that more valuable transactions will push out less valuable transactions in the competition for blockspace.

More miners and throughput

To discover a new block, a miner has to find a block template that fulfills the current difficulty level. This is a rebalancing system, if mining power increases, the difficulty will follow suit to slow down block discovery. Adding more mining power will only briefly create more capacity before the difficulty catches up.


From my point of view, any chaos in the monetary system may be an opportunity for an alternative system.

Taking control out of the banks would be the first step towards an attempt to improve the economy, but we must be very careful about the government control.

The current scenario in Venezuela is all fault of the Government and not totally of the banks, if the government itself wants to launch a monetary system without the interventions of the banks what would be the logic of this?


Can I hide my IP address by blocking incoming connections in the client?

Dan Kaminsky's deanonymization works by having a lot of probes in bitcoin network that collect data about how transaction propagate and than trying to localize it's source.

When packet travels in the network (Internet), it has to have source and destination IP addresses in it's header. Therefore when your bitcoin client sends transaction it has to wrap it into IP packet with your source address and destination address of the connected peer.

For one way communication it's theoretically possible to have random IP source address in a broadcasted transaction, but it would be still possible to deanonymize by knowing location of closest peers.

It would be easy to avoid deanonymization by using any kind of IP proxy, see this question.

P.S. The answer has some speculations because Dan Kaminsky didn't release the software yet.


How has the Bitcoin average block size recently risen above 3 MB?

I also believe I read that the signature part can account for 65% of the block size.

This is not entirely correct. The typical size of a block depends on the make-up of transactions in that block. The size of signatures to overall block size will depend on the number of inputs in a transaction. More the number of inputs in a transaction, higher the signature components and higher the ratio of signature size to block size. Also, higher the number of multi-sig inputs, more the signature components per input. Also, one has to note that both the signature and the redeemScript form the part of the witness, and not just the signature.

  Is there a way to calculate the theoretical maximum allowed in Bitcoin blocks and where is my understanding above flawed?

Yes, the theoretical maximum limit of block size is 4,000,000 WU. To calculate size in bytes, it will be very very close to 4,000,000 bytes. Consider a block made up of only one transaction, with only one OP_TRUE anyonecanspend output in that transaction and only one input. Assume the redeemScript and signature are so big that they take up the maximum allowed space in the block (Bitcoin supports custom scripting, so I can theoretically create a script in that way). Now, the standard components of the a block are:

size = 4 bytes / 16 WU
block header = 80 bytes / 320 WU
transaction counter = 1-9 bytes (1 byte in our case as we use 1 tx) = 4 WU
Transactions = variable

So this leaves 4,000,000 - (16 + 320 + 4) = 3,999,660 WU for our transaction.

Standard components of the transaction are:

nVersion = 4 bytes / 16 WU
number of inputs = 1 byte / 4 WU
previous transaction txid = 32 bytes / 128 WU
previous transaction output index = 4 byte / 16 WU
script length = 1 byte / 4 WU
script = 0 byte
nSequence = 4 bytes / 16 WU
output count = 1 byte / 4 WU
amount size = 4 bytes / 16 WU
script length = 1 byte / 4 WU
script (OP_TRUE) = 1 byte / 4 WU
nLocktime = 4 bytes /16 WU

so witness size is: 3,999,660 WU - 228 WU = 3,999,432 WU

Now, to convert this to traditional bytes that would be relayed on the wire:

340/4 + 228/4 + 3,999,432 = 3,999,574 bytes

Note: Standard transaction weight is 400,000 WU, which means full nodes won't relay transactions higher than this cap. However, consensus rules allows transaction to be as high as the block size, which means nothing stops a miner from including this transaction in a block and then mine the block with it.


90% confidence interval for mining a block?

Bitcoin blocks are mined according to a Poisson process with a mean of 10 minutes (600 seconds) if you assume constant network hash rate. The difficulty of mining blocks gets adjusted every 2016 blocks to address this variability.
Interarrival times of a Poisson process are exponentially distributed.
The 95th quantile of an exponential distribution with a parameter of 1/600 is 1797.4
The 5th quantile of an exponential distribution with a parameter of 1/600 is 30.8.
90 percent of the time an observation from an exponential distribution will fall in the interval of (30.8,1797.4) seconds
The median time is 415.9 seconds.


How can nodes verify the transactions before miner ? Give me easy explaination

Contrary to popular belief, it is not the miners' job to verify transactions. Rather it is the job of the full nodes on the network to verify the transactions, and miners are a subset of that (i.e. miners are also full nodes). Rather miners only exist to establish the ordering of transactions, within certain restrictions.

Full nodes can verify transactions without them being a block and without mining a block because the process of mining does not alter the transaction. A full nodes merely needs to know the transactions that a given transaction spends from in order to determine whether the transaction is valid. Miners must do the same thing so that they only include valid transactions in their blocks.

What miners exist to do is to establish the ordering of transactions. They are not there to say that a transaction is valid. Rather what they do is, when given two transactions that conflict with each other, say which one is "first" and thus the one that everyone else should believe. Bitcoin uses a first come, first serve system, and miners are only here to say which transaction was first. The two conflicting transactions must be valid as transaction validity is a precondition for this conflict resolution.

  I read somewhere that if miner changes the transactions in a block, the block will be invalid. How can miner change the transactions in a block?

A transaction is just data. Anyone can alter data that they have. If a miner alters a transaction and includes it in his block, the transaction will be invalid and all full nodes on the network will reject it.


Yes, this is a scam.

The scammer has probably asked for your login info, so that he can 'set you up for mining'. In reality, mining does not work like this at all, the scammer simply wants access to your account so that they can copy down your seed phrase. With that done, even if you change your password, the scammer will be able to re-create your wallet on a different device, no password needed! The scammer could then steal your coins at a later date, after convincing you to 'fund the wallet for mining', etc.

DO NOT give the scammer any login or otherwise identifying information. There is never any need to do so.


Eclair Lightning network node is not public

For future reference:

Lightning Network explorers are also nodes and just make their own "world view" of the network publicly available
Your node will only become publicly visible once a channel has been opened and that information is announced to the network (and reaches the Explorer)
Explorers do update irregularly, so it makes sense to give it some time and check multiple explores


how can I resolve an unconfirmed deposit to my blockchain.info wallet?

Every transaction has everything it needs to process, so you cannot really boost the priority of the transaction already on the network. If your transaction is not confirmed , i am assuming you have set low fees or there is unusual load on network, at current time of writing it does not look too bad.

If you send another transaction with higher fees , it will get confirmed quicker and the earlier one will be removed from the pool at some point (or will get rejected as you will have already spent your inputs).*

*Assuming here you are trying to spend everything in the address.


How to make a persistent SPV wallet? (bcoin)

As commented here, the cause of the problem is that I

  sorta have created two wallets. The first is instantiated by the plugin statement towards the top, and then you also create a new walletDB right after.

So the solution is using WalletClient:

const {WalletClient} = require('bclient');
const {Network} = require('bcoin');
const network = Network.get('regtest');

const walletOptions = {
  network: network.type,
  port: network.walletPort,
  apiKey: 'api-key'
}

const walletClient = new WalletClient(walletOptions);
const id = 'primary'; // or whatever your wallet name is
const wallet = walletClient.wallet(id);

Instead of walletdb.create().


Is creating a long password for my coinbase account enough to keep my bitcoins secure?

The long password will not help that much and is also likely difficult to enter. Much better enable 2 Factor Authentication with Coinbase (https://support.coinbase.com/customer/en/portal/articles/1658338-how-do-i-set-up-2-factor-authentication-) which gives you a second level of control.

If you have the wallet e.g. on the phone you have much more control on your funds and do not depend on the security implementations of Coinbase. Also does Coinbase have limits when moving funds which does not apply to your funds in your local wallet.

Often splitting funds in local and online wallets gives most flexibility and security so your eggs are not all in one basket.


What is the maximum size of the memory pool?

There is no cap on the maximum size of the mempool, nor a janitor which cleans up transactions which are not confirming. Loss of unconfirmed transactions isn't a problem as wallets are supposed to rebroadcast transactions if they don't confirm within a reasonable time frame, so it wouldn't be unreasonable to drop them in a critical low memory situation. The limit on free transaction relay is there partly to prevent this from being an issue, it would be fairly expensive to pack the mempool with junk from a fee standpoint.


get Armory to use an existing blockchain?

If your settings are correct, try restarting Armory, and let it run for a few minutes. I had the same concern thinking that Armory was redownloading the blockchain, but it was actually reading from the harddrive (Listen to the harddrive).

After roughly 10 minutes, the block synchronisation went from 0% very quickly to 100%, then the status changed to "Connected". Next Armory synced the transaction history for another 10 to 15 mins.

I guess there is a user experience bug here. Armory should have had a user friendly message somewhere saying something like: "Verifying local blockchain".


How exactly are public/private keys stored?

No they are not stored, the child keys are calculated from the master when needed as they are deterministic, not random.

Here are some references:

https://www.oreilly.com/library/view/mastering-bitcoin/9781491902639/ch04.html#_deterministic_seeded_wallets

https://learnmeabitcoin.com/guide/hd-wallets


prev_block = "000000000000000117c80378b8da0e33559b5997f2ad55e2f7d18ec1975b9717"

This is simply setting a variable called "prev_block" to the hexadecimal text hash of the previous block. It could have been stored as the raw byte hash, but for ease of use it is stored as hexadecimal text.

prev_block.decode('hex')[::-1]

This converts the hexadecimal text stored in prev_block into it's binary representation as a string/array of bytes.

If you simply want to create a header then this code will accomplish that as long as you provide all the variables (ver, prev_block, mrkl_root, time_, bits, and nonce):

ver = 2
prev_block = "000000000000000117c80378b8da0e33559b5997f2ad55e2f7d18ec1975b9717"
mrkl_root = "871714dcbae6c8193a2bb9b2a69fe1c0440399f38d94b3a0f1b447275a29978a"
time_ = 0x53058b35 # 2014-02-20 04:57:25
bits = 0x19015f53
nonce = 1 # make sure to change this to the correct nonce
header = ( struct.pack("<L", ver) + prev_block.decode('hex')[::-1] +
      mrkl_root.decode('hex')[::-1] + struct.pack("<LLL", time_, bits, nonce))
print header.encode('hex')

Update

The struct.pack("<L", ver) and struct.pack("<LLL", time_, bits, nonce) calls simply use the first argument (a format string) as instructions to convert the remaining arguments to little endian (also called least significant byte or LSB) unsigned long Byte arrays more details on that here. In the latter case when three "L"'s are used that's because there are 3 integer arguments provided which we want to convert into unsigned longs.

[::-1] is used to reverse the bytes of an array (this is necessary because the hashes are stored in textual hex in reverse order from how they are stored in binary which is little endian). So if for example prev_block.decode('hex') returned the Byte values 0, 1, 2, 3 then prev_block.decode('hex')[::-1] would return Byte values 3, 2, 1, 0. More about extended slicing here.


What is the purpose of XBTEUR.d tradable pair?

The difference between XBTEUR and XBTEUR.d is that the former is on the "regular" kraken exchange whereas the latter is on a dark pool.

In substance, dark pool orders are only visible to the exchange (and the exchange will fill your order as and when somebody comes with an opposite order) but not to other market participants. In theory it allows you to place larger orders without the market knowing about them.

Note: in a regulated environment (say equities), the exchange is not allowed to use the information provided by your order to "front-run" you. I don't think there are any similar laws applicable to crypto-currencies - to be checked.

You can find additional information in the official announcements here and here.


Has a spend from a hybrid public key ever made it to the blockchain?

Surprisingly, there's a number of UTXO entries for the obscure hybrid key format. The transaction 657aecafe66d729d2e2f6f325fcc4acb8501d8f02512d1f5042a36dd1bbd21d1 makes a number of interesting P2PK outputs, two each of which are 0x06 and 0x07 respectively.
OP_PUSHBYTES_65 06da9be28d6e6266ddc0bc71b09032f3a810ffc917b5876e23a03c118f24f6a84dae4a9a5244fbf47860bc0760102d6bde6257bfcb7155d3dd66b97181119f98c5 OP_CHECKSIG

OP_PUSHBYTES_65 07d19ef6ba5b92b87078dba3a00df392efc16917defb2be08f22e41ce2873335705bff95fed463550f291d3b1fd559af11e432256a47e738572be3b74fc6f73ed0 OP_CHECKSIG

None are spent, but there's no technical reason for this, the outputs are valid.


From its api info page, dashblockexplorer.com uses insigth api, and so just append to the url:

  &pageNum=#

For example, for the next page (#1, as it starts on zero):

  https://dashblockexplorer.com/api/txs/?block=990001&pageNum=1

Last page should be pageNum = pagesTotal-1


What will happen to bitcoins stored at segwit outputs pre-BCH-fork?

According to BIP 141, talking about the Bitcoin chain, it'd still trigger "Witness program" and the funds would be stored safely in the SegWit address -after the fork.

Talking about the Bitcoin Cash chain, the miners can redeem SegWit outputs, (both Bitcoin Cash sent to SegWit addresses and Bitcoins in SegWit addresses pre-hardfork.) However those addresses need to have exposed their Witness program, or the outputs can't be redeemed.


Many decentralized exchanges like etherdelta allow you to buy Ether assets at higher prices. If you're looking for Neo specifically, I believe bittrex.com allows you to buy and sell above/below the current price.


Can I import my wallet while my btc core is syncing

Like this?

  This guide is intended for users of Bitcoin-Qt who do not want to wait for their wallet to be synchronized with the network, which may take many hours or days depending on the hardware spec. The guide teaches users how to transfer their coins to Electrum bitcoin wallet, which has lower security but a faster startup time.

To answer your question, yes you can.  Syncing the blockchain has nothing to do with your private keys.  Electrum has a list of blockchain servers to use your keys with immediately.


Bitcoind uses only ~1.5% CPU for RPC command "getnewaddress"

This is a known problem in the wallet code.

Whenever a new address is retrieved from the key pool, a new key is also generated to replenish the key pool. When this happens, we try to make sure this new key is safely on disk, so we flush the wallet file to disk. Due to probably overly aggressive flushing, this results in large writes to disk in BDB.


Creating a virtual wallet to display balance in a store

It is a way much better practice to generate a new address for every new order and not per user, as this would imply address reuse for returning customers, which is generally discouraged. Then the users won't have to keep their funds on your website and will only pay the exact amount for each order.

You can take a look at these open source projects for bitcoin written in PHP for starters.


How to programmatically determine the number of bitcoins ever deposited to a given address?

Using electrum, after instantiating a Wallet instance, the code to achieve this looks like so:

def get_total_received(addr):
    """Returns the number satoshis ever received by this addr.
    Includes coins sent to this addr from this addr (eg change)
    and coins received by addr, but already spent"""
    load_interface()
    hist = wallet.get_history(addr)
    s = 0
    for tx_hash, tx_height in hist:
        tx = wallet.transactions.get(tx_hash)
        for out_addr, value in tx.outputs:
            if out_addr==addr:
                s += value
    return s

The main difference between this method and what is presented by blockchain.info as 'Total Received' is that if the address sends bitcoins to itself, this method will count those towards the total received whereas blockchain.info will not.

Note that this only works if addr is contained in your electrum wallet.


What bytes are calculated on the transaction fee?

One hexadecimal digit represents 4 bits which is half of a byte (8 bits). Therefore, the raw byte length of a transaction is half of the length of its hexadecimal representation.

In your case, there are 384 hexadecimal digits, and the raw byte length of the transaction is 192 bytes. Depending on whether the fee rate is given in [satoshi/byte], [satoshi/kilobyte] or [BTC/kilobyte], you need to apply the corresponding unit conversions. Note that Bitcoin uses kilobyte here for 1,000 bytes.

There are two more pitfalls here:

Since the activation of segwit, fees are paid per weight, not raw byte length. In practice this means that transactions with segwit inputs require less fees than what would correspond to their raw byte length. I've explored the topic further here: Medium: PSA: Wrong fee rates on block explorers
Signatures in Bitcoin have a variable length. It is therefore common that your fee estimate is off by a byte or two, especially if your transaction has few inputs. You can get around that by either using a slightly conservative estimate (which is for example how this is addressed in Bitcoin Core), or by repeating the signature for the transaction until the size fits your estimate.


It is important to note that with this process, you will want to use a wallet that does not have private keys. Otherwise, you could accidentally be sending Bitcoin to an address that is in the online wallet. This especially important with change addresses because change addresses are automatically pulled from the current wallet. By disabling private keys, you won't have any change addresses (or other addresses) in the wallet that has your addresses imported. You can create a wallet that has no private keys by using createwallet "<wallet name>" true.

When doing the following with bitcoin-cli, make sure that you include the option -rpcwallet=<wallet name> so that you are using the correct wallet that does not have private keys.

  I've created privkeys, redemption script, and matching address on an offline node. How do I import this into my online node (presumably as a watch-only address)?

Use the importmulti command to import your addresses, their redeemScripts, and their witnessScripts, if any. When you receive coins to these addresses, you will be able to see them in your online wallet's balance using getbalance "*" 0 true.

  Using the online node, how do I construct a PSBT that spends some of the UTXO(s) for this address?

You can use the walletcreatefundedpsbt command. Your command will be something like:

walletcreatefundedpsbt '[]' '[{"<recipient address>":<recipient amount>}]' 0 '{"includeWatching":true,"changeAddress":"<change address>"}' true

What this will do is create a transaction with the outputs to your recipients. It will then choose inputs from the wallet, and add them to the transaction. If there is change, it will use the change address that you specify. walletcreatefundedpsbt has other options too. Read the help text for more information.

  Using the offline node, how do I sign said PSBT using the privkeys, redemption script, and matching address that I have stored on paper?

Assuming that your offline node has the private keys, you can sign using the offline node by taking the PSBT from the previous step and using the walletprocesspsbt command. Your command will be something like this:

walletprocesspsbt <psbt>

It will give you a PSBT that contains signatures. You can double check this by decoding it with decodepsbt <psbt>.

Then you can finalize and extract using either your online or offline node, it doesn't matter. You will use finalizepsbt <psbt>. If everything is correct, you will get a hex transaction that you can send with sendrawtransaction. If some part of the process failed, then it will fail to finalize and extract, so you will get another PSBT from finalizepsbt.

  Secondly, is this process expected to work in today's 0.17.1 software?

Yes

  Is it expected to change in the near future?

Not significantly. There may be more commands that are added that are useful, but not necessarily required. The format for the existing commands won't change significantly if at all.

  Thirdly, is this secure, assuming a secure offline node but an insecure online node? Can I be sure this isn't funding a too-large miner fee, for example? I understand that hardware wallets sometimes require the entire input transactions in order to verify input amounts.

Yes, it is secure, even if the online node is compromised. When the offline node signs, it does several checks. It will check that the entire previous transaction included for non-witness inputs has a txid that matches the one specified in the transaction being made. This ensures that you are spending what you expect to be spending.

For segwit inputs, part of what you are signing is the value of the output being spent. So you always know what amount you are spending. If the amount is incorrect (does not match the amount that you expect for that output), the signature will be invalid and thus the whole transaction will be invalid.

These checks ensure that what you sign will either be exactly what you expect it to be, or that the result is invalid and nothing moves anyways. Since the transaction includes full amount and scriptPubKey information, you can double check that the amounts are correct, the fee is correct, the inputs are the ones you want to use, and the outputs are the ones you want to create by using the decodepsbt command.


How do you get "the raw bytes for the genesis transaction"?


ah, indeed that was not clear to me. The input sigscript is composed of two parts, the signature itself, and the following "condition", that need to be met for spending the tx. Usually this is a public key, but can also be multisig elements or smart contracts.

In the case where a public key follows, there are two representations of public keys: compressed keys and uncompressed keys. How they are generated is explained in a thread here: How are compressed PubKeys generated?.
So you can have this representation:

pubkey hex uncompressed (04 + x + y):

04 50863AD64A87AE8A2FE83C1AF1A8403CB53F53E486D8511DAD8A04887E5B2352 2CD470243453A299FA9E77237716103ABC11A1DF38855ED6F2EE187E9C582BA6

or this:
pubkey hex compressed (02 + x, y=even):

02 50863AD64A87AE8A2FE83C1AF1A8403CB53F53E486D8511DAD8A04887E5B2352

In the case where y=odd, then a 03 is at the beginning.
Looking at the length, you have 65 for uncompressed, and 33 bytes for compressed keys.


Does a Stellar ledger contain all the state of the world? How does it scale?

It's my understanding that if a transaction set is voted as valid during an SCP round, that transaction is applied to the "last closedledger".  The new state of the ledger now becomes the "last closedledger" and the process repeats.  So you can think of voting as modifying a big, shared global state.

E.g. if the last current ledger shows Foo: 1 and the transaction is +1 to Foo, when the nodes ratify this transaction one is added to Foo and the ledger state moves to Foo: 2.

The ledgers are "linked" via a cryptographic hash so that they form a chain and you could verify the hashes match...but my understanding is that there's no real need to keep historical ledgers around other than for historical book-keeping/archival purposes.

Consensus is reached through the SCP voting algorithm rather than verifying cumulative hashes (proof of work).  So the current state is valid because it's been voted on being valid, and there's no need to do the whole "validate the universe" sync that happens with proof-of-work blockchains.  I'm assuming that when new nodes join, they just bootstrap themselves from nodes in their trusted quorum slice and there's not really any "verification" going on

It scales because, while you need an entry for all existing accounts, you really only need the current ledger rather than all previous permutations too.

Obligatory disclaimer: new to SCP myself, not a developer on the project but have been reading the whitepaper, may be wrong :)


How do I find the exchange an address belongs to

It is basically impossible to identify who (whether it is an exchange or someone else) owns an address unless they announce that they own the address. You will not be able to figure out what exchange the address that you have belongs to by just looking at the address alone.

You will have to look elsewhere, and knowing the address is not really important. Look through your emails and think of the exchanges where you have made an account on. Only through other data that you have (e.g. your emails, saved login info, etc.) can you figure out what exchanges you have used and thus potentially deposited coins to. The address that you have is irrelevant.


You can issue gift-in-kind receipts, the same sort you would issue for any other non-cash donation.

(e.g. Thank you for your generous gift of 7 Bitcoins which we received on _(Date)_. Your generous contribution will help to further the important work of our organization.)


Migrate wallet from Bitcoin Core to Armory

The easiest way is to simply send them from the bitcoin core wallet to an address in armory wallet.

The other option would require you to use dumpprivkey on each address and then importprivkey on armory.


So called "block chain based refund" is not reliable with bitcoin.

The sending wallet may be a shared web wallet (blockchain.info, MtGox, e.g. any web site) and thus you cannot guarantee that any of change addresses in the transaction are controlled by the user. Even by exploring the block chain and knowing from which address the bitcoins arrived and where unspent change went, it is not guaranteed that if you make a refund to any of these addresses the sender receives the payment.

Instead, all refunds must be handled off-band and the refund bitcoin address must be asked separately.

E.g. SatoshiDice includes the following disclaimer (players basically must use a desktop wallet where the wallet software generates a change address and the wallet is not shared with other users):

  IMPORTANT: Only use wallets that allow you to receive Bitcoin from the same address you sent from. If you're not sure, test by sending a bet for the minimum amount. If you get nothing back, then your wallet is not compatible. Note that some bets may require one confirmation before the win/loss value is sent back.

A just-dice.com FAQ regarding shared web wallet.

In the case you still want to pursuit change-address based refund you might find these links useful

https://bitcoin.stackexchange.com/a/9152/5464
https://bitcoin.stackexchange.com/a/5982/5464
https://bitcointalk.org/index.php?topic=138752.msg1481892#msg1481892

Here is some more info (I have written this down some time ago, but I have not verified whether this is still valid):

Your bitcoind must run in a special: Since bitcoind/Bitcoin-qt 0.8, no transaction index is kept anymore by default, as it is not necessary for validation in the new database model. Instead, there is only a database of unspent transaction outputs, which has enough information to (slowly) locate transactions in block files. getrawtransaction uses this, but it only works for transactions that are not yet spent in the block chain. If you want to be able to look up historical transactions, you need to set the txindex=1 configuration option (or start with the -txindex command line flag). As this setting can only be set when the database is created, you'll need to rebuild it from scratch (using -reindex).


Pump & Dump communities. Are they legal?

Legality depends largely on jurisdiction, and you didn't specify one.  In addition, the regulation of cryptocurrencies is constantly in flux, and even in a given jurisdiction it's difficult to say which laws apply to them and which don't.  It also may be in question whether fiat money is involved, or are these scammers selling their altcoins for bitcoin.

As far as I'm concerned, this looks like it is illegal, or at the very least should be.  Whether it actually is, is impossible for me to say.  If you want a more definitive answer, I recommend consulting a lawyer in the jurisdiction you are concerned with.


How is blockchain not responsible for someone stealing my Bitcoin?

Many people have asked similar questions here concerning theft and recovery but I think the question of responsibility is a good one.
This answer makes a few digressions but I hope by reading to the end, the issue of responsibility will be clearer.

Unexpected transfers

Can anyone please tell me what happens when you set up the recovery phrase did that automatically send my coins somewhere

No. That wouldn't be normal.

Control of cash
It is probably useful to clear up a few basics.
If you live in the USA, when you go to a coffee shop and pay cash in paper dollar bills or coins for a cup of coffee, this obviously does not involve the car rental business called Dollar (website: dollar.com) even though you are paying in dollars. If there was a bank called Dollar Bank Inc, your use of paper dollar bills and coins to buy a cup of coffee would have nothing to do with them.
Businesses like blockchain.com or bitcoin.com are not in control of bitcoin. Just as dollar.com is not in control of the US dollar. You don't have to use those businesses (or any others) to use bitcoins (or dollars)
Bitcoin was created as electronic cash that does not depend on trusted third parties like banks.
From what you write, you chose to give your money to a company named blockchain.com. If you are unhappy with their service or feel they have failed to take proper care of the money you gave them, that is something that you must take up with them. No-one else has any special inside knowledge of what that business does.

Theft

It's weird the moment I set my recovery phrase was when my money disappeared.

It seems likely that someone else saw that recovery phrase and used it to take control of your money and spend it. Maybe your computer or phone has been infected with malware that lets a criminal spy on your use of it using a software keylogger or some other malicious technique.

Responsibility

I see where it was sent cause it's public and NOONE can tell this thief that they need to give my funds back?

That is correct. Bitcoin is mostly anonymous. You can see an address where money was sent but there is no central registry of who controls which addresses. The addresses all look like random numbers. Bitcoin is a peer-to-peer cash - which means there is no central authority who can intervene to reverse transactions.
This is the nature of cash. If you are walking through a train station or airport and a pickpocket removes a paper $5 bill from your pocket without you noticing. The next day there's no government agency and no bank you can ask to press a button that will put that paper $5 bill back into your pocket. Cash doesn't work like that.
If you feel you have evidence you have been robbed. you should report it to your local police. That's what you would do if a pickpocket stole the cash in your pocket.

Recovery
You will get lots of offers for help but all of them will be from conmen and scammers who are trying to get you to trust them so they can trick you out of more money. They will eventually try to confuse and panic you by talking about refund fees, release fees or the need to prime a wallet with money and lots of other lies.

Related Questions

How do I recover from a cryptocurrency scam?


Why didn't Satoshi make the nonce space larger?

There were many good answers to this question. After reading through them, I'm going to take a stab at the answer as well.

The coinbase field of the coinbase transaction (as it is called) is really just a scriptSig which doesn't have to pass any validation about its contents (except that it is less than 100 bytes, and the newer BIP34 requirements). Satoshi knew you could put arbitrary contents in here, and so he put a timely news headline in the genesis block's scriptSig: "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks". A message like this also helps confirm that no pre-mining was done, as the message could not have been put into the block before the date that the article was published.

I think that Satoshi thought that a 32 bit nonce-space was overkill. A standard computer, like the one I am writing this on, can get about 3 MH/s, which is about 0.07% of the way through a single nonce-range before you can increment nTime and get a whole new range of nonces. That's not to say that Satoshi thought that there would only ever be single computer CPUs mining (this post shows he didn't), but I bet he thought that each miner would have it's own address in this case.

I don't think Satoshi envisioned pools happening, especially in the fairly centralized way that they exist today, and the flexibility of the coinbase field was just utilized by mining pools (as somewhat of a hack) when hash power became large enough to go through more than a single nonce-range per second.


Could a mining pool attack Satoshi Dice?

You're absolutely correct. The following would completely work:

Get ready to perform a Finney attack.
Gamble some coins.
If you lose, go through with the Finney attack. Otherwise, cancel your Finney attack, and collect your 1250 BTC from satoshidice.

Is anybody doing this? I don't know.


Do you know your Bitcoin address?

Check on https://blockchain.info/ that it still has a value.

Locate wallet.dat, it should be in ~/Library/Application Support/Bitcoin/.

Install MultiBit and get a new address.

Visit https://blockchain.info/wallet/import-wallet. Drag the wallet.dat file into the dotted area. Follow the instructions.

Send your coins from blockchain.info to your new MultiBit address.

You'll now be in control of your coins again without requiring huge blockchain downloads.


How do I calculate expected earnings when mining a cryptocurrency?

Calculate your share of the network hash rate for that particular hash algorithm (your hash rate divided by the network hash rate), let that be HR.

Calculate the emission by unit of time (block reward times 86400 divided by block time in seconds), let that be E.

Calculate your expected average coins mined in a day (HR times E), let that be C. Note that variance will be high, unless you mine on a large pool, or have a large HR.

Calculate the price in the coin you want to convert to (C divided by exchange rate, or C times exchange rate, depending on whether it's expressed by altcoin per bitcoin, or bitcoin per altcoin, respectively).

If you want per second, or per MH, scale accordingly.


What is a good place to ask for bitcoin to fund a scientific project?

You could look into posting about your project in the Einsteinium community. The coin is designed specifically to help fund science projects and research.

http://einsteinium.org/

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


Can you create multiple transactions per block in chronological order?

Yes. The transactions will be in the correct order chronologically, or else block validation would fail because there would be missing inputs to the transactions out of order. See Is there a fixed order for all transactions in the block chain?

Another way to do this is to see which previous outputs each transaction references. If they are in the same block, they will reference each other and you can determine order that way. See also Can multiple transactions transferring the same bitcoin be done in one block?. You cannot use a timestamp, because the block is what is timestamped, so all transactions in the block have the same timestamp.


What would happen if miners refused halving

What if after this phase the first miner or more than 51% of them decide to keep the current production rate ? Do their block will be refused like if they had produced a wrong block ?

Exactly. This is no different than if a miner (or a majority of miners) created blocks which paid out anything more that 12.5 BTC today: the network would simply ignore the new blocks, and the miners will have wasted their resources, working on an invalid block.

@JBaczuk's answer is technically correct that this would create a hard fork, but it ignores the bigger picture that even if a majority of miners make the switch, that doesn't mean users will follow. So while the miners could create a new, hardforked chain, this would be rather uninteresting, as there would be no users on it. As we've seen with past events (ie, blocksize debates, Segwit2x, etc), miners will follow users, not the other way around.

If this were not the case, then users (and the network's rules) would be at the whim of the miners. This would create a broken system of incentives, as miners could just change the rules to benefit themselves (eg, changing the issuance of new coins).


Send cash: bitcoins vs western union: which is cheap?

If you pay enough fee, which is ~ 5 dollars currently (but paying 10 dollars will guarantee fast confirmation), your payment will get confirmed in an hour. Good luck!

Actually it's possible to send with lower fee by using a SegWit address, but don't take the risk if you don't know what you're doing, set its fee 8-10 dollars. Rescuing the low fee transaction is difficult unless you're an expert.


Required conditions to be selected as intermediary node (Payment Service Provider) in Lightning Network?

Note that this video is made by shitcoin paddlers trying to spread FUD. If I remember correctly the further episodes are much much worse.

  "There's no way to add more beads or take off a portion of the beads
  without taking the rod down all together."

This is false. It is possible to both add and remove coins from a channel. It's called topping up or splicing. Having all your coins on one "abacus" is pointless. So who cares if you have 10 channels that you close one to pay something onchain? (Possibly using the same transactions to re-open the channel immediately.)

  this answer (Link to answer) distinguishes between the channel capacity and the channel balance as follows

I think you're reading that answer wrong. Of course capacity is different from balance as capacity is one number and balance is 2 numbers. Also note that "capacity" is a nice thing to talk about when talking about the total capacity of the whole Lightning network (as sum of all channel capacities) but the capacity of a single channel is kind of pointless. I'd argue it's actually more informative to define a channel as having two capacities: one in each directions. So your first drawing would have 2 + 1 as capacities. With this definition you can talk about the capacity of one channel in a certain direction as well as the capacity of a whole path from payer to payee over multiple channels (and a different capacity in the reverse direction). The total capacity of the whole network would still be the same.

  So, user B cannot be selected as Payment Service Provider (intermediary node) and users A and C have to establish a direct channel between themselves.

False in two ways. 1) A can use this path for 1 BTC and send the rest over another path. 2) A and C don't have to connect to each other, they just need to have a few more channels. This is called Lightning Network after all.

  (1) The intermediary node has a direct channel with either destination or another node that has all conditions of an intermediary node.

Sounds correct.

  (2) If the amount of transaction is n coins, the intermediary node has at least n coins payable towards/in the direction of destination.

Yes. I'd even say "each intermediary node" (not "the") as according to (1) there can be more than one. But note that the payer always has the option of splitting "n" up into "n1 + n2", sending each over different paths.


Testing `avoidpartialspends` option in Bitcoin Core

In this particular case, it is because Bitcoin Core prefers to make transactions which do not create change over anything else. Notice how this transaction does not have any change. If the Branch and Bound exact matching algorithm finds a solution, it is always used, regardless of other "optimality" as it considers "no change" to be an optimal solution.
Obviously this may not be actually be optimal, but there are planned changes to the way coin selection works to have different metrics for "optimal".


Do the DNS servers make Bitcoin more secure than the IRC channel?

The DNS system is vastly more scalable than an IRC channel. It has its downsides, in particular it is only unidirectional. However, given enough seeds it is much harder to knock out than a centralized IRC server.


How to get a wallet address and set label via RPC?

You may have already read this, but make sure you read this if you want to know about how the accounts feature of the core client works: https://en.bitcoin.it/wiki/Accounts_explained. (It's somewhat of a legacy feature.)

Are you looking to be able to do this manually with the RPC methods, or automated?

For manually, do:

bitcoin-cli getaddressesbyaccount "donations"

If the JSON array returned is empty, then no address is associated. To create a new bitcoin address with that label, do:

bitcoin-cli getnewaddress "donations"

To get an address for the "donations" account, do:

bitcoin-cli getaccountaddress "donations"


Is it possible to delete received or sent transaction in your mobile btc wallet

The Bitcoin Wallet App doesn't have the option to delete or hide transactions from the list.


How do nodes come to a consensus on difficulty?

There is no coordination done specifically for difficulty calculations. The difficulty is computed deterministically based on the data in the blockchain (shared among all nodes), specifically the timestamps of blocks.


BlockUntilSyncedToCurrentChain: txindex is catching up on block notifications

One way to solve this seems to be to disable and then reenable txindex. In other words, stop bitcoind, set txindex=0 in bitcoin.conf, start bitcoind, wait until fully started, stop bitcoind, set txindex=1, start bitcoind, wait until message "txindex is enabled at height xxx".

Unsure why this is necessary though.


What are the advantages of Schnorr vs ECDSA?

Your question seems to assume that the only goal is minimizing on-chain transaction size. Reducing size and related costs is certainly something that can be improved upon, but it's far from the only thing. The primary advantages of the Schnorr proposal are:

Better privacy, by making different multisig spending policies indistinguishable on chain. When combined with Taproot, this extends to pretty much all cooperative executions of contracts (which become just a single signature on-chain, regardless of complexity or number of participants)
Enabling simpler higher-level protocols, such as atomic swaps that are indistinguishable from normal payments. These can be used to build more efficient payment channel constructions.
Improving verification speed, by supporting batch validation of all signatures in a block at once (for a fraction of the speed of validating them individually).
Switching to a provably secure construction, perhaps preventing an exploit against ECDSA in the future.

As far as your specific suggestion of using public key recovery to avoid publishing the public key in a spend goes, there are some arguments against:

Public key recovery is incompatible with batch validation, and when ignoring batch validation it is (slightly) slower than normal validation on itself.
There may be patents that apply to public key recovery.
The same size savings can be accomplished more simply by using pay-to-pubkey instead of pay-to-pubkeyhash (again, when combined with Taproot this advantage extends to scripts as well as single key constructions).
Longer term cross-input signature aggregation holds much better potential size savings by reducing the total number of signatures per transaction (not just transaction input) to 1. Cross-input aggregation is also incompatible with public key recovery, though this isn't currenty included in the Schnorr proposal.

Also note that the lack of public key recovery isn't inherent to Schnorr - it is a result of choosing key-prefixed Schnorr. It's better to see it as a tradeoff between 3 properties:

Linearity: the ability to jointly produce a signature for the sum of public keys (the basis for all Schnorr multisignature constructions).
Lack of key malleability: with key malleability it is possible to take a signature for an existing public key and turn it into a signature for a related key (for example, one in the same BIP32 tree)
Public key recovery: the ability to reconstruct a public key from a signature and message.

Key-prefixed Schnorr lacks public key recovery. Non key-prefixed Schnorr suffers from key malleability. ECDSA lacks linearity. It doesn't seem possible to construct a signature scheme that has all three.


Trying to access my BTC from Bitcoin-Qt wallet that is out of sync

Assuming you mean 0.8.4 ? (Or 3). Latest is 0.8.5 now but nevertheless...

What is the fastest possible way to download the blockchain?

Although I wouldn't recommend the bootstrap.dat answer because you'd need to create a new wallet for that--and eventually would likely have to resume syncing the old one anyway.

Edit: it appears I'm mistaken about the above paragraph.  The thing to know about bootstrap.dat is your client still has to verify everything that was imported over the network so it's still going to take some time. But a combination of both answers might be best. And only download from a trusted source.

Try to just get the fastest connections as per the "high bandwidth" answer.  There's really nothing much you can do in the meantime because wherever else you try to send the coins is not going to go through until the entire block chain is synced.

I've gone through this when I had to re-download the whole thing after a kernel panic -- LFMF -- don't import the private keys elsewhere before it's synced.


How to change the displayed denomination in GreenBits Android wallet?

On the top right corner of GreenBits there's a menu with a number of entries: the first one is named "Settings" and we should select that, then "Info & settings" and then you can change the fiat currency, the bitcoin denomination as well as your preferred exchange if available.


Can Bitcoin Help with a devalued currency?

See the comments above, but the answer to your question is that the exchange will happen at the "instant" exchange rate.

So, whatever value CAD is at when you do any kind of exchange, that is the value you will get.

In terms of increasing savings, all you can do it make sure you exchange it for one that is rising.


Difference in hash rates between Bitcoins and Litecoins calculation

If you are using general purpose mining hardware (i.e. CPU, GPU) then it really depends on lots of factors, not only hardware, but also mining software and even its configuration.

For details on mining hardware you can check the tables for Bitcoin and Litecoin.

But with the inevitable introduction of ASIC miners (already for Bitcoin, and soon for Litecoin) the question is actually irrelevant.

ASIC miners can only work with the hashing function for which they were designed.
So a Bitcoin ASIC miner (SHA256) cannot mine Litecoin (scrypt) at all, and vice-versa.


Accepting 0-confirmation transactions and detecting double-spends with open source solution

You should not interact with bitcoind, because it (current versions at least) filteres double-spend transactions

You should have your own network-sniffer solutution - the program which connects to the network nodes (as many as possible) and listens for all transactions, checking do they have conflicts with particular ones.

(How much would you pay for such program? Just interesting :) )

This is also not 100% safe solution - a miner can place double-spending transaction in block and mine it himself. Look here: https://bitcointalk.org/index.php?topic=327767.0


How do I restore a wallet from a backup file in MultiBit HD when you have the words and cloud backup?

Be sure to write the words in correct order and with small letters, secondly use only spacebar button between them, DO NOT USE Enter button to go to the next line.


Confusion over BTC value - MtGox vs CoinDesk

MtGox is an exchange: people trade Bitcoin for USD there. The value they report is what the exchange rate is on MtGox.

CoinDesk calculates its Bitcoin Price Index based on a number of factors, including MtGox's price, and the prices on other exchanges. This appears to be a much better indicator of the true market value than MtGox's exchange rate.

You might wonder, if the price difference is so large, why don't people buy on one and sell on the other to make a profit? People do, in something called arbitrage trading, but how close this will bring the markets depends on the overall costs of the transactions (fees, etc.). Since getting USD out of MtGox is not easy (or even possible?) at the moment, the gap can be quite large.


What happens to my bitcoins if a hard fork occurs?

Technically, the UASF that will go live on August 1st isn't a hardfork (see What is the User Activated Softfork (UASF) proposal? How do its risks compare to hardforks?), but it may have still have a chainsplit.

When there is lack of consensus about the rules in the bitcoin network, there may be multiple blockchains, one blockchain following one set of rules, one following another. These two chains share the beginning of their chains, but there is a distinct point in time where they diverge. If the transaction where you received bitcoins happened before that point in time where they diverged, then your coins will be in both chains, so no matter which one is eventually selected, you'll be on the 'winning' side.

I should note that a chain split isn't necessarily ever resolved. There might be two ecosystems and networks that build around 2 different chains. In this case, your pre-split coins are available on both chains, and you could even spend them twice, once with one merchant on one side of the chain split and once with another merchant who is on the other side of the chain split!

The risk mainly comes in when you make transactions after a chain split. For example, if you are a merchant and you accept coins on side A of the chain split, but that transaction doesn't also get included on the other chain (side B), then sometime later the network gets back to consensus that chain B is the correct chain, then your coins on chain A are worthless. So it is risky to accept payment while the network lacks consensus.


Calculating the target from the hash leading off bits

I'm struggling to find a way to calculate the bitcoin equivalent “target” from that number.

Your difficulty recalculation algorithm will need to be completely different then. The easiest way to change it is to just start with an initial difficulty with all bits set and then bit shift this number as needed to get a target with some set number of leading zeros.

  Additionally I wonder why it is not implemented that way in the bitcoin protocol? Does it cause too harsh steps of difficulty?

Because it only allows for the difficulty to double or halve. Furthermore, there are only 256 possible difficulties so this is not at all ideal nor would it work particularly well. This means that the target would usually be too high or too low. By using a target value, the difficulty can be adjusted to far more levels (2^256 possible difficulties) to better match the network hashrate.


Assuming you have not created any new bitcoin addresses from the time that you had only 10 coins, your balance will remain intact (20 BTC) when you load your private keys into another client.

In other words, your client doesn't store your coins locally, it only stores a reference (through your keys) to the unspent transactions that have been received by your addresses which at a high level compose your wallet's balance.


Bitcoin script has no way to get information about the outputs of a transaction spending it, so no, neither of those things are possible. If you want withdrawal only to a specific address, why not just send to that address the desired amount in the first place and save yourself a transaction fee?


This layer 2 wording is an analogy/comparison to the network TCP/IP stack. Basically the TCP/IP stack allowed for networking machines as the foundational layer (or the layer 1 infrastructure). And on top of this infrastructure came the protocols, which are commonly used today (http, mail, ...). When comparing to the bitcoin world, the idea is that bitcoin as per today is the "payment infrastructure", and on top of it there will be protocols for lightning (micro transactions), schnorr sigs, smart contracts, ... So the underlying bitcoin network has proven to be reliable, and serves as a utility for future setups on top.

There is also a certain euphoria when people talk like this, hoping the future will reduce/avoid today's limitations with these "layer 2" protocols. Exciting times ahead!


If bitcoin was created years earlier, would we see the same rate of mining hardware evolution?

Difficulty would have risen slower, but would have still been out of reach for most people at the same proportion as today. The GPU makers have not been creating graphics cards with the target audience of general processing and algorithm solving.

ASIC/FPGA mining hardware has zero innovative aspects than what you would have seen a decade ago. These are simply dedicated chips for solving Sha-256 algorithms. ASIC stands for "Application Specific Integrated Circuit" and could mean anything, although the cryptocurrency miners use this term very loosely. But for clarity, the bitcoin ones are ASIC for solving Sha-256 algorithm.

The industry has always been able to make dedicated chips, as you have dedicated chips for Mpeg-2 processing in video editing rigs, your digital camera has an ASIC for processing light very quickly. Whereas the CPU in your computer is for general processing, with the most R&D being to create faster and more efficient general processors for a variety of applications, instead of just one.

So to sum it up, with a profit motive the Sha-256 ASICs would have come out a decade ago because there has been little advance in technology needed to create them. Sha-2 was created by the NSA in 2001, or at least published by the NSA in 2001.

It is not a feat of engineering to make a machine efficient at solving one algorithm.

Another difference between a decade ago and today is that crowdfunding over the internet by presales would have been less trusted. Making securing the capital more difficult to create and produce ASIC mining equipment.

It is also worth noting that bitcoin can be switched to another algorithm if a vulnerability is found in the current algorithm (sha-256). This would mean that a different kind of ASIC would have to be created.

Finally, the folly of fiat currency mismanagement was not as apparent a decade ago during a period of prosperity, so people may not have viewed acquiring bitcoin as a worthy endeavor.


Blockchain beyond bitcoin etc. - Who is mining?

These days there's a lot of new systems being shipped - or marketed even before that - that came with 'blockchain' attached somehow. We're not sure how and why someone would set up a blockchain for logistics transactions, to stay on your example. Most of the news about 'adopting blockchain technology' we see on the media fails to explain why they need a blockchan at all - or are afraid to say they will anchor data on Bitcoin or Ethereum chains.

One can design a database with hashes and digital signatures in blockchain's fashion and call that a 'blockchain', without mining. They can even have ming with no reward or token of value, and call that a 'blockchain'. There's no one to stop them.

But the meaning of 'blockchain' as it's used in Bitcoin, is something where mining is hard and needs incentives like block reward to happen. That's the design originally proposed by Satoshi Nakamoto in his solution for the Bizantine Generals Problem.


How big is the blockchain on disk as of 5th July 2012?

At the moment, it's about 2.6GB, but it will be growing with time.

You can try looking into using an eWallet or some lightweight clients if you are tight on the disc space. Their space requirement is minimal in comparison, but the security model they offer is different. The lightweight clients are developed by other people than the core Bitcoin team, so you have to know that you can trust them (haven't yet heard about a case of the lightweight clients being malicious). With the eWallets you put the security of your money in the hands of the third party and their server. There have been incidents of people losing a lot of coins because of this (like MyBitcoin), but if ran well and by trustworthy people, your Bitcoins can be more secure than on your computer.


Is how can I enable my wifi router to accept Bitcoin for adhoc/ anonymous usage?

There is a project called wifiportal21 that uses the 21 Bitcoin computer in conjunction with an OpenWRT router running the wifidog captive portal software.  This is still in beta at this time, but seems to suit your application.

It is also worth noting that OpenWRT does have the ability to create a separate network that cannot pass traffic to the main network, and works with RADIUS authentication.


How do you generate a Bitcoin wallet by hand?

"Mining Bitcoin with pencil and paper: 0.67 hashes per day" suggests that doing SHA256 hashes by hand requires on the order of 36 hours of work.
I've done some work on "Verifying Bech32 Checksums with Pen and Paper", though I have not timed myself.  That work is slowly being folded into my work on Shamir Secret Sharing (over the Bech32 alphabet) using paper computers in my SSS32 project to design a new master-secret format.
I have never tried to do any elliptic curve operations by hand and I have always assumed that it doing so many modular arithmetic operations over such large numbers is just too tedious and error prone to do by hand.
If you are willing to use a computer to pre-generate a list of nonces (and SHA256 midstates for your nonce/public key for BIP340), it might be plausible that you could compute an ECDSA or BIP340 signature, as the remaining steps only require a few modular arithmetic operations.  While such a list of nonces is independent of your private key and your transaction, if that data were leaked it would compromise your private key from your signature, so even pre-computing that data may not be secure enough for whatever your purpose is.


What happens if you receive a block with an unknown previous hash in the header

Blocks with an unknown parent block are stored in the orphan block pool. They will stay there until the parent block is received and then linked to the existing chain.

As far as I know, there's no other condition for the block to be removed from the pool. If the particular parent is never received, they will remain there forever.

The current difficulty should be enough to prevent people from spamming this pool with orphans, because that would require a lot a processing power and a huge waste of money. A block has to be valid to be stored in this pool, block hash has to meet target and so on. If that is not the case, the block is discarded and will not spam the orphan pool.

See Mastering Bitcoin, Chapter 10, Section Assembling and Selecting Chains of Blocks for detailed explanation.


The ledger chain stores all transactions. So yes, you can rebuild the transaction history.
But the validators don't need to store or serve the whole chain to operate. A new validator only needs the last closed ledger to validate new transactions.
This is different from bitcoin, where nodes need the last output of the relevant public key to validate a new transaction (and that last output won't necessarily be on the last block).

In theory the ledger chain could be forgotten, as validators don't need the history, but probably some "history storage" services ala blockexplorer.com will appear. Some validators can find it useful to store the whole history too.

Since it's not really necessary for the network to work, I'm not sure what happens if a server doesn't serve the ledger history, but I would say the RPC call useful to query the history is this one: https://ripple.com/wiki/RPC_API#ledger_entry


Gaming Bitcoin by generating millions of wallets

Nothing stops anyone from doing that. However, I don't think you'll find many people who agree that it's a "major flaw". If that's a major flaw, then every system in existence has thousands of major flaws. When you say things like "regardless of how many possibilities there are" you're engaging in wild speculative fantasy.


Can a bitcoin transaction from a specific bitcoin address be banned? (via mining pools)

Yes, miners can censor transactions. A mining pool (or solo miner) can choose to not add a transaction to any blocks that they create. And, of course, this can be done dynamically so that transactions that match whatever arbitrary rules they want can be disallowed.

However this only effects one mining pool or miner. Other miners will not necessarily follow the same rules. So if one miner is censoring transactions, then some other miner will probably include them in a block.

But it is also stupid for a miner to censor transactions. All transactions pay a transaction fee and by refusing to add a transaction to their blocks, they are voluntarily taking a lower payout. The transaction fees are there to incentivize miners to include transactions.


Any other sites for exchanging bitcoin for ripple apart from shapeshift and changelly?

You can view all exchanges that support converting XRP <-> BTC on coinmarketcap.com . Here are all the markets that XRP trades on. Just look for markets that say XRP/BTC.

I've successfully exchanged XRP on Bitstamp and Poloniex.


Bitcoin was barely around 2 years ago;).

Currently to my knowledge the closest thing to a Bitcoin book is my master thesis on Bitcoin. It focuses on analysing the security of Bitcoin software and the ecosystem, but a lot of people find it to be a good read even for beginners. It is in English, but wasn't published anywhere but a couple prints for my studies and online.


Are there any mining pools that publish what transactions they will include?

Knowing won't help
You are effectively looking for a centralised entity to provide you with a prediction of the future behaviour of a decentralised entity (asking a mining pool to predict the blockchain).
Even if one or more mining pools share this information, I do not believe it will provide you with a significant risk reduction in accepting transactions with zero confirmations.
Knowing that the transaction has been accepted by a mining pool simply means that it is a valid transaction with a sufficient fee for that pool. This gives no guarantee that it will not be orphaned by a rival block or rejected from another pool in favour of another transaction which double spends the same input(s) with a larger fee. These things may not have a high probability but if you're going to assume they won't happen then you are accepting a small risk of the transaction failing. This risk is there regardless of whether the pool has announced it is including the transaction.
The sender can still attack
The transaction still has zero confirmations and it is only in the case that the transaction sender is not an attacker that you could trust that the transaction will eventually be confirmed. If you are trusting the sender not to be an attacker then you do not need an announcement from a pool. It is unlikely the sender would accidentally send an invalid transaction or one without sufficient fees. If you do not trust the sender then you should wait for an appropriate number of confirmations (depending on the level of risk you wish to accept and the resources you estimate the sender has).
For amounts you are prepared to risk losing, you are of course free to accept payments with zero confirmations. My point is that the risk involved with accepting unconfirmed payments is much the same regardless of whether a mining pool has stated that they will include a transaction.
Miners are free to change their mind
As Peter Michael Lacey-Bordeaux points out in the comments to Scott's answer, there is nothing to stop a mining pool changing which transactions it includes at any time. The calculation of which transactions to include is short, whereas the search for a valid block hash is long. Given that no hash has yet been found, there is no disadvantage in abandoning a given block of transactions in favour of a slightly different block which includes some higher fees. This means the sender can attempt a double spend without any mining resources at all. This is no threat to people who wait for a few confirmations, but should be considered by people who wish to accept unconfirmed transactions.
The expected time until a valid hash is found (by someone, somewhere) is approximately 10 minutes (depending on how recently the difficulty has been updated). If 7 minutes have already elapsed, the expected remaining time is not 3 minutes. It is still 10 minutes, because the process is an exponential distribution which makes it memoryless. So starting afresh with a new block of transactions doesn't have any effect on the expected time to find a valid hash, but it may increase the total fees. There is therefore an incentive for a miner to keep restarting the search with a more up to date transaction block, and the same incentive will apply to any pool equipped to do so.
In summary, even if mining pools did announce transactions to be included, I would definitely not rely on that information.


How to remove an address used for signing from the key pool?

I am not a developer, but I believe that once you assign or create the address in a new account (you can name the account "Signing Key"), and then don't touch the account, this address will never be reused. Except only after there are some bitcoins sent to it.


when a miner solves the problem in less than one timestamp then what does it do with its extra capacity?

The resolution of the timestamp in a Bitcoin block header is one second.  However, if a miner should find a valid proof-of-work and create a valid block, they do not have to wait one second before starting work on a new block.  It is perfectly legal for two successive blocks to have identical timestamps.  In fact, it is legal for the succeeding block to have a timestamp that is earlier than that of the preceding block by up to 7200 seconds.  See Why is two hours the maximum acceptable offset for Bitcoin blocks?

So a miner can immediately start work on a new block, and this is normally what they actually would do.  Hence there is no "excess capacity" at all.


What's the impact of net-splits on block generation... over a long period of time?

If 25% of the network hashpower were to be isolated (Australia had no Internet for example), what is the effect on block generation?

Aussie transactions take 4x longer to confirm, actually. Everybody else's transactions take 33% longer (1.0/0.75)

  What would happen to the isolated Australian chain if it reconnects to the main chain? (w.r.t. the difficulty adjustment)

It's instantly blown away, and the main chain is downloaded to all of the Aussie bitcoin clients.

  Suppose a different percent of the network were to become isolated. What combination of %isolated, duration, and network hashrate would cause a 4x difficulty to be reached?

Suppose that 3/4 of miners suddenly have no internet access. For 8 weeks. That's when you'd see the difficulty drop to 1/4 of its previous value.


Altcoin does not create .altcoin folder and debug.log

The latest bitcoin source doesn't output any debug log in chainparams.cpp.
You can,

Use GenesisH0 to find your Genesis block hash.
make && sudo make install
Run it again, then you will see debug.log within your bitcoin folder


How much does the weight of 2-of-3 multisignature inputs differ between P2SH and P2SH-P2WSH?

To calculate the block weight, you need to know the size in bytes of the non-witness data and the size in bytes of the witness data.

With a P2SH-P2WSH input, your scriptSig will always be 35 bytes. This makes the size in bytes of the inputs to be 36 + 35 + 4 = 75. The witnesses contain your signatures and scripts, so the witness for that input will be 1+m*(1 + sigSize) + SizeOfVarIntFor(RedeemScript) + SizeOfRedeemScript. For a 2-of-3 multsig input, you will thus have 1 + 2*(1 + 72) + 2 + 105 = 254 as the size in bytes of your witness.

The formula for calculating block weight is base size * 3 + total size. The base size is the size of all non-witness data, so your base size is 75 bytes. The total size is the size of all data, including witnesses, so your total size will be 75 + 254 = 329. Plugging this into the formula gets 75 * 3 + 329 = 554. Thus the weight of the P2SH-P2WSH 2-of-3 multisig is 554.

*Note that SizeOfVarIntFor(RedeemScript) is actually two bytes because you need to use OP_PUSHDATA1 since the length of the redeemscript is longer than 75 bytes.


how does lightning network transactions appear?

I am sorry to write so but your understanding that the lightning network is a side chain is wrong. Thus there is not transaction with many inputs and outputs that represents the payments tat go on in the lightning network.

A payment channel is encoded as a 2-2 multisig wallet. you have one key and I have one key. The capacity of the channel are the funds sent to this multisig wallet with the funding transaction. The balance in this payment channel is encoded by a commitment transaction which spends this funding transaction. This transaction has one input (the funding tx) and two outputs (one for the amount of funds that you own and one for the amounts of funds that I own). (There can and will be more outputs but those exist only temporarily while this channel is being used to rout a payment.)

The commitment transaction only hits the chain if the channel is closed and in the best case still has two outputs. Meanwhile on this channel literally million of payments could have taken place (between the peers of the channel, and to route payments through this channel for other nodes of the network) non of those payments will be seen in the blockchain.

The key observation of the lightning network is the revocable sequence maturity contract (RSMC) which is the protocol that allows to invalidate or revoke old commitment transaction by creating a strong incentive (I should better say penalty) to not publish an outdate commitment transaction.

since all the commitment transactions in the history of the payment channel are spending the fundingding transaction (creating massive double spends) and since double spends will not be accepted by the bitcoin network you can see that the blockchain will not save old channel state. This is exactly the reason who scaling through this offchain protocol is achieved.


how to calculate max spendable from all wallet

In Bitcoin Core, there is the option to subtract the fee from the amount. When you create a transaction, you set the amount to be the maximum amounts, and then you enable the subtract fee from amount options which will then reduce the specified outputs by the fee. This way, you can choose to send your entire balance without change and have the fee be subtracted from the output.

In the GUI (bitcoin-qt), there is a checkbox labeled "Subtract fee from amount" which you can set for each recipient. You can use the "Use available balance" button to auto-fill the full wallet balance. It will also automatically check that option for you.

If you are using bitcoind over the RPC interface, sendtoaddress has a parameter subtractfeefromamount which you can set to true in order to deduct the fee from the amount you are sending. sendmany has a similar option but it is instead an array of addresses so you specify the addresses that will receive less due to the fee being subtracted from their amounts.


What do the different .dat files contain?

wallet.dat, addr.dat and blkindex.dat are Berkeley Database files. They can be read using standard tools, but aren't human readable by themselves. blk0001.dat (and additional blk000n.dat blocks) contain the blockchain itself, that's just a binary concatenation of the blocks.

wallet.dat contains your private keys, your address book, a copy of the transactions that send coins from or to one of your addresses, accounts, reserve keys, personal settings, and a pointer to the current best block.
addr.dat contains IP addresses of peers, both those you've connected to yourself or those you've only heard about. It has been replaced by peers.dat since 0.7.0
peers.dat contains the same information as addr.dat, but using an efficient custom format.
blkindex.dat contains an index of the blocks and transactions that can be found in all the blk000n.dat files.

I don't know about any standalone tools that convert addr.dat and blkindex.dat to human-readable form, although blockexplorer.com can be used to inspect the blockchain, and addr.dat just contains IP addresses.

Update: the data above is only valid before v0.8.0. As of v0.8.0, a new database structure (with associated filesystem layout) is used for blocks and indexes.


How can I recover an Exodus Wallet with lost password?

you need to search for the seed.seco file which should be in your appdata/roaming folder named exodus.wallet
this file cointains your encrypted 12 word seed.


Determine which transaction output is a change address and which is not

You can guess at which output is a change address, but the only way to be certain is if you are the person initiating the transaction.

In fact, some wallet software could be designed to intentionally obfuscate this data, to improve user privacy. At best, services like blockchain.info can only guess.


A double spend is an attack where the given set of coins is spent in more than one transaction. There are a couple main ways to perform a double spend:

Send two conflicting transactions in rapid succession into the Bitcoin network. This is called a race attack.
Pre-mine one transaction into a block and spend the same coins before releasing the block to invalidate that transaction. This is called a Finney attack.
Own 51+% of the total computing power of the Bitcoin network to reverse any transaction you feel like, as well as have total control of which transactions appear in blocks. This is called a 51% attack.

To prevent damages from the first attack - wait for one confirmation to appear on a given transaction. To prevent damage from the second attack - wait for 6 confirmations to appear on a transaction, or less if the transaction is small (but still require at least 1). Damage from the third attack can cripple the entire Bitcoin network, so don't worry about it - your business most likely won't be the main target (it's unlikely to happen without really big money getting involved).

For more information about all those attacks, you can check out my master thesis on Bitcoin security.