How do you determine 'magic byte' or version for alt coins?

0x0488B21E is the extended public key prefix / version bytes (as described in BIP32) and stands for xpub. In the same manner, 0x019DA462 stands for Ltub.

For bitcoin and litecoin these codes are:

Network             Extended private    Version bytes        Extended public    Version bytes
                    key prefix                               key prefix
---------------------------------------------------------------------------------------------
Bitcoin main        xprv                0x0488ADE4           xpub               0x0488B21E
Bitcoin testnet     tprv                0x04358394           tpub               0x043587CF
Litecoin main       Ltpv                0x019D9CFE           Ltub               0x019DA462
Litecoin testnet    ttpv                0x0436EF7D           ttub               0x0436F6E1


How to get info for public address from bitcoin-cli + local db? (Can it be done without creating a wallet?)

getaddressinfo is a wallet RPC. It reports the information a specific wallet has about a receiving address it created. Without wallet, there is no information.

It seems to me that it should not be that difficult to dump all the information that the local blockchain currently has for a given address, without the need for a wallet.

The local blockchain database in Bitcoin Core has no information about addresses or the scripts they refer to at all. All it has is the raw block data, and a database of unspent transaction outputs (indexed only by the txid and output position that created them - as you can query using gettxout).
It is of course still possible to index the chain and compute information related to addresses/scripts, like various block explorer websites do. Such functionality does not exist in Bitcoin Core, as it is unnecessary for the features it provides (full block validation, wallet functions, ...).

If not, is there some other way to do it (without creating a wallet)?

Perhaps you're interested in the scantxoutset RPC. You give it a descriptor (which can contain an address, but also xpubs, ...) and it will scan the current set of unspent transaction outputs that are assigned to those. Note however that this doesn't use any index, so it is rather slow (several minutes) for a query.
If you want the ability to query things faster, various indexing software packages exist.


Getting IP address of other NXT / Ardor peer nodes for Open API access?

Use the getPeers API and specify the desired service(s).  For example, to retrieve nodes with an open API (either HTTP or HTTPS) from an application, issue the following HTTP request:

https://localhost:7876/nxt?requestType=getPeers&service=API&service=API_SSL

You can use the API test page at http://localhost:7876/test from your browser to view the same information.


Not an expert on the issue, but try to find out what algorithm was used initially to generate your private key from those 17 words.
You should be able to apply the same algorithm and get it back.
I did not get from the question if your wallet was hardware or software, but either way, by checking the documentation of that wallet, you should be able to find the information above.
Hope this helps.


I don't understand the "51% attack" problem. Why does a mining pool have power with a 51% share?

Conceptually it isn't difficult to understand conflicts of interests (COI) principles.  If a pool has over 50% of the computing power required to demonstrate adequate "proof of work" to add entries to the Blockchain Ledger, this absolute centralized power will eventually "absolutely corrupt".

That centralized pool could be used to change the history of what constitutes the longest chain in the Blockchain by computationally orphaning blocks that were legitimately mined by other pools or solo miners. When a pool gets very large, do you honestly think it will not be tempted to modify the nominal Bitcoin transaction priority scheme?

If a pool has roughly a third of the computing power used to populate a Blockchain, they can start to statistically change the destiny of the Ledger, especially if all of its miners are using STM mining protocol. This is because miners are effectively slaved to the set of transactions the pool decides is important to mine, whether legitimate or not. When STM is used, the pool sets the mining block agenda, not the miners. Can you now see where the COI enters into the picture?

If miners use GBT, opposed to STM, they have more choice in the grouping of candidate transactions they bundle together for mining as long as they follow a template. As long as those miners are not colluding with the pool, this will help keep the large pools honest. The problem is GBT coordination sucks more network bandwidth, effectively ever so slightly lowering the profit margins miners can achieve. Most miners are interested in maximizing their profits, and are thus likely not to adopt GBT.

Knowing this information, and looking at the two big to fail pools is very disheartening. A barometer for when the big pools have gotten too large is when numerous small pools suddenly have higher orphan block rates, and their mining profits start to go south of what is expected for known difficulty factors for a protracted period of time.

To keep large pools honest, for the good of the public, the large pools that mine 25 to 30% or more of the Bitcoins need to support transparency with above the board full disclosure policy of what they are currently mining in advance of advertising their lucky block strikes. Such transparency, helps to ensure they are not violating the trust of good Internet netizen miners competitively mining at other pools.

This is a very hot topic.  From the flack that I received (i.e., negative Bitcoin Stack Exchange passive-aggressive votes) when asking a prior related question, I believe this is something that must be watched very closely...

FYI - I'm a security consultant and a guy that did wargaming for over 10 years.


Electron Cash wallet password not working!

Try it with the caps locks on. For me it was that the application wasn't telling me that my caps lock was on. Then, on restart, "Wrong password." Etc.


How do traditional transactions take place (paypal, banks, etc) in comparison to Bitcoin transactions?

A traditional payment with PayPal or a bank works like this:

You find the identifier of the intended recipient.
You request a payment being made in your name to the intended recipient.
The central entity checks your balance in their books.
The central entity deducts the payment's value and fees from your balance.
The value is then added to the recipient's balance (possibly by a cooperating third party).

→ The central entity is in control of your funds and transacts on your request.
→ The central entity has full information on your payments.

A transaction in Bitcoin works like this:

You find the identifier of the intended recipient
You signal your intention of signing over some of your funds to the intended recipient, you add a transaction fee to incentivize confirmation
The transaction's validity gets vetted by all other participants of the network
When the transaction is confirmed the recipient is in sole control of the assigned balance.

→ The users transact on their own behalf.
→ Only recipient and sender are aware of their involvement, the payment is private.


How does the signature verification feature in bitcoin-qt work without a public key?

The ECDSA public key can be recovered from the signature.

See this bitcointalk thread and the linked pdf for details.


I believe that you don't need to encode the array.
The library you are using should take care of this for you - at least the EasyBitcoin library does.

Let us know


What happens if everyone discovers much faster way of solving hash function problem (mining)?

They already did find a faster way. Bitcoin mining now is run on specialized ASIC chips but it wasn't always that way. In early days it was CPU or GPU.

So nothing happens really, difficulty will adjust so that new blocks are found every 10 minutes on avg.

If this new mining tech is only in the hands of one entity though, then they could potentially do bad things, but your question was "What happens if everyone...".


Why does hash of new created block must meet certain requirements in blockchain?

The hash must be less than or equal to a certain target hash. This is to reduce the probability that any random hash you choose will be a valid hash with valid work. The whole point of this is to prove that you (as a miner) did, on average, a certain number of hashes (work) in order to find the block.


are you running bitcoin testnet3?

put these lines to your conf file, shutdown and restart syncing again

addnode=104.237.131.138
addnode=151.80.205.132
addnode=192.155.82.123
addnode=74.220.255.190
addnode=80.100.203.151


Do I need to mix my coins to stay anonymous?

It depends what you mean by "knows" and "proof".

You're right that an analyst will not be able to be prove with absolute certainty that you sent the coins to address 3, because it is possible, consistent with the blockchain evidence, that address 2 belongs to some third party.

But in the real world, people and organizations don't need absolute certainty to take action.  They have lower standards, like "proof beyond a reasonable doubt", "probable cause", "reasonable suspicion", etc.  It's entirely possible that a detective / jury / president / mob boss would consider this sequence of transactions to be sufficient evidence for an arrest / conviction / drone strike / vicious beating.  That's particularly true if there is other evidence linking you to the owner of address 3.

So in evaluating whether a system or protocol has enough anonymity for your purposes, you have to ask yourself who you are trying to stay anonymous from, what consequences you are trying to avoid, and what level of evidence you think your adversary would need in order to proceed against you.   Maybe a single extra transfer is enough anonymity for you.  Maybe a mixer would be needed.  Maybe even that isn't good enough.  It all depends.  These questions don't have straightforward yes-or-no technical answers.

It's like asking whether a system is "secure".  It depends who your adversary is and what their capabilities are.  It might be secure enough for some people, and not for others.


How create / generate a coinbase transaction for a new block?

The coinbase transaction is like every other transaction except it has only 1 special coinbase input which you can read about here: https://bitcoin.org/en/developer-reference#coinbase. The outputs must have a value which sum to the block subsidy (currently 12.5) plus any transaction fees in the block. Those are the only stipulations for a coinbase transaction.


How to get transaction fee from raw transaction?

To get the input values, you need to look up the values of the outputs that they spend from. So call getrawtransaction one each input's txid and then find the output at index vout. The value of that output is the input value. Do that for all of the inputs and sum them. That is the total input value. Sum the values of the outputs to get the total output value. Subtract the total output value from the total input value and you will get the transaction fee paid.


Can someone explain how this person hacked bitcoin?

Question: what is that public key? do you see any keys? ("3" is a multisig address & requires 3 address? so there must be 3 public keys right?)

No. An address beginning with a 3 is a P2SH address. This does not mean it is a multisig address or requires any number of keys to sign the transaction. Rather it just means that there is some script (it can be any script, not necessarily a multisig script) that needs to be included in the input that spends the P2SH output. That script will dictate the other items in the input.

For a P2SH nested Segwit output (P2SH-P2WPKH and P2SH-P2WSH), the script that the address refers to (known as the redeem script) is of the form OP_0 <20 byte hash> or OP_0 <32 byte hash>. When a segwit node sees this script in an output or as a redeem script, it knows that it should look in the newly defined witness are of a transaction to get the rest of the data it needs to verify the transaction.

However for a non-segwit node, they will mark the transaction as valid (but not standard) because for a non-segwit node, those redeem scripts don't specify that a signature is needed. This makes these outputs anyone-can-spend to non-segwit nodes.

Since Bitcoin Cash does not implement segwit, all of their nodes are non-segwit nodes. Thus in order to spend from the P2SH nested segwit outputs, you only need to provide the redeem script. However the redeem scripts are protected by a hash; given only a P2SH output, you cannot figure out the redeem script unless you already know it. Redeem scripts are revealed when the output is spent from.

What the miner did here was that they found as many redeem scripts as they could. The redeem scripts of the P2SH outputs used were all redeem scripts that had been revealed on the Bitcoin network because they had been used as an input in a transaction. So the miner took all of those revealed redeem scripts and checked to see which ones had corresponding outputs on the Bitcoin Cash network. Those that did could then be spent by the miner as the miner then knew the redeem script.

  it gets even more stupid ????????????????????? Article says after making that raw transaction he mined it ..... without broadcasting it ?????? what

A transaction does not need to be broadcast before it is mined. A miner can include whatever transactions he wants, and that includes transactions not broadcast to the public. Once the block is mined, the transaction will then be broadcast with the block.


What does a segregated witness transaction look like?

From Bitcoin Core's primitive/transaction.h:

/**
 * Basic transaction serialization format:
 * - int32_t nVersion
 * - std::vector<CTxIn> vin
 * - std::vector<CTxOut> vout
 * - uint32_t nLockTime
 *
 * Extended transaction serialization format:
 * - int32_t nVersion
 * - unsigned char dummy = 0x00
 * - unsigned char flags (!= 0)
 * - std::vector<CTxIn> vin
 * - std::vector<CTxOut> vout
 * - if (flags & 1):
 *   - CTxWitness wit;
 * - uint32_t nLockTime
 */

In other words, before the txin count, there is a 0x00 0x01 sequence (which would otherwise be interpreted as a transaction with 0 inputs and 1 output, which cannot be valid), and before the locktime there is a witness record for each input (the txin count is not repeated, it's implicitly assumed to be equal to the txin count given before).


How can the number of peers from the same IP address be counted?

That monitoring page states that it counts hosts from 'addr' messages seen on the bitcoin network.

An 'addr' message contains the IP number & port number of a bitcoin client. Since all bitcoin clients use the same listening port number the IP number is the only information to count by.

When a bitcoin client connects to a peer it does send out an extra number to identify it by. However there is no friendly way to force all clients behind an IP number to connect to you so you cannot capture that number for all those clients.


Is wallet.dat linked to the blockchain file?

From what I know, yes. The wallet and the blockchain data exist independently from one another. The wallet file keeps track of all transactions relevant to itself that appeared in the blockchain, as well as information about the latest block it has seen. If you use an old wallet on a newer blockchain, the client should scan any blocks that came after the waller's last synchronisation and update the information accordingly.

If you need Bitcoins urgently, you might want to use an eWallet until your client synchronises. Those are ready to run in seconds.


What happens when the sent amount doesn't match the payment request exactly?

There are no rules.

Once you share an address with someone, they can send arbitrary amounts of bitcoin to that address.  They can also send further transactions to that address any time in the future.  There is no way to reject a transaction just because you don't like the amount or for any other reason; if the transaction spends valid coins and is properly signed, it's valid and is irreversible once confirmed.

The various schemes for requesting a payment (bitcoin: URI, QR code, BIP 70) do include a requested amount, but it is nothing more than a request.  Most client software handles it by pre-filling the amount field in their "send coins" dialog, but typically the user can just change the amount if they want to.  They could also just extract the address from the payment request and send whatever they want to it.

It is up to you to decide what to do if you receive a different amount than you expected.  As far as the Bitcoin protocol is concerned, the money is just yours to keep or to spend as you please.

In a typical commerce platform, you would have had the user log in to make a purchase, and you would generate a unique address for them.  So if the user sends a different amount than you requested, you would know to contact that user and ask them to send more money or to provide refund instructions.  But that is outside the scope of Bitcoin itself.

You can try to create a new transaction that sends the coins back to the address(es) that sent them, but this has some pitfalls.  In some cases the sender may not have access to that address anymore.  You will also have to pay a transaction fee for this new transaction (or manually deduct it from the amount).  The BIP 70 payment protocol contains a "refund address" feature that makes this a bit more reliable; but this is optional. The sender can still send coins to your address without providing a refund address, if they choose.


As you said, AlphaGo is "just" a collection of CPU's and GPU's. CPU's can mine at a few dozen megahashes (millions of hashes) per second. GPU's can mine at several dozen gigahashes (billions of hashes) per second. ASIC miners mine at several terahashes (trillions of hashes) per second. So a miner is a 100 to a 1000 times better/faster than a GPU which is a 100 or a 1000 times better/faster than a CPU.

So mining with AlphaGo would be insignificant. You would be better off with even one ASIC miner. If mining with CPU and GPU farms was profitable, people wouldn't bother with ASIC's.


What are some of the things that would make bitcoin better and more accepted?

Adoption is limited because of a chicken and egg program. People don't accept bitcoins because nobody else accepts bitcoins.

Normally, the way you solve a chicken and egg problem is to get the cycle going by finding a niche in which the technology works so much better than other available solutions that adoption is possible even without a critical mass -- that is, by finding a killer app. The problem with bitcoin getting started through these kinds of mechanisms is the lack of stability in the price of bitcoin relative to national currencies.

For a while, speculation and investment were the killer apps that were driving bitcoin. The problem is that if this is the driving force behind a commodity, there will inevitably be bubbles and crashes. These drive down the use of bitcoin as a medium of exchange. The adoption cycle only works if the killer app drives widespread adoption, it fails if the killer app works against it.

So that's where we're stuck. But there are a lot of really smart people working on the problem. They're working on getting ATM machines to sell bitcoins, adding the ability to accept bitcoins into widespread point-of-sale systems, solving the problem of having to wait for confirmations, and so on.


Actually if he has the password he can use brute Force attack and gain access to the wallet if that didn't slove the problem he should use bip39-standalone input his passphrase get the key and import to another wallet


Do you have to be a node to use the Lightning Network

Yes.  In order to be a part of a network, you need to be a part of the network.  This is the same as with Bitcoin...or even the internet in general.

However, it is perfectly possible for someone to run a node on your behalf.  This is the same as how a web wallet operates.  Some service runs one (or multiple) nodes on the Bitcoin network, and then provides you with a web interface and an account such that you can interact with the network without running your own node.  This is similar in concept to printing out your grandmother's email for her to read without requiring her to touch a computer.  Yes, she can still send and receive email, but with someone else operating the network node.


Make sure you backup your files before doing this!!

This might be late, but you need to replace the following files in your system.

p2pstate.bin
blockchainindices.dat
blockindexes.dat
blocks.dat
blockscache.dat

MacOS: ~/.digitalnote

Linux: /home/Your username/.digitalnote

Windows: C/Windows/Users/Your username/AppData/Roaming/digitalnote

Here is a video on how to do it for MacOS: https://www.youtube.com/watch?v=_QCeQxsZxus


How output transaction works in Bitcoin?

So what will happen if an output of 1 BTC is available for me to spend, but I want to spend 10 BTC?

If you have 1 USD in your pocket and you want to buy something for 10 USD, you simply can't.

The cited section is equal to: If you have 10 USD and want to buy something for 1 USD the merchant gets 1 USD and you get 9 USD in change.


Does pruning affect a node's security or consensus ability?

Full nodes derive their security from enforcing all of the rules of Bitcoin self-sufficiently on any data they receive, and by validating the complete blockchain from the genesis block to the chain tip. This does not require keeping the data after validating it. Pruning nodes have the same security that archival nodes have. Since following Bitcoin's rules is sufficient to converge to the chain-tip, pruning nodes have full consensus capability.
The only difference is that pruning nodes cannot serve the blocks that they have pruned, and if a pruning node requires a -reindex for any reason, it will need to repeat the full Initial Block Download (IBD).


How to listsinceblock mempool transactions?

Currently there is no way to get this information. However Bitcoin Core does track this information (at least the block height at the time the transaction entered its mempool) so it should be possible to make such a command.

Note that listsinceblock is a wallet RPC so it cannot also work on the mempool due to the separation between the node and wallet that we are trying to make.


Can miners be paid transaction fees even if they don't solve the current block?

Generally, the point of a mining pool is that everyone gets a portion of the mining profit (in proportion to how much hash power they contribute relative to everyone else) regardless of whether their own miner found the correct block or not.

This is so that small miners can make a more consistent and predictable revenue. If they mined by themselves, their chance of finding a block is very low, resulting in an unpredictable revenue stream where the vast majority of the time they would make no revenue.


Does Electrum use Bitcore Apis as it's backend?

Electrum uses the electrum-server backend (electrumx is a newer variant)

In fact, electrum actually predates bitcore by about 2 years.

As to why there are multiple implementations of similar APIs and softwares, the answer is really "Why node?". Even the bitcoin node software has multiple implementations (Bitcoin Core and btcd, for instance).

This is a very open source friendly space, and it is generally actively encouraged to have multiple approaches to a problem.


how does one map a transaction number to a block with just the bitcoind client?

figured it out after finding my own previous post about how I found out this info with americancoind, coin seems to have gone to a duplicate address, by its error message on attempting to resend the raw transaction. but bitcoind doesn't tell you what block it's in, merely stating error: {"code":-5,"message":"transaction already in block chain"}. however, on searching through the source (rpcrawtransaction.cpp) I noticed that getrawtransaction takes an extra arg, verbose, which if greater than 0 gives the blockhash:

jcomeau@aspire:~/rentacoder/jcomeau/bitcoin/src$ bitcoind getrawtransaction 3dd264f603f75871c5a36b61db8e137d8cee6b019a8d5bdfdabd7383ccc47068 1 | grep block
    "blockhash" : "000000000000000116f3abab7d0f620f620eae189de29ddb06fe8baae566467a",
    "blocktime" : 1393013064

and with the blockhash you can use getblock:

jcomeau@aspire:~/rentacoder/jcomeau/bitcoin/src$ bitcoind getblock 000000000000000116f3abab7d0f620f620eae189de29ddb06fe8baae566467a
{
    "hash" : "000000000000000116f3abab7d0f620f620eae189de29ddb06fe8baae566467a",
    "confirmations" : 255,
    "size" : 341358,
    "height" : 287092,
    "version" : 2,
    "merkleroot" : "d0fd6154ba64682b48c9c15600ee7c8594336cf4c0a2917b5cbcf1f5a74d2096",

so, 287092 is the block number that contains the transaction.


Is EFF's proposed Sovereign Key system similar to how Namecoin/Bitcoin works?

No.  Sovereign keys are simply a technical mechanism to use the DNSSEC trust anchors instead of companies like Verisign.  Trust is still centralized; it's just centralized in a different place.


Raw Transaction Fee - 256: absurdly-high-fee error

The fee is calculated from the difference between vin and vout. Here you are sending a very small amount to an addresses but you have not specified an output to receive the change. The client sees this change as the fee which is probably very large.

You need to create a separate vout to send the change from the transaction, leaving a small amount for the fee.


What block had the most transaction fees? Why?

I am not sure which block it is, but you can see it on this graph from blockchain.info. It was ~305 BTCs in transaction fees. The blockchain will not tell you why the transaction fees are so high. It is probably an accident or a joke.

I believe the largest size a block can be is measured in terms of bytes, and it is 1MB. So the largest transaction can be as large as 1MB of data will let it be.


How is the exchange rate for Bitcoin established?

You have people that have BTC or currency already in their accounts.
Those people can claim: "I will buy/sell X amount of Bitcoins for Y amount of currency". If you divide one by the other, you have the exchange rate for that particular transaction.
If a buy and sell transaction overlap, they are executed and removed from the system.
After all such transactions are removed, you have a gap between the exchange rate at which people want to buy Bitcoins, and that at which people want to sell Bitcoins.
Average the closest buy-sell pair of transactions and you have the exchange rate, halfway between those two, or the price of the last trade may be used. In both cases, it's only an estimate of the price that the next trade will take place at.


Almost all of the drawbacks of using bitcoin over Tor revolve around the fact that your node can't trust that it isn't segmented from the network and thus can't truly verify the state of the network it sees is real. So if you ran two bitcoin nodes (both with the same privkey), one on the clearnet just to have an accurate view of the network and the other over Tor, which you use to send transactions, the worst that could happen is that the Tor exit node doesn't relay your transaction to the network. Since most (all?) bitcoin IP tracing schemes trace you by monitoring your sent transactions, you would be as safe. (Or as safe as Tor is normally.)

Since bitcoin clients always use the same nodes, the Tor bitcoin client should never be connected over the clearnet, as that would at least allow it to be determined that you had also used the same client over Tor.

However, this isn't a solution if you just want to run a node secretly. This method is a way to secretly send transactions, but the monitoring node on the clearnet is obviously not secret.


Would an optimization proof-of-work problem where the entity with the lowest hash wins have any security weakness or other disadvantage?

You're not thinking like an attacker yet. ;)

Beside this incentivizing selfish mining, a miner can do the following attack:
Mallory sends all her funds to herself every block.
As soon as she finds a block with a very low hash, she can execute the following attack: Make a payment to someone that accepts first confirmation with a substantial fee ensuring it will be in the next block. Wait for the next block. Receive the counterside of the deal (e.g. coins on another chain). Publish their block and laugh.


Assuming your script is called btce_ticker.sh, the following line would do it:

while true; do btce_ticker.sh; sleep 3600; done

The sleep 3600 sleeps for an hour before looping around and running the script again.


Was the time warp attack the only reason it was not safe to compare chains by length?

If the time warp bug was fixed in bitcoin, would comparing chains by length always produce the same result as comparing by work done?

No.  It's easy to create a chain with more chainwork but fewer blocks.  For example, lets say we have a chain with 2,016 difficulty 1 blocks.  This chain is created in 20,160 minutes so the difficulty doesn't change next period, meaning that by block 4,032 we have 4032diff chainwork:

  2016 *  diff1 == 2016diff
+ 2016 *  diff1 == 2016diff
--------------------------
  4032 blocks with 4032diff

Then somebody mines an alternative chain with mining equipment that's 4 times faster, producing the first 2,016 blocks in 5,040 minutes.  Difficulty increases to 4 and by block 2,521 this chain has more chain work but less blocks than the first-described chain.

  2016 *  diff1 == 2016diff
+  505 *  diff4 == 2020diff
--------------------------
  2521 blocks with 4036diff

I assume you're more interested in practical attacks against Bitcoin's mainnet chain if that chain still used longest-is-best logic.  Here's an easy one:

The Genesis Block is dated 3 January 2009.  If you mined only difficulty 1 blocks from then until now (144 blocks a day), you'd have about (144*365*6)+(30*144)==319680 blocks.
The "real" block chain has 342,908 blocks, a 23,228 block difference.
Because difficulty can only increase 4x in a single 2,016-block period, mining 23,228 blocks would only requiring going from difficulty 1 to difficulty 4**(23228 / 2016) == 4194304.
Although difficulty 4,194,304 sounds high.  Current mainnet difficulty is 44,455,415,962.  So, if I did my math right, you can create a chain longer than mainnet with roughly 0.001% of the current network hashrate.


Is it possible to use Selfish Mining to steal bitcoins?

Selfish Mining cannot be used to change transactions in any way, therefore, it is impossible to steal funds in such fashion.

Also, Selfish Mining is somewhat the opposite of Double-Spending, as double-spending would require you to publish your own blocks as quickly as possible in order to overtake the network, while selfish mining is based on keeping blocks private as long as possible.

Since successful selfish mining makes another already found block obsolete, one might argue, that the Selfish Miner steals money from the miners that found the obsoleted block. However, in order to perform Selfish Mining, a new block has to be found in the first place, so the mining reward would have been the selfish miners anyway, if he had published his block right away.

Lastly, selfish mining forces the network to continue wasting their cycles on an already outdated block height. Yet, while their effort is wasted in a successful selfish mining attempt, this may better be described as obstruction than as theft.

Altogether, I can't think of a way that selfish mining would be used to perform anything that might be labeled Theft.


There's no perfect answer for this question and it depends on individual.
You had used address A (one of the outputs) in a transaction 1 where inputs are from X.
You used the address A (one of the outputs) again in a transaction 2 where inputs are from Exchange Y.
IF someone is trying to analyze transaction 1 to know the owner of address A, he can look at transaction 2 to assume owner has an account on Exchange Y. Most of the withdrawal transactions from exchanges are done in batches with lots of inputs and outputs involved so it won't be easier to know more information about the owner except if one of the below tries to investigate:
Exchange, chain analysis companies, government agencies (in case of centralized exchanges) etc.
You have two options in my opinion:

Ignore and avoid reuse in future
Coinjoin


Is there an efficient way to exploit arbitrages between the different exchanges?

Yes.  Simply hold accounts on multiple exchanges.  In the account you should try to keep your holdings at 50% bitcoin and 50% other currency.

When there is an arbitrage opportunity you can execute "complimentary" transactions on both exchanges.  On one you buy the difference, and the other you sell the difference.  You can then equalize the accounts by transferring bitcoins between them, or withdrawing profits.  Don't forget to account for transaction fees on each exchange.

If you are so skilled most exchanges have APIs that would allow you to script interfaces for doing this automatically.  I recommend against accepting other people's scripts to do this since it gives the script access to your funds and it would be trivial for them to write the script to transfer your funds to them.


In your install directory, you should have armoryd.py.  Once you run

python armoryd.py

then you have a daemon.  Now you can run

python armoryd.py help

to get a list of commands like this (which can then be run with python armoryd.py <command>):

{
"backupwallet": {
    "Description": "Back up the current wallet to a file at a given location. The backup will occur only if the file does not exist yet.",
    "Parameters": [
        "backupFilePath - Path to the location where the backup will be saved."
    ],
    "Return Value": "A dictionary indicating whether or not the backup succeeded or failed, with the reason for failure given if applicable."
},
"clearaddressmetadata": {
    "Description": "Clear all armoryd-specific metadata for the currently loaded wallet.",
    "Parameters": [
        "None"
    ],
    "Return Value": "None"
},
"createlockbox": {
    "Description": "Create an m-of-n lockbox associated with wallets loaded onto the armoryd server.",
    "Parameters": [
        "numM - The number of signatures required to spend lockbox funds.",
        "numN - The total number of signatures associated with a lockbox.",
        "args - The wallets or public keys associated with a lockbox, the total of which must match <numN> in number. The wallets are represented by their Base58 IDs. The keys must be uncompressed."
    ],
    "Return Value": "A dictionary with information about the new lockbox."
},
"createustxformany": {
    "Description": "Create an unsigned transaction to be sent to multiple recipients from the currently loaded wallet.",
    "Parameters": [
        "args - An indefinite number of comma-separated sets of recipients and the number of Bitcoins to send to the recipients. The recipients can be an address, a P2SH script address, a lockbox (e.g., \"Lockbox[83jcAqz9]\" or \"Lockbox[Bare:83jcAqz9]\"), or a public key (compressed or uncompressed) string."
    ],
    "Return Value": "An ASCII-formatted unsigned transaction, similar to the one output by Armory for offline signing."
},
"createustxtoaddress": {
    "Description": "Create an unsigned transaction to be sent to one recipient from the currently loaded wallet.",
    "Parameters": [
        "recAddr - The recipient. This can be an address, a P2SH script address, a lockbox (e.g., \"Lockbox[83jcAqz9]\" or \"Lockbox[Bare:83jcAqz9]\"), or a public key (compressed or uncompressed) string.",
        "amount - The number of Bitcoins to send to the recipient."
    ],
    "Return Value": "An ASCII-formatted unsigned transaction, similar to the one output by Armory for offline signing."
},
"decoderawtransaction": {
    "Description": "Decode a raw transaction hex string.",
    "Parameters": [
        "hexString - A string representing, in hex form, a raw transaction."
    ],
    "Return Value": "A dictionary containing the decoded transaction's information."
},
"dumpprivkey": {
    "Description": "Dump the private key for a given Base58 address associated with the currently loaded wallet.",
    "Parameters": [
        "addr58 - A Base58 public address associated with the current wallet."
    ],
    "Return Value": "The 32 byte binary private key."
},
"encryptwallet": {
    "Description": "Encrypt a wallet with a given passphrase.",
    "Parameters": [
        "passphrase - The wallet's new passphrase."
    ],
    "Return Value": "A string indicating that the encryption was successful."
},
"getactivelockbox": {
    "Description": "Get the lockbox ID of the currently active lockbox.",
    "Parameters": [
        "None"
    ],
    "Return Value": "The Base58 ID for the currently active lockbox."
},
"getactivewallet": {
    "Description": "Get the wallet ID of the currently active wallet.",
    "Parameters": [
        "None"
    ],
    "Return Value": "The Base58 ID for the currently active wallet."
},
"getaddrbalance": {
    "Description": "Get the balance of a Base58 address associated with the currently loaded wallet.",
    "Parameters": [
        "inB58 - The Base58 address associated with the current wallet.",
        "baltype - (Default=spendable) A string indicating the balance type to retrieve from the current wallet."
    ],
    "Return Value": "The current wallet balance (BTC), or -1 if an error occurred."
},
"getaddressmetadata": {
    "Description": "Get all armoryd-specific metadata for the currently loaded wallet.",
    "Parameters": [
        "None"
    ],
    "Return Value": "A dictionary with all metadata sent to armoryd."
},
"getarmorydinfo": {
    "Description": "Get information on the version of armoryd running on the server.",
    "Parameters": [
        "None"
    ],
    "Return Value": "A dictionary listing version of armoryd running on the server."
},
"getbalance": {
    "Description": "Get the balance of the currently loaded wallet.",
    "Parameters": [
        "baltype - (Default=spendable) A string indicating the balance type to retrieve from the current wallet."
    ],
    "Return Value": "The current wallet balance (BTC), or -1 if an error occurred."
},
"getblock": {
    "Description": "Get the block associated with a given block hash.",
    "Parameters": [
        "blkhash - A hex string representing the block to obtain."
    ],
    "Return Value": "A dictionary listing information on the desired block, or empty if the block wasn't found."
},
"gethextxtobroadcast": {
    "Description": "Get a signed Tx from a file and get the raw hex data to broadcast.",
    "Parameters": [
        "txASCIIFile - The path to a file with an signed transacion."
    ],
    "Return Value": "A hex string of the raw transaction data to be transmitted."
},
"getledger": {
    "Error": "The function description is malformed."
},
"getledgersimple": {
    "Description": "Get a simple version of a wallet or lockbox ledger.",
    "Parameters": [
        "inB58ID - The Base58 ID of the wallet or lockbox from which to obtain the ledger. The wallet or lockbox must already be loaded.",
        "tx_count - (Default=10) The number of entries to get.",
        "from_tx - (Default=0) The first entry to get."
    ],
    "Return Value": "A dictionary with a wallet ledger of type \"simple\"."
},
"getlockboxinfo": {
    "Description": "Get information on the lockbox associated with a lockbox ID string or, if it exists, the currently active armoryd lockbox.",
    "Parameters": [
        "inLBID - (Default=None) If used, armoryd will get information on the lockbox with the provided Base58 ID instead of the currently active armoryd lockbox.",
        "outForm - (Default=JSON) If used, armoryd will return the lockbox in a particular format. Choices are \"JSON\", \"Hex\", and \"Base64\"."
    ],
    "Return Value": "If the lockbox is found, a dictionary with information on the lockbox will be returned."
},
"getnewaddress": {
    "Description": "Get a new Base58 address from the currently loaded wallet.",
    "Parameters": [
        "None"
    ],
    "Return Value": "The wallet's next unused public address in Base58 form."
},
"getrawtransaction": {
    "Description": "Get the raw transaction string for a given transaction hash.",
    "Parameters": [
        "txHash - A string representing the hex value of a transaction ID.",
        "verbose - (Default=0) Integer indicating whether or not the result should be more verbose.",
        "endianness - (Default=BIGENDIAN) Indicates the endianness of the ID."
    ],
    "Return Value": "A dictionary with the decoded raw transaction and relevant information."
},
"getreceivedbyaddress": {
    "Description": "Get the number of coins received by a Base58 address associated with the currently loaded wallet.",
    "Parameters": [
        "address - The Base58 address associated with the current wallet."
    ],
    "Return Value": "The balance received from the incoming address (BTC)."
},
"gettransaction": {
    "Description": "Get the transaction associated with a given transaction hash.",
    "Parameters": [
        "txHash - A hex string representing the block to obtain."
    ],
    "Return Value": "A dictionary listing information on the desired transaction, or empty if the transaction wasn't found."
},
"gettxout": {
    "Description": "Get the TxOut entries for a given transaction hash.",
    "Parameters": [
        "txHash - A string representing the hex value of a transaction ID.",
        "n - The TxOut index to obtain.",
        "binary - (Default=0) Indicates whether or not the resultant binary script should be in binary form or converted to a hex string."
    ],
    "Return Value": "A dictionary with the Bitcoin amount for the TxOut and the TxOut script in hex string form (default) or binary form."
},
"getwalletinfo": {
    "Description": "Get information on the currently loaded wallet.",
    "Parameters": [
        "inWltID - (Default=None) If used, armoryd will get info for the wallet for the provided Base58 wallet ID instead of the current wallet."
    ],
    "Return Value": "A dictionary with information on the current wallet."
},
"help": {
    "Description": "Get a directionary with all functions the armoryd server can run.",
    "Parameters": [
        "None"
    ],
    "Return Value": "A dictionary with all functions available on the armoryd server, along with the function parameters and function return value."
},
"importprivkey": {
    "Description": "Import a private key into the current wallet.",
    "Parameters": [
        "privKey - A private key in any format supported by Armory, including Base58 private keys supported by bitcoind (uncompressed public key support only)."
    ],
    "Return Value": "A string of the private key's accompanying hexadecimal public key."
},
"listaddrunspent": {
    "Description": "Get a list of unspent transactions for the currently loaded wallet that are associated with a given, comma-separated list of Base58 addresses from the wallet. By default, zero-conf UTXOs are included.",
    "Parameters": [
        "inB58 - The Base58 address to check against the current wallet."
    ],
    "Return Value": "A dictionary containing all UTXOs for the currently loaded wallet associated with the given Base58 address, along with information about each UTXO."
},
"listloadedlockboxes": {
    "Description": "List all lockboxes loaded onto the armoryd server.",
    "Parameters": [
        "None"
    ],
    "Return Value": "A dictionary with the Base58 values of all lockboxes loaded in armoryd."
},
"listloadedwallets": {
    "Description": "List all wallets loaded onto the armoryd server.",
    "Parameters": [
        "None"
    ],
    "Return Value": "A dictionary with the Base58 values of all wallets loaded in armoryd."
},
"listtransactions": {
    "Description": "List the transactions associated with the currently loaded wallet.",
    "Parameters": [
        "tx_count - (Default=10) The number of entries to get.",
        "from_tx - (Default=0) The first entry to get."
    ],
    "Return Value": "A dictionary with information on the retrieved transactions."
},
"listunspent": {
    "Description": "Get a list of unspent transactions for the currently loaded wallet. By default, zero-conf UTXOs are included.",
    "Parameters": [
        "None"
    ],
    "Return Value": "A dictionary listing information about each UTXO in the currently loaded wallet. The dictionary is similar to the one returned by the bitcoind call of the same name."
},
"receivedfromaddress": {
    "Description": "Return the number of coins received from a particular sender.",
    "Parameters": [
        "sender - Base58 address of the sender to the current wallet."
    ],
    "Return Value": "Number of Bitcoins sent by the sender to the current wallet."
},
"receivedfromsigner": {
    "Description": "Verify that a message (RFC 2440: clearsign or Base64) has been signed by a Bitcoin address and get the amount of coins sent to the current wallet by the message's signer.",
    "Parameters": [
        "sigBlock - Message with the RFC 2440 message to be verified. The message must be enclosed in quotation marks."
    ],
    "Return Value": "A dictionary with verified message and the amount of money sent to the current wallet by the signer."
},
"relockwallet": {
    "Description": "Re-lock a wallet.",
    "Parameters": [
        "None"
    ],
    "Return Value": "A string indicating whether or not the wallet is locked."
},
"sendlockbox": {
    "Description": "E-mail ASCII-encoded lockboxes to recipients.",
    "Parameters": [
        "lbIDs - A colon-delineated list of Base58 IDs of lockboxes to send to an email recipient.",
        "sender - The email address of the sender.",
        "server - The SMTP email server.",
        "pwd - The email account password.",
        "recips - The recipient or, if the string is delineated by a colon, a list of recipients.",
        "msgSubj - (Default=Armory Lockbox) The email subject."
    ],
    "Return Value": "A string indicating whether or not the attempt to send was successful."
},
"setactivelockbox": {
    "Description": "Set the currently active lockbox to one already loaded on the armoryd server.",
    "Parameters": [
        "newIDB58 - The Base58 ID of the lockbox to be made active."
    ],
    "Return Value": "A string indicating whether or not the lockbox was set as desired."
},
"setactivewallet": {
    "Description": "Set the currently active wallet to one already loaded on the armoryd server.",
    "Parameters": [
        "newIDB58 - The Base58 ID of the wallet to be made active."
    ],
    "Return Value": "A string indicating whether or not the wallet was set as desired."
},
"setaddressmetadata": {
    "Description": "Set armoryd-specific metadata associated with Base58 addresses.",
    "Parameters": [
        "newAddressMetaData - A dictionary containing arbitrary metadata to attach to Base58 addresses listed with the metadata."
    ],
    "Return Value": "None"
},
"signasciitransaction": {
    "Description": "Sign an unsigned transaction and get the signed ASCII data.",
    "Parameters": [
        "unsignedTxASCII - An ASCII-formatted unsigned transaction, like the one used by Armory for offline transactions.",
        "wltPasswd - (Default=None) If needed, the current wallet's password."
    ],
    "Return Value": "A dictionary containing a string with the ASCII-formatted signed transaction or, if the signing failed, a string indicating failure."
},
"unlockwallet": {
    "Description": "Unlock a wallet with a given passphrase and unlock time length.",
    "Parameters": [
        "passphrase - The wallet's current passphrase.",
        "timeout - (Default=10) The time, in seconds, that the wallet will be unlocked."
    ],
    "Return Value": "A string indicating if the wallet was unlocked or if it was already unlocked."
},
"verifysignature": {
    "Description": "Take a message (RFC 2440: clearsign or Base64) signed by a Bitcoin address and verify the message.",
    "Parameters": [
        "sigBlock - Message with the RFC 2440 message to be verified. The message must be enclosed in quotation marks."
    ],
    "Return Value": "A dictionary with verified message and the Base58 address of the signer."
},
"watchwallet": {
    "Description": "Send an e-mail notification when the current wallet spends money.",
    "Parameters": [
        "send_from - The email address of the sender.",
        "smtpServer - (Default=None) The SMTP email server.",
        "password - (Default=None) The email account password.",
        "send_to - (Default=None) The recipient or, if the string is delineated by a colon, a list of recipients.",
        "subject - (Default=None) The email subject.",
        "watchCmd - (Default=add) A string indicating if emails from the sender should be sent or, if set to \"remove\", emails from the sender that are currently being sent should be stopped."
    ],
    "Return Value": "None"
}
}

Source: armoryd.README in the install folder


It seems you're having technical issues with the app. I would recommend to bring this issue to the devs on their forum: https://gitter.im/ACINQ/eclair. Also, please prepare to have all info such as the version of the app, your OS, mainnet or testnet.


Can someone explain this double spend on blockchain.info?

Nothing malicious.  Two blocks were mined at the same time by different miners (Block 267647).  Both blocks included the transaction and both were broadcast to the network.  Both blocks show up in the block chain because you don't know who actually won until additional blocks are mined and added to one chain or the other.  The chain with the greatest amount of work done on it becomes the main chain and the other one gets orphaned.

This is why you need to wait for several confirmations before spending an output.  If you spent it as soon as you saw one of the blocks, your transaction could get rejected later on if the other block ended up winning.

You can tell this is what happened because the transaction ID is the same in both blocks.  In a double-spend, you would have two separate transactions attempting to spend the same transaction output.


Installed 2nd Bitcoin client and invalidated blockchain progress

BU might have changed their default installation directory, but I doubt it. Then it sounds to me that you were running two copies of Bitcoin software working with the same blockchain data. Even when not running them at the same time, I'm not surprised that this might corrupt the block data. (If you've run them at the same time, no wonder at all, although I thought there was a lock in place to prohibit that.)

Don't run more than one Bitcoin software from the same directory.
Pick whatever flavor you may choose to run, install a current version of that.
Wait until synchronization is finished. Later blocks take longer than earlier blocks due to more content.


How does the blockchain.info shared receive work?

The Shared Recieve is also a mixer. When you get a new shared address, it will also show the "Forward To" address which will be one of your main addresses. If anyone sends bitcoins to that shared address, Blockchain.info will send them through its mixer then send it to the "Forward To" address. However, there are transactions costs and blockchain.info's 1.5% fee. It's meant for bigger amounts.


Abandoned transaction with low fee and now can't get any transactions to confirm

I'm not an expert, but have you tried setting the transaction to "abandoned" ?
Also disabling the wallet broadcasting in the meanwhile?

You can check this two links on how to recover a wrong transaction and how to do a proper full rbf

https://en.bitcoin.it/wiki/Fee_bumping#I_sent_the_stuck_transaction

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

( i am aware that by this time either the transaction is forgotten or confirmed  but there would be more people that needs this answer (in fact that's how i got here))


How do I restore a Lightning Node with active channels that has crashed causing data loss? Is it similar to restoring a Bitcoin wallet?

Unlike bitcoin stored in an on-chain wallet, funds in the lightning network are stateful. Some channel data cannot be deterministically reconstructed like keys derived from a BIP32 seed. If you do not have backups and your channel counterparty is non-responsive, you will likely experience permanent loss of funds. Make sure to have backups of your channel data made with each additional transaction you send/receive/route to other nodes in the network.

If a node falls down and loses critical state data it is important not to broadcast commitment transactions from old backups. If these commitment transactions have been revoked, the channel counterparty will submit a justice transaction to the network and claim all of the funds in the channel.

This failure scenario can be partially mitigated by nodes that use option_data_loss_protect as specified in BOLT 2. This allows a node to detect that it has fallen behind when reestablishing its connection. This only works when both nodes support this feature and the node that has not fallen behind is honest. If the honest node detects its counterparty has fallen out of sync, it should unilaterally close the channel and the fallen-behind node can then reclaim its funds with data it received on connection reestablishment (my_current_commitment_point).

In the future, state backups can be outsourced to 3rd parties on-the-fly, such that if a node falls down it can call on these 3rd parties to provide the necessary data for channel reconstruction. It has been proposed that Watchtowers - nodes that can be compensated to monitor channels for bad behavior - could also be tasked with storing encrypted state backups.

If you do have a backup you can restore it and reestablish connections with your peers and get back to business!


Why is wallet.dat BerkeleyDB instead of LevelDB?

BerkeleyDB support  ACID (Atomicity, Consistency, Isolation, Durability). Leveldb no ACID, I think this is the main reason using BerkeleyDB.


How to determine what type of coins a wallet.dat contains?

Here's one way I found.

Get pywallet (https://github.com/jackjack-jj/pywallet) and run

python pywallet.py --dumpwallet --wallet=/foo/bar/wallet.dat

Look in the output for a field called names.  This will contain a list of addresses in the coin's own format, and by looking at the first character you can try to identify the coin by its version byte.  See here for a list of some common ones.  For example, 1 is Bitcoin, L is Litecoin, etc.

Note that you will see a number of other fields named defaultkey, addr, etc.  These will appear to be in Bitcoin address format (starting with 1), no matter what the actual coin is.  The reason is that for these keys, the wallet.dat file only contains the private key, and pywallet has to do the conversion to the public key and address.  In  particular, pywallet has to fill in the version byte, and it always picks the Bitcoin version byte unless told otherwise on the command line.  So you always get a Bitcoin-style address in these fields, so for purposes of identifying the coin, you should ignore them.


bitcoin testnet is mining about 50 blocks per minute right now - why?

There is an adjustment for the testnet when a block takes 20 minutes or longer to mine, it will adjust the difficulty down to 1. This was caused presumably because of the difference between blocktimes of 1356765 and 1356766 because block 1356767 was reset to 1.

Every 2016 blocks, the difficulty is adjusted, but it can only be increased by a factor of 4 each time.

pow.cpp as of version 0.16.2

// Special difficulty rule for testnet:
// If the new block's timestamp is more than 2* 10 minutes
// then allow mining of a min-difficulty block.
if (pblock->GetBlockTime() > pindexLast->GetBlockTime() + params.nPowTargetSpacing*2)
    return nProofOfWorkLimit;


Creating address from private key (bitcoin puzzle)

Don't mix priv with pub keys. You're on the right track. Usually keys with length of 52 bytes beginning with "K" are the privkeys. Keys with "1" at the beginning would be the public keys, derived from the privkey.
So e.g. the private key "KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU7hDgvu64y" results in public key "1McVt1vMtCC7yn5b9wgX1833yCcLXzueeC".
A good playground for keys is here http://gobittest.appspot.com/Address and here https://www.bitaddress.org - warning: never use your own production private keys on such public tools, they might get stolen.


How does market cap of currency decrease?

The market cap is the product of the total currency supply and its instant exchange rate. If either the exchange or supply goes down, the market cap does too.

The supply generally doesn't decrease, except through things like burning coins (see this answer of mine for more information). The exchange rate of course goes up and down all the time.

Market cap is generally a pointless metric, because it does not in any way reflect the cost or income of selling or buying the entire currency's supply. Only small fractions of the supply are being offered on the market, so selling or buying any significant amount will easily move the price around.

  Consider if Sathosi (the founder of bitcoin) sells all his 1 million coins

Just to be clear: how many BTC Bitcoin's creator has is speculation.


How the bitcoin network solves the double-spending problem by adding all the transactions that happened at the same time into one block

according to my understanding bitcoin network solve this issue by adding all the transactions that happened at the same time into one block of the block-chain.

This is not true.
Same time
You should remember that the Bitcoin network doesn't really try to keep accurate time. Blocks are not always in sequence by timestamp in the block. So long as they do not seem to be more than about 2 hours wrong, it will be accepted. So the notion of "happened at the same time" is ill-defined.
There is a limit to the size of a block, so it would often not be possible anyway.
Choosing transactions
Miners choose transactions for incorporation into a block. They choose transactions from a pool of unconfirmed transactions they have received. This pool is called the mempool.
Which transactions miners choose is entirely up to them. They could choose on the basis of highest fees that the transactions will pay to the miner. They might choose on any other basis that their operator feels makes sense for them.
What might be causing some confusion is that if an unconfirmed transaction B spends the output of another unconfirmed transaction A, I believe miners will find it necessary to include A in any block that contains B.
Double spending
A miner cannot include in one block two transactions that spend the same input. Such a block would be rejected by everyone else.
If a miner includes in a block a transaction that spends an output already spent by a transaction in an earlier block, the later block will be rejected by other nodes. So miners don't do this if they can avoid it.


How can I verify my merkle root function is correct?

Most likely, you have some endian-ness issues. Remember that the merkle root published is in little-endian and so are the transaction hashes. You'll have to reverse them and then calculate merkle calculations.

You can take a look at the details of a block with the tx hashes here:

https://webbtc.com/block/00000000000000000375c25e5af8f3b2310585ad6a7c264d66398018ce4c6a41.json

There's a very helpful key in that json payload called "mrkl_tree" which tells you all nodes of the merkle tree (so the parent of two adjacent leaf nodes is in that set). It's probably easiest to build tests around that.


MultibitHD is No Longer Supported (transfer funds without fee)

Check the average transaction fee on the blockchain right now, and then look for your transaction on blockchain.info. If your mining fee is significantly lower that average, it will be stuck there for a long time. Eventually your transaction priority will be pushed higher, but there's a backlog of unconfirmed transaction overloading the blockchain right now. If your fee was too low, it will eventually reject the transaction and it will come back to your wallet. You can't do much at the moment right now when your transaction is in a hanging state.


Yes. You can get the public key, chaincode, and address for any derivation path.

If you use the btchip-python library, you can use the getWalletPublicKey() method to retrieve a dictionary containing all three of those things.


Kraken also known as Payward Ventures Inc is currently registered as a Money Service Business in every single state in the US.

As far as I can tell however they will still not do business for the 2nd 3rd or 4th tier verifications in any state. I have no idea why this is.


The simplest way is to not reuse addresses, something that wallets do by default anyways. Every time you want to receive Bitcoin, get a new address from your wallet and give that to whoever is sending you Bitcoin. You typically do this by going to the "Receive" page or tab in your wallet and clicking "Receive Bitcoin" (or similar). By doing so, the sender will not know how much money you have in your wallet and they won't be able to see all of your transactions.

When you send Bitcoin, you should also use new change addresses every time. This is the default behavior in wallets so this is not something you need to do manually or worry about.

By not reusing addresses, it is harder to link your transactions to you and it makes it more difficult for everyone you transact with (both receive and send) to know how much money you have and who you are sending money to or receiving money from.


You can check this site for average Bitcoin transaction fees
https://bitcoinfees.earn.com

133 Sat/Byte is below the average, therefore not favored by most miners.
In times like this where the network is congested with over 200000 uncomfirmed transactions, higher fees have higher probabilty of getting through first.

A block can hold at maximum 1MB / 192 bytes = about 5200 transactions, but in reality the average is less than half that number, and a block takes on average 10 minutes to solve.
Right now there are more incoming transactions per 10 minutes, than what the miners are capable of solving, hence low fees != prioritized .


FutureBlock offer and example seems to violate No Arbitrage Rule

It is a well-known observation that Bitcoin exchanges are not efficient (in the academic sense of well-approximating what you call the No Arbitrage Rule). The reason is simply that there are real world barriers that academics usually assume not to be present. If you do consider the risk associated with depositing funds at a Bitcoin exchange, there is an obvious reason why someone would demand a high return for taking such a risk. If you look e.g. at the difference in exchange rates between big exchanges (try Mtgox, Bitstamp, BTCE) you'll see that a difference as large as 10% can persist on the timescale of a year.

The risks include having the exchange hacked and leaving it unable to return your deposit (have a look at Bitfloor) or having its bank accounts frozen during legal investigations and hence unable to return your deposits during the first 6 month or so (check bitcoin-24.com). And then there's the combination of it all with (presumably) enough reserves not to shut down the operation right away (e.g. mtgox). And that's not even considering the risk that the operator is dishonest and gets tempted to defraud customers...

On top of all this, consider that even moving Bitcoins around is not instant. You run the additional risk that during the transfer time the situation changes (e.g. a crash in Bitcoin exchange rate). And the transfer time between bitcoin trading sites can be surprisingly long, since some legislation (e.g. anti money laundering) typically seems to compel them to insist on verifying your identity. This process may, depending on the site, occur in a somewhat surprising fashion, so you never know if they will instantly, or at least within the first days, allow you to continue accessing your bitcoins (or real money) that you gave them.


Possible to create 5+0$ founding transaction in Ligthning Network?

The current protocol implementations only allow one party to fund a channel.

If only one party funds the channel, then the first payments can only be sent from the funding party to the counterparty. After that, subsequent payments could go both directions (until the entire channel balance rests with one party, at that point transactions could again only flow in one direction. It is not possible to have 'debt' in a channel).


How does peer banning work for onion peers?

There's no handling of this really. The incoming connection just appears to be from localhost, bitcoind has absolutely no way of even identifying what circuit they came from. Banning them becomes a nothing or everything affair. It would be extremely unwise to act in the way that you have defined, especially given that at this time there are less than 50 connectable peers, and there's no guarantee they aren't all run by the same operator.

Realistically Bitcoin has very little defense against any meaningful denial of service attacks. It is very vulnerable to volumetric, protocol level (especially prior to the removal of BIP37), and resource exhaustion attacks by even a relatively unfunded attacker, regardless of the network being used as a transport.


copay didn't provide this information for the transaction. It can be retrieved from other APIs.


Some mining pools have a reward method for which some times are better to mine than others; normally, miners contribute to the pool equally through good and bad times, and their reward averages out to what is statistically expected.

Pool-hopping is the practice of mining in a pool only during the good times, and leaving during the bad times; by so doing, a pool-hopper can get more out of the pool than the value they contribute to it, increasing their rewards at the expense of other miners. Pool-hopping gets its name from the act of constantly hopping into and out of the pool (to either other pools or solo mining).

The most well-known form of pool-hopping is with pools using the proportional method, which is among the oldest, simplest, most widely used and most prone to hopping. By all accounts hopping in this context was first discussed in a paper from January 2011 by Nakamoto Ryo; a more accurate analysis was given shortly after in Optimal pool abuse strategy by Raulo; these results were extended in Analysis of Bitcoin Pooled Mining Reward Systems by myself.

In the proportional method, a block's reward is distributed between miners in proportion to the number of shares each of them submitted since the previous block; the reward per share is the block reward divided by the number of shares in the round. Because of this, the reward of a share submitted at any given time is affected by the number of shares already submitted since the last block; a share submitted early in the round will have a higher reward on average than a share submitted later.

It can be shown that until the number of shares in the round is 43.5% of the difficulty, a submitted share will have higher than normal reward on average; the optimal way to exploit a single proportional pool is to mine in it until this point is reached, hop to a different pool, and return when a block is found. The gain that can be achieved by following this strategy is up to 28.1%, depending on the ratio between the hashrates of hoppers and continuous miners in this pool (the more hoppers, the less they will gain). The gain can be higher if more than one proportional pool is taken advantage of (for example, 51.6% can be achieved with 2 pools).

The extra profits of hoppers come at the expense of the continuous miners. The exact loss depends on the ratio between hoppers and continuous miners; when they are equal the loss is about 17.1%, and the theoretical limit when there are only hoppers is 43.5%.

Slush's method, which scores shares based on the time they are submitted, was designed to combat pool-hopping, but is only an incomplete solution. SMPPS which strives to converge to the full value of each share in the long run can only be hopped to minimize the time until being paid in full, not to increase the expected reward.

Modern methods make sure that the reward per share depends only on the future of the pool, not its past. This way, without being able to divine future random events, any time is as good as any other to mine, so there can never be any gain or loss from hopping (with the exception of block-withholding attacks). The most popular such methods are PPS, PPLNS and DGM.

Advanced forms of pool-hopping, possible in some naive reward method implementations, include difficulty retarget hopping, tx fee hopping and hashrate fluctuation hopping.


How does Alice know she is receiving the correct address?

The problem itself is not Bitcoin-specific per se. It's a matter of being able to verify the sender of some data. Bitcoin addresses are only designed to be immune to typos (they contain a checksum), but otherwise the protocol does nothing.

One can, however, do a couple things to make sure a proper address is sent and received:

One can use a vanity address that is hard to generate and clearly is related to the situation. Using 1Bob... would not be the best choice, but 1BobEveryman..., or 1ThankYouAlice... can be better (examples chosen for clarity, normally you'd be using base 58 alphabet). Generally, if it takes more than a couple minutes to generate an address you know it either came from the original sender, or someone deliberately wanted to steal Bob's identity (by spending a lot of time beforehand generating the address).
One can try checking the history of the address in the Bitcoin Block Explorer. If the address has been used a couple times, it is less likely it will be fake. Being Eve I probably wouldn't want to use the same address for scamming people more than once, and generating a history of transactions would take some time.
One can ask Bob to provide his Bitcoin address wrapped in Bob's digital signature. The main problem with this is securing Bob's signature in the first place, which is basically the same problem as we are solving right now.
One can look for address received on the internet. A lot of people have a habit of including the Bitcoin address they use in places like forum signatures, their websites and the like.
If Alice knows Bob, they might decide on using some information only they would know to create an ECDSA keypair and use that for transmitting Bitcoins. Such information might be for example be the movie they saw when they first met, some information from the school they attended and so forth. Generally, something that they remember and would be hard to find out. Alice can use that as the private seed of the keypair, generate the public address to send the Bitcoins to, and make the transfer. Bob then would have to repeat the same process and withdraw Bitcoins on their end. The main problem with this approach is whether Bob an Alice know each other beforehand and trust themselves with handling private keys.
When all else fails, one can always meet Bob in person and get their address that way.

All in all, there are many ways to prevent a man in the middle attack in the descried scenario.


Is there a way to delete a test wallet without stopping bitcoind?

You can unload the wallet using unloadwallet and then delete the wallet file.


Since you are choosing to use network specific sections in your config file, Core requires you to have certain arguments in those sections, such as rpcport. So you need to move rpcport into a network specific section.


distinguish change address from real origindestination

There is no way to know for sure which address is which.  This is part of the reason why some clients use a new address for change, for privacy; an observer will not be sure which coins now belong to whom.

There is no public timestamp recording when an address was created.  If one of the addresses has been used before and the other has not, this might suggest that the new one is for the change; but it could also be that both outputs are going to two different people, or that the sender is sending coins to herself and both addresses are "change".


Trying to open an old wallet.dat (from ~2013)

You could try checking balance from blockchain, just click on receive and copy the address and search in blockchain.com, youll see you'll how much you got there.


Is bitcoin-gold more ASIC-resistant than Litecoin?

This appears to be old but to correct the above answer, Bitcoin Gold used to use the Equihash algorithm but recently forked to the Equihash-BTG proof of work algorithm in order to keep in line with the protocol's main objective, ASIC resistance.

As for which protocol is better? I suppose for some that is a matter of opinion but if you ask me (and the majority of the ecosystem as evidenced by the price), LTC has it all over BTG in terms of developer interest, liquidity/volume, price, propagation, potential use cases, etc.

The GPU-mining ship sailed long ago for LTC.


Any sort of entity can own a bitcoin wallet. Being a decentralized system, there are no rules in place saying what sort of persons or organizations can own bitcoins.

The simplest way to manage it would be to give the password to one or more trusted leaders of the association. This would mean that any of those leaders could spend (or steal) the funds at any time.

Another way would be to use a multi-signature address, so that some quorum (say, 4 out of 5 board members) of signatures is required. This would mean that your leaders must agree to spend (or steal) some amount of funds. You might generate this with, e.g. https://coinb.in/multisig/

You could have one of each: a "hot" wallet that anyone can spend from, for convenience, and a "cold" wallet that stores the bulk of your funds, but requires additional authorization to spend from.


How to exchange small amount of bitcoin?

The best and optimal method would be to avoid exchange since they will take their fees plus the fees taken by the miners that you gonna have to pay to send the coins to them on the blockchain, and also you gonna have to give them your personal information (KYC Know Your Costumer)

Exchanges are still the most simple, I suggest Coinbase who only require 2 euro of minimum deposit.

If you want a cheaper, savy way, more optimal and more bitcoin way of trading your bitcoin you could try local bitcoin which allow you to met other person willing to trade bitcoin in real life, or Bisq which is a decentralized exchange software.


How many MB of data does my bitcoin client have to download to be fully sync'd?

My current Bitcoin folder, May 28th 2012, is 2.16 GB. Of which maybe 60MB is data personally to me like my wallet, addresses, logs and transaction history.
So basicly you will have to download a little over 2 GB for being in sync with the network.

To answer your second question: I think yes. Bitcoin exists out of a long chain with blocks containing all the transactions that were ever made. So the longer Bitcoin lives and the more it is used, the bigger this block chain will grow and the more data every user will have to download before they can use the Bitcoin client safely.

EDIT: blockchain.info charts the pure blockchain size here: https://blockchain.info/charts/blocks-size

If this growth rate stays the same, bitcoin can get in trouble...


When update mining difficulty, Is the timespan of the past 2016 blocks approximated value?

It is impossible to know that actual timespan due to network delays, malicious miner behavior, being offline, etc. The target readjustment just uses the closest thing it can get to the actual timespan which is the difference in the timestamps. However those timestamps can be faked as well, so it is just an estimate.


By input script, if you mean scriptSig, the max standard scriptSig can be up to 1650 bytes.

See policy.cpp :

// Biggest 'standard' txin is a 15-of-15 P2SH multisig with compressed
// keys (remember the 520 byte limit on redeemScript size). That works
// out to a (15*(33+1))+3=513 byte redeemScript, 513+1+15*(73+1)+3=1627
// bytes of scriptSig, which we round off to 1650 bytes for some minor
// future-proofing. That's also enough to spend a 20-of-20
// CHECKMULTISIG scriptPubKey, though such a scriptPubKey is not
// considered standard.
if (txin.scriptSig.size() > 1650) {
    reason = "scriptsig-size";
    return false;
}


Is there a way to take out a loan on your Bitcoin like how Ethereum can be used as a CDP in the MakerDAO to get DAI?

The closest method of doing this is using an exchange that provides margin trading. The only issue I have with it is that you need to trust your BTC with the exchange. One can recreate what the makerdao has with better rates too, but with a more centralized approach.

Say you wanted to cash out $1000 USD worth of BTC (ex. 0.1 btc @ 10k btc price), but you also don't want to sell it because you see the price might be higher in the long term. What you can do is the following:

Deposit 0.2 btc ($2000) onto an exchange that provides margin.
Sell the 0.2 btc for USD. Now you have $2000 in your account.
Send $1000 to your coinbase or however you want it in and cash out to your bank account. Now you have $1000 USD in your bank.
The remaining $1000 USD that is on the exchange. Open a margin buy position for 0.2 btc.
When the price of BTC doubles from the price you sold at, you close the position. Now you have back your 0.2 BTC minus the fees.

The liquidation price of your margin position will be usually 50% of the price you sold at. Say its 10k, if you were to get liquidated, BTC would need to drop to 5K.

Bottom line, your basically taking a loan out with your BTC as long as the price doesn't drop by 50% from the current price. Also to note, not your keys not your coins risk if the exchange exit scams or freezes your account.


Multiple mining pool workers or just one?

  It would seem from a server farm administration perspective at least that managing less workers could help simplify some of the configuration and tracking tasks.

The initial task of configuring the pool and miners is certainly simpler with just one worker name, however, the overall job of administration is made more complex by using that method.

By using a separate worker name for each physical miner (even if you enter it three times, once for each pool in the miner configuration) your job of monitoring is simplified since you can then just check on your pool to see that each miner is performing as expected. Some pools even have alerts if a particular worker's performance drops below a threshold.

By using a separate worker name for each miner you can easily identify a) that there is an issue, and b) which miner has the issue.

You could even label the worker name on each miner to simplify this further.


How to create a cryptocurrency backed by an asset (say a fiat currency or physical commodity)

Value is a subjective matter and as such you can't make something be worth something else.

As such, your best bet is to create a cryptocurrency and have all participants agree that it's worth the desired asset.

Every other scheme with oracles and "smart contracts" and whatnots are just an iteration of the previous aforementioned social contract between the participants of the network.

If you still want to try to develop something I'd advise you to take a look at MakerDAO and DAI from Ethereum, here. They are working on creating a stablecoin without any of the stable asset. Be advised that any people (me included) have doubts about that.


If your business partner knows your address, they can learn the transaction history and balance of that address. Often it is possible to guess or deduce that other addresses also belong to you, but this requires a bit more effort and is less reliable. However, this certainly doesn't translate to your complete wallet's balance and activity to be known.

This is why Bitcoin users are advised to generate a new address for every business interaction they have and why generally Bitcoin software makes it easy to create new addresses.


How do miners communicate in Bitcoin/ Decentralized Network?

Bitcoin is a gossiping network. There is no hierarchy among the nodes, each node operates at equal privilege level. Bitcoin has an established protocol defining how nodes communicate with each other, and some stepping stones to find the first peers (although they could easily be replaced by other on-boarding mechanisms).

Whenever a node learns new data on the Bitcoin network, it gossips to its peers about that data. As every node connects to multiple peers, the information will generally reach every participant eventually.

Block data has special propagation guarantees: the blockchain ensures that the whole network converges on a shared ground-truth regarding the network state and new blocks are relayed with priority.
Some nodes that are otherwise indistinguishable from other participants use the transaction data they collected from the gossip network to author new blocks. Some of the so-called "miners" run additional communication protocols to expedite communication between each other, but this is not required.


Luckily you are not the first person trying to figure this out.

According to an online poll, the average user of Bitcoin is a 32.1-year-old “libertarian” male, from a report at ThinkProgress.

There are some realy detailed Demographics out there:
Zerohedge.com
Simulacrum.cc


How do I calculate the sum of transaction inputs?

You have to look up the previous unspent transaction output using the hash and txout-index, and this output contains the amount in satoshis which is provided in entirety as input for the transaction.


The certificates have been fixed and SSL/HTTPs is working properly now.

TXID referrers to the transaction ID

N referrers to which input you want to use from that transaction.


UTXO stands for Unspent Transaction Outputs. Thus, a node only keeps track of transaction outputs that are unspent. As soon as a transaction (even an unconfirmed one) consumes a UTXO, it is removed from the UTXO db (if the tx is dropped, it is added back).

  What I think is ,they should be removed from the memory pool.

The mempool is a list of unconfirmed transactions consuming as-of-yet available UTXOs. UTXOs are not removed from the memory pool. There is a separate UTXO database

  Also what I think is that the memory pool is nothing else but the state of the blockchain.

The state of the blockchain is the UTXO database. The mempool is essentially a list of proposed changes to the UTXO set, which can be mined and confirmed, which then results in an update to the state of the blockchain.


OP_HASH160 pops the public key from stack after hashing it?

OP_HASH160 pops an item from the stack (it can be a public key or any arbitrary array of bytes), hashes it and pushes the result to the stack


Can wider acceptance cause the value to fall?

The point you bring up is fundamental to understanding how the bitcoin market operates.

The majority of companies that have grown quickly in the space help merchants accept bitcoin. As you mentioned, these merchants generally end up selling bitcoin for fiat currency. Companies that provide bitcoin payment processing have grown more quickly over the past year than consumer wallet companies (which help consumers purchase bitcoin). Consequently, the bitcoin price has experienced downward price pressure over the past year, since we find more market participants selling bitcoin than buying it.

As regulation and banking becomes more attainable for bitcoin businesses over the coming year, we should see consumer wallet companies grow, which would lead to more people buying bitcoin. Until then, expect to see continued downward pressure on the bitcoin price.

PS: I'm the CEO of bitcoin exchange Coinsetter.


In Lightning commitment transactions, what do the upper 8 bits of sequence and locktime represent?

If you look at git blame of BOLT 03 you can track the sentence regarding the locktime down to this commit: https://github.com/lightningnetwork/lightning-rfc/commit/f1eaa2544665c9b85a2fd95be9c83dad45888982

luckily the author gave a good explanation in the commitment message in git of why the 0x20 was introduced for the upper 8 bits in the locktime field (I have nothing to add to this):

Use 0x20 as high byte for locktime in commitment transaction

The most significant byte of the locktime in a commitment transaction
must be set to 0x20. This is to make sure that the locktime value
is always higher than 500,000,000, making it interpreted as a Unix
epoch timestamp, and not a block height. It also makes sure that the
locktime is below the current time, allowing the commitment transaction
to be included in a block.

Since the sequence field in the input of the commitment transaction is
used for the other half of the obscured commitment transaction number,
it will never assume the maxInt value (0xFFFFFFFF) which would disable
locktime checking.

Similarly for the first 8 bits of the sequence number we find this commit: https://github.com/lightningnetwork/lightning-rfc/commit/125b9a36572d05eb79b1c9527a70acadadc7cfc1 From the commit message I can quote again:

 BOLT 3: Fix commitment transaction input sequence number.

From BIP 68:

    If bit (1 << 31) of the sequence number is set, then no consensus
    meaning is applied to the sequence number and can be included in any
    block under all currently possible circumstances.

Which is what we want.


Is there a chart that shows Mhps mint speed over time?

Yes, the total hash rate will correspond to the difficulty. After all, difficulty is adjusted based on how fast hashes are found.

Here is a chart on sipa.be that shows hash rate on the left axis and difficulty on the right.

Here is another hash rate chart from blockchain.info.


Are there any Web Crawlers for Bitcoin addresses?

Well Google, or any other search-engine, already crawls the Web for you. Probably just Googling an address will lead you to the Website where its owner published it, and it'll allow you to find other relevant information related to that address. This of course assuming the publisher of the website actually owns that address.

The only real way to prove that someone owns an address is for them to actually sign a transaction using that address - in other words: they can prove to you they own an address by making a payment of a specific amount using that address.


Is there a JavaScript library for validating P2SH addresses?

You can use the library you've linked.

Instead of using:

isValid(address, 0)

use

isValid(address, 5)


Bitcoin Core wallet update schedule and transaction

Different versions of the Bitcoin-qt wallets can most certainly send and receive bitcoins from each other. They are compatible. And it looks like it will stay compatible for the foreseeable future as no hard forks are planned near term.

Just make sure you use the "official" client from bitcoin.org and check signatures to make sure you get the correct one. Also try things with small amounts of money to make yourself comfortable with how it works.

All the other wallets mentioned at bitcoin.org are also compatible regarding sending and receiving bitcoins by the way, but I'm assuming you're interested in running a full node i.e. bitcoin-qt.

Note that this site is not affiliated with bitcoin.org or the core developers (although some of them post here sometimes). I'll clean up your question to better fit the purpose of this website. One way to contact core developers is through the #bitcoin IRC channel.


The value of the transaction fee is not at all tied to the value being spent. It is entirely based upon the weight of a transaction as defined by BIP 141, which is based on the size of a transaction in bytes. To pay a lower fee, you need to make your transaction smaller by spending less inputs and creating less outputs. There is no way to spend fewer inputs except to not receive many low valued payments.

If you are receiving those payments by withdrawing from some service, then you should wait for your balance to be higher before withdrawing.


Connect to bitcoind from a different device within the same local network

If you're going to just use within the network and not outside of the LAN then as mention below, use rpcallowip=0.0.0.0/0 will work and also don't use rpcconnect as it may cause issues. If your planning future to use that option outside of the LAN (aka WAN) then there will be security issues so make sure to not use it outside of the LAN unless you can configure it correctly to not allow accept all ip.


QR Scan "Unrecognized format" mycelium "Mastering Bitcoin'

Mh i'm try with Bitcoin android wallet and work, this is the result

Can be your wallet have a bug?


If i reset my block chain do i lose my btc that is unconfirmed for 2 days?

no. if you have stored your private key anywhere (where it is safe), no one can steel your bitcoin in practice.

theoretically you can write down your private key on a piece of paper. then you can loose your entire py and you can not create a transaction quickly (however your address can still receive bitcoin). but you will not loose any bitcoin if you backup your private key. because: you can (whenever you want in future on any pc/mobile phone with internet access) start to use a bitcoin-wallet-software which allows to import private keys and then you have full access to your fund again.

the fact that a transaction is not confirmed does not affect that either the sender or the receiver of funds of a transaction has access to the funds. (depending on whether the transaction is confirmed or not.)


How to code the Simplest BitCoin CPU Miner?

If you're fluent in Python, there is a reference RPC miner, written by one of bitcoin's developers: https://github.com/jgarzik/pyminer


Why do miners choose low fee rate transactions sometimes?

For miners lower transaction fee doesn't matters but fee rate does.
There are three cases where the miner chooses transactions with low fee rates.

1) When the mempool has three sets of transactions {A}:High fee rate , {B}:Average fee rate and {C}:Low fee rate. If there are few transactions of set A and B the miner will select transactions from C as well.

2) In a child-pay-for-parent scenario, where A is the parent transaction and B is the child transaction.

A: { size: 200 vB, fee: 200 satoshi } ⇒ fee rate: 1 sats/vB
B: { size: 100 vB, fee: 2800 satoshi } ⇒ fee rate: 28 sats/vB

The miner really wants to collect the fee of B, but B spends an output of A, and the miner has to add both A and B in order to get the transaction fee.
You can see this in full detail here.

3) The miner has some personal interest to add a certain lower fee rate transaction.

Hope it helps.


Is it possible to transfer money from another country to the U.S.?

You can certainly transfer fees internationally with Bitcoin, and in many cases this is a great way to do so.

Keep some things in mind, however. For one, you will have to pay conversion fees when you convert from currency, to Bitcoin, and then back into currency.

Also, with some exchanges and traders it can take awhile to convert your Bitcoins into money. The Bitcoin system is growing, but it's not as efficient as a bank or wire transfer, at least not yet.

In the meantime, as you are trying to conduct your transfer, Bitcoin prices can swing up and down. If Bitcoin prices go up, good for you, you'll make extra money. If Bitcoin prices drop, however, you could end up losing more money than if you just went with a bank.

If you are new to Bitcoin, I'd wait another semester before using this method. You should familiarize yourself with the whole system first before conducting such transactions.


How are the requirements of the hash for mining a new block determined?

The difficulty calculation is part of the consensus rules that nodes on the network follow. It can be calculated at any time by a node and is calculated every 2016 blocks (two weeks, on average). When the correct number of blocks has passed, the node calculates it based on the last two weeks and adjusts in order to maintain a 10 minute block time (on average). The calculation is in CalculateNextWorkRequired.

Miners can request a block template from a node, in order to start mining, which contains the hash target (i.e. difficulty), see getblocktemplate.


How Do HD Wallets Keep Track of all accounts?

In general, HD Wallets use the following logic for how many addresses to query, and when to stop:

Start with account 0, generate gap limit number of addresses (usually 20)
Check for any transactions in those addresses
If there are no transactions, stop searching for new addresses and accounts
If there are transactions, generator gap limit more from the index of the last address with transactions on it. Additionally, also do this process for account 1 (you only check for n+1 accounts if Account n has transactions

The general idea is that no accounts will exist if the previous account is unused, and that no addresses in an account will be used after a single, consecutive block of gap limit number of unused addresses.

Companies like BitGo who offer HD wallet services to exchanges etc. where you can easily have thousands of unused addresses in a row, and then addresses with transactions, generally ignore the gap limit. They instead maintain a list of all generated addresses and index them as individual addresses, not as an HD wallet.

On the API side of things, wallets generally try to keep a running index. They will maintain a cache of known transactions, and keep appending to it. This way, when you start it up, it only scans for transactions in the new blocks since the last time it scanned. This allows even light clients such as Electrum or Ledger/Trezor wallets to serve thousands of users with just a handful of nodes, since each wallet will not requery for previous transactions it alread knows about.

Naturally, if you import a frequently used HD wallet to a new wallet or delete the cache, the initial sync can take very long. However, subsequent syncs of the wallet will be much faster.

In addition to this, HD wallets will often rely on a full node (such as Bitcoin Core) or a system such as ElectrumX or Insight. All of these are capable of maintaining a full index. Bitcoin Core maintains only a running index across known addresses (which is why you need to rescan when you import an address). ElectrumX and Insight maintain an augmented index which keeps track of all transactions, and can quickly return data for any given address.

HD Wallets do continue to check for transactions across all used addresses. They simply don't rescan the entire chain every time. But for every new block, every tx in that block will be checked for every address in the HD wallet. This check can be done quickly via bloom filters or preindexed data such as from Electrum or Insight, without reaching a bottleneck.


You can't, but you could do something similar.

To start off with there isnt a single set of order books for BTC/USD, because there are dozens of exchanges each with their own set of books. Aggregating all of data from all the exchanges in to a single order book isnt going to work due to the pricing differentials (arbitrage opportunities) across the exchanges.

If you wanted to do this for a single exchange (such as BitStamp) you'd need to write script (or program) to download all of this data from their API (or scrape it from the HTML), and insert it in to a database. However this would only give you data from the present forward. If you wanted historical data, you'd have to find someone who is actively running a bot, and try to purchase the data from them. Try asking around on BitCoinTalk.org, or you could ask the exchanges themselves if they'd be willing to sell you this data.

Also something you should be aware of, in my experience writing my own trading bot, i've noticed that some open orders exist for a very short amount of time (< 1 second). So if you're going to write your own bot, keep this in mind. Also keep in mind that most exchanges use CDNs to prevent DDoS attacks, and will actively throttle your bot if you send too many requests per second. If you're clever you can evade the CDN throttling, and send enough requests per second to observe those short lived orders.

And how to create this in to a moving 3D graph? I have no idea. You could always write your own program, but for something like this i'm sure there is already a product out there than can do it.


Can a transaction be conditioned on signing another transaction?

Not directly, but you could do something similar by combining tx1 and tx2 into a single transaction.
So, instead of:

tx1:
Input         | Output
Alice (1 BTC) | Eve (1 BTC)

tx2:
Input          | Output
Eve (0.99 BTC) | Bob (0.99 BTC)

you could use:

tx:
Input          | Output
Alice (1 BTC)  | Eve (0.01 BTC)
               | Bob (0.99 BTC)

This doesn't seem useful for the lightning network, because you really don't want to have a payment fail just because a settlement somewhere along the path failed.


Do you lose money when transferring between wallets?

Bitcoin transactions always pay fees. Your friend had 0.04488434 BTC, he sent you 0.0306 BTC, paid miner fee 0.00036984 BTC and his change was 0.0139145 BTC

  So do you lose money when transferring in the blockchain ?

Bitcoin transactions are not free