When you hear about bitcoin "mining," you envisage coins being dug out of the ground. But bitcoin isn't physical, so why do we call it mining?

Because it's similar to gold mining in that the bitcoins exist in the protocol's design (just as the gold exists underground), but they haven't been brought out into the light yet (just as the gold hasn't yet been dug up). The bitcoin protocol stipulates that 21 million bitcoins will exist at some point. What "miners" do is bring them out into the light, a few at a time.

They get to do this as a reward for creating blocks of validated transactions and including them in the blockchain.

Nodes

Backtracking a bit, let's talk about "nodes." A node is a powerful computer that runs the bitcoin software and helps to keep bitcoin running by participating in the relay of information. Anyone can run a node, you just download the bitcoin software (free) and leave a certain port open (the drawback is that it consumes energy and storage space - the network at time of writing takes up about 145GB). Nodes spread bitcoin transactions around the network. One node will send information to a few nodes that it knows, who will relay the information to nodes that they know, etc. That way it ends up getting around the whole network pretty quickly.

Some nodes are mining nodes (usually referred to as "miners"). These group outstanding transactions into blocks and add them to the blockchain. How do they do this? By solving a complex mathematical puzzle that is part of the bitcoin program, and including the answer in the block. The puzzle that needs solving is to find a number that, when combined with the data in the block and passed through a hash function, produces a result that is within a certain range. This is much harder than it sounds.

(For trivia lovers, this number is called a "nonce", which is a concatenation of "number used once." In the case of bitcoin, the nonce is an integer between 0 and 4,294,967,296.)

Solving the puzzle

How do they find this number? By guessing at random. The hash function makes it impossible to predict what the output will be. So, miners guess the mystery number and apply the hash function to the combination of that guessed number and the data in the block. The resulting hash has to start with a pre-established number of zeroes. There's no way of knowing which number will work, because two consecutive integers will give wildly varying results. What's more, there may be several nonces that produce the desired result, or there may be none (in which case the miners keep trying, but with a different block configuration).

The first miner to get a resulting hash within the desired range announces its victory to the rest of the network. All the other miners immediately stop work on that block and start trying to figure out the mystery number for the next one. As a reward for its work, the victorious miner gets some new bitcoin.

Economics

At the time of writing, the reward is 12.5 bitcoins.
Although it's not nearly as cushy a deal as it sounds. There are a lot of mining nodes competing for that reward, and it is a question of luck and computing power (the more guessing calculations you can perform, the luckier you are).

Also, the costs of being a mining node are considerable, not only because of the powerful hardware needed (if you have a faster processor than your competitors, you have a better chance of finding the correct number before they do), but also because of the large amounts of electricity that running these processors consumes.

And, the number of bitcoins awarded as a reward for solving the puzzle will decrease. It's 12.5 now, but it halves every four years or so (the next one is expected in 2020-21). The value of bitcoin relative to cost of electricity and hardware could go up over the next few years to partially compensate this reduction, but it's not certain.

Difficulty

The difficulty of the calculation (the required number of zeroes at the beginning of the hash string) is adjusted frequently, so that it takes on average about 10 minutes to process a block.

Why 10 minutes? That is the amount of time that the bitcoin developers think is necessary for a steady and diminishing flow of new coins until the maximum number of 21 million is reached (expected some time in 2140).

creds: https://www.coindesk.com/information/how-bitcoin-mining-works/


Bitcoin price synchronized between exchanges

The exchanges don't need to synchronize.  It's just traders keeping the prices close.  If the price is $6500 on one exchange and $6700 on another for BTC.  Traders will sell on the $6700 exchange and buy on $6500 exchange until they are close.  They now own more BTC then before without spending any money


How can I import a private key into a pruned node?

I think your choices are

Restart your Bitcore-core node with adequate diskspace and pruning mode disabled, wait for it to sync all over again and then use importprivkey or
Import or sweep your private key into a different wallet such as Electrum. Optionally transfer the money back to your Bitcoin-core wallet. This might be quicker but you won't get the full transaction history back into Bitcoin-core


How to calculate the size of the blockchain?

du rounds up file sizes to the next multiple of your filesystem's block size.  It also includes the sizes of directories.  So this will give you a (slight) overestimate.

You really just want to add up the total sizes of all the blk*.dat files.  You can get that with

du -c --apparent-size /home/me/.bitcoin/blocks/blk*.dat

You can divide this number by 1000000000 to get GB, or by 1024*1024*1024 to get GiB (note the distinction).

Note that this will still include "orphan" blocks that you downloaded and stored, but that are not part of the main block chain.  There isn't any easy way to exclude those, as far as I know.


What is the maximum number of keys/addresses that can be created for a single wallet? Phrased another way, what is the largest value one can safely put for the keypool option in bitcoin.conf?

The type of that parameter is int64_t so the maximum value is 2^(64-1)-1. In practice, you can put any number you want and it should not make the software break. However having a lot of keys (hundreds of thousands) will result in a very large wallet and potentially slow down the wallet loading phase.

  If I generate some keys with bitcoind keypoolrefill then generate some new addresses and then call keypoolrefill again, will the original addresses still work,

Yes. Everything is stored in the wallet and keys are never deleted.

  and will my private key now work for all addresses I've ever created?

That's not how private keys work. Each address has a private key, so if you have one private key, it corresponds to one address. Each address that is generated in the keypool will have its own private key which is stored in the wallet file.

  Is there some way to determine how many keys are left in the current key pool?

bitcoin-cli getwalletinfo will tell you how many keys are left in the keypool. The keypool is automatically refilled when your wallet is unlocked.

  The Bitcoin documentation says that this feature is actively being phased out. When will this happen and what will the new system be?

This system with the keypool is still in use and making periodic backups is still recommended as the wallet contains transaction data that is not backed up by deterministic wallets. The "new system" is to use BIP 32 Hierarchical Deterministic key derivation instead of randomly generated private keys. A seed is first randomly generated and then all private keys are derived from that seed. This means that only one backup is necessary in order to backup all of your private keys, but periodic backups are still recommended as stated above.

This feature was added to Bitcoin Core in Bitcoin Core 0.13.0. Most other modern wallets use BIP 32 HD wallets.


Sending from address to address in bitcoind

To find the transaction outputs you can spend

listunspent 0 99999999999 "[\"addressYouWantToSpend\"]"

Then create the tx

createrawtransaction "[{\"txid\":\"txIdToSpend\",\"vout\":n}]" "{\"destinationAddress\":amountToSend, \"changeAddress\":changeAmount}"

Then sign the tx

signrawtransaction <hexStringProvidedBycreaterawtransaction>

Then publish the tx

sendrawtransaction <hexStringProvidedBysignrawtransaction>


OP_RETURN marks transaction or output as invalid

Both.

Transaction output scripts are only executed at the time they are attempted to be spent.

If you try to spend an OP_RETURN output, the spending transaction is invalid, as this instruction immediately fails the execution.

As a result, OP_RETURN outputs (not the transactions they are in) are unspendable.


I have bitcoins in Poloniex. How do I get them to CANADIAN dollars?

it looks like I can get money out of Quadrigacx?? but how do I transfer my bitcoins from Poloniex to Quadrigacx

You will need to register and verify your account with Quadrigacx. Next obtain a deposit address for your Quadrigacx account, and initiate a withdrawl from Poloniex to the Quadrigacx address. After some time, your Quadrigacx account will be credited with the bitcoin.

  am I totally off and there is another way? I'm ready to cash out and would like my bitcoin in cash!

You could find someone to sell them to in person. There are some websites that facilitate this, such as Local Bitcoins.


Regarding use of bitcoin mining hardware for generating sha 256 hash, other than bitcoin mining

Most bitcoin ASICs take as input a SHA256 chaining value and a 480-bit block, and they try every possible 32-bit suffix to check if SHA256(SHA256(block + suffix)) begins with sufficiently many zero bits.

So, it won't be easy to do what you want to do (crack a password?).

There are use cases where this limited functionnality is sufficient though, see the 3SUM-pool for instance (disclaimer : it's mine).


Do mining pools expose attempted nonces to the public?

Do mining pools expose attempted nonce to the public ?

No, that's pointless and would be completely infeasible. The combined network tries over 100 billion billion nonces per second (as of december 2020, it's around 120 exahash/s).

I would think no because it would be counter competitive. I can let a giant mining farm tell me what nonces not to use

That's irrelevant. They are trying to find nonces for a different block candidate than you are (at the very least, they're trying to mine a block that pays them; you're trying a block that pays you).

Would it be faster to continue attempting random nonces

No, every block candidate + nonce is a completely independent attempt. Nobody will ever try the same combination again (because the timestamps change, the composition of transactions changes, and the payout depends on the miner). It doesn't matter in what order you or anyone else tries nonces - only how many you try per second matters.

or storing the nonces previously attempted in memory and finding them in a sorted array

No, same reason.


How to make permanent Bitcoin Address for donations?

Just generate a new address and put it on your website. Not sure what you mean by permanent, all addresses are permanent as long as you keep the private key safe.


How to get total number of transactions from bitcoin core wallet using rpc

You can pass the output of listtransactions through a JSON parser which can get that information for you. You can install a command line tool like jq and pipe the output of your commands to it so you can access the JSON fields that you want.


When using createrawtransaction, are the outputs ordered as they are presented within the request?

I found the answer on mailing list.

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-October/016441.html

  The createrawtransaction RPC will now accept an array or dictionary (kept for compatibility) for the outputs parameter. This means the order of transaction outputs can be specified by the client.

According to the description, it should be the same order.


Get Historical Bitcoin Prices on GDAX in CSV Format

This is my first ever response on any forum so I hope you find this helpful.

I think your question is "is it possible to get one year worth minute by minute data from gdax?". I only recently started trading with gdax via it's API but i have been trading with kraken's API for a while now and my experience with all crypto currencies so far is that you can only get a few days worth of historical data or ticks. However, if you want minute by minute data from the API, then you will have to query the data at some interval (maybe every minute). Note that the frequency of such queries are usually limited by a rate limit often determined by the exchange.

Also, I do not think Coinbase is an exchange in the sense conventional sense. I see coinbase and gdax as different business units of the same enity. Hence, I suspect that whatever trade or tick information you get from either of the two will be the same. However, they function differently and have two different category of people they cater to. Coinbase API is primarily for building phone applications with only basic features e.g. buy, sell, send, historical data.

However, gdax caters to the more sophisticated trader with more advanced features like limit order, margin trading, OHLC data etc.

You should check the links below to see if there are features that may attend to your needs

https://developers.coinbase.com/
https://docs.gdax.com/?javascript#introduction


From the Accounts wiki page:

getaccountaddress will return the same address until coins are received on that address; once coins have been received, it will generate and return a new address.
getnewaddress always generates and returns a new address.
setaccount changes the account associated with an existing address. Coins previously received on that address (if any) will be debited from the previous account's balance and credited to the address' new account. Note that doing so may make the previous account's balance negative.

Use the getaddressesbyaccount method to list all addresses associated with an account.


"Why are miners allowed to not announce their mined blocks to the network?" you can not prohibit to mine blocks and not announce them. if you do some mining-calculations on your mining-hardware, you can do that offline. no one knows that until you publish your block(s).

"So then, why not just force blocks into the main chain the moment they are mined?" you can not know assuredly the timestamp when a block was mined because the miner can write an arbitrary timestamp in the block. furthermore all bitcoin-nodes/-miners should/will follow the longest block-chain by definition. the timestamps in the blocks does not really matter.

this "private mining" and resulting doublespend-attacks are absolutely possible. the bitcoin community trust that no one ever will have enough hashing-power to do this attack.


How can we run regtest without transaction fees

This is a duplicate - see also  Does the Bitcoin Qt client have a minimum transaction fee?

Bitcoin-QT will protect you from sending transactions that are very unlikely to ever be included in the blockchain.  If you really want to try sending with 0 transaction fee, you will need to use another wallet software or patch and recompile the code.

It is highly recommended to include some transaction fees.  See estimates at https://bitcoinfees.earn.com/ (former "cointape") to figure out how much is needed.  Keep in mind that the estimates are very uncertain, they count it's like 90% probability that the transaction will go through within the estimated window - but then there is also a 10% probability that the estimate is off.  There have been times where transactions that should have gone through within hours have taken days or weeks to get through, though it's rare.

I often also consult https://jochen-hoenicke.de/queue/ to see what's going on, particularly the "mempool size in MB"-graph may be relevant.


In the example, the user is demonstrating that they are willing to lose access to some amount of Bitcoin for a period of time.  The example is based on an assumption that a rational user wouldn't do that unless they were serious about something.  The implied benefit is that casual users or bots won't want to put a lock on their funds.

However, as Tadje Dryja pointed out in a recent talk, time value of money is not necessarily equal among users.  In the example, the contract is for 10 BTC.  For some folks 10 BTC may be a lot to part with for 6 months.  For others it may be no big deal.  So it's questionable if the site gets the benefit they think they are.

Imagine an exclusive club where you had to deposit $1,000 just to get in the door, but you were guaranteed the return of your money when you left.  It does act as a selection filter for who is able and willing to go through with this arrangement.  Whether or not it really selects for the clientele the club is looking for is another question.

Also, at the risk of pointing out the obvious, I would add a step 7 to that example that the web site verify that Tx1 is confirmed on the block chain and is as expected before proceeding.  The web site already knows the transaction ID for Tx1 since that was given in step 3.


How to list all addresses in a deterministic wallet?

How many keys can be generated by a deterministic wallet?

Effectively infinitely many. The same as a non-deterministic wallet which just keeps generating random private keys. There is a limit, 2^256, but you are never going to reach that. It is effectively infinite.

  Is it possible to list all keys (public keys, to avoid leaking critical information) in such a wallet?

It depends. If you are using hardened derivation, then no.

Also, because there are effectively infinitely many addresses, this would be impossible to do. You could reasonably generate enough addresses that you would ever use in your lifetime though.


It is implicitly assumed that the attacker performs a Finney attack, and hence gets a block for free. If the merchant accepts a 0-conf tx, the attacker will proceed immediately to release a double-spending block he has already computed, and thus succeed.

In any case, Satoshi's analysis is approximate, see https://bitcoil.co.il/Doublespend.pdf for a more accurate one (which makes a similar assumption).


Bitcoin Insight API - How to create new address?

You can't "create new addresses" with the Insight API.
The Insight API is for querying the blockchain for information.

You want to use the Bitcore Wallet Service, THAT will manage a list of addresses/wallet for you:

Bitcore Wallet Service on Github


wallet software that doesn't require downloading the entire blockchain

Electrum wallet. Works like a charm on my mac.


Pros and Cons between Ripple payment verification and centralized authority's payment verification

A centralized payment verification system, like Paypal or any number of financial institutions, only considers payments "valid" if they come from within the organization. A single organization is responsible for verifying the truth of statements (with a statement being "Bob sent Alice $50" and the like). This means that there is no mechanism of agreement on transactions required.

By contrast, decentralized systems like Bitcoin, Ripple and Stellar all must come to agreement on which transactions are valid, without a centralized authority to confirm their truth. Proof-of-Work, Proof-of-Stake, Tendermint and SCP (Stellar Consensus Protocol) are each different solutions to this problem.

Pros of a centralized system:

No need for a mechanism of agreement, such as mining or consensus
Lower operational costs

Cons of a centralized system:

There is a single point of failure. If the central authority goes down or offline, the entire network is compromised.
Centralization can post ethical issues of who controls information and money.It opposes the ethos of a neutral net.
Creates a closed network, meaning that entities can only join the system with the consent of the centralized authority
May only serve the interest of the centralized authority.
Does not allow for p2p interaction/payments


How to generate a valid bitcoin address for destroying bitcoins?

Start with an invalid public key

Bitcoin addresses are the pubkeyhash (not pubkey) plus version and checksum information, encoded in base 58.

Bitcoin address = version + RIPEMD-160(SHA-256( Public Key )) + checksum

The steps for converting a public key to an address can be found here:
https://en.bitcoin.it/wiki/Address

Since the address uses the pubkeyhash not the actual pubkey we can exploit this by hashing an invalid pubkey (one which can't possibly exist) and thus produce a valid address from an invalid pubkey.

So to start we find an invalid public key.  All valid public keys begin with 0x04 if uncompressed and 0x02 or 0x03 if compressed.  A pubkey beginning with any other value is undefined and thus there is no possible signature that can be created to satisfy that key requirement.  Since spending coins requires signing the transaction with the correct private key, an address which has no known private key is unspendable.  By using a public key which is known to not have a private key others can confirm that no private key exists.

A valid Bitcoin public key (not address):

  04678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f

An invalid public key

  0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

There are other ways to produce a known invalid public key.  ECDSA keys must be exactly 65 bytes if uncompressed or 33 bytes if compressed so a key with a different length will also be invalid.  For uncompressed keys the y value must be correctly produced from the x value.  The point must also lie on the curve.  It also can't be above the modulus for the curve.  So there are a lot of ways to produce provably invalid keys but it best to choose one which is obviously invalid.  This is probably the simplest obviously invalid public key.

  0x00

This public key is invalid for a number of reasons (not produced by private key multiplied by the generator, not located on the curve, not a valid point, but even simpler it doesn't have a valid prefix and is not the correct length).

The important thing is this isn't just some probably invalid key it is a provably invalid key.

You should test your invalid public key against the reference client to ensure the client reports it as invalid as well.  The validity of keys is a consensus issue so this will not change short of a hard fork.

Produce a valid (but unspendable) address from your invalid public key

You may wonder why we want the address to be valid.  All clients should validate addresses given by users to avoid accidental loss of funds.  So an invalid address is also unspendable but most users will find it impossible to send funds to the address.  A P2PkH address is the pubkeyhash with version and checksum information encoded in base58.

When you provide an address to a Bitcoin client it decodes the address back down to the 'raw' pubkeyhash.  So producing a valid address means starting with a valid pubkeyhash.  This isn't a problem because the hash of anything is a valid hash.  Clients don't know what pubkey is hashed to produce the pubkeyhash as the underlying pubkey is not provided and hashing functions are one way.

The Bitcoin network only verifies that an address is in the right form, length, and has the right checksum when "validating it".  Producing an address from a pubkey is beyond the scope of this question but there are utilities and the link above provides the steps.  The resulting pubkeyhash and encoded address will be seen as valid by the network and client but it requires a provably impossible private key to spend funds sent to that address.

Now with just the address (and decoded pubkeyhash) a user can't verify that the underlying pubkey is invalid so you should publish the raw pubkey along with the address.  Users can recreate the address using any bitcoin client or tool and will produce the same address you provide.  Users now have a trustless way to verify that the coins indeed are unspendable.  Any coins sent to the address can never be spent and are effectively destroyed.

Hash collision

Technically it is possible but improbable for more than one public key to have the same Bitcoin address. This is called a hash collision.  If public key p1 and public key p2 both hash to the same address A then privates keys for either of these public keys can spend the funds.  However the likely of this happening is very low.  Unless RIPEMD hash algorithm is broken the probability of finding two public keys which generate the same hash (Bitcoin address) is 1 in 2^160 which is far beyond our computational power to locate.

A few words on why you should use a 'Nothing Up My Sleeve' number:

Using a "nothing up my sleeve number" (such as a single zero, all zeroes, single repeating digit, sequential numbers, digits of pi, etc) is not required as any invalid public key is equally unspendable but it would improve public confidence that you haven't already found a collision (as improbable as that is).

If you just take a random invalid key like say:

  00000fdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f

Some may question why you chose this specific key. The fear would be that you choose this key not randomly but because you have stumbled upon a collision between this key and a valid key.  There is no way to prove the key is random thus the fear will always remain.  Cryptographic functions (like RIPEMD or SHA-256) often use "nothing up my sleeve values" to provide security that a constant was not chosen to enable some cryptographic flaw or "backdoor" in the algorithm.  For example SHA-256 uses constants for the initial values of the block segments.  Technically these could be any random number but that would lead to concern that the 'random' number isn't actually random.  So SHA-256 uses first 32 bits of the fraction portion of the cube root of the first 8 prime numbers.  This allows verification when a pseudo random number is needed.  It is very unlikely there is some magical property between the fractional portion of the cube root of sequential prime numbers that undermines SHA-256.

http://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number

Update (03/31/2015)

It is easier to do this now by using an OP_RETURN (null data) output and it doesn't bloat the UTXO with outputs that can't be spent but the network is unaware they can't be spent.  Any funds sent to an output which contains OP_RETURN are provably unspendable and the network will drop the output from the UTXO.  The UTXO (unspent tx output set) is a critical resources which is necessary for validating new transactions and blocks so destroying/burning coins using UTXO is a more responsible use of this shared resource.


No longer receiving inv messages from node

As of 0.14.0, when you receive a verack, you also need to send a verack message back.

So whereas before you could do this:

Client: version
Node:   version
Node:   verack
......

You now need to do this:

Client: version
Node:   version
Node:   verack
Client: verack  <- do this!
......

Links

https://bitcoin.org/en/release/v0.14.0 (#9715)
https://github.com/bitcoin/bitcoin/pull/9715


What is the official explorer and value API for Bitcoin?

I am new to cryptocurrency development, and I have noticed that Bitcoin has an official wallet for both Desktop and Mobile (correct me if I am wrong).

There is no official Bitcoin wallet.

My question is, does Bitcoin have an official explorer and value API (such as Bitcoin to fiat conversion) too?

There is no official Bitcoin explorer or value API.

If not, are there services or APIs for developers that are recommended and widely used?

If using Bitcoin Core, JSON RPC can be used. Example: https://bitcoindev.network/accessing-bitcoins-rpc-service-from-php/
List of RPC commands: https://bitcoincore.org/en/doc/0.21.0/
There are also lot of Bitcoin libraries in different languages which can be used to make things easier:
Scala- Bitcoin-S
.NET- NBitcoin
Open Source block explorers:
https://github.com/Blockstream/esplora
https://github.com/dgarage/NBXplorer


Can you specify a date in the future for the Bitcoin transaction

That looks like a glitch with blockchain.info, there is no "time" encoded in a bitcoin transaction itself so that number is likely just when blockchain.info received the transaction.

In general though, it is possible to create a transaction which is only valid after a certain point in time or a certain block height in the blockchain, by using the "locktime" component of a transaction. If a locktime on the transaction is set, the transaction can only be included in a block after that point, not before, which may be of interest to you.


Displaying price in ETH based on USD exchange rate

There are an huge number of different sources, for instance CoinMarketCap have all the existing coins with the relative value in dollar, computed by averaging over many exchanges.


How does change address interact with original address

There is no relation at all between the two addresses, except that they're owned by the same person/wallet.
At the protocol level, "change" does not exist. It's just another output (with a corresponding address), indistinguishable from normal "payment" outputs. It is your wallet that's creating it: it needs a place to send the remainder of a spent UTXO of yours that you don't actually want to transfer, so it creates a new address of its own (just like you'd do when receiving funds), and sends the remainder there. And it stays there, until there is a need to spend those funds. It could send them back to the same address, but this would be a serious privacy leak (it lets people distinguish change from payment), and have no cost advantage.


Bitcoin's real-time Buy and Sell price API

Bitcoin does not have one single buy and sell price. Bitcoins are exchanged on many different exchanges, each keeping track of their own market price.

However, BitcoinCharts.com has a useful API that summarises many of the largest exchanges according to their trading volume. You could use that to display the Bitcoin price on your website.


Your intensity is very low (I:8) - dynamic intensity does not work well with scrypt. You will need to increase it manually. You can set a value to use when starting the program by adding --intensity 13 to your command line options/batch file. Replace the number 13 with the desired intensity. For a HD6850, I suggest you try values from 10 to 15.

If increasing the value by one notch does not significantly raise kh/s, gives you hardware errors (the number after HW:) or starts impacting in a noticeable way on desktop performance, then reduce it again.

You can also change the intensity whilst cgminer is running. Press g, then i, then carefully type the number, then enter.


getblockchaininfo returning excessive "soft fork" info

You can use the jq shell command to filter out the unwanted keys.

$ ./bitcoin-cli getblockchaininfo | jq 'del (.softforks)' | jq 'del (.bip9_softforks)'

with as output:

{
  "chain": "main",
  "blocks": 485623,
  "headers": 485623,
  "bestblockhash": "000000000000000000772fa60c075c57b8ba2db277a84454e1f8e27c3c307b10",
  "difficulty": 922724699725.9628,
  "mediantime": 1505593445,
  "verificationprogress": 0.9999959396017668,
  "chainwork": "0000000000000000000000000000000000000000008aeb8bb8310a6b50e24bb0",
  "pruned": false
}


How to check confirmations number programmatically

Confirmations for an address aren't really a thing.  Addresses are not confirmed; transactions are.  A single address is typically used in multiple transactions: one where the address is used as an output, and one where the first transaction was used as an input.  Although it's not a best practice, addresses can even be re-used multiple times.

It looks like this particular address has been used in two different transactions.  Once as an output in 00c83c7677d414053488d0b51067feee157a5b82d5acec5bfe8e9c540c11c624, and once as in input in 378f829160cb9c99cc7a8fb1152472b80f0e1ea9c9cc24118dbccc2da72dedcf.

Each of these two transactions returned in the API response has a block_height value (489353 and 489355).  That is the block at which the transaction was included.  To find how many confirmations each transaction has, subtract the block_height by the height of the most recently confirmed block, and add 1.  So if the current block is 489355, one transaction has 1 confirmation, and the other has 3.


Given a Bip38 encoded private key, Can you derive the address without knowing the password?

This doesn't appear to be possible from reading the BIP38 draft specification. However in this specific case, the key you have posted is a example from the moneywagon python module documentation. The password is 123 and the address is 1BrUfC75qyLQxxp7qcisfaMmwRMECo4ETC.


How do SPV clients acquire transactions from other nodes and verify that they are part of the blockchain?

I found out that SPV has no mempool, but although SPV client is participating in transaction verification. So, what happens when node verifies transaction? Is SPV client checking only owner's outgoing transactions?

That depends on what you mean by "verification". SPV clients cannot and do not verify the validity of transactions themselves; they can only verify that they were included in a block, relying on the assumption that miners would not waste their energy on creating a block with invalid transactions in it.

Transaction that SPV client is trying to verify has block hash as a reference where did a transaction came from? That's how SPV client knows in which block to search for target transaction when SPV asks full node for part of Markle tree. Is this correct?

Transactions do not (and cannot) contain a hash of the block they're contained it; that would be a cyclic dependency. I don't understand the rest of this question.

SPV client asks full node client for hashes inside Merkle Tree, so he can reconstruct the part of the tree of his interest and that way check if transaction is really in the block that transaction is referring to.

When using BIP37, the client sends a Bloom filter of which scripts/addresses/utxos they're interested in, and then requests blocks. The server responds with filtered blocks, containing only the matching transactions, plus efficient Merkle proofs that those transactions are actually in a block with the claimed hash.

If I'm on a right path, how does bloom filters help in increasing of level of privacy since SPV client still needs to ask full node client for a transaction by its hash?

BIP37 bloom filters are primarily a way to improve efficiency - it means that with little bandwidth overhead, the server knows what to not send to the client. It was intended to optionally offer some moderate level of privacy, because a client can choose to send an overly broad filter, resulting in false positives. It has since been discovered that this basically offers no privacy at all, due to correlation the server can still observe between requested things.


How to retrieve POST data that contains JSON

$data = json_decode(file_get_contents('php://input'), TRUE);
$text = print_r($data,true);
file_put_contents('coinbase.txt', $text);

This actually sends the following information to a text file:

Array
(
    [order] => Array
        (
            [id] =>
            [created_at] =>
            [status] => new
            [total_btc] => Array
                (
                    [cents] => 100000000
                    [currency_iso] => BTC
                )

            [total_native] => Array
                (
                    [cents] => 2270
                    [currency_iso] => USD
                )

            [custom] => 123456789
            [button] => Array
                (
                    [type] => buy_now
                    [name] => Test Item
                    [description] =>
                    [id] =>
                )

            [transaction] => Array
                (
                    [hash] => 4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b
                    [confirmations] => 0
                )

        )

)


Micro-payments definition and ideal platform

I do not think there is anything to reach consensus on.

very small payments (in relation to the transaction fees)
they belong to neither (some developers will create a micro-payment solution on the main chain and other on side chains); both are viable and it depends on the application


having trouble installing electrum, can't find libsecp256k1

Bitcoin Core does not install libsecp256k1. It is packaged into the binary itself so it is not installed into the system. If libsecp256k1 is not available in your system's package managers (which it probably shouldn't because it isn't officially distributed AFAIK), you can install it from source. The instructions for that are directly in the README.


How does BitCoin prevent fraud during confirmation period?

This is definitely a concern, and is the reason why Bitcoin users are encouraged to wait for several confirmations before accepting a transaction and delivering goods.

It's not quite as easy as you suggest, though.  When you made your transaction at the cafe, it was, as you say, broadcast across the network.  Barring connectivity problems, every node on the network gets a copy almost immediately.  (They don't need to wait for it to be included in a block.)  In particular, the gas station gets a copy.  So when you try to spend the same coin with them, they know it has already been spent and will reject your transaction.

To make this work, you have to ensure that the victim is not aware of the other transaction.  One approach is that the first transaction, rather than buying some other goods, simply sends the coin back to another address you control.  You don't broadcast it on the network; rather, you give it directly to a miner, with the understanding that they should include it in their next block, rather than the conflicting transaction that sends the coin to the gas station.  In a variant called a Finney attack, the miner (possibly yourself) has already mined a block with the transaction that sends the coin to you, but they wait to submit it to the network until you have bought your gas.


How does one create another transaction when all funds are tied up in an unconfirmed previous transaction?

It depends on your wallet software. Some may simply refuse to create the transaction. Others will spend the change output of the unconfirmed transaction. CPFP and RBF typically only occur when you specifically request for it in order to increase the fee of an unconfirmed transaction. Wallets will not do this automatically for you.


Unable to bind to 0.0.0.0:8333 on this computer. Bitcoin is probably already running

Are you sure that betcoind is not running?

Bitcoin is probably already running.

You can try to restart your computer...


You can actually pick up a PCI to PCI-E 1x (open end) adapter and plug in any video card you want. Then use a PCI-E 1x to 16x adapter. This is an example, but there are cheaper ones out there.

http://www.quill.com/startech-pci-cards/cbs/352874.html?cm_mmc=SEM_PLA_T_352874


How to refund money send to an address already used

money is not found in the account

If you sent your money to an exchange market wallet then you should ask their support about that issue.

Otherwise, please give us your transaction ID so we can look at it. You may have sent your coins without enough fees or to a wrong address.


First you need to define "reorg". Under the definition I'll use, the minimum reorg is two blocks. The definition would be:
"A reorginization occurs when a block is broadcast with a history that is incompatible with the previously work-heaviest** known blockchain, under the same consensus rules"

Say a block is mined onto the height 593000 block, with hash 000000000000000000a11... so that apparently, block 593001 has been found, and many miners are now mining based off of this hash.

Now imagine that someone broadcasts block 593002 with hash 000000000000000000c84...but upon examining block 593001, you see that the hash is 000000000000000000b5c...

A reorg has just taken place. Someone mined block 593001, and without broadcasting it (or perhaps after broadcasting it too late), mined 593002 on top of it. Now any transactions in the block with hash 000000000000000000a11... have not been confirmed (one of which was the original miner sending the block reward transaction to themselves), since the (valid) block that contains them has been orphaned.

As far as "how long", a reorg is relative to the observer, so one could technically take place before you observe the original chain at all.

** essentially, the longest chain, but there are exceptions where a "reorg" could be a shorter chain in terms of number of blocks, when a shorter chain contains "more" proof of work. This is outside the scope of this answer.


Repeated transactions using Bitcoins is impossible, unless you have access to the private key. This requires a specific client. Such functionality is not yet available, as most people encrypt their wallets (the client can't decode it without the user. The second approach would be preferable.


Does the software to conduct a 51% attack exist?

When you have open-source software, it's a fine line between "configuring" and "writing".

Say you want to reject all attempts to spend a particular transaction. There isn't a command-line option or config file directive to do this in the standard Bitcoin Core distribution, so in that sense the answer is "no". But you can do it by adding two obvious lines of source code and recompiling, which is only marginally work than modifying a config file.

There is certainly no need to rewrite Bitcoin Core from scratch, if that's what you're asking.  You can assume that if anyone is planning a 51% attack, the need to modify software is not going to be a significant obstacle.


A miner should not be correlated with a device. I can have 10 devices and I will still be a single miner from the perspective of the pool. I can have a mining farm with thousand devices and I can still look like a single miner to the pool.

Also note that a miner, in the above sense, is just a person that provides hashing power to a pool that runs a mining node; i.e. there are much less mining nodes.


Is there any tech that uses a signature as a private key?

It seems that publishing a transaction that shouldn't be published (a
  "bad act") must involve publishing something the victim can use to
  unwind everything.

Really, I should have asked the question that Murch answered for me (and the LN paper also answers it, but I didn't read it carefully enough the first time).  That question is: "Does LN use signatures as private keys?"  The answer is no, it uses the existence of UTXOs from obsolete transactions as the information published by a cheater to defeat the cheat.

Thanks to Murch's explanation, and the link Nick provided to the LN paper, I can answer my own question.  There is a scenario I now understand better, so I'll mention it below.

In fact, the bad act itself is publishing an "obsolete" transaction that puts (some) bitcoin into each party's address, but from which the cheater can't spend for a while.  The existence of that transaction in the blockchain is what the victim can use to unwind the bad act.  This is the case because the victim, according to the way LN works, will have an "anti-cheat" (Murch's term) transaction from the cheater, already signed, which spends the cheater's output from that obsolete transaction.  It's a useless transaction unless the obsolete one gets broadcasted, and once that happens, it becomes useful and will end up sending most of the funds to the victim.

This may seem to provide the cheater with a "double-spend" opportunity.  The bad act (publishing the obsolete transaction) creates an output (the cheater's output) that the anti-cheat transaction is supposed to send to the victim.  Couldn't the cheater make their own transaction that also spends that output, but provides a high fee to reward miners for choosing to help the cheater?  The answer is no, the cheater can't make such a transaction because the outputs from the obsolete transaction require signatures from both parties.  The cheater already signed the anti-cheat transaction.

On the other hand, regarding the question I actually posed, I think the answer is NO, there is currently no tech that uses a signature as a private key.  Perhaps this is for the reasons Nate gave in his comment, or perhaps no one who could appreciate the benefits of doing so has thought of it yet.


Did I lost the chance to get my BCH from Aug 2017 fork?

Your BCH will still be at the same address your BTC were in as of the fork date. BCH is a separate chain, so if you send BTC transactions it will not affect the BCH balance.

In order to move the BCH, you will need to install some BCH wallet software, and then import the private keys/seed for the addresses that were funded at the time of the fork. You can obtain the keys/seed from your BTC wallet, but be warned: it is prudent to empty out your BTC wallet before doing this, in case the BCH software is malicious and attempts to steal your funds. (even if it is a small chance, better to be safe)

The BCH software will be able to communicate with the BCH network, allowing you to access those coins.


You would need to create some guarantee that someone would be willing to exchange this token for exactly a dollar.  This means that the value of the token would in no way be market driven, except that it is pegged to an existing currency and its value fluctuations.  I don't believe there is a way to do this in a decentralized manner, but since that's not what you asked, I'll assume that's okay.

You would need to create a company/organization that issues the token, and guarantees that they will buy it back for the price you peg it to.  For example, you would always exchange one token for one dollar.  This would have to be a legally binding agreement, so that if your organization ever refused to exchange at that rate, holders of the token would have legal recourse against you.  You would also need to be able to prove your solvency, and thus hold enough assets in dollars that holders of the token can be assured that you have the dollars to exchange if there was ever a run.  If a question of your solvency ever arose, your token would drop in value, so you'd have to allow regular audits of your organization's asset holdings.

Likely, much of this probably negates many of the advantages you are attempting to seek by creating a digital currency in the first place.  The trust in your system would be based on the legal system and the government that enforces that system...just like government issued fiat currencies.  Your organization would more or less be a bank, but a bank that issues its own token, and therefore is locked out of the existing financial infrastructure.  You would be subject to regulation, and therefore won't be able to offer anything more than a bank does.

In the modern age, nearly all money is digital.  You've basically just asked how to start a bank.


Is in-person double-spending attacks negligible on bitcoin payments?

Double spending attacks can certainly happen in person. A customer could have set up a system on a different computer which they remote into on their phone to initiate a double spend attack. However double spends can really only exist under certain conditions, so if you are planning on accepting unconfirmed payments, you should check that those conditions do not exist. This gives you a higher confidence in that transaction confirming.

You should make sure that the transaction does not have:

A low transaction fee
BIP 125's Opt in RBF flag set
A locktime that is in the future
Spending from any unconfirmed transactions
Is unusually large (e.g. several kilobytes)

If you check for these things and they are not in a transaction, you can be reasonably confident that the transaction will confirm.

You can also have a system set up to immediately perform a Child-Pays-For-Parent transaction so that you can ensure that the transaction has enough transaction fee to be confirmed. Note that if the transaction is Opts into RBF, this method may not work.


How do I import private keys from Bitcoin-qt to Multibit client?

Manual Steps

Copy your public receiving addresses from Bitcoin-Qt.
Go to the Bitcoin-Qt console: click Help/Debug Window and then select the Console tab.
Run walletpassphrase [your password] [timeout in seconds] to unlock your password protected wallet.
Run dumpprivkey [Receiving Bitcoin Address] for each receiving address to be migrated to MultiBit. There may be hidden private change addresses in Bitcoin-Qt which don't show up in the receive tab. Run listaddressgroupings.
Copy the results of dumprivkey for each address (which are the corresponding private keys).
Start the Multibit client and create a new wallet.
Click Tools/Export Private Key after selecting the Do not password protect export file option.
Open the exported file in a text editor.
Below the private key generated by MultiBit, paste the private keys you have copied above. Remember to paste them before the End of private keys line.
After each private key, add a date that is prior to when you created the corresponding wallet. (You can check this date in the Bitcoin-Qt Transactions tab and scrolling to the very bottom.)
Repeat for all addresses you want to move to Multibit Client.
Save the key file and import it to the Multibit client using Tools > Import Private Keys.
In MultiBit, you may not see your total until you click Tools > Reset Blockchain and Transactions
In order to protect yourself from theft, delete the private key files.
Done!


What is the fee charged by MtGox to receive a wire transfer in AUD?

From the International Wire Transfers - Deposits section of MtGox's FAQ:

  Our bank charges a receiving fee of 1,000 Yen.  You can send wires in
  any currency to our bank in Japan. Funds sent in non-USD will either
  be added to your wallet in that currency if you have one, or converted
  to USD with a 2.5% exchange fee. Any fee charged by your bank or an
  intermediate bank will be deducted.

  If you plan to invest more than 50000 USD or equivalent on the long
  term in bitcoins, we need to know about you. In this case please use
  our verification system to get your account verified first. Submission
  of forged documents will result in declaration to the appropriate
  authorities.

  Not following the instructions written below can result in your funds
  being lost, or handed over to the local authorities while pending
  investigation.

  Also note that International deposits lower than 75 USD (or
  equivalent) typically result in only a small amount of funds being
  deposited into the receiving account or may be rejected because the
  amount of fees went over the amount of sent funds. This is due to
  intermediaries and banking fees.

Google tells me that 1000JPY is worth about 12AUD.

There is a mention of another method "Technocash" having issues, which likely means it's no longer available. It also mentions that AurumXChange will soon accept Australian bank deposits (no mention of withdrawals, but you could hope!).


How was transaction a4bfa8ab6435ae5f25dae9d89e4eb67dfa94283ca751f393c1ddc5a837bbc31b mined?

"Relayed" and "mined" are completely separate processes and should not be conflated.

The transaction is valid, so it was perfectly fine to mine it (i.e. include it in a valid block).

"Standard" is a more restrictive requirement, and as you say, this transaction is not standard.  That means that a default version of Bitcoin Core will not relay it, i.e. will not transmit it to other nodes on the Bitcoin peer-to-peer network.  But if the transaction reaches a miner some other way, they are perfectly free to include it in a block.

We can only speculate as to how that occurred in this case, but here are some possibilities:

Some people were running a modified version of the Bitcoin client (or alternative Bitcoin software) that does relay non-standard transactions.
The creator of the transaction sent it directly to a miner, by some means other than the peer-to-peer network.  Some miners or pools have web sites where anyone can submit a transaction.
The transaction was created by the miner herself.


Does an Invalid Transaction persist in the mempool?

A Wallet tries to spend more BTC than it current has

Technically, that would only be possible, if you try to spend an input (coin) that you can't sign (a.k.a. that you don't own).

Your local mempool (if you run Bitcoin Core or a similar fullnode) would reject the transaction immediately.
The transaction would not be broadcasted over the p2p network, because all nodes do reject transactions that are trying to spend inputs with invalid signatures (or inputs that doesn't exists)

  At some much later point, the Wallet gets more value.

The transaction is already made. It won't auto-update. It was already rejected.

Now one expect your local wallet knows the ("old", invalid transaction).

The only thing you can do now is to recreate the transaction (now with the correct inputs) and have it send over the network (and have it mined).

  The previously rejected transaction can suddenly be confirmed.

Invalid transactions cannot be mined and will not be broadcasted (broadcasting would be possible but extremely unlikely).


Why does Bitcoin adjust the difficulty every 2016 instead of 2048 blocks?

2016 blocks at an expected interval of 10 minutes are exactly 14 days. Likely the window for the difficulty period and interval were picked first and 2016 resulted from that.


Storing private key in apps and softwares that are local

BreadWallet & Seed: the seed is not your private key, it is used to generate the private key, and it is stored locally on your phone. However, the level of trust in me (or anyone else) is not sufficient, when saying this. You might want to do a source code review by yourself to be 100% sure. In general I use Bread as well, for daily usage, not for big amounts. It is a fairly well working wallet, and the value in it is comparable to the wallet with FIAT money. There are privacy issues with such wallets like BREAD (they are called SPV wallet), and the risk with these SPV wallets is, you trust someone else that they verify the bitcoin blockchain correctly. E.g. there was the risk to fall victim of the segwit2x fork, and then you would think you are on the original bitcoin, but in fact the provider (and all SPV wallets) would be on a new blockchain, which has changed parameters. So with SPV wallets, only use small amounts of money.

Electrum: this is similiar, the seed is used to generate the privkeys. Electrum is also an SPV type of wallet, and you trust the provider's blockchain. I am not sure about the possibility of code review though.

Wanting to be 100% secure and safe, you need to run a full node (aka bitcoin core client or similiar), and get used to the idea of cold storage. There is lots of links to cold storage here in the forum.


Can I mine with CGMiner or BfgMiner with both an AMD and NVidia GPU on the same MOBO?

Yes, it´s possible.

But, there are some things that you shound know:

1) Minning Bitcoin with GPU is almost dead, you should have read about other crypto coins. Specifically "scrypt" based ones.

2) Nvidia are not power efficient for mining... would be better if you just sell the nvidia and buy a amd with the same price. Unless you want to use your nvidia for gamming, video editing... dunno... just not for mining.

3) CGMiner = AMD ; CUDAminer = Nvidia ... diferentes programs. don´t no if they work well together... if it does, them you are good to go :-)

hope i had help you.


Which version of the JSON-RPC does Bitcoin use?

1.0, but with a couple of 2.0 features:

"Batch" calls are supported.

And the 2.0 error semantics are used.

Passing named parameters is not supported.  "Patches welcome" if you want to add full 2.0 support.


How do new nodes learn the topology of Lightning network?

This is done via the peer 2 peer network that comes along with lightning and is specified in BOLT 07 - routing-gossip. If you read the details you will see that you have to peer to a node in order to maintain a channel. But you could also establish peer2peer connections with other peers without the necessity to maintain a channel.

The peer protocol supports channel announcement messages that are being forwarded via the gossip protocol and query messages to ask for messages if a node connects for the first time to the network or was offline as asked.


Why does "Hodl Hodl" not seem to... support Bitcoin?

It's not a scam. It doesn't allow lending Bitcoin, you are correct. When it says it supports Bitcoin, it means it allows you to use Bitcoin as collateral for a loan.
For example, if you want to borrow USDT, you'd be allowed to post an appropriate amount of BTC as your collateral, receive USDT, then when you pay back your USDT loan, you receive the BTC you posted as collateral back. If you default on the loan, then the lender receives the BTC you put up as collateral.


What is the probability of generating 6 sequential blocks, less than an hour?

I would first like to comment that there is widespread confusion about how double-spending works. In particular, the question you've asked here is irrelevant. I urge anyone who is seriously examining this issue to carefully read Analysis of Hashrate-based Double Spending, which also examines the effect of changing the average time between blocks.

For your question as is - do you mean

The probability that in a given hour, the miner will find at least 6 blocks? Or
The probability that the event "the miner finds 6 blocks in a row, without the other miners finding blocks between him" will happen in a given hour?
Or something else?

The first option is relatively easy - If the average time between blocks is T, the miner's proportion of the hashrate is q, and you're looking at a time period S, he will find on average (Sp/T) blocks, following the Poisson Distribution. So the probability this will be at least 6 is

1 - \sum_{x=0}^{5} (exp(-Sq/T) * (Sq/T)^x / x!)

For example, if q = 0.5 then that's 8.4% for 1 hour, and for 1 day it's 99.9999999999999999999999%.

I'll need to work out the 2nd option, but the answer to the easier question "What is the chance to find 6 blocks in a row starting right now" is of course q6.


Can private keys be exported more than once in Electrum client so long as the've not been spent?

It seems like you don't understand how Bitcoins, private keys and bitcoin addresses work, so I'll make it simple:

As I explained to you here https://bitcoin.stackexchange.com/a/11479/2467 , you should not (more like MUST NOT) export your private keys from an Electrum seed. This can compromise all your private keys.

Your private keys are derived from your seed every time you make a payment to sign the transaction. So there's no need to see them, the client calculate them for you, use them, and hide them again. all you need is to keep your seed safe.

If you want to know the balance in your offline Electrum wallet's addresses you can use a seedless wallet on an online computer. To do that look for your Master Public Key in the offline Electrum, and restore from your MPK on an online computer.

You don't need your private keys to know the balance on their public addresses anyway. Public addresses are public and if you have already received on them, you can check their balance on Blockchain.info


How frequent are side-chain reorganizations of various lengths?

Random reorganizations of length more than 1 are rare. To get a fork of length 1, you need two miners find a winning nonce at nearly the same time. To get a fork of length 2, you need the same (1) happen right after a fork of length 1 and (2) have those miners mine on different sides of the fork.

However, such fork happen once in a while. See this answer for some statistics. And even longer forks happen due to bugs in Bitcoin code, like this one in March 2013.


Today I did my second transaction for just 0.005 BTC but 2 hours after, it's unconfirmed yet. The transaction is in the block 320385 and it is orphaned.

Is it in a block, or is it unconfirmed?

  block 320385

Which block 320385? This one or this one?

  today are 10 orphaned blocks and this is a high value according the graphic.

Huh, that's pretty odd. Screenshot for posterity:

It's unusual for blockchain.info to be wrong, but it definitely is in this case. This is the best chain that my client can find:

2014-09-13 01:59:04.460 UpdateTip: new best=000000000000000000652d48e212a9fdb16ce57d7097b76200a2fe5e9cd643fe  height=320406  log2_work=80.639033  tx=46574398  date=2014-09-13 01:56:16 progress=0.999993

The chain that blockchain.info thinks is invalid appears valid to my client. They'll probably have it sorted out in a few hours.


This is normal - importing an address does not produce any output, and you will see null in the debug console.


Why doesn't address contain a full scriptPubKey?

There are several reasons for this, some historical and some more recently:

At first, addresses were probably not intended to cover everything Bitcoin Script could do. They were a fallback for the case where the recipient was not online (we're calling addresses still addresses because they were originally IP addresses you'd connect to to request a scriptPubKey). So at the time they were introduced, a focus on size was probably far more relevant than considerations about flexibility. Note that addresses have a 'version byte' (which was intended for upgrading the format, not for identifying altcoins).
Later, when P2SH was introduced the concern about flexibility went away entirely: P2SH permitted conveying any spendability concern in a constant-size address. Furthermore, it removed the concern of senders needing to create larger outputs. The fact that I am using a multisig wallet shouldn't mean you have to pay a higher fee when sending to me.
When SegWit was introduced, P2SH was no longer sufficient to encode any output, for reasons of efficiency and security. Despite the need for a new format anyway, we still chose not to propose something that could encode arbitrary scriptPubKeys. The reasoning given in BIP173:

Why not make an address format that is generic for all scriptPubKeys? That would lead to confusion about addresses for existing scriptPubKey types. Furthermore, if addresses that do not have a one-to-one mapping with scriptPubKeys (such as ECDH-based addresses) are ever introduced, having a fully generic old address type available would permit reinterpreting the resulting scriptPubKeys using the old address format, with lost funds as a result if bitcoins are sent to them.


Does a transaction always get verified/processed by ALL full nodes in the network before being added into the block by some mining node(s)?

Does a transaction always get verified and processed by ALL full nodes in the network before it is added into the block by some mining node(s)?

Technically no, but only because of the way you've phrased the question. In a decentrilized network, there is no way to know what ALL nodes have done.

However, EACH particular full-node (including miners) will verify every transaction in a candidate block before updating their own blockchain state to the new head. Since no one will include the invalid block, it doesn't accomplish anything to produce one.


What can be done to mitigate the risk of a Finney-attack?

The key to understanding why the Finney attack isn't really that big of a deal is understanding the business case for accepting 0/unconfirmed transactions. An online merchant doesn't usually have to accept such transactions since they probably do batch-shipping anyway. It's not required from an integration standpoint since the API includes many options to simply not return transactions without confirmations. The only business case that requires the acceptance of 0/unconfirmed transactions is when your customer is standing directly in front of you and won't be around for 10+ minutes. In such cases, a Finney attack isn't feasible and here's why:

Imagine I'm a scammer wanting to use the Finney attack against you, the honest merchant. I've spent a few grand and bought myself 3 GH/s worth of Radeon 5830 rigs. This number isn't arbitrarily chosen, I specifically picked it to make for easy math - 3 GH/s will net you about 1 block per month at current difficulties. Given that actual brick-and-mortar stores are closed for about 8 hours per night on average, this means that 1/3 of my found blocks will occur outside of business hours so on average I get a chance to double-spend with a Finney attack every 45 days.

Now as with all mining, there's no telling when you'll hit that lucky block so if I'm dead set on executing this attack I have to stay hypervigilant because once every 45 days I'll get an alarm of some sort telling me to go spend money at my target's store. I have to get there quickly because if I don't make my purchase and remotely trigger the release of the block fast enough, that block will get solved by some other miner and I'll lose my chance. So let's say on average it takes me 5 minutes to get somewhere, pick something and make a big purchase - I've got a 50% chance of failure, so now I'm able to execute my attack about once every 90 days.

Mining isn't cheap - my 3 GH/s setup draws something like 2 kilowatts, add in another 800 watts or so for cooling and at my local electricity costs it runs me about $8 a day to try for this attack. Multiply this by the 90 days it takes on average for me to be successful and I have to be successful to the tune of $710 just to break even. I'd make better money mining! Keep in mind that I've spent 16 hours a day every day for three months waiting for that alarm to go off too, so even if I double-spend $1420 (double my costs) I still only make $236.67 per month for my trouble - 49.3 cents per hour.

Oh and once you've made the purchase there's still the gap between then and releasing the block. If a block is found during that window, you've actually spent that money now. This particular attack is not without risk.

So there's something of an answer - not how to mitigate the attack but why the attack doesn't really matter. Online merchants don't need to accept 0 confirmation transactions since your stuff probably won't ship within 10 minutes anyway and brick-and-mortar merchants add a delay to the transaction process that makes the attack unfeasible. Even without the delay, the transaction would have to be positively huge to make any sort of profit and the attacker still stands a large risk of actually spending the money anyway. I don't really see this taking off.


How fast is the NXT blockchain growing in 2014?

NXT blockchain size is now around 1.5GB in 18 month that's roughly 83MB increase per month.


What are the bandwidth requirements of a mining rig?

With pooled mining, at 900Mhash/s, you'll need a new work unit every 3 seconds or so. Each work unit requires about 256 bytes out and about 768 bytes back. So that's 700 bits per second out and about 2,000 bits per second back. Essentially, zero.

Solo mining is a bit harder to estimate. You will need to receive and relay all new blocks as they are discovered, you will need to receive all transactions that are relayed by nodes you connect to. You can heavily limit the number of other nodes you are willing to connect to, but this will impact your stale shares level and may reduce your transaction fee income.

I measured the bandwidth usage of the client with 60 connections (you can drop down to 8 if you want) and made sure my sample included discovering a block. The inbound average bandwidth was 12Kbps (1.50 KB/s) and the average outbound bandwidth was 9Kbps (1.04 KB/s). So that should give you an idea what solo mining would be like.

Notice that the bandwidth usage is basically insignificant in both cases.

For multiple rigs, there is no adjustment in the solo mining cases. All the rigs can be configured to query the single client. The client's bandwidth requirements will be the same.

However, there is a change in the pool mining case. When a new block is discovered, each miner will need a new work unit immediately since its existing unit is stale. This happens on average about every 10 minutes. Effectively, increase the bandwidth requirements by .5% for every additional mining rig. Note that if you run more than one instance of the mining program on a rig, count it as more than one rig. (This still assumes the rigs total 900Mhash/s.)


If I understand multi-PPS correctly, it's really simple.

How does multi-PPS work: Miner Alice registers with Bob's pool: she gives Bob one of her addresses (to use for payouts) and Bob gives her one of his addresses (to use in coinbase transactions). Bob will give Alice credit for mining shares which pay that coinbase address, and at defined intervals or compensation levels, he'll send payment to her payout address. Alice also registers with Charlie's pool, which gives her a different coinbase address that does the same thing.

Using a protocol like GetBlockTemplate, Alice gets a block template from any full node and inserts a custom coinbase transaction with two outputs: one that pays 50% of reward+fees to the coinbase address from Bob's pool, and one that pays 50% to the coinbase address from Charlie's pool. When Alice finds a share, she submits a merkleblock for its coinbase transaction, plus the coinbase transaction itself, to both pools. Both pools give her 50% credit for that share based on difficulty, pool fees, and other pool rules. The same thing happens for a block, except that Alice only has to submit the full block once so it gets on the block chain---the pools will still give her credit for it as a share once they see it on the block chain. At the defined reward interval, which is up to pool policy, each pool pays Alice's payout address based on the number of shares she submitted and the percentage each credited towards the pool.

Two pools each with 50% is the example here, but in reality Alice will be able to distribute her 100% among as many pools in whatever proportion she wants, provided it's technically possible and allowed by pool policy.  Because this is Pay-Per-Share (PPS), Alice's variance is fully determined by share difficulty---so Alice makes the same amount of money mining for a tiny pool as a giant pool as long as the share difficulty is the same.

The kicker---if I understand correctly---is that multi-PPS also reduces variance of pools to the average of all the pools their miners mine in.  For example, if all mining was done in pools and every miner mined in every pool (no matter how little of their reward they dedicated to any particular pool), every pool would have variance exactly equal to that of regular block creation (e.g. 99.8% chance a block will be mined within 60 minutes: 1-exp(-1/10.*60)).
Can multi-PPS prevent mining centralization: You can't prevent what has already happened. :-)  Seriously, multi-PPS isn't a cure-all (and Mr. Rosenfeld doesn't claim it is), and there are still economies of scale that benefit large pools---including things that no Bitcoin technology can fix, like marketing advantages.  What multi-PPS offers is the ability of small pools to have the same variance as large pools, equalizing one significant competitive advantage large pools currently enjoy.

Multi-PPS has the additional highly-beneficial advantage that, in order to implement it, block-creation policy must be separated to a certain degree from pool payouts---in other words, if Alice mines in both Bob and Charlie's pools at the same time, neither Bob nor Charlie will have as much centralized control over what transactions Alice creates, further decentralizing mining.

However, this is also multi-PPS's primary weakness and likely the reason nobody has implemented it in the 15 months since Mr.  Rosenfeld first described it: current mining and pool software isn't fully compatible with decentralized mining. And, except for Bitcoin Core developer Luke-Jr, I don't know of anyone focusing on making decentralized pooled mining possible. (Perhaps everyone else who really cares about decentralized pooled mining has already switched to P2Pool.)

An additional weakness is that most people may not care enough to use multiple pools, or that they have come to trust certain pool operators. Because multi-PPS makes small pools more competetive, hopefully they'll be able to innovate to make themselves more desirable to miners. For example, they can make immediate payouts for each share received using a micropayment channel, significantly reducing the trust miners need to place in the pool operator.


How do I Transfer Bitcoins If I have a watch-only account with the Private Key

Transfer control to a new Electrum wallet

If you have the private key you can, in principle, either import the key into a new wallet or sweep it into a new wallet.

Electrum supports sweeping and doesn't encourage importing.

Importing doesn't involve a transaction or transaction fees but is more vulnerable to subsequent loss. The recovery-words also known as recovery-phrase or seed-phrase, cannot be used to recover control over money associated with an imported key. You'd need to make regular backups and test recovery from backup.

Sweeping involves a transaction but is regarded as safer.

Transferring Bitcoins

Note that you are not really moving bitcoins. The record of who controls what money is recorded in the public Blockchain which every full-node wallet has a copy of.

A watch-only wallet lets you observe transactions relating to money controlled by other people (or by other wallets). So there's no sense in which your bitcoins are in a watch-only wallet. You could as well say that everyones bitcoins are in every full-node wallet.

Electrum account

Electrum is a wallet, not an account. Your money is not stored by, managed by or controlled by Electrum.org. You control your money using software you install on your own computer.

Watch-only

Watch-only wallets are a useful feature if you keep your private-keys in cold-storage - such as in a hardware wallet.

They are also a favourite method by which scammers trick people out of money.


After a lot of search I finally found what was causing the issue. Apparently with Asus routers the AIProtection regarding malicious site blocking will actually block the connection to the pool. Disabling this setting in the router resolved the issue.


How to alter user's data in block in blockchain if i want to change user's details

In blockchain each user's data stored in seperate block, right?

No, blocks do not store user data, they store transactional data.

A user of bitcoin can create a wallet using software of their choosing, and the wallet will store their keys that allow them to spend coins. The blockchain simply has a record of transactions, but no accounts/personally identifying information.

Instead the blockchain just specifices where the coins exist (in a certain address as a UTXO), and then users can spend coins if their wallet software contains the keys to that address.

So you never have to go and change an old block in order to spend coins. If you're trying to spend coins that were last sent 10 blocks ago, then you just need to sign using the key that corresponds to the address those coins exist at. This will create a new UTXO, with your transaction specifying which new address the coins will be locked into.


You can not send transactions that small. The minimum is 0.00005460 BTC, anything smaller is called dust and will not be accepted into the network. You will most likely need to pay a fee with something with this little priority, which will cost you more than the amount you're sending. Bitcoin is not intended for micro transactions. Also bear in mind that collecting a lot of transactions this small will cost you more in fees to spend them again than the value of the coins.


Why bitcoin rise causes altcoins to drop?

There are a few reasons, some examples (not limited to the below of course):

People will buy coins before forks, in the hope of claiming both coins and getting a "dividend" even if they don't believe the fork coin has value, they can simply sell at any price to get "free" money.  Possibly these people will then sell the coin they bought for bitcoin anyway, benefiting from the rise as other people bought in, and the sale of the fork.

Another possibility, if you're a BTC maximalist (and a "Whale"), is driving alt coins up, after the coin has pumped, you can sell back for BTC, increasing your BTC holdings.  Buying randomcoin and a few cents, driving the price up, or waiting for an announcement etc, will mean, again, you can safely move back to BTC increasing your holdings.  There's some circumstantial evidence of this happening.

People realising "gains" from alts, moving to BTC, people tell you to "diversify", but that's not always the best long term strategy, especially if your altcoins have experienced a gain, moving profits back to BTC (in lieu of FIAT) makes sense.

Dont forget the power of FOMO (Fear Of Missing Out), people will buy anything if the price is rising!


How to receive payments online to single address per user in scalable way?

Use Bitcoin Core in server mode and use it's notification functions:

server=1
blocknotify = curl\yoururl
walletnotify = curl\yoururl

Set them up to make a call to your app.

This way, you won't be making expensive RPC calls to Bitcoin Core. You will only be receiving notifications for operations  that Bitcoin Core itself already is making. So you won't bring any extra load to Bitcoin Core. You will be limited by it's own scalability.

  how "big players" like Cryptsy do receive payments?

Most big players are relying on Bitcoin Core's scalability running in server mode without bringing extra load to it as far as I know.

  But I heard that it is possible to change transaction id in block
  chain, so is such solution safe?

Not after they have received a confirmation. So the method you described works if you wait for the blocknotify call for a TX before you update your users balance.


For set up the dns seed node, the parameter can be directly specified in chainparam.cpp if you are using bitcoin source in line that reads as "

vSeeds.push_back(CDNSSeedData("someaddress.com or IP addy", "someaddress.com"));

And  you need to add all the seed node IP address to the A records where  you have your domain name from. You might need to do it on your own if you have a privater server or can use cpanel depending on the scenario at your end. I did it via cpanel as I have domains hosted with siteground.


Do thin clients leak which addresses you own?

Electrum:

No protection, the server you are connected to knows every address you own and will own in the future. If you use Tor your IP address is hidden, but the addresses are still associated. Bloom filters are not in use for this client.

MultiBit

In theory the bloom filter can be modified to include junk data to hide your addresses with loads of fake ones, currently this is disabled for speed and so there's no protection. Your peers know your IP address and the contents of your wallet, Tor is not supported.

Mycelium

I believe this client uses BitcoinJ (same as MultiBit) so the same caveats apply.


Most important spec to look for on a GPU for scrypt mining (e.g. Litecoin)

I think the important factors for scrypt in OpenCL are as follows

GPU core clock rate
Memory clock rate / memory bandwidth
Memory bus width / channel
Computation Units
Processing Elements

You can check out in Programming Guide of AMD Accelerated Parallel Processing.

single or double precision of floating number does not matter. Either SHA-256 or scrypt is doing integer arithmetic operations.


Blockchain.info Payment API -> Callback gets a 302?

normally it has to be 200, the 302 mean that the requested resource resides temporarily under a different URI.

Dont block "GET" requests on your code because blockchain use GET method to send your notifications about the transactions.

Use your full domain name including the leading www example :

http://www.example.com/callback....

In case of https ! make sure you include it in the callback URL.


Is it possible to pay part of a Bitcoin to someone?

Yes! To send $200 at a Bitcoin price of $800/BTC, you'd send 0.25 BTC. Bitcoins are highly divisible, up to eight decimals behind the point. The smallest subunit of a bitcoin is currently still less than 1/1000 of a cent.

Many Bitcoin clients will also keep track of the current value of Bitcoin and allow you to enter the amount of a payment either as bitcoins or your preferred national currency.

For example, when I want to send someone $5 from my phone, I could either enter BTC 0.00625, or $5 to set the amount.

As Bitcoin has become so valuable that one bitcoin is worth much more than many things we want to pay for, some people have moved to denominating prices in mBTC, i.e. millibitcoin, which are 1/1000 of a bitcoin.


Who do i see the commissions taken by miners?

From Transaction fees on the Bitcoin wiki:

  The transaction fee is processed by and received by the bitcoin miner. When a new bitcoin block is generated with a successful hash, the information for all of the transactions is included with the block and all transaction fees are collected by that user creating the block, who is free to assign those fees to himself.

So yes, the fee is collected by the miner of the discovered block. If you look to a random block on the blockchain site you see that the fees are 0.03334571 BTC (in that specific block).

The transaction fee you pay could be different depending on which wallet software you use. For example the fee from multibit is 0.0001 BTC. You can also pay no fees, but then there is a chance that your transaction takes a lot of blocks to be included in the blockchain.


Transaction ID not found- Status still unconfirmed after a month?

After 72 hours the transaction will get purged from the mempool if no miner has picked it up. Try resending the funds and include a transaction fee so that the miners will expedite your transaction.


Bitcoin RPC: Can I test for standardness?

The top-level type parameter of the decodescript RPC can tell you if a scriptPubKey is standard.  For example:

bitcoin-cli decodescript deadbeef
{
  "asm": "OP_UNKNOWN OP_CHECKSIGVERIFY OP_UNKNOWN OP_UNKNOWN",
  "type": "nonstandard",
  "p2sh": "3PbdV4zdrjtFD4fyYebGR4oxeatrSzb2d1",
  "segwit": {
    "asm": "0 5f78c33274e43fa9de5659265c1d917e25c03722dcb0b8d27db8d5feaa813953",
    "hex": "00205f78c33274e43fa9de5659265c1d917e25c03722dcb0b8d27db8d5feaa813953",
    "reqSigs": 1,
    "type": "witness_v0_scripthash",
    "addresses": [
      "bc1qtauvxvn5usl6nhjktyn9c8v30cjuqdezmjct35nahr2la25p89fssxejht"
    ],
    "p2sh-segwit": "37CpdZEgXUB7LS7rvTLsYopRifDf76eZrZ"
  }
}

However, I don't know of a way to test whether a P2SH/segwit redeem script is standard using the RPC.  If, instead, you want to know whether or not a particular spend would be accepted to your node's memory pool, Bitcoin Core's development branch (master) features a new testmempoolaccept RPC; here's it's current help:

testmempoolaccept ["rawtxs"] ( allowhighfees )

Returns if raw transaction (serialized, hex-encoded) would be accepted by mempool.

This checks if the transaction violates the consensus or policy rules.

See sendrawtransaction call.

Arguments:
1. ["rawtxs"]       (array, required) An array of hex strings of raw transactions.
                                        Length must be one for now.                                                                                2. allowhighfees    (boolean, optional, default=false) Allow high fees

Result:
[                   (array) The result of the mempool acceptance test for each raw transaction in the input array.
                            Length is exactly one for now.
 {
  "txid"           (string) The transaction hash in hex
  "allowed"        (boolean) If the mempool allows this tx to be inserted
  "reject-reason"  (string) Rejection string (only present when 'allowed' is false)
 }
]

Examples:

Create a transaction
> bitcoin-cli createrawtransaction "[{\"txid\" : \"mytxid\",\"vout\":0}]" "{\"myaddress\":0.01}"
Sign the transaction, and get back the hex
> bitcoin-cli signrawtransaction "myhex"

Test acceptance of the transaction (signed hex)
> bitcoin-cli testmempoolaccept "signedhex"

You could also test out the complete script using regtest.  By default regtest has the standardness checks disabled, by you can re-enable them by starting bitcoind with the -acceptnonstdtxn=0 parameter.


Big disclaimer: you really shouldn't do this. Transaction prioritization works based on fee per size, so that's what you should be configuring.
As for an explanation of what you're seeing: the block explorer you're using is showing the wrong size. For fee computations what you need is the vsize, not the serialized size. This is the size that takes the discount for witness data introduced by BIP141 (segwit) into account.
The vsize of your transaction is 141, not 222.


What are the risks of a lower-than-95% activation threshold for soft forks (particularly SegWit)?

There are two related risks:

Activating without a majority of hashpower supporting it over the long term.

Let's use BIP 66 as an example. Imagine it had activated at the 95% threshold, but 30 minutes later, more than half of the miners reverted to the old implementation that doesn't support BIP66.

What you now have is a situation where nodes that enforce the new BIP66 rules will not come to consensus with nodes using older rules.

There's no perfect solution to this problem. As a miner, how can you prove that you won't change implementations after the activation point? The solution so far is to require 95% agreement to upgrade, on the theory that as long as less than 45% falsely signals, you'll be OK.
Miners running old code may still produce blocks, fooling SPV/non-upgraded clients.

At some point, someone will probably make a block that complies with the old rules, but not the new rules. Bitcoin Core won't do this by default, but it's probable that at least one miner will modify their code, or run some weird set of software, or even maliciously create a block to make a 51% attack easier.

Old nodes will accept this block, and try to build on it. Even if non-upgraded miners are in the minority, they're still going to manage to build chains of several blocks by pure chance sometimes. These will be orphaned eventually, but in the short term people may rely on them being valid, and be harmed by that.

It's worth noting that lowering the threshold to 60% would likely still not activate segwit. Segwit signalling is currently about 30%.


How do I synchronize my wallet quicker with bitcoins already sent?

Yes there is, get a better Internet connection and a faster computer.

You need a better Internet connection because you are downloading the whole blockchain (I guess you're using bitcoin-qt or the like) and it is a few GB.

And you need a faster computer because as you download the blockchain you are processing those transactions and updating your DB, so a faster computer will lower the time needed to process that information.

Until you have downloaded the whole blockchain you won't be able to spend bitcoins with your wallet because it will wait until all transactions have been processed to know the amout of bitcoins remaining in it.


Is Bitcoin's mining difficulty adjusted if it fails to solve a block

No,

According to the Bitcoin Wiki, the difficulty is only adjusted every 2016 blocks.

  The difficulty of the mathematical problem is automatically adjusted by the network, such that it targets a goal of solving an average of 6 blocks per hour. Every 2016 blocks (solved in about two weeks), all Bitcoin clients compare the actual number created with this goal and modify the target by the percentage that it varied. The network comes to a consensus and automatically increases (or decreases) the difficulty of generating blocks.

However, Bitcoin Cash has a solution to the problem.

If less than 6 blocks have been mined in the past 12 hours. It becomes 20% easier to mine blocks.


Are there any poker websites that accept bitcoins?

The best resource to look for a poker site is the gambling section on bitcointalk.org.  There are a lot of smaller sites advertised in that section of the forums trying to cater to the poker players who want to use their bitcoins.

I think I've also seen people will to trade bitcoins for money on bigger poker sites, but I do not believe any major sites accept bitcoins directly at this time.


What are some good resources for understanding Bitcoin?

I wrote the "New to Bitcoin? Start here!" post at bitcointalk.org.

OrigamiRobot, I highly recommend that you read that introduction before proceeding on to anything else, especially the original whitepaper, which is incredibly unapproachable for the average person.  After you finish it, come here and ask about the things that still confuse you--Bitcoin is very complicated, and it can take a while to wrap your head around it!


Automatic savings account using 2 wallets?

I answered my own question.

I used the following PHP code...

$savings = 0.001;
$txfee = 0.0001;
$amount = floatval(($bitcoind->getbalance() - $savings) - $txfee); // getbalance() returns 0.005
$outputAddr = [
    '1GAnaq3atnKkxFsUC4Vky8Ysb751LbxHSC' => $amount, // wallet 1 address
    '122ExHr92bEgJbepSHmQCruCRR3YRR6dx5' => $savings // wallet 2 address
];

$rawtxUnspent = [];
$unspent = $bitcoind->listunspent();
foreach($unspent as $tx) {
    array_push($rawtxUnspent, [
        'txid' => $tx['txid'],
        'vout' => $tx['vout']
    ]);
}

$rawtx = $bitcoind->createrawtransaction($rawtxUnspent, $outputAddr);
$signedtx = $bitcoind->signrawtransaction($rawtx);
$senttx = $bitcoind->sendrawtransaction($signedtx['hex']);

$senttx === false ? print $bitcoind->error : var_dump($senttx);

and got this output...

string(64) "bae6d6978da7a50422a943ac42017c64478169ce87a264d7cedbaa5a869558b4"

The transaction is confirmed and worked exactly as I hoped. :)

https://blockchain.info/tx/bae6d6978da7a50422a943ac42017c64478169ce87a264d7cedbaa5a869558b4


What prevents a transaction being added to the block chain twice?

In Bitcoin, each full node follows all transaction activity on the network by digesting the blockchain. To that end, every full node enforces their ruleset on the data that they receive. As (usually) the full nodes all follow the same ruleset, every node indivdually converges on the same state.
Hereby, the blockchain's transaction data represents a journal of the activity, which if digested according to Bitcoin rules yields a ledger of all balances at the current blockchain tip, the Unspent Transaction Output Set (UTXO Set).

Every full node maintains this complete set of UTXOs. Each UTXO is uniquely identifiablee by the transaction it was created in, and the position in that transaction's output list.

When a transaction is confirmed, the UTXOs in the transaction inputs get spent and removed from the UTXO set, while the transaction's outputs in turn get added to the UTXO set. If someone tries to replay the same transaction again, the referenced inputs are no longer in the UTXO Set as they were previously removed and the transaction is just as easily identified to be invalid as a transaction spending made-up UTXOs.


If Bitcoin is traceable, how bitcoin scams are exist?

Bitcoins can be exchanged to dollars in questionable exchanges like BTC-E or LocalBitcoin. These exchanges are not interested in the source of Bitcoin, do not co-operate with authors (police) and thus scammers are able to do cash out stolen Bitcoins. You can only see the Bitcoins go into the exchange, but the exchange won't give you, or the authors, the details who is the user who is cashing out.

Furthermore, when more legit exchanges try to make sure they follow Know Your Customer rules and demand the users to show the proof the Bitcoins they are selling are not stolen, there is a backslash from Bitcoin community. Some libetarian parts of Bitcoin community do not wish to destroy Bitcoin fungibility, e.g. making sure that criminally obtained Bitcoins cannot be discriminated from legally obtained Bitcoins. This is because much of Bitcoin transactions are fuelled by dark markets which are outright illegal.

Please see recent discussion with Evolution exit scam.


How can one remain relatively anonymous while using Ripple?

Current client doesn't expose it yet, but each account is really an Account Family of un-linkable addresses which can be single use.

https://ripple.com/wiki/Account_Family


unrecognized output wallet when using Electrum to send bitcoin

I don't know how Electrum chose that wallet for sending the payment , is the choosing of the wallet automatic from Electrum ?

Maybe its a change address. You can read about change addresses in the below links:
What does change address mean inside Electrum wallet?
What all the addresses are in my Electrum wallet?

I am not sure why change address is starting with "3" which can be a p2sh-segwit address because input address bc1qxesjp5g4d23kpt9xghwxlu4mfhu9xxrehp0ytnm023ely43kdh9spsy4k7 is most likely an address from 2 of 3 multisig wallet with p2wsh addresses.


The block hash has to be below a certain value and the block hash depends (among others) on the nonce and on the Merkle root.

The Merkle root depends on the sequence of transactions. Note that it's a sequence, not a set, meaning the order is important.

Different miners choose many different lists of transactions. For every list of transactions with the other fields which go into the block hash, chances are there is no 32 bit nonce which will make the block hash low enough to qualify as a new block on the blockchain. So miners add a transaction, or remove one, or permute some to get a different Merkle root all the time.

I'll just calculate the time an AntMiner S9 with a hash rate of 14 TH/s takes to go through all the numbers in a 32 bit field (2^32 hashes) for you:

2^32 H / (14 TH/s) = 2^32 / 14 / 10^12 * s = 0.30678 ms

To answer your second question: Network traffic takes longer than 0.3 ms. To give you an impression on it: In fiberoptic cables, signals travel with about a third of the speed of light. With the speed of light, something travels 90 km in that time, so signals in fiberoptic cables can travel about 30 km in it. Many miners are more than 90 km away from each other and attempting to travel more than 90 km in that time turns out to piss physicists off, a lot.


If I buy Bitcoins at Coinbase.com, should I leave them on Coinbase.com, or should I move them into a Bitcoin Wallet? Why?

This depends solely on trust and ease of use.

Trust

Who do you trust more? Coinbase's security setup or your own? Some things to consider:

Coinbase makes profit from it's website and so wants people to use it. For this reason they benefit from taking security serious. They probably have a dedicated team thinking about how to improve the security of their system.
You own computer, let's say running Windows, is likely very much less secure. Any virus or malware can steal your coins. Also, without a backup, a disk failure will make you lose all your coins.
While Coinbase's security might be much stronger than yours, it is very more likely to be targeted by hacking attempts. They store a very large amount of coins, while you only store your own.

Ease of use

Running a Bitcoin wallet yourself can sometimes be some hassle, while e-wallets can offer you extended functionality and features.

You will need to download and sync the complete block chain, which takes around 9 GiB or storage. There are also clients that don't require you to do this, but still they have to sync all the time and use network bandwidth.
You will need to worry about backups. You can trust Coinbase for taking backups regularly. If you want your own wallet to be safe, however, you will have to backup them yourself.
Much e-wallets like Coinbase offer extra functionality, like links to information on blocks, transactions and addresses. Also many of them have a Mobile App that you can use to access your wallet with.


You can delete them with the second click options if you think so.

If you ever receive coins in that imported addresses you won't know if you don't have them imported in Electrum or in other client. Or if you've registered somewhere signing messages with it (like in #bitcoin-otc)

In case you want to keep them you will have to keep a backup of those keys separately by copying the wallet file as they won't become part of your Electrum seed.


Is it possible to set a dynamic -minrelaytxfee?

No, there is no way to do that.

However you could make your mempool smaller and that would have a similar effect. The mempool has its own minmempoolfee. The in-practice minrelayfee is the maximum of the -minrelaytxfee and the minmempoolfee. The minmempoolfee will change when the mempool becomes full, and decreases when it has space. So if you set your -maxmempool to be much smaller, you would get a similar effect to changing -minrelaytxfee dynamically.


What economic incentives would help wider geographic distribution of bitcoin nodes?

No incentives to run nodes are required. As people in these countries are presented with more use cases to use bitcoin, organic growth in the number of nodes will follow.

International money transfers and a superior alternative to M-Pesa for retail transactions are both attractive areas for growth in some of the areas with limited node counts today.


Bitcoin system with payins and payouts using bip32

For some code examples, take a look at Synala -- http://synala.com/

Or on Github:  https://github.com/peterscott78/synala/

Supports watch-only BIP32 wallets, user registration, etc.  Will also gather the unspent inputs and format them into an outgoing tx, allows for offline signing, etc.

However, doesn't allow for users to automatically send funds from their account.  Due to security reasons, no private keys are stored online, and sends must be manually processed by admin.

Nonetheless, will give you some good example code to build on.  Hope that helps.


Why non-SegWit nodes do not reject SegWit block since there is no witness?

So output is changed to anyone-can-spend output? If so, what prevents it to be spent by anyone not the intended recipient?

No, it is not changed.

A SegWit output is anyone-can-spend from the view of old nodes. This means that to them, it can be legally spent without signature.

To new nodes, it has a different meaning, and requires a (valid) witness to be spent. Nodes that care about SegWit outputs enforce this rule, and will not accept a blockchain that spends without such a witness.