When creating a block, who actually generates the 25 bitcoins that act as a reward?

The 25 BTC are actually generated out of thin-air. Essentially every peer in the network knows to accept blocks where the first transaction in every block should be of maximum 25 BTC. If it's more, then the block is considered invalid. Note that these are the coins given to the miner since the miner is the one creating the block and can therefore set to which address these 25 BTC go to. Also note that 25 is not an hardcoded value, it changes with time. Again, there's another rule "programmed" into each peer where they can calculate the current reward. Currently the maximum allowed is 25, but every certain amounts of blocks, peers know that the value needs to be halved - it was originally 50 BTC, now it's 25, next it will be 12.5.

So to answer your question, peers collectively know that the rule is to generate coins out of thin air every so often, and the person that gets them is the person that mined the block. You might be asking: what if a dishonest peer changes the 25 BTC transaction to go to himself rather than the miner. They can't do this because they would need to re-mine that block (changing contents of a block also changes its hash).


Do I need to register my shiny new Crypto with some agency if I want to pay someone with it?

If you agree to buy your neighbour's old lawnmower using buttons and lint as payment, the SEC don't want or need to know about your novel form of payment.
The same generally applies to other forms of payment.
Generally where a taxable event occurs, you have to work out the equivalent amount in some government approved currency. For example, if the price of lint skyrockets and your US neighbour sells her lint stockpile for huge profits, she'll probably have to work out the dollar equivalent and pay some sort of capital gains tax. But this is different from registering lint as a currency - you don't have to do that.
Where government agencies mostly like to be involved is when  you are setting up some sort of financial institution or money handling business like a payment processor. The creation of BItcoin did not involve the creation of any financial institutions or money handling businesses. In fact it was designed to do away with that sort of third-party that needs to be trusted. Such institutions may have crept in and taken over a lot of Bitcoin usage but that does not mean the SEC are after Nakamoto to register Bitcoin. If Nakamoto had needed to register Bitcoin in 195 countries beforehand, it would never have got started. Ditto any cryptocurrency or lint-based system invented today.
Of course all this depends greatly on jurisdiction. The rules in Burkina Faso may differ from those in Ecuador.


Bitcoin trading volume: what's going on?

This question could be asked of any financial instrument. Volumes decreasing is not a bad or good sign. It's simply something that occurs when volatility decreases. The market theory behind it might go like this.. Price has fallen to such low points sellers are no longer interested in selling. Buyers are still hoping for lower prices. This effect causes the price to trade within a range where anytime the price rises to an acceptably high level sellers begin to sell again and any time it reaches an acceptably low level buyers begin to buy. As traders notice the price is range bound more traders stop trading. This compounds decreasing volumes and also decreases the trading range. Eventually this will lead to reduced trading interest which can then lead to the price breaking out of the range in the direction of least resistance (as traders give up their respective buying or selling).

Sorry there is no provable answer to your question, as this is all market theory. However, if you were to look at different financial instruments historical volumes you would see many instances similar to what is currently happening in bitcoin's market volumes. This is a common pattern in markets and is normally described as not predictive of future events (range trading is often thought as having a random breakout direction).

https://en.wikipedia.org/wiki/Triangle_%28chart_pattern%29#The_symmetrical_triangle


bfgminer is a fork of cgminer. bfgminer allows the use of Get Block Template (less trust in the pool), but they're otherwise functionally the same.


How do I broadcast an OP_RETURN transaction using bitcoin cli

Bitcoin Core allows you to create transactions with up to 80 bytes of arbitrary data in an OP_RETURN output. You do this by using the raw transaction process (using createrawtransaction or fundrawtransaction) or the psbt process (using walletcreatefundedpsbt). For all of those commands, when you specify the outputs, you can specify one that is like: {"data":"<hex string>"} where <hex string> is the data you want to send as a hexadecimal string. This will create a transaction with an OP_RETURN output of 0 value with whatever data you specified in <hex string>. The transaction can then be signed and broadcast just like any other raw transaction or psbt.


How can Bitcoin protect itself from a "dumb majority soft fork"?

If the users who want to keep the use of timelocks do not constitute even a significant minority of users, they're simply out of luck. There's no mechanism for a minority to force the majority to tolerate rules the majority doesn't want.

Assuming the users who want to keep the user of timelocks are significant, they first communicate their intention to miners to take their business elsewhere. If they leave, they will take a good sized chunk of the ecosystem with them, reducing the value of the remaining system.

Even if they're not a majority, most users will not want even a significant minority to leave. So they can put additional pressure on the miners. The ultimate threat if the miners don't do what an economic majority of users want is that users can change the hashing algorithm changing the miners' precious ASICs into expensive space heaters. Or, to be more precise, changing them into expensive space heaters a bit faster. The miners definitely don't want that.


Are there mixing services or online wallets that are explicitly compliant with anti-laundering laws?

"AML-compliant" bitcoins are not anonymous/anonymizable by definition since most AML laws require the origin of funds to be traceable to real person, at least for bigger transactions. The "tainted" bitcoins are completely different thing, you should be completely fine accepting them in good faith if you have sender's real life ID. Law does know nothing about "taint", that's completely bitcoin-related invention, since cash nor goods usually have it. It's yet to be proven how it would be considered by jury.

IANAL, you should do some own research on this.


Disregarding anything clever (I am still pretty new to this), you can simply convert your Bitcoins to your local currency through a third party.  There will be a transaction fee (I imagine), but I doubt Apple is going to hop on the BTC wagon anytime soon and their business model, AFAIK, won't allow for the same lever of third-party integration as Amazon does.


Graceful way to stop bitcoind in Docker container?

Best way to stop bitcoind is either by calling the JSONRPC interface with the stop command or by issuing a SIGTERM or SIGHUP.

But it may take a couple of seconds to shut down Bitcoin Core since it eventually has to write larger amount of data (time depends on your dbcache, disk-speed, mempool size, etc.).

So the environment layer (docker in your case) must be capable to take this into account (a slow process shutdown).


Do miners have to hold all the blocks in memory?

No, miners do not need the entire block chain to be accessible. Technically, they don't even need it at all. The blocks themself are only needed for rescanning wallets, reorganisations, and serving blocks to other nodes. That is why pruning them away will likely become viable in the future.

What you need for validating blocks and transactions (a fundamental demand from miners), is the database of unspent transaction outputs. 0.8+ clients maintain this database explicitly in a compact form (around 200 MB now, as of May 2013).

In addition to that, a miner needs to maintain a memory pool: a set of transactions that are validated against the current best chain, to choose transactions for the next candidate block from.


Whats the process of Creating a Block on the BlockChain

When miners try to compute a block, they pick all transactions that they want to be added in the block, plus one coinbase (generation) transaction to their address. They may include any transaction they want to form a tree of transactions later hashed into the merkle root and referenced into the block's header.

It is to note that for a block to be accepted by the network it needs to contain only valid transactions: inputs that are not yet spent, inputs that have the valid ammount, signature that verifies ok and etc...

After having a valid merkle root they build the block's header:

Version (4 bytes)
Hash of the previous block, thus making a chain of block (32 bytes)
Merkle root, the tree of transactions' reference (32 bytes)
Timestamp, number of seconds since 1970-01-01 00:00 (4 bytes)
Bits, a representation of the networks current difficulty (4 bytes)
Nonce, incremented when mining (4 bytes)

See more here to learn more on how to build the header.

Then this where your miner enters the game. It starts with the nonce at 0, hash (sha-256 2x) the block's header and then check if the hash in under the current target (if you are on a pool the share target). If not it increments the nonce and hash again. If the hash is under the current target YOU FOUND A BLOCK, you then transfer your block's header and the associated transactions' tree and the network accepts it. Because you had a coinbase transaction in your block paying to your bitcoin address those bitcoin then becomes yours.

It is to says that finding a block is rare so your miner will eventually run out of nonce to use you can then change parameter in your block header (more likely the timestamp) or add a extra nonce field in your transactions tree thus changing the merkle root.

As for which transactions are chosen to be part of a block, it is mostly the miners choice to include one or other transaction. But normally they would include transaction with a miners fee in it to gain more bitcoin, a miner could also choose not to include any transaction and only get the coinbase one. The propagation of ones transaction through the network also influence which transactions a miner do include.


where can I get resource such as Blockchain technology in C++

The best pdf about bitcoins would be the original white paper by Satoshi Nakamoto https://bitcoin.org/bitcoin.pdf

For programming free ressources I invite you there: https://www.lopp.net/bitcoin-information/developer-tools.html

Then you have some great book like "mastering bitcoin" or "programming bitcoin"


c-lightning internally calls bitcoin-cli and will pass a couple of commandline arguments to it. These arguments are all prefixed with --bitcoin-* and will match the ones that bitcoin-cli accepts.

So for your use-case you first need to make sure that bitcoin-cli is available on the machine that you will be running the c-lightning instances on. If it isn't you can simply use the Bitcoin PPA to install (but not run) bitcoind which will also install bitcoin-cli (assuming you're using a debian based OS):

sudo add-apt-repository ppa:bitcoin/bitcoin
sudo apt-get update

For a remote bitcoind you need to specify the following arguments:

--bitcoin-rpcconnect=<bitcoind-ip:port> this tells bitcoin-cli to connect to a remote bitcoind instance instead of trying localhost:8332 (make sure bitcoind is configured with -rpcallowip=<ip>, where <ip> is the machine you'll be running c-lightning on)
--bitcoin-rpcuser=<username> the username configured with bitcoind
--bitcoin-rpcpassword=<password> the password configured with bitcoind

In any case I'd suggest running bitcoin-cli --bitcoin-rpcconnect=<bitcoind-ip:port> --bitcoin-rpcuser=<username> --bitcoin-rpcpassword=<password> from the command line on the c-lightning machine to verify that bitcoind and bitcoin-cli are configured correctly.


How do I explore the current commitment transaction for a channel?

Answer by Oliver Gugger (guggero):

You can use the dumpchannels command of chantools:
https://github.com/guggero/chantools#dumpchannels That will show you
the commitment transaction inputs and outputs for both parties.
Remember to shut down lnd first, otherwise chantools will block on
trying to open the channel DB.


I don't know based on what algorithm I need to convert a 512 bits seed into a 256 bits private key.

Regarding algorithms:
BIP-0039 says:

From mnemonic to seed
A user may decide to protect their mnemonic with a passphrase. If a passphrase is not present, an empty string "" is used instead.
To create a binary seed from the mnemonic, we use the PBKDF2 function with a mnemonic sentence (in UTF-8 NFKD) used as the password and the string "mnemonic" + passphrase (again in UTF-8 NFKD) used as the salt. The iteration count is set to 2048 and HMAC-SHA512 is used as the pseudo-random function. The length of the derived key is 512 bits (= 64 bytes).

So the algorithms so far are described by

PBKDF2
HMAC-SHA512
Reference implementations
Example implementations

According to the Bkitcoin Wiki entry for Private key:

Wallet software may use a BIP 32 seed to generate many private keys and corresponding public keys from a single secret value. This is called a hierarchical deterministic wallet, or HD wallet for short. The seed value, or master extended key, consists of a 256-bit private key and a 256-bit chain code, for 512 bits in total. The seed value should not be confused with the private keys used directly to sign Bitcoin transactions.

BIP-0032 says:

Extended keys
In what follows, we will define a function that derives a number of child keys from a parent key. In order to prevent these from depending solely on the key itself, we extend both private and public keys first with an extra 256 bits of entropy. This extension, called the chain code, is identical for corresponding private and public keys, and consists of 32 bytes.
We represent an extended private key as (k, c), with k the normal private key, and c the chain code. An extended public key is represented as (K, c), with K = point(k) and c the chain code.

It then goes on to describe the algorithm used.

Regarding Javascript Libraries

https://github.com/bitcoinjs/bip39
https://github.com/bitcoinjs/bip32

It seems to me that this requires a lot of digging about in documentation and source code.
It initially doesn't seem to be something that can be fully encompassed in the space alloted to answers in this Q&A forum.


getting public key from any raw transaction - what to take care of?

I have summarized some popular payment types in my book "Grokking Bitcoin". There are 6 standard payment types:

p2pkh: Pay-to-public-key-hash. The public key is the second (last) item in scriptSig.

p2sh: Pay-to-script-hash. The public key(s) are packed into the redeem script which is the last item in scriptSig. To get them you need to parse the redeem script (which itself is a script) and look for key patterns (push of 33 bytes).

p2wpkh: Pay-to-witness-public-key-hash. The public key is found in the witness of the transaction. More specifically in the second item of the witness field with the same index as the input you're investigating (the witness contains one witness field for each input. There's only one witness field in this example, because there's only one input).

p2wsh: Pay-to-witness-script-hash. The public key(s) are packed into the witness script which is the last item in the input's corresponding witness field. To get them you need to parse the witness script (which itself is a script) and look for key patterns (push of 33 bytes).

p2wpkh nested in p2sh: The pubkey is in the same place as in p2wpkh.

p2wsh nested in p2sh: The pubkey is in the same place as in p2wsh.

I hope this helps


How to place a sell order on Kraken that only sells when the price stops going up?

At the moment, Kraken has disabled all advanced order types - so there is nothing that can do what you're looking for on Kraken.

That said, I think the order type that you are looking for is called trailing-stop-order.
You can read more about it here, for example: https://support.bitfinex.com/hc/en-us/articles/115003506545-Trailing-Stop-Order


Sending bitcoin from Bitcoin-QT v0.6.2.2 wallet

I don't know exactly what features are available on your version, but here are some ideas to try.

First, take a backup of your wallet.dat file.

In the debug window (help menu?), make sure that your peer is actually connected to some other peers so that your transaction will be broadcast to the network.
Make sure your node is fully synced to the latest block.
Start the application with the -zapwallettxes=1 argument to delete the transactions that are not in the blockchain from your wallet.
Start again with the -rescan argument to scan the blockchain for bitcoins assigned to your private keys. This will take a long time (hours possibly).
Your bitcoins should be available again, so try to send the transaction again with a higher fee. You can use https://bitcoinfees.earn.com/ to decide what an appropriate fee is.

If you really want to export your private keys, you can use the dumpprivkey "address" command from the console inside the debug window (if the console is available in your version). But be very careful when moving your private keys around, they could get stolen by a key logger, screen grabber, other malware, or phishing sites, etc.


What is the point of comparing sha256 of downloaded file with published on the same website code?

Nothing. It is mostly only useful for checking data integrity, not detecting malicious modification (unless you know someone trustworthy that signed the hash). SSL has the same problems though, because public keys can be altered too of course.

There are multiple solutions to this problem, although none is perfect.

Trusting some central authority to decide who is trustworthy and who is not (i.e. Certificate authority). This approach has been shown multiple times to be dangerous, see DigiNotar for example.
Building a web-of-trust, the method PGP (and later GPG) implemented.
Circumventing the normal network with private lines and routing (the military approach), or wait for quantum encryption to become available.


Man, maybe the answer will shock you, but... your amount of crypto is probably lost.
I say ''probably'' and not for sure.
the options may be 2:
1. the transaction was too small, so miners didn't pick it
2. it's fault of the exchange
I don't suggest you to use coinbase, I suggest you buy on spectrocoin -> https://spectrocoin.com/en/
And to trade from crypto to crypto using Binance -> https://www.binance.com/?ref=16821839
Anyway here's a guide to choose the best exchange -> https://medium.com/@bitfinexed/coinbase-insider-trading-litecoin-edition-be64ead3facc


It really depends from country to country and card companies:

Countries are enforcing regulations on financial institutions: KYC (Know Your Customer) and AML (Anti Money Laundering) - which when applied to disposable cards make them impossible to use in the same way you can't use them to transfer money to anyone's personal account

Second issue is fraud and chargebacks - as explained here: Why is Bitcoin so susceptible to credit card fraud?

Third issue is TAX. Taxman wants to know how much money you have on your bank accounts and that is impossible with bitcoin, unless they can track transaction when you bought it.

Dutch taxman is asking you to report if you have bitcoins, and in Holland you can buy them using Dutch money transfer system (IDEAL). If you live in England you can buy them from EU bitcoin exchanges/sellers but you need to execute SEPA transfer from your bank which may take few days to clear.


Which clients offer a way to replace unconfirmed transactions?

Electrum Bitcoin Wallet has the feature. I've confirmed that mac client worked. It seems that Android app has the same feature.

https://electrum.org/#download


First of all, clearing your mempool doesn't really do anything if the transactions you're clearing have already propagated through the network. The mempool will sync again when you connect to other peers.

mempool.dat was introduced in 0.14.0 and will persist the mempool on shutdown. In order to clear the mempool you have to:

Shutdown Bitcoin Core $ bitcoin-cli -testnet3 stop
Delete mempool.dat $ rm ~/.bitcoin/testnet3/mempool.dat
Restart the daemon $ bitcoind -testnet -zapwallettxes

Note: You might also need start the daemon with -zapwallettxes so the transactions related to your wallet aren't loaded into the mempool at startup.

Another Note: If you only want to remove transactions related to your wallet, you can skip step 2: https://github.com/bitcoin/bitcoin/pull/10330


How frequently should one update wallet backup?

The Bitcoin-Qt/bitcoind client's keypool has by default 100 Bitcoin addresses.  Each spend transaction that has change chews up one of those addresses.  Additionally each click on New Address will consume an address from the keypool as well.  So you should be able to get by without a new backup until after 100 spend transactions plus any requests for a New Address.

So if you do 10 spend transactions a month, and receive funds 5 times a month  you would be fine with a backup every 4 months maybe.

A backup plan should consider that backups fail, so multiple backups don't hurt anything.

The size of the keypool can be configured so that frequent use can occur without having to make backups as frequently.  For instance, weekly backups would be fine for a wallet that does 100 transactions a week but the keypool has size of 250.

When the wallet is encrypted, no keys are added to the pool until an action that requires the passphrase to be entered. Backup strategy should take this into account.

And finally, if you import a private key, that key will not exist in any previously made backups.


Could the standard pay to address script be simpler? e.g. no compare of the HASH160?

This is the standard pay-to-pubkey script, which was the original "standard script" for a while, and is still used if you'd solo mine from within bitcoind.

Originally, Bitcoin transactions were intended to use pay-to-IP, where the "address" was an IP address, and the public key to pay to was computed on the fly when requested by the sender. These transactions used pay-to-pubkey scripts.

Pay-to-IP became deprecated and eventually removed quickly, mostly because of security reasons (man-in-the-middle), and the "workaround" (intended for when the recipient was offline) pay-to-pubkeyhash took over, with several unfortunate side effects (address reuse, no comments on transactions, ...). Hopefully the Payment Protocol (BIP 70-72) can bring these back.

There are other reasons for preferring pay-to-pubkeyhash instead of pay-to-pubkey, such as a very minor security advantage (before the pubkey is revealed, the attacker first needs a preimage attack on the hash, before starting to attack the EC key), and smaller effect on the UTXO set (the database every full node maintains in addition to the block chain).


Where can I find Armory 92.3 for download?

A version for XP can be downloaded from github. This is actually 93.3 not 92.3. It says "Armory 0.93.3 for Windows XP, Vista, 7, 8+ (64-bit)"

I have not used this version and cannot vouch for it in any way.

As I expect you know, Windows-XP is an insecure operating system. Microsoft stopped supporting XP in 2014, 5 years ago now. Personally I'd install Linux (e.g. Ubuntu) on the same hardware in order to create a safer environment than XP for a Bitcoin wallet. This might be slightly less of an issue if the computer is never connected to the Internet or to USB devices etc. Duubtless you have considered this but I feel I should mention this for any less-informed people who might read this.


What is the point of adding transation to block chain

What is the advantages of adding transaction into the blockchain

preventing doublespends

for more informatoin look to https://en.wikipedia.org/wiki/CAP_theorem (Partition tolerance)


I wouldn't worry to much yet. These days Bitcoin transactions take their time to be confirmed on both sides. A transaction that would have previously been confirmed successfully in one hour, can these days take a day or more.
With the small fee you offered for the transaction you didn't exactly help in speeding up the process.


Using the default client (which it appears you are) transactions received while the client is online will usually appear immediately but transactions which occur while the client is offline will not appear until the block containing them is downloaded. Based on your description this appears to be what has happened, so your transaction should show up whenever that particular block downloads.

You could also try punching your address into http://blockchain.info and you should be able to see your transaction as well as what block contains it.


How do off-chain transactions get back on-chain?

Coins don't really move "off-chain", in the described case you would send money to an address at Coinbase that is associated with your friend's account. As Coinbase manages their customers' accounts for them, he would see on his account page that his balance increased, but he wouldn't be in control of the private key associated with the address.

Now to "move coins off-chain", means that only the accounted values were updated, while no coins actually moved on the blockchain. Just as if a bank is wiring money from one of their own customers to another own customer, they wouldn't take the money from the vault then put it back, no they would just update the two accounts involved.

In the case of Coinbase it would work like this:

1) Coinbase internal accounting:
rageofreason: 1BTC
friend: 0.5BTC

2) rageofreason sends friend 0.4BTC

3) Coinbase internal accounting:
rageofreason: 0.6BTC
friend: 0.9BTC

They just update the accounts, no actual bitcoins were moved. Now, when friend closes his Coinbase account he will want them to send the 0.9BTC to an address directly under his control. That moment, bitcoins will move on the chain, as they actually need to be moved to that address instead of just updating balances in the internal accounting of Coinbase.


How does using a Turing-complete programming language compromise the security of the network?

It is much easier to formally verify the behavior space of Bitcoin script vs. Solidity.

For example, the DAO project suffered from reentrancy vulnerabilities, given that one could not predict the behavior of anonymous smart contracts when they were called/sent funds to (fallback function, now deprecated).

There are formal verification efforts for Solidity, but this increases the design difficulty tremendously, and one must ask whether it is worth the turing-completeness.


Why do web wallets using multi-signature need 1 of N keys?

From what I understand, it looks like multi-signature 2-of-3 addresses require three public keys to generate

The requirement is for private keys, the public keys are well, public: everybody knows them. A 2 of 3 script requires that any two of the three mentioned keys is needed, and you can use variations of this such as 2 of 2, 3 of 3, 1 of 3, etc.

  are spent via raw transactions

It's also worth nothing that "raw transactions" is just a term used in Bitcoin Core when taking about anything which is not Pay to Pubkey Hash, it's pretty meaningless unless you're talking about the client itself.

  So why do these services not allow you to keep all three keys?

The intention in multi signature wallets is that you can have a requirement for multiple parties to authorize a transaction. In the case of this model, you would have a 2-of-2 system, where there are two parties and both are required to sign in order to spend the related funds. This has the following properties:

The service can not outright steal the money from the user, as the user needs to sign the transaction as well.
The user can have restrictions placed on them by the third party, say, they won't sign transactions which spend more than $10 a day, or without the requirement of additional authorization.
Transactions can be authored in such a way that if the service refuses to sign any transactions (randoms the user, or goes out of business), after a significant passing of time the requirement is reduced to just a single signature from the user.

With these properties you can author very powerful systems with arbitrary spending requirements without risking the loss of money by giving complete of your money to anybody else.

In the case of web wallets however, this system is almost completely snake oil cryptography as the third party is also the one serving the code to the users. At any time they can alter this to different code which just sends the private keys back to them, or blindly signs any transaction they want. There's absolutely no way of making web wallets safe in light of this property.

  So why do these services not allow you to keep all three keys?

Then it would be pointless having multisignature transactions where one party holds all the keys, it would cost a lot less to just use regular transactions. Multisignature scripts tend to have significantly higher costs for use compared with regular transactions.


Unconfirmed Transaction using Blockchain.info wallet

The previous transaction that you are using to spend the coin is also unconfirmed. See below. Looks like this is a problem with the blockchain wallet that you want to email their tech support about. It doesn't even seem to be broadcasting the transactions anymore.

https://blockchain.info/tx/2bf18c5ba2fe56f3d9ada4880181518e905f275bfc9826fdbebd07dca34f2ef2

If you want to fix the problem yourself, you could manually broadcast the transactions out by first getting the transaction hex :

https://blockchain.info/tx/2bf18c5ba2fe56f3d9ada4880181518e905f275bfc9826fdbebd07dca34f2ef2?format=hex

And using:

https://blockchain.info/pushtx


My miner doesnt show up on network but running?

I have posted how i got my miner to run on bitcointalk at the following link: https://bitcointalk.org/index.php?topic=1161887.new#new  try to see if these tips work for you...


watch-only addresses doesn't work properly in bitcoind v0.10.0

It seems that v0.10.0 is not documented yet, apart from the release notes. Referring to the github repository: Issue #4045

It appears that a boolean watchonly argument is needed at the end of those commands. Thus below commands would work:

bitcoin-cli listtransactions testacc 100 0 true

or

bitcoin-cli listreceivedbyaddress 0 false true [account, includeempty, includewatchonly]


Bitcoin Wallet is downloaded I think. What next?

Addresses are not private information. If you ever want to receive bitcoins you will have to give one of your addresses to the sender.

The information that you keep private is what is known as the "private key". Each addresses has its own private key. The private key is what allows you to spend the coins sent to the corresponding address.

Usually you don't see the private key in your bitcoin-qt window. The private key is stored in a file called wallet.dat in your bitcoin-qt folder. If you decide to encrypt your wallet by setting a password it is the wallet.dat that is encrypted. So the best way to keep it safe is to a) set a password and b) routinely backup the wallet.dat file.


**SOLVED** Failed to verify this transaction?

I mistakenly added an OP_PUSHDATA(0x4c) before the second byte of the redeem script and got a wrong hash. The problem is solved...


Always be watchful for any promise that you will receive bitcoins by creating an account or any other thing. Bitcoin is money and like real money, it is not easily given. In the crypto world, unfortunately, there are a lot of scammers, be aware.


Will there be a hard-fork with BTC and B2X?

Will there be a hard-fork between B2X and BTC?

Yes, most likely, although it's hard to know for sure. There seems to be enough people who want the 2x fork that it will happen, and there definitely are people who will continue running Bitcoin Core (which is the form of the bitcoin protocol that will stay with the current block size), which will create two separate chains. There is a really good debate on this fork that took place recently that you can watch here

  How can we know for sure?
  When will it occur?

We will know for sure once we get to block 494,784 which is when the fork is scheduled to happen (sometime around Nov 16). You can view the current block number (usually referred to as "block height") over at blockchain.info. Watch for news around that time about what is happening. Coindesk is a good resource for that.


Not getting merged mined coins on p2pool

I also do merged mining with p2pool. Keep in mind that you are essentially solo mining for namecoin and iXcoin--when another member of p2pool (not you) finds a winning share that exceeds the target difficulty for bitcoin it isn't usable by you as a winning share for the other coins. So you can't leverage the efforts of the rest of the pool to help you find the other coins.

However if you (or other clients connected to your p2pool node) generate a winning share then you will see the altcoin blocks get generated. Given that you are solo mining for those coins it can take quite awhile before you get a share with high enough difficulty. But I assure you that it works.


How to withdraw or transfer to bank account

Bitcoin is not tied to bank accounts but instead lives on a distributed ledger known as a blockchain. This ledger is verified and stored by thousands of nodes across the world. Selling and buying bitcoin is not part of the protocol for Bitcoin, and instead is bought and sold on Exchange services such as Coinbase, Kraken, Gemini, etc. or Peer-to-Peer/Face-to-Face. Bitcoin is exchanged for fiat, not converted. When you sell bitcoin, someone is buying that bitcoin for fiat.

You will need to research and find an exchange that will allow you to sell bitcoin for your native country's fiat currency. Then you can withdraw said fiat into your bank account.


Move the blockchain to a different location

First close your client down and then copy the .bitcoin folder that was created in your home directory to the new location where you wish to store the data.  Second create a symbolic link using the new path:

  ln -s /new/path/to/.bitcoin .bitcoin

Finally restart the bitcoin client and it will use the blockchain stored at /new/path/to/.bitcoin (or wherever you put it)


Yes, you need to upgrade.  You have version 0.16.2, and the 32MB block support was added in 0.17.0.  The latest release version is 0.17.2.

Your apt-get commands will only work if you originally installed bitcoin-abc from the apt package repository.  It sounds like you didn't.

You can check if you installed from a package at all with dpkg -l bitcoinabc.  If so then you can remove the package with dpkg -r bitcoinabc.  Otherwise you can figure out where the bitcoin-abc binaries are installed (using which or similar) and delete them manually.  Then install a new copy from scratch, either from the above-linked repository or any other way you choose.  (But this time make a note of what you did!)


Can someone with 51% computing power earn more than he deserves?

Yes, if you have 51% of the network you can reject all other blocks, thus making sure you receive all rewards. The difficulty will adjust to match just your own hashrate, making sure you mine the expected 144 blocks per day.

In fact, with a clever strategy you can get more than your fair share of block rewards even if you're below 50%. This was discussed here - for example, with 46% of the hashrate you can get 51.29% of the rewards, assuming the rest of the network is honest.

In the multi-attacker case, an attacker with more hashrate than the honest network and any other attacker (where every attacker rejects all blocks but his own), will get 100% of the blocks. If there are several attackers at the top, you'll have occasional massive reorgs where one moment one attacker owns all the bitcoins generated since the attack started (if he hasn't spent them), and the next moment another attacker one-ups him and replaces the whole branch with one where he has generated all coins.


You are probably deriving a legacy P2PKH address (addresses that start with 1) versus the bech32 P2WPKH address (addresses that start with bc1) that Exodus uses.
A single WIF private key can generate multiple address types, other wallets and software are likely defaulting to a different type which is probably why you are having trouble. This is the same for seed phrases as well.
Also just FYI Bitcore-lib is an old outdated library and is not compatible with modern address types. The code example you provide would create a legacy P2PKH address (start with 1).


how to generate bech32/segwit address from pubkey in golang

I have found the answer thanks to modood/btckeygen.
Here is the relevant code extracted from the repo.
witnessProg := btcutil.Hash160(pubkey.SerializeCompressed())
addressWitnessPubKeyHash, err := btcutil.NewAddressWitnessPubKeyHash(witnessProg, chainParams)
if err != nil {
    panic(err)
}
address := addressWitnessPubKeyHash.EncodeAddress()


Does using deterministic wallets reduce our anonymity?

It is hard, if not impossible, to do so when you only have the addresses. Most clients that support multiple deterministic addresses for a wallet, make sure it is impossible to know that two or more addresses are linked together. They usually use a random value as the starting seed and another random value to chain consequent new addresses.

Also keep in mind that they chain the addresses by generating new private keys. These private keys are generated through their algorithm (and are already hard to link together), but normally no one will come to know the private keys of the addresses you use. So it is already hard to link private keys together, but it is even harder to link addresses resulting from the public keys together. So it's good to assume it's impossible.

But, there is more than the addresses alone. There also are transactions. Most wallets generate a new address from a sequence whenever change is generated. This way, people could f.e. track all the transactions coming from one of your addresses and be able to follow the chain of addresses from your wallet.

To do so, they must be able to distinguish between transaction output and change, which is not trivial. This is not easy, especially when you have multiple transaction outputs. Also, once they make one mistake, they lose their track.

But this method is not as hard to exploit as using the addresses. However, the vulnerability of this method has nothing to do with the fact that you use a deterministic wallet. People will also be able to do this if you would generate completely random addresses for every change output.


The way that VerifyingKey works is that it will actually hash the message before it verifies. The default hashing algorithm is sha1, so you will need to specify it to be sha256 as that is what Bitcoin uses. Furthermore, you are passing it the fully hashed message. What you need to do is pass it the step before hashing the message. Since Bitcoin uses SHA256 double, you need to give it the result of the first SHA256 hash and let it generate the second SHA256 hash by itself.

So your message should actually be

083867478cb0d1d8bb864175bbc49728cffcc114bc2e762c6df64f2c965a9a66

and your verify call should look like

vk.verify(bytes.fromhex(sig), bytes.fromhex(message), hashlib.sha256)


Miner modifies unconfirmed transactions and put it into the block

Is is possible that a miner modified a unconfirmed transaction (like changing the output of transaction to the miner himself) and put it into the local block, and after 10 mins the miner luckily solved the PoW, putting the block on the chain and broadcast it to others?

No, because the transaction would be invalid. The vast majority of transactions contain digital signatures which signs the entire transaction. If the transaction is changed, the signatures will become invalid and thus the transaction will be invalid. And if a transaction is invalid, the block containing it is also invalid.

  If a transaction was modified and finally linked onto the chain, how others check whether the tx was valid or not? (others only check if PoW answer was right or wrong, not checking tx, am I right?)

No, this is completely incorrect. ALL full nodes verify all transactions in all blocks that they receive (as well as transactions received outside of blocks). Just because a block has a valid proof of work does not mean that the block is valid. It must still build upon a valid block and must only contain valid transactions. Full nodes still verify that transactions contained within a block are valid.

Contrary to popular belief, miners do not say what transactions are valid. Their job is to determine the order of transactions, within certain constraints. It is the job of full nodes to verify transactions, and all miners (or the mining pools) should be running full nodes.


P2WSH, witness_v0_scripthash: how to derive an address

It's a Segwit output and hence does not have the address associated with it. The locking script for a Segwit transaction includes the witness version (0 in this case) and the redeem script (which is 43aac20a116e09ea4f7914be1c55e4c17aa600b7). Given that the length of the redeem script is 20-byte, this locking address is pay-to-witness public key hash (P2WPKH). Hence the redeem script is hash160 of the compressed public key.

Since Segwit was implemented with a soft fork, there are clients that have not fully updated their software. For those clients, the locking script will look in a way that anyone can spend the output. But for Segwit aware clients, they would realize that it is a Segwit transaction with 0 as the witness version.

You could create a pay-to-script-hash of the P2WPKH. By that I mean that you could embed the witness as a script and generate an address. What you need to do is take hash160 of (0x001443aac20a116e09ea4f7914be1c55e4c17aa600b7). The first byte 00 is the witness version, second byte (14) represents the bytes to push to the stack (20-bytes) and the rest is your witness. Then you can base58check encode it using a prefix of '0x05'

In the future it is expected that most clients will upgrade to Segwit. At that time, it is proposed that the address to be locked will be a base32encode of the script (0 43aac20a116e09ea4f7914be1c55e4c17aa600b7). The address will start with bc for mainnet, separated by 1 and then the encoded version including the checksum. This addresses are called Bech-32 address.

This is how the address will look. Refer BIP-173 for more details.

Mainnet P2WPKH: bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4

Testnet P2WPKH: tb1qw508d6qejxtdg4y5r3zarvary0c5xw7kxpjzsx

Mainnet P2WSH: bc1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3qccfmv3

Testnet P2WSH: tb1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3q0sl5k7


The store would accept the paper wallet, import the private key and sent the money to a safe address (for which only he has the private key).

When it turns out that there was no previous double spend, the store can be sufficiently at ease that the money will arrive.

The customer would now present a second paper wallet from which he only shows the address (and keeps the private key secret). The store could then sent the correct amount of change from its own wallet. Both transactions would be unconfirmed, but for small amounts it should not be an issue.

However, without internet access the customer would have to trust the store that the change was actually sent as promised.


The blockchain is a public ledger and all transactions can be viewed.  But it doesn't contain any names or other personal information.  So you could determine that a particular bitcoin address owns 9% of all coins, but you couldn't determine who has the private key associated with that address.

That said, you can follow a chain of transactions and make inferences based on the addresses used.  For example, if address A and address B are both used as inputs in the same transaction, then you can assume that the addresses are owned by the same individual.  If you sent coins to somebody at address A and you know their identity, then there is a good chance that you know the identity of the owner of address B as well.


Given OP_VER was never used, is disabled and not considered useful can its meaning be stripped and it be made OP_SUCCESS?

BIP 342 does exactly this. (Thanks Pieter)


what is a discrete logarithmic assumption? how does it set-up trustless proofs?

The discrete logarithm problem is a cryptography concept that underlies the basis of much of modern cryptography.

In general the discrete logarithm problem states that for the equation bk (mod p) = a where b, a, and p are known values and p is prime, finding k is hard.

This is hard because of modular arithmetic; in order to find k, you would need to brute force it. Furthermore, there are an infinite number of solutions because you don't know how many times p b^k is. The values b and p are also specifically chosen values which make this problem harder as some values (especially lower values and non-prime values) are easy to solve (easy in that it doesn't take much time but the time complexity is still the same).

Although there is no proof that the discrete logarithm problem is actually hard, but it is believed to be hard as no one has found a way to actually compute the logarithm quickly.

But Bitcoin actually uses a slightly different version of this problem known as the Elliptic Curve Discrete Logarithm Problem (ECDLP). With EC math, b is actually a point on an elliptic curve, it has an x and a y value. Rather than raising b to some number k, you actually do EC scalar multiplication with some number k, so it is

bk (mod p) = a

What this boils down do is adding b to itself k times, and the security comes from the fact that it is hard to figure out what two points were added together to get a third point.

The process of adding an EC curve point to itself means that you find a tangent line to the point, extend the line to where it intersects the curve, and the invert the y value of that point. Doing this, and reversing it, over the real numbers isn't that hard, but EC cryptography is done over a finite field of order p which is a large prime, which means that all values are (mod p) so, when you graph the curve, it's all over place in your graph. This means that, given a point on the curve, it is hard to figure out what other points were added to get to that point so it is thus hard to reverse this process.

In both ECDLP and the normal DLP, k is the private key and solving either discrete log problem would result in you finding the private key k.

There are algorithms such as Shors algorithm which can allow quantum computers to solve the discrete log problem.

Note that this stuff is hard and I am not a cryptography expert. This is just how I understood things and it may not be necessarily correct or make sense.


bitcoin-cli createwallet electrumpersonal server true

There's no warning there.

The createwallet command will always return a JSON object containing the name of the wallet created, and a warning string. If there was a warning during wallet creation, that warning string would contain text. But it is just an empty string so there is no warning.


Your method is correct: you'll need to use the mnemonic seed phrase that generates the bch wallet, to generate a btc wallet. If you do that, you should see your btc balance.

To see if your btc are at the address you sent them to, just use a block explorer website such as blockchain.info. When you use the mnemonic to generate a btc wallet, it should show you the sae addresses as the bch wallet (as long as the software uses the same derivation scheme. Most software does).


How many zeros must be in a bitcoin share for a pool to accept it?

First of all, Bitcoin does not actually use the number of zeroes for the difficulty. Rather it interprets the hash as a number and checks that the block hash is less than or equal to a particular target. This makes the hash have several leading zeroes, but those zeroes are not being considered directly.

The target for a share varies by pool, and usually, by miner as well. Miners can choose a target that matches their hash rate so that they aren't submitting shares too quickly or too slowly. Of course the shares are weighted by difficulty (i.e. target). So a share with a higher difficulty (lower target) is worth more than a share with a lower difficulty (higher target).

Most pools offer setting the difficulty to many values. For example, Slushpool lets you set it anywhere between 128 and 500,000.


Is altering Blockchain Wallet possible even after all the securities?

The key thing to learn is that a scammer doesn't need to alter your wallet. They don't even need your wallet to exist, they can access money that was in a wallet that has even been deleted.

  The minute I fund the wallet, he took all the money out even after all the securities on my wallet. How is this possible?

Bitcoin wallets don't contain any Bitcoin really. What they contain is a private-key that gives you the right to spend any Bitcoins that have been sent to a Bitcoin-address that is derived from that private-key.

The money is effectively stored in the blockchain, every "full-node" bitcoin wallet has their own full copy of the blockchain. Any wallet can spend money if they can prove they have the private-key for the bitcoin-address associated with the Bitcoin.

You can prove you own a private-key without disclosing it. That's the mathematical feature that makes Bitcoin possible.

The wallet-password or two-factor authentication only protects access to your copy of a wallet. By earlier giving someone temporary access to your wallet, they can copy from the wallet the private keys (or seed-phrase/recovery-phrase) that they can use to create another copy of the wallet.

Even if you change the password on your wallet, that doesn't affect other copies of the wallet.

If you put money into your copy of the wallet, that money appears in all copies of the wallet which contain the same private key. It doen't even matter if the copy was created before or after you put the money into your wallet.

Any of those wallets can spend the money you put in there. Once one wallet has spent the money, it disappears from all other wallets too.

You may think that calling this thing a "wallet" is misleading since it really contains no money. I'd agree. The inventors of Bitcoin needed a familiar name for a thing that controls access to money, that was the best they could come up with.

Maybe it is best to think of a wallet as a combined key-holder and accounting-ledger viewer.

So never share access to your wallet, even if it is empty at the time.


Multisig: How to identify who (public key/address) has signed the transaction?


What is the significance of this last line?

It ensures that the built-in miner does not create blocks that are larger than MAX_BLOCK_SIZE. It checks whether the transaction selected be larger than the limit. The reason there is a - 10000 is to ensure that there is enough space for the coinbase transaction and the block header.

  How does this impact consensus?

It's effectively a soft fork. Miners won't make blocks larger than MAX_BLOCK_SIZE. Otherwise there is no effect on consensus.

  Where is the code limiting block size in the most current version of Bitcoin Core?

It's in CheckBlock(), the same function the size check was since a size check has existed. Of course the location of this function has moved. Currently it is here: https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L3093


How can I hide my bitcoin transactions to protect anonymity?

It is possible to trace Bitcoins all the way back to the blocks they were mined, although it might be a hard task. Similarly, one can also trace them back to any withdrawal from MtGox, as long as we know which transaction to look for. No matter how many times you send them from one address to another, it is still possible to trace them back to that transaction, especially if you send the full amount each time.

If you want to make it way harder for someone to trace the transaction, you'd need some service that would take your Bitcoins, send them to some address that is used in many transactions and send them back to some other address you own. There have been many services like this started, but I don't know of any that had the traffic volume necessary to obscure anything. This option assumes that the service would not keep track of the finished transactions, thus not being able to reveal information about you.

You can also try "laundering" your Bitcoins by paying someone to send you Bitcoins from another address. Similarly, you could pay someone to mine a fresh block of Bitcoins for you. Similar as above, it only works if the person would not keep information about you.

Lastly, you could just order some physical Bitcoins. Trading them is completely offline, so nobody can trace who you gave the coins to. I'm not sure though if Casascius keeps any order data, which could be later linked to the person that redeemed the coins at some point in the future.


What's the best way to transfer bitcoins between two exchanges?

Withdraw your Bitcoins from your Kraken account directly to an address provided by your Poloniex account.


a) If Bob aborts before step 2, then Alice will not reveal s. 6T will elapse and Alice will get her BTC back. If Bob aborts after step 2, then Alice will not reveal s, as she has no incentive to do so - only Carol is paid, so why would Alice reveal s and lose her BTC for nothing? Again the timeout is reached.

b) If Carol aborts before step 5, Alice receives the NMC, but Carol's payment times out and so Carol does not receive the LTC (and it is given back to Bob, who will, at the end of the protocol, have both LTC and BTC). However, Bob can continue executing the protocol and receive his BTC, so Carol aborting is only harming her. If Carol aborts after step 5, she will get her LTC payment. Alice has already received her NMC and Bob can continue executing the protocol to receive his BTC.

c) This does not make any difference in the protocol.

d) This would be a problem if Alice's contract expires in 6T, but both Bob's and Carol's expire in 4T. Alice could wait until time 3T has elapsed to claim the coins from Carol's contract. As soon as s is seen on the NMC blockchain by Bob and Carol, time 4T has elapsed. In this case, Carol can no longer claim her coins, as Bob's contract has now expired. Hence, the 1 LTC is returned to Bob. However, Bob can also claim the 1 BTC. So, in case Carol sees that Bob's contract has an expiration of 4T she should refused to create her contract.

e) In case Alice reveals s prior to step 3, Carol has not yet created the smart contract. If she is rational, she will not continue executing the protocol. If both Bob and Carol are rational, Bob can take the 1 BTC and Carol can take the 1 LTC. Then Alice is left without any money. Hence, Alice can only harm herself by revealing s early.

Maurice Herlihy has written a paper on atomic swaps involving multiple parties which I recommend.

PS: Typically, stopping execution in the middle of a distributed protocol is called "aborting", not "halting". The "Halting problem" usually refers to something else in theoretical computer science.


In a chain split scenario (not soft fork), a miner has to confirm transactions from both chains?

No they don't. Miners only work on one chain.

In a chain split scenario miners are divided: some work on a chain and the others work on an other chain (both chains are correct, but they have a different last block). The miner who find the next block makes its chain the correct one because it's now the longest.


how does merkle root building work for empty array?

This cannot happen. Every block contains at least a "coinbase" transaction that distributes the subsidy and fees to the block's miners.
Blocks without coinbase are invalid, even if the subsidy were 0.


What is ASIC hardware good for besides mining?

ASIC stands for Application Specific Integrated Circuit.

This is hardware that is specifically designed for one use case.

Bitcoin mining ASICs are good at one thing: Bitcoin mining. If they were good at more things, they'd be less efficient and/or more costly than they need to be, and competition would replace them.


Why does Ripple's consensus process have a 80% threshold?

If validators waited until other validators declared consensus to declare consensus themselves, no validator would ever declare consensus. So you must declare consensus and hope you turn out to be right. Most of the time you will be. If not, you will later not be mathematically certain of the results and will not pass them on to clients.

If you use a 75% threshold for mathematical certainty, many times you wouldn't be certain and would have to repeat the process. If you picked a 90% threshold for mathematical certainty, you'd be certain almost all of the time, but you'd be wasting time.

The video is a bit misleading. In fact, any threshold could be used and you would still have mathematical certainty if you actually did reach consensus. However, if you set the threshold too low, you would only rarely have certainty. 80% is the threshold we've chosen for mathematical certainty because it's a compromise that results in certainty being reached often and quickly.

Maybe that's not clear enough. Let me try it another way. When we report a transaction as fully validated, we want to be mathematically certain of that. We will not make such a report until we are. Choosing 80% as the consensus threshold allows us to reach consensus quickly, requires at least 20% of validators to be completely malicious to delay consensus, and allows us to (in a later step) be mathematically certain of the result almost all of the time.

Note that almost all of the time is not always. Sometimes, we reach 80% and later are not certain of the results. In that case, we wait until the next consensus round completes and hope we fare better in that one.

Say for some stupid reason you set your threshold to 10%. You would think you had consensus all the time. But equally obviously, a lot of the time there would be no actual consensus. If there were, you could be certain that it had happened (because you would see it). But it often wouldn't happen, and then validators would have to resynchronize and clients would be waiting patiently for the network to fix itself so their transactions can be confirmed.

Ledgers that pass the consensus process are still held up by the "validation gate". They are not reported to clients as "fully validated" until they pass this gate.

80% worked very, very well in simulation. Validators are free to change this threshold if they want. Perhaps in a future network topology, a different threshold will give better performance characteristics.

It's hard to write clearly at 3AM. Maybe I'll rewrite this when I'm more awake.


What is the expected time until the next block is found?

10 minutes. Assuming, as you say, that the current network hashrate matches the difficulty - otherwise it is proportionally higher or lower.

Block finding is a Poisson process. The rate parameter λ is chosen so that 2016 blocks on average are found every 2 weeks, and since in such a process the expected number of events is proportional to the time span, it means λ is 1/(10 minutes).

The time until the next event (the next block found in our case) follows the exponential distribution with mean 1/λ, which is 10 minutes. This distribution is memoryless - the amount of time spent waiting for a block has no effect on the amount of time left to wait. When a block is found the expected time until the next block is 10 minutes (which is intuitive), and it is also 10 minutes at any other time.

If blocks arrived once every 10 minutes like clockwork, the expected time until the next block at a random point would be indeed 5 minutes - but then we wouldn't have to worry about expectations, we'd know exactly when the next block will be found.

In the future, the decreased generation reward might cause the total hashrate to fluctuate as transaction fees accumulate, causing reduced variability in block finding times, and reduced expected waiting time.


Storing your private key on a "security server"?

Usually we try to discourage storing private keys on a server at all unless absolutely necessary.
However, if necessary, just having the keys on a separate server increases the complexity of the attack, as it's an extra step. But, in addition to that, you may employ things like rate limits, limits on transaction size, whitelists on addresses that can be sent to, etc. If there is unusually high transaction volume, a site operator could be notified to step in and review the activity log. In essence, you're right, such a system does have the risk of a hacker who has completely exploited the application server just using the application server to forward requests. But we can slow them down to limit the extent of possible damage.


You didn’t specify, so I’ll answer in terms of the btc blockchain:

When two valid blocks with the same blockheight are found, only one will be accepted into what will become the longest valid chain. The other will be discarded, it is what is called an orphan block.

Usually, the block that propagates through the network first and fastest is the one that will be accepted into the longest chain. The number or nature of the transactions will not affect which block is accepted (so long as all of the transactions are valid). The miner that found the orphaned block receives no part of the reward, since the orphaned block is dropped from the chain.


Remove address from sequence in HD wallet

The problem with dropping an address from an HD wallet is that they are deterministic, so how do you change the determined sequence? The only way I see is creating a new HD wallet (a new sequence), transfer all your money there, and then denying the original affected one was yours (this may need coin mixing).


C secp256k1 : ec_pubkey_parse successful on NULL context despite attribute

If you look at the source code, secp256k1_ec_pubkey_parse doesn't actually use its ctx argument.  So no harm is done if it's null.

You can see in the code that there is a VERIFY_CHECK macro to test if ctx is non-null.  However, this is meant only for testing; you can see in util.h that nothing is actually done about the test unless the VERIFY macro is defined, which presumably is only the case for test builds.

The SECP256K1_ARG_NONNULL macro, defined here, uses the GCC function attribute mechanism to tell the compiler that this argument is supposed to be non-null.  The compiler will optimize on this basis.  It can try to issue a warning if it can determine, at compile time, that the argument is null; but only if you use the -Wnonnull option.


-1 means "not enough information for an accurate estimation".

Try with a higher confirmation target.


How to calculate the the amount of all Peercoins(PPC) in circulation?

According to Wikipedia:

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

  the reward is halved every time the mining power increases by x16. So
  does that mean that you need historic data on the mining power in
  order to calculate how many coins there are?

No you do not need historical data on mining power, but you can calculate out the historical data with a simple calculation used by the entire ppc chain to get an idea of how much hashing power there has been historically. (but that's not the question you are asking).

  Also, does anyone know what's the initial reward and difficulty? I
  can't seem to find those either

Block explorers are your best bet. ABE based explorers like cryptocoinexplorer have some nice API functions. using http://ppc.cryptocoinexplorer.com/chain/PPCoin/q/totalbc I am told there have been  21019084.894021 PPC mined currently

the first block with a reward (block 1) hash is 00000000000be4e024af5071ba515c7510767f42ec9e40c5fba56775ff296658

http://ppc.cryptocoinexplorer.com/block/00000000000be4e024af5071ba515c7510767f42ec9e40c5fba56775ff296658
"
2499.75 Coins generated
Hash: 00000000000be4e024af5071ba515c7510767f42ec9e40c5fba56775ff296658
Previous Block: 0000000032fe677166d54963b62a4677d8957e87c508eaa4fd7eb1c880cd27e3
Next Block: 0000000000fdfc564b25df5858ad9f5e3378d9102a22d5c785f9ab92ec3a304a
Transaction Merkle Root: 1bdae84eff34e15399335fc2a48c70fa6b0b9caf972e38b0e3bda106d223f668
Time: 1345400356 (2012-08-19 18:19:16)
Difficulty: 256.003 (Bits: 1c00ffff)
Nonce: 1915373966
Transactions: 1
Value out: 2499.75
"

So there were 2499.75 coins on the first block.
The first mined block had a difficulty of 256.003

as always, google is your friend. Check it out


Is there a way to figure out when an address is created?

Addresses are not created, per se. They're simply a representation of a public key. So, you cannot know when an address is "created."

However, it is possible to know the first time an address is used.


Integrating Bitcoin payment methods to a UK Opencart store?

Have you considered https://spectrocoin.com/en/merchant/integration/plugins.html there is also live technical support if needed.


Can I use the same seed words for two wallets?

I'm not too familiar with how Electrum handles duplicate seeds. Personally, I start a multi-signature wallet and require only one signer but add two signers (my mobile device & my laptop). You can do this on Copay, Electrum, and most other bitcoin wallets.


How to get unspent bitcoins using bitcoinj

Bitcoinj is only a library, but there is an experimental full verification mode that would allow this. https://bitcoinj.github.io/full-verification  It is important to note it is not intended for production use and almost certainly contains chain splitting bugs.


What is the purpose of addr_from and addr_recv in version message?

Answered in this comment:

  Bitcoin Core actually ignores addr_from in received version
  messages. addr_recv is used to influence the heuristic that
  determines which of the receiving node's IP addresses is publicly
  reachable.


HTLC (Hash Time Lock Contract) using bitcoin-qt

The HTLC isn't really a specific type of bitcoin transaction, it is more a specific output script with the required spend conditions. Thus to make an HTLC, you really need to create a custom script which the bitcoin core command line tools don't really accomplish. You could construct the script by hand or perhaps find another tool which allows more easy script editing, perhaps btcdeb by kallewoof.

A HTLC script format can be found in BIP 199. There was also a PR opened to bitcoin core to add HTLC support to the wallet, but the author became too busy to continue maintaining that PR and it was never merged. It may interest you, you can find it here.

Let's show an example. Take your value "secret", and hash it with sha256 (you could use hash160 instead also). Then create the following script:

OP_IF
    OP_SHA256 hash_of_secret OP_EQUALVERIFY OP_DUP OP_HASH160 your_pubkey
OP_ELSE
    timeout OP_CSV OP_DROP OP_DUP OP_HASH160 their_pubkey
OP_ENDIF
OP_EQUALVERIFY
OP_CHECKSIG

To spend, the first value on the stack is true or false to pick which branch of the if statement to evaluate. If you are the seller who has the preimage of the secret hash, you use the top branch and reveal the secret and sign the transaction to spend the output instantly.
Otherwise, if the deal falls through or whatever, they can redeem their funds again without revealing the secret after a certain amount of time. If the CSV with the timeout (you could use CLT instead) is successful, meaning the time has passed, they redeem it with just their signature on the transaction, and don't require the preimage of the hash.

It is relatively trivial to convert this script to an actual hex encoded script, simply by looking up the correct hex representation of each op_code and using the correct push opcodes for the length of each piece of data you are pushing (pubkeys, secret hash, etc)


You will need a Bitcoin wallet to store your coins. Check out https://www.bitcoin.com/ for some options.

After you set up a wallet you will get an address where you can store coins. (The address will be a long string of letters and numbers but you will also get a QR code, which is basically the same address but in a form you can scan)

If you then find an ATM you can insert cash, scan your QR code at the machine and you will get the coins sent to your wallet.

That's basically the process of how ATM's work.


How to programmatically send Bitcoins without requiring a local copy of the blockchain?

There is a similar question from 6 years ago with different options and answers Is there a remote, trustless bitcoin API that doesn't require anything (blockchain/SPV headers) to be stored locally?

Otherwise I suppose the options havent changed much, unless maybe the pruning mod which allow you to run a lightweight bitcoin node (550mb instead of 250giga+)


Is it true to say 51% of nodes should validate a transaction?

No, it is not necessary for any node validate a transaction before it is included in a block and thus added to the blockchain. A transaction can be included in a block without being validated, but doing so risks the transaction being invalid and thus making the block invalid. This has happened several times in the past; miners will make their own transaction and include it in their own block without broadcasting it to the rest of the network.


I was scammed, told I had bought bitcoin and that it had been put in my wallet. I have never had a bitcoin wallet

How do I prove that I have never had a wallet for this currency.

You can't.

  If someone else created the wallet how do I identify where it is?

You cannot identify the name of a person owning a wallet nor the person's location from any Bitcoin data like a Bitcoin address.

At least not if the scammer avoids any obvious mistakes like re-using the address for a later (or earlier) transaction with an honest business in your jursidiction which insists its customers provide ID and which is willing to assist your local law enforcement. This is unlikely nowadays.

I would report the fraud to local police, then try to accept that the money has gone forever and move on with my life.


Finding the purchase values of all currently held bitcoin

You cannot do this for a number of reasons.

Bitcoin is mined - There are many bitcoin around that have never passed through an exchange (all of Satoshi's, for instance). Since they've never been traded, you can't find any trade data for them
Exchanges operate offchain - You cannot link an onchain transaction to an offchain trade and its price easily. Many people only withdraw when moving between exchanges, or to cold storage. This could mean that they traded BTC months/years ago, but an onchain transaction only appeared yesterday
Onchain transactions don't have to be from exchanges - Transactions could simply be moving money between the user's own wallets, or exchanging for other goods/coins. Once again, you can't look at a transaction and know what it's for.

Exchange wallets are usually identifiable for most major exchanges. However, it's going to be nearly impossible to link individual transactions on the chain to individual trades without extensive raw data from the exchanges itself. Even after that, you will be missing data on OTC and other non-exchange trades.


Clients only need to track the currently valid information (there is an expiry date for domains, for example) and not all applications need all of the data stored in the chain.  So, much like Bitcoin itself, application specific versions of the information stored in the blockchain will be used by most applications and they can use SCIP or distributed trust models to check the validity of information instead of storing the entire blockchain locally.

For shits and giggles, I downloaded the top 1 million domains and some IP blacklists, resulting in a 4MB CSV file containing 142,202 IP <-> domain pairs. Simple Zip compression yielded 2:1 - 3:1 compression rates while PAQ8 delivered rates >4:1. A custom data-structure would likely yield even higher compression ratios.

Simple extrapolation of these numbers shows that 5megs can easily handle half a million such pairings. If traffic is distributed in a Zipf-like distribution, the .bit namespace can grow to 2.5 million domains (the size the .bi*z* domain space) and clients could still store the top 20% of sites which receive 80% of all traffic in a 5 meg cache. With even .INFO carrying 6 million domains, we have room to grow :)

And, finally, storage tends to get cheaper over time and the chain could be setup to dynamically set prices.


What they stored in cold wallet? All bitcoins anyone owned is already in blockchain

Do they store the private key of users in cold wallet?

In short, yes. (Some) private keys are stored in cold wallets.

The record of all bitcoins (UTXOs) exist as a public database, which is stored in full nodes all around the world.

To spend a UTXO (ie, some amount of bitcoin), the user must be able to produce a valid signature, by using the appropriate private key for that bitcoin address/script.

Those private keys are stored in various ways. One such way is a 'cold wallet'. Generally, a cold wallet describes a way of storing a bitcoin private key, such that the device storing the private key has not, and will not, connect to the internet. Conversely, a wallet that exists on an online machine is usually referred to as a 'hot wallet'.

There are also different types of hot wallets, and cold wallets. But the online/offline distinction is the main distinguishing factor.


Can you make a profit mining with CPU/GPU?

No you are not missing anything. CPU mining has been unprofitable since 2011, GPU mining just slightly later.

Today, ASICs rule mining. The Bitcoin network has more than 300 Phash/s by now, that is 300,000,000,000 Mhash/s.

The upcoming ASIC miner generation is announced to provide more than 9,000 Mhash/s per Dollar. Times for GPU/CPU mining are long gone.

The situation is largely the same for Litecoin with a slight delay.

Also see: Why does mining profitability tend towards zero?

There might be some altcoins that can still profitably CPU/GPU mined and traded for Bitcoin thereafter, but I am not sure even they are worth when you factor in time investment.


Bitminter has an auto cash out function. On the Account homepage, you can set a Bitcoin address to which your coins are deposited as soon as you reach a certain amount.

I assume you already have a Bitcoin wallet somewhere that can give you an address to enter in the auto cash out form. If you don't, visit this page on the Bitcoin website and create a wallet. (I recommend you for simplicity and security considerations to choose a web wallet or a fast wallet like Multibit or Electrum.)

Once you set up auto cash out, you will receive your bitcoins in your wallet. They you can create an account on an exchange that allows you to sell bitcoins. They will give you a deposit address to which you will need to send your bitcoins using your wallet. As soon as the deposit arrives, you can sell your coins and withdraw the cash from the exchange site.


Manage multiple users wallets for web wallet service

You can do estimatesmartfee 6 to calculate suggested BTC/kB fee aiming confirmation in six blocks. Then you can do fundrawtransaction <tx> "{feeRate: 0.000something}" to add inputs with the specified fee. This way, you'll have more control over the fees.


Does my Bitcoin-Qt wallet backup file have "everything" I need (private key)?

Your bitcoin.dat file contains your private key(s) as well, however I would suggest you extract them now for the addresses that hold money (if any), if empty then it's not much of a use, unless you accept donations there or have a business set up to that address.

How to extract your private keys for addresses that hold at least some money:

Go to Help > Debug > Console
Unlock your wallet if it is encrypted by calling: walletpassphrase YOURPASSWORD
Call listreceivedbyaddress to get all not-empty addresses
For each of them call the dumpprivkey MYADDRESS
Call walletlock once you're through to lock back your wallet


Will there be 21 million bitcoins eventually?

People say the total will be 21000000 BTC.

... however:

The 1st 210000 blocks each allow creating 50 BTC.
The 2nd 210000 blocks each allow creating 25 BTC.
The 3rd 210000 blocks each allow creating 12.5 BTC.
...
The 10th 210000 blocks each allow creating 0.09765625 BTC.
The 11th 210000 blocks each allow creating 0.04882812 BTC, and not 0.048828125 BTC, because only 8 decimals of precision are supported.
...
The 33rd 210000 blocks each allow creating 0.00000001 BTC.

After that, the reward is 0.

If you sum all these numbers together, you get 20999999.9769 BTC.

... however, either due to an oversight or intentionally, the coins created in the genesis block cannot be spent.

This leaves us with 20999949.9769 BTC.

... however, due to an early problem in Bitcoin, fixed by BIP30, it was possible to create a coinbase transaction identical to a previous coinbase. This caused the coins created by that older coinbase to be irreversibly "overwritten". This happened in block 91842 (overwriting the coinbase of block 91812) and 91880 (overwriting the coinbase of block 91722). Each time, 50 BTC was lost.

This leaves us with 20999849.9769 BTC.

... however, the protocol rules allow creating up to the amounts listed above. Due to various bugs and miners experimenting with code, some blocks claim less than allowed. Those coins can never be recovered.

Block 124724 tried to intentionally claim 0.00000001 BTC less than allowed, but accidentally also failed to claim the fees, losing 0.01000001 BTC.
Between block 162705 and block 169899, 193 blocks claimed less than allowed due to a bug, resulting in a total loss of 9.66184623 BTC.
Between block 180324 and block 249185, another 836 blocks claimed less than allowed, resulting in a total loss of 0.52584193 BTC.
Block 501726 had no transaction outputs (except a 0-value commitment), losing the entire 12.5 BTC subsidy.
Block 526591 didn't claim half of the block reward, losing 6.25 BTC.

This leaves us with 20999821.02921183 BTC.

... however, since recently there is a concept of provably unspendable coins. Coins can be sent to an "address" which provably burns them (using OP_RETURN). Bitcoin Core tracks these and removes them from its database, so they are easily accounted for. At least 3.71612692 BTC were burned this way.

This leaves us with 20999817.31308491 BTC (taking everything up to block 528333 into account)

... However, various wallets have been lost or stolen, transactions have been sent to the wrong address, people forgot they owned bitcoin. The totals of this may well be millions. People have tried to tally known losses up here.

This leaves us with: ??? BTC.


Majority attack no drawbacks (unlike bitcoin wiki suggests)

One thing to consider is that if tomorrow some attacker dumps his year long alternative chain on us, basically reversing a years worth of confirmations: that will likely cause panic and would cause a big drop in price of Bitcoin. So even though he got a lot of rewards in his blocks, if the price halves, the rewards will be worth less than if he had just used his mining power honestly to begin with.

Another thing to consider is that it would be fairly easy for the community to decide to completely invalidate the attacker's chain. For example by blacklisting the hash of his first block in a hard coded manner. Yes that is a centralized decision and yes that will still be a very messy and damaging situation where some wallets get confused and pick the wrong chain. But it is possible to make the attacker's chain completely worthless and should be therefore be a deterrent against such attacks (with long chains at least).


How are transactions from incoming blocks verified?

The blocks contain the complete transactions. When you validate a block, you validate every transaction in it the same way the miner who mined that block presumably did.

To spend a previous transaction's output, you must provide a valid signature.
Every signature is accompanied by a public key in the transaction. If you have a signature to verify, you also have a public key.

On the other hand, it's just for the outputs of a transaction that you have only an address. However, there is nothing to verify then since there's no signature. There is no need to validate an address. What would an invalid address be?

The only thing they need to validate are signatures and, as I said, signatures are always accompanied by a public key. When a transaction contains a signature, that signature is accompanied by a public key. Where a transaction does not contain a signature (such as for its output addresses) there is no signature to validate and hence no need for a public key.

The important thing is that the miner validates the transaction and then includes the transaction in the block, so everyone else has everything the miner had.


Why the transactions are put into blocks in the first place

The purpose of the blockchain is to prevent the double-spending of coins by ensuring that there can be at most one valid transaction which spends some known coins. The only way to ensure this is that validators must be aware of all valid transactions.

While it is possible that someone may attempt to double-spend some coins, only one of the transactions may make it into the chain of valid blocks - which serve as an immutable record of which transactions were accepted as the correct ones. They are immutable because even the change of a single bit in a transaction would alter its transaction id, which in turn would alter the block's merkle root, and in turn, would require that all subsequent blocks have their block hash recomputed, because they all refer to a hash of the previous blocks header, which contains its merkle root.

The way all validators agree on which chain is the correct chain is by always taking the chain with the most proof-of-work done on it. This is necessary to keep the ledger immutable, because it means that an attacker attempting to modify a transaction, and thus, needing to recompute the merkle root and the hashes of subsequent blocks, would be constantly playing catch-up with the longest chain, and if they have less hashing power than the other honest miners who are working on extending the longest chain, they will not possibly be able to catch up and generate the chain with the most proof-of-work.


What does "Not yet redeemed" mean in a BlockExplorer transaction output?

No, it means that those coins are not yet spent.

Bitcoin transactions work with inputs and outputs. Every transaction can have one or more inputs, and it may then create one or more outputs of which the total amount adds up to the sum of the inputs (minus the transaction fee).

Only coinbase transactions do not require inputs. Those are the first transaction in every block that gives the miner of the block his block reward and all the fees from the transactions in the block.

When you want to spend bitcoins from one of your addresses, you will have to find an "unspent transaction output" for that address, make a transaction with the output and assign new inputs.

What this means is that an address does not really have a balance stored in the block chain. There is just a list of unspent outputs, and those that are bound to some address add up to this address's balance.


To achieve a whole block solo in a month you're going to need about 1500 TH/s

https://www.coinwarz.com/calculators/bitcoin-mining-calculator/?h=1500000.00&p=2600.00&pc=0.10&pf=0.00&d=922724699725.96300000&r=12.50000000&er=4486.23010000&hc=0.00

Just to double check that: https://blockchain.info/charts/hash-rate

Total hashrate: 7Million TH/s divided by 6*24*365/12 = 4380 blocks a month = 1598 TH/s

So you need about 115x AntMiner S9s which cost about US$ 1,288 each, so US$ 148,120.

But then the last block generated US$ 60,900 of bitcoin (14.4BTC).

  Would it matter if the farm is in Southern Africa away from anyone, would another miner that is closer always get the block first?

Closer to what? There is no centre. And as blocks take an average of 10 minutes to produce, and they are small (1MB), so while there are race conditions they are the same for everyone everywhere.


One Code, Two Different Compilations (One Dirty Version of BitCoin)

Dirty means that the compiled binary includes code that is not committed in git. You can use the git diff command to see what the uncommitted code is and use git show to see what the  most recent commit is for each of your code trees. There's a good chance that what you think is the same code is not actually the same code.


In what cases would a bitcoin address not have a private key?

If an address merely 'looks like' an address and all other aspects of a transaction are ok then miners will include it in a block.

This has been (ab)used to embed ASCII art into the blockchain at the cost of permanently destroying some bitcoin.

For an example with explanation see https://bitcointalk.org/index.php?topic=33618.msg420597#msg420597


Why can I observe three different network difficulties in a span of a few days?

The information you are looking at is incorrect and seems to be the result of interpolation of the graph, there was no difficulty changes that resemble that in the Bitcoin block chain. Difficulty changes are every 2016 blocks, which is approximately 2 weeks if there is no difficulty change within the period.


If you are solo mining against your own bitcoin server, then for each hash your miner tries it either solves the block (and earns 50BTC [plus transaction fees], provided it doesn't get orphaned), or doesn't (and earns nothing).

If you're mining with a pool, then payment depends on the pool's payment system. If for example it is PPLNS (Pay Per Last N Shares) with a value of 500,000 for N, then you don't get paid anything unless a block is solved within the 500,000 "shares" mined following each share that you submit. Let us know the pool you're using (or the payment mechanism), and we will be able to provide some more info.

With 97.3Mhash/s, I'd (roughly) estimate you'd earn around 0.04 to 0.05BTC per 24hrs with a difficulty of 2,100,000 (approx the current difficulty).


"Request Payment" is just a nifty little tool that generates a QR code that points to the address on the page, so it won't help you unless you want a QR code for the address.

Check to see if the address you've sent to is in a wallet you own. If you have lost the private keys to the address, the only thing you can do is try to find them. It's nearly impossible to regain control of addresses you've lost or forgotten.


What is a Mining Pool, what is it good for?

A Mining Pool is a protocol for a group of miners to work together, in order to smooth out their mined coins. A miner working alone would generate a block (= 50 Bitcoin) whenever he is the first to find a correct hash. In practice, this happens quite rarely for a single miner.

When several miners are working together in a pool, their earnings are split among all miners (with the pool usually taking some commission). This guarantees an even spread of earnings over time instead of "all or nothing" in solo mining.

One disadvantage of a mining pool is its centralicity - most pools today have central nodes that can be DDOSed, and if not configured accordingly when a DDOS happens the miner will just sit idly instead of reverting to a different pool or to solo mining.


If someone is sending bitcoin with low transaction fees and then sends the same bitcoin with higher transaction fees before the previous one is confirmed, so it is obvious that miners will pick the second one

By default, the miner won't pick the second one, except the previous one had Opt-in RBF enabled.

However, technically or theoritically speaking, a miner always has the ability to pick any transaction he likes into his block template, so that he could mine such transaction(s) into his block. It's just the matter of whether his block would be widely accepted by the network (including other miners, non-mining full nodes which the wallet relied on, etc).

  ethereum has nonce value of each transaction which avoids this, but how does bitcoin avoid it?

I don't know much about Ethereum. As far as I know, the UTXO model itself is the equivalent of the nonce value, since each UTXO (uniquely identified with TXID and output index) could be spent only once, otherwise it would be an invalid transaction or block.

Note that the nonce value/UTXO model and double spending by forking the chain are two distinct problems.

Without the nonce value/UTXO model, even an individual chain itself cannot rule out double spending or replayed transactions, which is actually inflation in bitcoin, or replay attack in ethereum (the replayed transaction would make the victim make another unexpected repeated payment, so he would lose money).

However, even with nonce value/UTXO model, the attacker can still produce forked chain to "rewrite the history" (in such case, the previous transaction would be actually discarded, which generally means the previous legitimate payment would be maliciously withdrawn), which is the reason why we need a consensus mechanism like proof-of-work.


What is the difference between bitcoin core vs bitcoinj vs bitcoind vs bitcoinqt?

bitcoind, and bitcoin-qt are all part of the same program. Bitcoind and bitcoin-qt are both Bitcoin Core and do the same thing except that bitcoind has no GUI. Both are part of the Bitcoin Core project and referred to as Bitcoin Core. Both share a large amount of code and are full nodes.

bitcoin-tx is a utility that is part of the Bitcoin Core project that allows you to create, modify, and sign raw transactions.

bitcoin-cli is a utility that is part of the Bitcoin Core project that allows you to interact with the headless (i.e. no stdin input, no gui) bitcoind and a bitcoin-qt if -server is set.

bitcoinj is a Java library for using Bitcoin. It does not have full node capability and is primarily used for Android apps and lightweight clients.


How can i effectively split large outputs into smaller ones?

The protocol and the standard client allow you to spend your own unconfirmed change. Multibit didn't allow this, but I believe it's a recently/soon added feature.

When constructing your transaction manually there is little advantage to choosing confirmed outputs.

If you do want to split your outputs, you can do it with a sendmany transaction. The Bitcoin-qt GUI allows you to do this ("Add Recipient"), which can scale to several outputs. For a larger number of outputs you can generate the command programmatically and issue it with the command line.

Bitcoin-qt does not allow you to pay an address multiple times in the same transaction. There seems to be little justification for that, and it may be possible with the raw transaction API. Alternatively, you can generate several addresses and split the amount between them.


Anonymous transactions with bitcoin core

Your VPN provider at least is in a position to deanonymize you. Therefore, I would rather use TOR. It's not infallible, but many people have used it successfully to achieve relative anonymity. Here's a short guide to setting up bitcoin core with TOR

As Saxtheowl has already mentioned, however, both a VPN and TOR can only hide your IP address. There are many other ways to get deanonymized. Fortunately, there is a comprehensive guide about everything you need to know about using Bitcoin in private


How to specify number of threads for bitcoind?

More threads will not make your software run faster.

Threads are used in order to be able to do more things concurrently, but not necessarily faster overall. Assume your internet connection allows you to download at 1 MiB/s, and you want to download 5 files of 200 MiB each. No matter what, you need to download 1000 MiB, which will take 1000 seconds. But you could choose to either download them one by one, or all concurrently. If you download them concurrently, they'll individually progress more slowly, but overall still finish at the same time.

Your CPU has a number of cores, and can typically run one or two threads on each core (See SMT). For computationally intensive tasks, it is therefore advisable to have as many threads as you have cores, in order to keep all cores busy. However, more is not helpful in making things faster. In fact, because of increased need for communication between threads, doing so may even reduce throughput. Bitcoin Core will automatically detect how many cores your system has, and create that number of threads for transaction and block validation. If you want, you can change this number using the par setting in bitcoin.conf.

Most of the threads you see are however not computationally intensive, and are in fact idling most of the time. They're just there to deal with occasional things that need to happen in the background and not interfere with other operations. That includes threads for sending and receiving network messages, for cleaning up database files, for interacting with the user (reacting when you click somewhere with your mouse if you use Bitcoin-Qt for example), or for responding to RPC commands. For the last one, there is a setting to control how many RPC commands can be processed in parallel, namely rpcthreads. Due to locking, only 1 or a few RPC commands can actually execute in parallel, however.

So, you can change the number of threads for some tasks, but that's rarely needed, as the defaults usually get you close to the best performance. If you want to make block synchronization go faster, the best approach is increasing the database cache size (dbcache) or running on faster storage (SSD helps a lot).


Bittrex doesn't let market trading at the moment. So you can't. Yes, it sucks.


If you sent Bitcoin Cash to a standard Bitcoin address you can still get to it (maybe).

There is too little to give you a fully correct answer. If the address is a wallet you control (not an exchange) then you should have a recovery password. It is possible to restore your BTC wallet into a BCH wallet, then transfer the funds from there.

I'm assuming you didn't accidentally send the coins to a Segwit address.

What would help the most, if you provided the transaction ID and the name of the wallet you use. (provide the path: Eg, Coinbase BCH > Exodus BCH > Coinbase BTC)

I can look into it a bit, make sure the tokens were transacted etc. Beyond that, i'm far more familiar about how to deal with this if you were running a bitcoin core node.


In general bitcoin means: "if you don't own the keys, you don't own the coins" (for example web wallets or exchanges) and "if you hand over the keys (have them stolen) or sign a transaction to the wrong destination (buy a cheap iPhone from Nigeria) then you just learned a lesson the hard way".

Having said that, Bitcoin does offer some unique protection methods like multisignature and wallet backups.

Depending on the situation and the kind of fraud, you might be able to contact your local law enforcement or FBI or equivalent.


What are some good ways of marketing a Bitcoin related service to Bitcoin users?

The folks at bitcoin.it run a moderated listing, https://en.bitcoin.it/wiki/Trade, which you can list at.  Another way is to work directly on reddit (r/bitcoin) and http://www.bitcointalk.org/.


How transaction manipulation handles in Blockchain?

For instance, A has some (i.e: $10) money and A is sending half($5) of it to B. but C manipulate that transaction before going to Blockchain and set $10 instead.

This is not possible, provided the original transaction is signed correctly. In a regular transaction, you sign the inputs and the outputs. If someone changes the input or output amount, the signature is invalid, and the transaction will not be mined.


How do I create a new address in the Bitcoin-Qt client?

The address field is unused and disabled - you can't put anything in even if you wanted. It is probably an artifact of reusing the dialog for adding a new sending address.

So you can't use Instawallet to create an address and import it; and even if such a strange procedure was possible, it would not be safe because then Instawallet would have your private key, which should be kept secret.

Since the address is generated locally using pseudorandom data, it is inconceivably improbable that 2 people will share an address (it is less likely that it will ever happen to anyone than that I will be struck by lightning while writing this answer). In this highly unlikely event, funds in this address can be spent by either of them, whoever gets to first.

Every address has an associated private key, which must be kept secret and is what allows the owner to claim funds in that address. Bitcoin-qt stores private keys in the wallet.dat file in the application data directory.

When sending bitcoins to someone (whether to sell them, donate them or to pay with them), the software internally uses the private key to prove prior ownership of them and announce to the network that they shall now belong to the owner of address X. You don't give your own private key to anyone; the new owner will use his own key to send them from his address.


Resolve BTC long mem pool (many unconfirmed tx)

Problem solved, make many sub UTXOs will resolve that well.


How do I switch from Bitcoin-QT to a lighter, faster (SPV) Bitcoin client?

From my experience, your solution is the MultiBit Wallet software - it should satisfy all your requirements: https://multibit.org/index.html

I use it on a regular basis and found it satisfying, and also have the possibility of storing more than one wallet, you should give it a try.

Cheers.


How does Trezor's wallet recovery work if the private key never leaves the device?

The Trezor generates a seed offline on your device. Neither the private key nor this seed are ever shared with SatoshiLabs.

In fact, you're in sole control of your private key: when you first set up your Trezor, you're being shown the 24 words that encode your seed. You have to write these words down and keep them as a backup. When you lose your Trezor, you can use these 24 words to regenerate your wallet by putting them into another Trezor, or using compatible software that performs the same key derivation.