What meanings do the "NodeId", "Version" and "Services" convey on Peers tab of Bitcoin-qt Debug window?

Is "NodeId" the ordered number (among all the existing bitcoin-core nodes) of the node that I am connected to?

It's just the number of the connection you made. It's not a global identifier of the node you're connected to. Every new connection you make (incoming or outgoing) is assigned a sequentially increasing number.

  How does "Version" differ from the "User Agent" version (on the picture, Version is displayed as 70015 and User Agent is displayed as "/Satoshi:0.18.0/)"?

Version is the protocol version. User agent identifies the software implementing it.

  And lastly, what does the "Service" mean (in this case displayed as "NETWORK & BLOOM & WITN...")?

The Bitcoin P2P protocol has a number of optional features that node can offer to their peers:

NETWORK means availability of all blocks since genesis
NETWORK_LIMITED means availability of the last 288 blocks
BLOOM means BIP37 bloom filters
WITNESS means support for Segwit witnesses in blocks and transactions
COMPACT_FILTERS means support for the BIP158 basic filter type


Does the bitcoin URI message parameter have character limits?

There isn't a limit described by the BIP (https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki). In general, however, URIs might be encoded into QR codes, so their length should be kept as small as possible.

GET requests often have limits on the length of the encoded URLs, something like 2000 characters (https://stackoverflow.com/questions/266322/is-there-a-limit-to-the-length-of-a-get-request). This might be applicable depending on how you are using the URI.

As a guideline, however, I would say that messages in Bitcoin URIs should be fairly short. I'd probably try to stick to less than 200 characters.


How to find one private key from the list of 15 million public keys for the sake of experimentation?

That's how crypto works where public key cannot retrieve private key. If you were able to retrieve the private key with public key then bitcoin would be at high risk.

The only way is to Brute Force (Nearly impossible) or Social Engineering (Only if you know who owns the key) or Somewhere that stores leaked private key otherwise, you just can't obtain it.


Solvable refers to the wallets ability to create a transaction which could spend those funds. As it is a watch only key that has been imported, there is no possible solution which it could come to in order to spend that money.


My lnd node hasn't routed any payments (1 week + since initial setup)

I haven't received any fee payments. (...) Any ideas? Or is this expected?

Running a LN node does not guarantee you will collect fees. Fees are collected iff you route a payment for another user, so at this time it appears that no users have routed a payment through your node.

Factors that could affect this: which nodes you are connected to, the liquidity of your channels, the online availability of your node, etc.

Routing fees offer an interesting incentive, but remember the network is still young and not widely utilized. Right now, payments for routing transactions may be rare, but in the future... ?

  I also pushed some remote balance to some channels

Worth noting, this is equivalent to making a payment to the node you are connecting to. When the channel is closed, that remote node will be the recipient of the remote balance. So I hope you have made those payments for a reason, otherwise you have given away some of your BTC.


Multibit security with regards to "backup" folders

The files with the .cipher suffix are the regular wallets encrypted with 256 bit AES.

The password used is the one you use to first encrypt your wallet. MultiBit goes through all the unencrypted wallets, creates an encrypted copy and secure deletes the unencrypted one.

You can open the .cipher wallets using File | Open wallet and it asks you for the password.


What if duplicate wallet addresses are created?

The probability is unfathomably small. In practice it will never happen. You can find one billion friends all keep generating trillions of addresses every second and there won't be any duplicate addresses til the end of the life of the sun.

Edit: this actually exaggerated a bit. By virtue of the Birthday Paradox you only need to generate 2^80 addresses (not 2^160) to likely get a pair of duplicate addresses among all the addresses generated. So this address generating party won't be able to run that long.

On the other hand if your billion friends all keep generating addresses in an attempt to get the same address as yours, then it does take forever to happen.


can’t figure out how to receive it

Once a transaction has been created by the sender, receiving Bitcoin requires no action whatsoever on the part of the recipient.
It is understandable that the recipient would like to have their wallet show them a received amount - but that is of no consequence in terms of transfer of control over an amount of money, The transfer either happened or it didn't. Regardless of whether your wallet knows about it or not.
So either the transfer happened and your wallet hasn't found out for some reason, or the transfer hasn't happened yet. The former can happen due to a wallet not being fully synchronised or not being able to communicate with other nodes. The latter can happen when the Bitcoin network is busy or when fees are set too low.
You can find out which is the case by putting the receiving address into a few Blockchain explorers.

the address is not open in my receiving tab but is under file receiving addresses

That is normal. The receiving tab usually generates a new address for each transaction for privacy reasons.

Possibly related:

Why is my transaction not getting confirmed and what can I do about it?


Remove address sub from blockchain websocket API

There is now the addr_unsub command taking an addr parameter to unsubscribe address updates.


Leading zeros and numbers of hashes before arriving to solution

Look at these numbers in binary.  A hex digit is 4 bits, so 7 in hex is 0111 binary, 3 is 0011, 1 is 0001.  You can see that 7 is the largest hex digit in which the most significant bit is 0; 3 is the largest hex digit in which the two most significant bits are 0; and so on.
Yes, you can get this same value by taking the log2 of the hash value and subtracting from 256 (which is the total number of bits in the hash).  Note that the number of leading zero bits of the hash (including "fractional bits") is required to be less than or equal to the target difficulty, but in general is much more likely to be less.


What can xxxCoin do to stop the impending 51% attack?

There are two basic fronts on which they can defend, and they really do have to do both.

First, they need to increase their total hashing power. 51% of a very large number is much harder for an attacker to muster than 51% of a small number. Merged mining is probably the most realistic way for these currencies to accomplish this.

Second, they need to fix specific vulnerabilities in their difficulty adjusting algorithms. Some of these attacks requires less than 51% of the hashing power or do more damage than they should because of specific weaknesses in the difficulty-adjusting algorithm.

Alternative currencies are vulnerable to hash rate decrease attacks. To resist them, they've adjusted their difficulty algorithms so that difficulty can drop rapidly. Unfortunately, these algorithms have been found to have unexpected defects. Because strict timestamp accuracy can't be enforced, an attacker can maliciously inject false timestamps into mined blocks to cause the difficulty to drop very, very quickly. This allows a malicious group of coordinated miners to extract a very large number of coins in a very small period of time with relatively little hashing power.

Effort will be needed to fix these algorithms so that they still provide protection against a hash rate decrease attack but don't create even more serious new vulnerabilities.

It may well be a rocky road these next few weeks. The 51% attack is fundamental to the decentralized nature of these currencies -- the only solution is more hashing power. But the difficulty algorithm attack issues will likely be solved by fixing the algorithms.


Could miners create a cartel to raise transaction fees?

Miners have huge investments in hardware that can only be used to mine Bitcoins. They have no incentive to do things that reduce the value and usability of Bitcoins. Any "mining cartel" with the power to get 95% of the hashing power to take collective action in non-emergency circumstances would create enough fears about 51% attacks and the like that it would drastically reduce the value of the Bitcoin system and greatly encourage competitors. So while this is theoretically possible, it's unlikely in the extreme.


What stops this style of attack on the Bitcoin network?

Then when my chain (which is essentially empty with just my mining address full of Bitcoin) is as long/longer than the current consensus I can broadcast it and nodes/miners should take the longer chain which will be mine.

It won't.

To compare the "length" of chains for the purpose of determining which of two valid chains is to be accepted, Bitcoin Core (and I hope all other implementations) look at the amount of work that went into them. Roughly speaking, this means the sum of the difficulties of all the blocks in it.

The only way you'll have more work than the existing chain, is by doing more mining than what went into the existing chain, in a short amount of time. In order to not be outrun by the existing network while you're performing your attack, you'll need (significantly) more hashrate than all the rest of the network combined has. So, what you're talking about is a 51% attack.

That said, there is a related, and far less serious attack possible. You could mine thousands of short low-difficulty branches, that are all valid, but won't ever be accepted, and broadcast them. If nodes would accept them, they'd eventually go out of memory from storing all your headers. The solution to this is the client checkpoints that MCCCS talks about in his answer. Note that the scope of checkpoints has been reduced several times, as they used to protect against many types of attacks that are now prevented through measures that don't rely on hardcoded knowledge about the network.


When you say you withdrew it, it sounds like you are withdrawing from an exchange.

In this case, it's completely up to the exchange when they'll broadcast a transaction sending you your money - some exchanges are very very slow at this and it has nothing to do with the bitcoin blockchain.

If they've actually sent the transaction, and you're just waiting for it to confirm on the blockchain it's possible they sent it with a really low fee. In this case, check the link commented by Зелёный for more information about why your transaction isn't confirming.


Is it possible to exchange bitcoins into PayPal credit?

Some people are selling bitcoins and receiving PayPal payment on LocalBitcoins.com:

https://localbitcoins.com/sell-bitcoins-online/paypal/

LocalBitcoins is in-person exchange. The problems with PayPal tend to hit the bitcoin seller; because PayPal transfers are reversible and bitcoin transactions are irreversible you must trust the party to whom you are selling bitcoins. A malicious party can file a PayPal claim and get their fiat currency payment recalled after they receive the bitcoins. This problem is not specific to PayPal, but all credit card backed payment methods (Venmo, Dwolla, etc.)

Some people have found it possible to resolve issues with PayPal payment recall policy.

Also LocalBitcoins has guide how to avoid this kind of fraud. The sellers have 25% - 50% margin when selling on PayPal, so they can cover up possible losses. Also when done successfully one can profit from the risk, as there is high demand buying bitcoins on PayPal.

LocalBitcoins also has an API, so you can at least half automatize the process, but you still need to have enough buyer audience to make sure there is demand for your bitcoins (there is).


Can a Miner or Mining pool have exclusive access to a transaction and its fees?

A non-standard client could choose to send his transactions only to a specific miner. One example might be for a client to negotiate a "monthly package" (off the blockchain), and then send all his tx directly to the pool, without any specific tx fees.

There is nothing in the protocol that prohibits or enables it - it is a possible extension that is outside of the protocol. To my knowledge, no such schemes have been reported in the real world.


Bitcoin testnet3: unable to push/publish raw transaction: how to verify validity of transaction?

Found the error!

I am using OpenSSL library and was signing using the function: ECDSA_Sign

The parameter unsigned int *siglen passed to this function is supposed to be filled with signature length. I was using the signature(parameter sig) and the length from parameter siglen to serialize the data. Turns out, although the signature being generated was always 72 bytes, the siglen parameter was filled seemingly randomly with 70, 71 or 72. And hence the number of bytes of signature that was being copied into my txn was not correct. Interestingly, if I call ECDSA_size(key) after making call to ECDSA_Sign(), i would get correct 72 value back.

AAAAh! Has anyone experienced this issue before with ECDSA_Sign? I haven't found anything on google yet.

But successfully posted the raw signed transaction using blockcypher's web tool/api.


Hashes are 256-bit integers, meaning they are whole numbers between 0 and 115792089237316195423570985008687907853269984665640564039457584007913129639935. There are no infinitely many different hashes. In particular, the number of hashes smaller than the target is exactly equal to the target.

In any case, Cantor's diagonal has nothing to do with it - if hashes were real numbers, there would be infinitely many of them even without any reference to their particular cardinality.

What makes mining difficult is that calculating a hash takes time, and that each hash only has a small probability to be less than the target. For practical purposes, each hash is a uniform random number between 0 and 2^256-1, so if the target is X it has a probability of (X/2^256) to be smaller than the target. This means that, on average, 2^256/X hash calculations will be needed in order to find a valid block. The lower X is, the more calculations will be needed.


Why do transaction fees exist in the Bitcoin blockchain if miners get rewarded with newly created bitcoins?

The block subsidy in Bitcoin serves as a decentral initial distribution mechanism and incentivizes the bootstrapping of the Bitcoin network. As you may know, the block subsidy halves every 210,000 blocks (approx. 4 years). Due to this reward schedule, more than 80% of all bitcoins have already been discovered, and in a decade, it'll be more than 95%. As the number of new bitcoins being added to the money supply dwindles, another mechanism to fund the security of the network will need to take over.

The source of that funding is meant to be transaction fees. This seems feasible, especially in light of us seeing the first block with transaction fees greater than the block subsidy last year.

  via smartbit.com.au

The transition to a fee funded mining market is tightly coupled with the blocksize debate. For example, Princeton's Weinberg et al have shown that a fee-funded mining market may become unstable unless there is a constant backlog of transactions waiting to be confirmed. Some Bitcoin clients explicitly lock new transactions to the next block's height to encourage mining of a new block in contrast to miners attempting orphaning attacks on the current blockchain-tip for fee sniping.

The described dynamic is also cause for speculation that altcoins with oversized (and thus empty) blocks may need to transition to a constant block subsidy in the longterm to maintain a stable mining market.

Finally, the limited availability of blockspace and presence of transaction fees creates a fair market for users to signal the urgency of their transactions. This allows more valuable use of a limited resource to displace frivolous or inefficient use. The fee market especially discourages spam and business models that depend on abundant blockspace. Early acceptance of the inherent limitedness of blockspace is a prime driver for innovation and investment in sound second layer technology such as the Lightning Network.

People have been speculating for years, why Bitcoin was designed with the abrupt halvings of the block subsidy instead of a smoother payout or even a constant reward. There even was an attempt to turn the initial block subsidy of 50 bitcoins per block into a constant subsidy around the first halving, but the broader network rejected the miner's attempt to increase the money supply.


Technically speaking, these are not identical hashes, because they are not hashes. They're just addresses someone created by encoding the value 0000...0000 into a P2PKH and a P2SH address.

Funds sent to those addresses cannot be spent, for two reasons.

It would require finding a public key or script whose hash is 0000...0000, which is assumed to be impossible (SHA256 or RIPEMD160 would be broken if that was the case).
Even the value wasn't 0000...0000, but the hash of an actual public key, it would still be impossible to find a script whose hash was equal. Alternatively, if it was the hash of a script, it would be impossible to find a public key with the same hash.


How Blockchain transaction verification takes place?

Each node stores the entire history of transactions (the blockchain). When a node hears about a new transaction, it performs a series of checks to make sure that transaction is valid.

So, when someone sends a tx, their software will use the private key of an unspent output (a 'bitcoin') to cryptographically sign the transaction. This signature proves ownership of the unspent output, and authorizes movement of the coins.

So when a node hears about a new transaction, it checks to make sure that the signature is valid. If the signature is not valid, it will ignore the transaction.

If you attempt to spend more coins than you own, then the signature will not be valid according to the blockchain record kept by the nodes. It is not possible to forge authenticity, you either own the coins and can create a valid transaction, or not.

Note that 'transaction validation' in this case just happens on each node, as the tx is relayed through the network. This is different than 'transaction confirmation', which happens when miners include a transaction in the next block. After 'validation', txs are stored in each nodes memory pool (mempool), until they are confirmed in a block.


Are transaction ids always the same length?

Yes. The transaction ID is SHA256(SHA256(transaction)) as described here and thus always has a length of 256 bits (32 bytes).


Is multisignature usable, if so what is the business process

Is it practical to use multisig on a Core wallet?

yes, but for sure it depends on your level of comfort. It's not (yet) plug'nplay :-) See also the example from Gavin at the end.

  If so, in simple two of two scenario, what is the process of
  generating a transaction?

see example.

  Can a third party holding neither of the private keys, propose a
  transaction for the two signers?

yes, a third party can create the transaction, and post it to the network (he would need to have the bitcoin addresses of the other  participants, to create the redeem script).

  Do they all need to use the same terminal?

no, not at all. I have done creation of the funding tx on my online system, and signing of the spending tx on an offline system (cold storage).

  How does a signer know a transaction is waiting?
  there is no protocol inside bitcoin for "notification". When you prepare a multisig, you need to have a different communication channel than the bitcoin network, to inform on necessary signing.

Example:
https://gist.githubusercontent.com/gavinandresen/3966071/raw/1f6cfa4208bc82ee5039876b4f065a705ce64df7/TwoOfThree.sh

btw: next to the examples to bitcoin.org, Andreas book "Mastering Bitcoins" (2nd edition) has many references to multisig, and it's wortwhile to read. It can even be found online.


Mining new litecoin based altcoin. Internal Server Error 500

The problem is that the Litecoin I used 0.8.4.7, does not have embedded mining software.

I ended up with two solutions:

Create mining pool and then:

connect nodes to each other
run the miner on my mining pool

Compile and run (-gen=1 option) old Litecoin node then connect to th
e other nodes one.


Is there any regulations on buying and selling Bitcoin on eBay?

According to eBay's Stamps, Currency and Coins Policy:

  Virtual currency must be listed in the Classified Ad format in the Coins & Paper Money > Virtual Currency category. These requirements apply regardless of whether the virtual currency is digitally or physically delivered. Examples of items subject to this policy include Bitcoins, Litecoins and other similar cryptocurrencies.

In particular, it appears you are currently not allowed to auction Bitcoins.


Does Namecoin support the bootstrap.dat file?

No. This feature does not exist (yet) in Namecoin.


As to elaborate on why this is accepted at all at blockchain.info, 1Wh4bh is:

>>> import base58
>>> bytes.hex(base58.b58decode('1Wh4bh'))
'001406e058'

Following https://en.bitcoin.it/wiki/Protocol_documentation#Addresses, it only contains the preface of a bitcoin address ('0x00'), and the checksum: '1406e958'. In fact, the double SHA256 of 0x00 (as the hash160 of the public key is not indicated) is:

1406e05881e299367766d313e26c05564ec91bf721d31726bd6e46e60689539a

The first 4 bytes coincide, so the checksum is right.

Because of this, the bitcoin address could be well formed... in a sense.... I suppose this is the reason why blockchain doesn't reject it.

But in fact, as no public key is indicated at all because no public key would produce a hash160 equal to the null string, it cannot be used for any purpose.

Note, also, that a null (or less than 160 bits) hashed public key is incorrect even in the case of (all) leading zeros, because Base58Check algorithm used by bitcoin preserves all leading zeroes.


What happens when transferring bitcoins to no address?

Most wallet software won't let you send to a null address. If you have a transaction without an output script, that's invalid and won't be accepted by the network. If you have an output script that's simply an OP_RETURN or otherwise unspendable, those coins are lost forever.

Generally, you should be using a wallet to transfer bitcoins and if you don't provide an address using a wallet, you'll most likely not be able to send it.


How are 'Not Mineable ' cryptos able to verify transactions?

I'm not sure about Ripple, but I know IOTA specifically uses each transaction to confirm the transactions around it. So instead of a dedicated miner, each user is essentially a "miner" for the short time they are making a transaction.


You can set a limit for blockchain data by starting your node with -prune=<n>.

-prune=<n> gives the target size in MiB to use for block files

This limit will only include the blocks and reorganization data. You also need some space for chain state, block index database, and wallet.

I run my node with -prune=20480 (i.e. 20 GiB) and fully caught up the whole directory has 20.77 GiB or 22.30 GB.

I suggest that you leave a few GiB room for overhead.


How could recurring payments be implemented?

I think the most obvious way, though perhaps not the best way, is precisely the same way as is done with other currencies. If Bitcoins are adopted as a primary currency, they'll probably be used the same way other primary currencies are.

I am paid in dollars, but no actual dollars transfer unless that is absolutely required. Instead, I have a bank account denominated in dollars from which I can withdraw actual dollars any time I need. These same mechanisms could be implemented with Bitcoins. I could have an account denominated in Bitcoins, I could be paid in Bitcoins, I could pay bills in Bitcoins, but no actual Bitcoins need change hands except where the benefits of doing things that way outweigh the costs.


Is there a way to undo transactions with a "too low" fee?

The transaction would have no effect. A transaction that wasn't accepted by the network has no effect on the ability to spend coins. The person whose coins were affected could simply delete that transaction from his own database. There's no need to undo the transaction since it was never committed to the block chain anyway.


Poloniex BTC withdrawal sent with 0 transaction fee, anything I can do?

The standard transaction fee rules allow for a transaction with no fee to be confirmed if it has high enough priority.  This depends on how old the transaction's inputs are; basically, how long since Poloniex received or last transferred those coins.

If it doesn't have high priority, it could still be confirmed, but it depends on the goodwill of the miners.  (In principle you could try to convince, or pay, a miner to include it in a block, but I don't know who you might talk to.)

As Tim S. points out in his comment, the priority continues to increase even after the transaction is sent.  You can work out from the formula in the above link how long it might take to reach a high priority level.

If it doesn't confirm in a reasonable amount of time, you should go back to Poloniex and ask them to resend it with a fee.  They can do this in a way that invalidates the original transaction (essentially a benevolent double-spend) so there would be no risk to them of paying twice.  Until you have a confirmed transaction sending you the coins you are owed, Poloniex hasn't fulfilled its obligation to you.


Holding Period Algorithms and the Blockchain

My question is, do these holding period algorithms have to correspond to the actual UTXOs being spent on the blockchain?

This is likely a question best answered by a qualified accountant, or tax lawyer.

I say this because there are many nuances to it: if you spend half of your oldest UTXO, to sell it for cash, then what do we say about the change output? It is a brand new UTXO, but clearly you bought those coins long ago. Similarly, how would the age or origin of a coin-consolidation UTXO be calculated? What about outputs from coinjoin-style transactions? What happens if I just want to update my cold storage system, and want to move coins to new addresses? etc.

I hope these examples help highlight the difficulty of applying existing regulations to a new system like Bitcoin. If you are looking for tax/legal advice, the best course of action is to ask a professional, not a stranger on the internet.

  Does using FIFO entail that you have to program your wallet to spend older UTXOs before newer ones, and vice-versa for LIFO?

A wallet using such a system would be bad for your privacy, UTXO-management, and fee-management, plus it still wouldn't answer the questions I mentioned above. So I doubt that any reasonable regulation would require such a thing.


Possible race condition(double spend) on HTLC-Timeout in the lightning network?

First of all I think there seems to be a small confusion about the notation. One does not spend a transaction but transaction outputs. In the case of offered htlcs the output is only one (of potentially many others) output.

Also I understand the timelock slightly different. If you publish the commitment transaction it can be mined and verified directly. It is the time locked output e.g. the htlc that can only be spend after the timelock.

Regarding the racecondition / double spend. First of all double spends in Bitcoin are impossible by design (unless we have an unknown exploit) so we can boil it down to the question of a race condition. Here we have to distinguish two cases:

Before the timelock: in that case you cannot spend the htlc output and only the remote side can do so with the preimage. It is the safty Period for the remote side to get the funds if the htlc was supposed to be forwarded.
After the timelock: in that case in deed a race condition can emerge. At that time the remote side should not get the preimage but abort routing anyway but if you don't sweep the output and the remote side gets hold of the preimage then in deed it comes to which spend will be included to a block first.


Why does bitcoin-cli not show the correct TXID for this transaction?

decoderawtransaction in 0.14.2 has some issues with decoding segwit transactions. Sometimes it will decode segwit transactions as non-segwit. These should mostly be fixed in Bitcoin Core 0.15.0.


I live in North America as well and just wanted to let you know that even though 110V is the most common wall socket voltage you've actually already got 220V coming in to your house.  There are 2 110V lines 180° out of phase from the other ... yadda yadda, some technical mumbo-jumbo...

Long story short, as long as you live in a building where you have access to the breaker box you should be able to add in a 220V circuit to power your miners, you may already have a couple in there for an electric range or drier, etc.

If electrical work is not your forte you should be able to get an electrician in to get you set up fairly easily, the hardest part is deciding where you want to access the power from and then routing the wiring there.

Hope that helps!

-J


Why do people claim that governments cannot confiscate Bitcoins?

While it is true that Bitcoin can still be physically taken away from you, it is still much harder to do that than it is for a government to confiscate your fiat stored in a bank account (as most fiat is). With fiat in a bank account, the government can simply go to your bank and order them to freeze your account and lock you out of it. There is no need for them to track you down, no need to go to your physical location, and no need to beat you up. It is very simple for the government to just freeze your bank account and thus confiscate your money.
But with Bitcoin, as you say, they need to go to your house, find your Bitcoin, and forcibly take it from you. It is much more work to do that as it involves people physically going to your home in order to physically seize the devices holding the keys to your Bitcoin.
And yes, this is not any different from having a bunch of gold or a bunch of cash. As with anything which is physically in your possession, the government can confiscate it by physical force. But those physical currencies and valuables are much less convenient to transact with, particularly online.
Furthermore, many countries have regulations regarding the amount of cash that you can be carrying across the border. They often will require you to declare it, and in some instances, the money can be seized by customs. Even when you are not crossing borders, simply having a large amount of cash or other valuables in your possession may raise the suspicion of police who may confiscate them. Bitcoin does not have similar problems (with the exception of novelty physical Bitcoin coins).
With Bitcoin, you can have all of the keys for your Bitcoin stored on a flash drive, a laptop, paper, or something else. It won't be extremely obvious that you are transporting large amounts of money. Even hardware wallets just look like random electronics and flash drives so they don't raise much suspicion. So if you are carrying some Bitcoin on your laptop, it is unlikely to be seized by customs agents or police where carrying similar amounts of cash or gold bars might be.
Lastly, there is also a philosophical form of confiscation that governments partake in - inflation. Central banks nowadays routinely issue more and more fiat currency leading to some amount of inflation. Over time, any cash that you have will have less purchasing power. If you simply save money, then over time, the government is effectively confiscating some of your money through inflation. On the other hand, Bitcoin has a known supply that eventually becomes fixed. While there is some inflation, because of the eventual fixed supply, Bitcoin largely becomes deflationary thus allowing your saved Bitcoin to actually have a greater purchasing power in the future. While precious metals currently have a fairly fixed supply, theoretically it would be possible to find large quantities of them somewhere else in the universe which would then cause the value of those precious metals to go down. With Bitcoin, that is not possible.


I found the answer. This 'unknown bytes' described in bip144


What cryptography hardware and/or software does a bitcoin exchange need to employ?

An exchange does not necessarily need their own hardware, as they won't be mining anything. However you will defenitely need some hardware.

A server

Where else do you host your exchange? Your laptop?

A dedicated device for cold storage

Every good exchange needs a cold storage wallet, to ensure that if you get hacked, you won't lose all your funds.
-A cold storage wallet is basically a dedicated device that has never touched the internet. This is very effective against malware, as there is no way for malware to access your computer unless the actual hacker has access to your device.

A dedicated device for your own node

You defenitely don't want the guy hosting your node to fake an incoming transaction and get you to credit them with free funds! Host your own node that will not be tamlered with.


The C API for processing JSON is Jansson. C applications like libblkmaker use cURL for making the calls and Jansson for interpreting the JSON that cURL fetches.

For example basic usage (which can be easily modified for Bitcoin RPC), see the Jansson example github_commits.c and the associated tutorial.

Here's an example of how to make JSON RPC calls with cURL, the output of which Jansson could process:

#include <stdlib.h>

#include <curl/curl.h>

int main()
{
    CURL *curl = curl_easy_init();
    struct curl_slist *headers = NULL;

    if (curl) {
    const char *data =
        "{\"jsonrpc\": \"1.0\", \"id\":\"curltest\", \"method\": \"getinfo\", \"params\": [] }";

    headers = curl_slist_append(headers, "content-type: text/plain;");
    curl_easy_setopt(curl, CURLOPT_HTTPHEADER, headers);

    curl_easy_setopt(curl, CURLOPT_URL, "http://127.0.0.1:8332/");

    curl_easy_setopt(curl, CURLOPT_POSTFIELDSIZE, (long) strlen(data));
    curl_easy_setopt(curl, CURLOPT_POSTFIELDS, data);

    curl_easy_setopt(curl, CURLOPT_USERPWD,
             "bitcoinrpcUSERNAME:bitcoinrpcPASSWORD");

    curl_easy_setopt(curl, CURLOPT_USE_SSL, CURLUSESSL_TRY);

    curl_easy_perform(curl);
    }
    return 0;
}

It will print, like the cURL example, something like this:

  {"result":{"balance":0.000000000000000,"blocks":59952,"connections":48,"proxy":"","generate":false,
       "genproclimit":-1,"difficulty":16.61907875185736},"error":null,"id":"curltest"}


There is none, and I don't think it will ever be significant. There is a gentleman's agreement that's part of what makes Bitcoin work that a Bitcoin is a Bitcoin is a Bitcoin.

You can have a few "rare Bitcoins" with extra value. I might pay extra to have one Bitcoin transferred to me directly from the coins in the genesis block, for example. But just like there can be a few rare dollar bills, a dollar only works as a medium of exchange if more or less, we all agree that a dollar is a dollar. A prime serial number is cool, but your grocery store can't care about that if it wants to do business.


This means your pool server has accepted one block, generated your CPU, third thread, of difficulty 288 (with a minimum of two).


Bitcoin HEISTS: Has USD, EUR, etc ever been stolen from an exchange?

Someone that gains access to an exchange's system has several options:

transfer out BTC
transfer out fiat
manipulate/corrupt the exchange

Option 1 is fairly trivial to do nearly anonymously. Governments and lawyers are good at tracking down people that take option 2. Option 3 isn't the most straightforward way to profit.

Why would anyone take the risks with #2 instead of just doing #1?


Full example data for scrypt Stratum-client

Alright, I finally managed to fix my bugs and get a full roundtrip. Here is an example for a full communication with a Pool.
I don't explain everything in detail as the API description can be found elsewhere.
a) Suscription
{"id": 1, "method": "mining.subscribe", "params": []}
{"error": null, "id": 1, "result": [["mining.notify", "ae6812eb4cd7735a302a8a9dd95cf71f"], "f8002c90", 4]}

We suscribe with the server. This has no parameters.
As result, we receive some Suscription ID, and our Extranonce1 + extranonce2 size, which we need for later.
b) authorization
{"params": ["User", "password"], "id": 2, "method": "mining.authorize"}
{"error": null, "id": 2, "result": true}

Authorize worker with Username + password. No parameters to store from the result.
c) Server -> difficulty
{"params": [32], "id": null, "method": "mining.set_difficulty"}

Sets the difficulty to 32, defining our target. The resulting difficulty can be calculated as
0x0000FFFF00000000000000000000000000000000000000000000000000000000 / 32 =
0x000007fff8000000000000000000000000000000000000000000000000000000

Now, the fun part:
d) Block info
{"params": ["b3ba", "7dcf1304b04e79024066cd9481aa464e2fe17966e19edf6f33970e1fe0b60277", "01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff270362f401062f503253482f049b8f175308", "0d2f7374726174756d506f6f6c2f000000000100868591052100001976a91431482118f1d7504daf1c001cbfaf91ad580d176d88ac00000000", ["57351e8569cb9d036187a79fd1844fd930c1309efcd16c46af9bb9713b6ee734", "936ab9c33420f187acae660fcdb07ffdffa081273674f0f41e6ecc1347451d23"], "00000002", "1b44dfdb", "53178f9b", true], "id": null, "method": "mining.notify"}

I split the parameters and assign them to variables
job_id = "b3ba"
prevhash = "7dcf1304b04e79024066cd9481aa464e2fe17966e19edf6f33970e1fe0b60277"
coinb1 = "01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff270362f401062f503253482f049b8f175308"
coinb2 = "0d2f7374726174756d506f6f6c2f000000000100868591052100001976a91431482118f1d7504daf1c001cbfaf91ad580d176d88ac00000000"
Merklebranches = [
    "57351e8569cb9d036187a79fd1844fd930c1309efcd16c46af9bb9713b6ee734",
    "936ab9c33420f187acae660fcdb07ffdffa081273674f0f41e6ecc1347451d23"
    ]
version = "00000002"
nbits = "1b44dfdb"
ntime = "53178f9b"
clean_jobs = true// Not required for block, just for completeness

What we also need is extranonce1 and extranonce 2:
extranonce1 = "f8002c90" // from earlier
extranonce2 = "00000002" // can be anything, but 4 bytes

With this, we can start building our Merkle root:
First, the coinbase:
coinbase = coinb1  + extranonce1 + extranonce2 + coinb2;
coinbase = "01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff270362f401062f503253482f049b8f175308f8002c90000000020d2f7374726174756d506f6f6c2f000000000100868591052100001976a91431482118f1d7504daf1c001cbfaf91ad580d176d88ac00000000"

Now, we convert this coinbase into binary. No flips or BE-LE conversions required, straight from left to right.
The resulting binary data is hashed with sha256(sha256(data)).
From here on, I will post binary as hex representation, but as is: Left to right, no endianess conversion
resulting hash : 280b3927f6763b1ed90cae2a3cef4d27c743f6a7d91e3901dc3816a46acacf36

This is the start for the merkle concatination. Concatinating means just joining them. 32 byte for the hash and 32 byte for each merkleroot result in 64 byte of data to hash.
for each Merkle_branch
    byte[64] = hash + merkle_branch
    hash = sha256(sha256(byte))
end

For the example it looks like this:
byte = 280b3927f6763b1ed90cae2a3cef4d27c743f6a7d91e3901dc3816a46acacf36 + 57351e8569cb9d036187a79fd1844fd930c1309efcd16c46af9bb9713b6ee734
hash = e6df228610b9f0e96a42a4877565627a3e1e133e984b6c46ff6e44b7dc9dc056

byte = e6df228610b9f0e96a42a4877565627a3e1e133e984b6c46ff6e44b7dc9dc056 + 936ab9c33420f187acae660fcdb07ffdffa081273674f0f41e6ecc1347451d23
hash = 0b1edc1ccf82d3214423fc68234f4946119e39df2cc2137e31ebc186191d5422

which is the final merkle_root. There is no need of converting it back to hex, it can be kept in binary format for the next step
e) Block header
The block header is build with all previous information + the calculated merkle root. It results in 80 byte of Data
blockHeader {
    version[4]
    prevhash[32]
    merkle_root[32]
    ntime[4]
    nbit[4]
    nonce[4]
}

Here, byte order gets a bit tricky: All 4 byte types are Little endian, and bytes have to be flipped. Merkleroot can be copied 1:1, without flipping bytes.
prevhash is what surprised me the most. It can be best viewed as an array of 8 4byte ints, where each of these ints has to be converted to LE, but the order is kept left to right.
I show it in the example:
version:  00000002 --> 02000000
prevhash: 7dcf1304 b04e7902 4066cd94 81aa464e 2fe17966 e19edf6f 33970e1f e0b60277
        -->   0413cf7d 02794eb0 94cd6640 4e46aa81 6679e12f 6fdf9ee1 1f0e9733 7702b6e0 // 8 ints left to right, each one flipped
merkle:   0b1edc1c cf82d321 4423fc68 234f4946 119e39df 2cc2137e 31ebc186 191d5422 // nothing changed
ntime:    53178f9b --> 9b8f1753
nbits:    1b44dfdb --> dbdf441b

Results in the following bytestream:
020000000413cf7d02794eb094cd66404e46aa816679e12f6fdf9ee11f0e97337702b6e00b1edc1ccf82d3214423fc68234f4946119e39df2cc2137e31ebc186191d54229b8f1753dbdf441b00000000

Note that we don't need the padding or anything, like the bitcoin implementations have, the 80 bytes are all we need.
Now, lets hash it
f) hashing and result
sending this through a scrypt cycle results in the following hash:
f6f13e350aa4f251e192ab8a78690ee99f1cc2d930d4ae16c4172a0a8aefddd0

Well, this is not the hash we are looking for... So we start playing with nonce first, and if thats not enough we can increase the ntime. Until finally, after a long time, we try
nonce = "00007f8a" // BigEndian
time = "53178f9f" // BigEndian

This gives us the following Block and resulting hash:
block = 020000000413cf7d02794eb094cd66404e46aa816679e12f6fdf9ee11f0e97337702b6e00b1edc1ccf82d3214423fc68234f4946119e39df2cc2137e31ebc186191d54229f8f1753dbdf441b8a7f0000
hash = 7441207b6390054623bc5e659ffe2581356dafc5ec41db44d27de85035000000

Looks kind of high, but here again, endianess has to be considered. To compare it with our Target, we have to compare high to low. And, not to forget that we have to change the byte order of our target:
target = 0x000007fff8000000000000000000000000000000000000000000000000000000
   --->  0x000000000000000000000000000000000000000000000000000000f8ff070000

Now if we compare them:
000000000000000000000000000000000000000000000000000000f8ff070000
7441207b6390054623bc5e659ffe2581356dafc5ec41db44d27de85035000000

We see that the hash is below our target, and we can submit it. Alternatively we can look at them in the other byte order (in which it is printed most of the time)
000007fff8000000000000000000000000000000000000000000000000000000
0000003550e87dd244db41ecc5af6d358125fe9f655ebc23460590637b204174

Which looks the same, mostly. This leads us to our final step:
g) Submit Share
Now we collect the variable parameters we used, and send them to the server.
user = "user"
job_id = "b3ba"
extranonce2 = "00000002" // No byte swapping needed. Its how we put it in the coinbase
ntime = "53178f9f" // This is Big Endian. The ntime in the block_header is little endian. IF you read it from your block_header, don't forget to swap
nonce = "00007f8a" // Same here. Convert To BigEndian before sending

We pack these Data in a neat JSon wrapper, and send it off to the server:
{"params": ["User", "b3ba", "00000002", "53178f9f", "00007f8a"], "id": 4, "method": "mining.submit"}

And, if all works well, and we have no other problems (like stale shares or anything), we get a positive response:
{"error": null, "id": 4, "result": true}

And thats it! For more shares repeat as often as wanted.


Can I be held liable if a gateway vanishes?

You are not liable when a gateway vanishes.
When you send money on Ripple, you are trading IOUs. In order for someone to receive IOUs, this recipient must have expressed his acceptance of IOUs from the corresponding issuer.

Alice wants to buy a lot of ice-cream from Bob for $20. They both trust the gateway Gateway.
Alice has previously paid $100 to Gateway and holds therefore an IOU from Gateway with the value of $100. She sends $20 to Bob. Bob also trusts Gateway, so he is willing to accept Gateway-IOUs as payment. Gateway now owes her only $80, and Gateway owes $20 to Bob.

At this point their deal is done. So, if Gateway went under after this, there would be no liability, because the payment was transferred and accepted by Bob. His beef is with Gateway, or with himself for trusting Gateway, not with Alice.


Why isn't my PSBT considered complete after walletprocesspsbt and finalizepsbt?

To get more details about the next steps for a PSBT, you can use the analyzepsbt RPC. Additionally, decodepsbt will tell you what information is in a PSBT so you can use that to inspect the PSBT to learn what is missing.


Is Electrum's SPV (thin-client) implementation not P2P (as opposed to Multibit's)?

MultiBit connects to (typically) four bitcoinds at random at start up. It then picks the best peer (using ping times, advertised blockchain height and the version of the peer to decide) and uses that as the download peer to get the block headers from.

It is thus using one peer to catch up the blockchain from where it previously knew about.

It listens to all four connections to hear about all the new broadcast transactions and uses this to work out a 'transaction confidence'. If four peers tell it a transaction exists, it has more confidence that the transaction is real.

When it sends a transaction, it sends it via the single download peer and then listens on the other peers to hear that transaction 'echo' back from the network. Once it has heard the transaction it just sent come back via other peer(s) it can be confident that the transaction is 'out in the Bitcoin network'.


Since which version is the mining functionality removed from the wallet?

Bitcoin Core removed it in version 0.13.0.  You can see the change log at https://bitcoin.org/en/release/v0.13.0:

  Removal of internal miner

  As CPU mining has been useless for a long time, the internal miner has been removed in this release, and replaced with a simpler implementation for the test framework.

For future questions like this, all change logs can be found at https://bitcoin.org/en/version-history.


What does the frequency of my miner mean?

I believe that is just a parameter to allow you to control the clock frequency (usually measured in MHz) of your miner. You can see a sample list of configurations for CGMiner here.

There is an inherent trade-off here. A higher frequency means a higher hash-rate but more energy consumption and wear-and-tear on your hardware. For example, this site shows a sample chart of different frequencies and hash rates for a particular piece of hardware. It's up to individual miners to figure out what the right trade-off between performance and energy consumption is for them.


I sent $50 worth of bitcoins from coinbase wallet to bittrex wallet but received only a third of it in the bittrex

This is normal, Bitcoin's transaction fees are getting excessively expensive. That could be why altcoins like BCH are gaining popularity


Hardware Wallet Security if Computer App (MEW, Ledger, Trezor) is compromised

But, I don't want to use MEW My Ether Wallet, it gets hacked!

The point of a hardware wallet is that even if the software or service you are using is compromised that your private keys are still safe. So even if MEW gets hacked, you can still use it and be sure that your private keys are still secure. The private keys never leave the Trezor or Ledger and in order to send any money anywhere, you need to confirm it on the device so your coins can't be stolen without you being aware of the transaction.


Is it wrong to spend Bitcoin from someone else's wallet if my Bitcoin client generates the same address?

However, perhaps because Bitcoin inherently allows for this possibility (by design)

I would dispute that.  A fundamental tenet of cryptography is that "extremely unlikely" is effectively the same as "impossible".  Bitcoin has been carefully designed so that this should never happen by chance.  And people definitely don't use Bitcoin with the assumption that there is a meaningful chance of someone else taking their coins through this route.  There is certainly no implied consent.

In fact, I think that it's meaningless to discuss the ethics of what to do if you accidentally generate the same key as someone else.  To me, it's like asking whether it would be ethical to kill a time traveler.  Maybe the discussion helps you think about ethics, as a thought experiment, but it has no practical relevance, because it's about a situation that fundamentally can never happen.

In practice, if you ever do generate an address that already exists, what it means is that both of you are using terrible random number generators.  Maybe one or both of you is doing so on purpose, suspecting that the other has a weak RNG and trying to exploit it.  So if it's not you that's intentionally trying to crack something, then throw away the software (or hardware) you are using, because it's horribly broken.  And do the rest of the community a favor and responsibly disclose the vulnerability, so that people know not to use it, and so experts can investigate the problem.

In this case, you could of course take advantage of the other person and steal their coins.  But you'll know that it's not just random chance - you're actively exploiting a flaw in the software.  I think that would help most people realize that it's clearly unethical to do so.  (You could also transfer the coins to another address, so that they can't be stolen by someone else, and then try to get them back to the rightful owner.)

The other possible explanation for such an occurrence is that one or both of you has found a severe weakness in the cryptographic primitives used by Bitcoin.  This is similar to the previous case: responsibly disclose and don't steal anything.


Is the synchronization process supposed to be downloading at less than 5kB/s?

The synchronization process may be slow on slow computers - it does not only rely on bandwidth. After downloading a chunk of blocks from various peers, the Client needs to verify every transaction in them, which is a very CPU intensive task. If you have a slow computer, this will be the bottleneck - you will spend a lot of time verifying the block and only a little downloading them, making the average download speed small.


The number of Bitcoins in circulation

That would be almost impossible to change and would drastically undermine confidence in the Bitcoin system. I think we're stuck with this forever, or until Bitcoin becomes obsolete.

  The rate of Bitcoin production

Again, almost impossible to change.

  Or the number of confirmations before a transaction is confirmed?

Anyone is welcome to consider a transaction confirmed after as many or as few confirmations as they like. There is no reason this requires any kind of agreement.


When transferring money between a bank and bitcoin exchanges, might the bank suspend my account?

There have been numerous reports of exactly this happening on bitcointalk.  This thread lists several people talking about this problem: https://bitcointalk.org/index.php?topic=255174.0;topicseen.  Another person also asked why this happens so regularly right here on stackexchange and received what sounds like a pretty good answer: Why so many bitcoin exchanges have their bank accounts closed and have problems establishing bank accounts?

I do not live in the UK, so I cannot speak with personal experience about UK banks' opinions about Bitcoin.  But if you are interested in buying bitcoins and concerned about having your bank account closed, I would encourage you to open an account with the Internet Credit Union: https://internetcreditunion.org/  They went on record at last year's Bitcoin Conference saying that they will support Bitcoin with their Credit Union, see their presentation for more details: https://www.youtube.com/watch?v=RD6fVNGEnlI&list=PLUOP0P68GJ3BGjfqoLLnzAefk3ZzXQtJ7&index=5  Unfortunately, I don't remember where in the 34 minutes it was that they said that, but it's in there somewhere.

Their bank is based in the United States, but their signup page (https://internetcreditunion.org/form-membership-application/) says you can use a foreign passport and United States tax ID number to get an account.  So if you're willing to get a tax ID number, you can get an account with them.  That would be my recommendation if you're interested in buying bitcoins without having to worry about having your bank account closed.


Yes, use your pool adress instead of yours.
Password usually doesn't matter, however you can set it on pool website.

This tutorial shows creating your own pool, but since this question also shows that you are a begginer, start by mining by someone else.


How do I know when my mining GPU has been worn out?

You can try running different software for mining after restoring the overclock settings back to factory settings. This way if the graphic card fails, you know the problem exists regardless of the mining software and the overclocking.


If you are having a hard time syncing (maybe poor internet connection?) , try getting all your private keys using the API command "dumpwallet" and then importing them into the Electrum wallet ( there will be an option to import private keys when starting a new wallet, and import private keys into an existing wallet). Electrum, available at https://www.electrum.org, will sync almost immediately since its an SPV client and you can check your balance.


How to stream transactions on the network

Reading your question again, and looking at the comments, I think your question is slightly misinformed.

The standard bitcoin QT client is a node, which means that it receives the inventory of all transactions and relays all valid transactions it requests to receive (from the inventories). That's a bit of a mouthfull but read it carefully.

This has nothing to do with your wallet. It is a standard function of the full node on the peer to peer network.

What you appear to be mixing is the functionality of the wallet and the functionality of the node. These are two different things.

Bitcoin QT is unlike other (lightweight or SPV) clients which only request information specific to the addresses they hold, when trying to syncronise themselves with the network.

If you are looking to essentially print all transactions that are being relayed through your node, I think this would be pretty straitforward using something like Node.js or just running a continuous regular process which queries Bitcoind using RPC.


What is Best Address to use to receive multiple payments?

All those addresses have the same structure (a public key hash) and are used the same way.
The difference is, bc1 addresses keep transaction signatures in a separate place in the blockchain than 1 addresses. That is, there's a fee discount when you spend from bc1 addresses. Without any doubts, the newer bc1 addresses are superior.
The reason 1 addresses are still in use is, legacy codebases that aren't updated for bc1 compatibility. Use bc1 whenever possible.


Addresses derived by an HD wallet are intentionally not publicly linkable to one-another (that would be obviously terrible for privacy). Your wallet software will know the addresses are related (ie, it derived them all from the same seed), but a casual observer will not.

Accordingly, when you pay some bitcoin to a child address, there is no associated activity involving the parent addresses.

  How to generate sub addresses belonging to one private key in blockchain.com API

You cannot. Each address derived by an HD wallet will have a corresponding, unique private key related to it. The master private key for the wallet will not be able to sign and spend any funds stored at child addresses - you need the child private keys to do that.


How fast can one generate Bitcoin addresses?

VanityGen uses the GPU to generate addresses until a desired match is found. On my 5870 it does about 27 million addresses per second.


Upper limit on the blockchain file size with pruning?

Assuming all remaining transaction outputs are 0.00000001 BTC (1 satoshi), with one single ouput per transaction left, and all assigned to standard pay-to-pubkey-hash addresses, I'd say the minimal upper bound on the pruned blockchain size is 21M * 10^8 * 54 bytes, or about 113 petabyte (100 pebibyte).

The 54 bytes per transaction, is calculated as 32 txid bytes, 1 info header byte, 1 byte to store the amount, 20 bytes to store the pubkey hash (address).


Why is decentralized e-commerce good or better?

Stealing directly from Satoshi's original paper:

  Commerce on the Internet has come to rely almost exclusively on
  financial institutions serving as trusted third parties to process
  electronic payments. While the system works well enough for most
  transactions, it still suffers from the inherent weaknesses of the
  trust based model.  Completely non-reversible transactions are not
  really possible, since financial institutions cannot avoid mediating
  disputes. The cost of mediation increases transaction costs, limiting
  the minimum practical transaction size and cutting off the possibility
  for small casual transactions, and there is a broader cost in the loss
  of ability to make non-reversible payments for nonreversible services.
  With the possibility of reversal, the need for trust spreads.
  Merchants must be wary of their customers, hassling them for more
  information than they would otherwise need.  A certain percentage of
  fraud is accepted as unavoidable.

In other words, it's cheaper and safer to not to have to trust the other party, or to have to pay someone else to trust the other party.


I took this from Andreas' book "Mastering Bitcoin" (2nd edition, page 158ff):

  To lock it to a time, say 3 months from now, the transaction would be
  a P2SH trans‐ action with a redeem script like this:

[now + 3 months] CHECKLOCKTIMEVERIFY DROP
DUP HASH160 [Bob's Public Key Hash] EQUALVERIFY CHECKSIG

  where  is a block height or time value estimated 3
  months from the time the transaction is mined:
  current block height + 12,960 (blocks) or current Unix epoch time +
  7,760,000 (seconds).

The problem is that we are currently at ~506000 blocks, so if this should be a block height, and not a time range, it must be ~94000 blocks in the future.

  CLTV and nLocktime use the same format to describe timelocks, either a
  block height or the time elapsed in seconds since Unix epoch.
  Critically, when used together, the format of nLocktime must match
  that of CLTV in the inputs—they must both reference either block
  height or time in seconds.

  If nLocktime is nonzero and below 500 million, it is interpreted as a
  block height, meaning the transaction is not valid and is not relayed
  or included in the blockchain prior to the specified block height.

So in your case it must be:

94000 CHECKLOCKTIMEVERIFY DROP
DUP HASH160 [Bob's Public Key Hash] EQUALVERIFY CHECKSIG

You could achieve the delay also with nLocktime, then the tx is not put into the blockchain before the block appears (I think the tx stays in mempool), but with the CLTV it goes directly into the blockchain (is visible in the blockchain), and can only be retrieved after block height  is reached.


zero fee txs get into blocks all the time. many pools accept zero fee txs that have sufficiently high priority. that is, the inputs are aged and of high value.


It doesn't seems to be a better solution than waiting. The original transaction (the 4 inputs 2 outputs one) has been relayed by the Electrum node that received it and spread over the network, therefore, it's in the mempool of the network nodes. Every transaction that tries to spend the same UTXO referred by the first transaction will be marked as double-spending until the first transaction is pruned from the mempool. Hence, waiting is unfortunately the only solution that comes to my mind.

Edit: Answering another question I came across a thing that could also be useful for you. You can use a CPFP approach. To do so, try to spend from the transaction that is pending to be confirmed with a new one with high fee. This new transaction will be like a candy for miners, and in order to include it in a block, they must include the previous also.

Edit2: Regarding the error message provided, there is a problem in how the transaction that the author wants to send (T1 from now on) has been build. The scriptSig of the transaction is not properly set.

The serialised T1 is:

01000000018964907116f6245417b9d9aea1d226e46486c5d485d6b947c95c794e032df612010000001976a9140043be27e16b93c275413e9b4411f08f2cd8bef088acffffffff0120082f08000000001976a9140b01599fd09ef602d71827601871e5a1081459f688ac00000000

Is we decode T1 we will get something like:

version: 01000000
number of inputs: 01 (1)
input 0
     previous txid (little endian): 8964907116f6245417b9d9aea1d226e46486c5d485d6b947c95c794e032df612 (12f62d034e795cc947b9d685d4c58664e426d2a1aed9b9175424f61671906489)
     previous tx output (little endian): 01000000 (1)
     input script (scriptSig) length: 19 (25)
     input script (scriptSig): 76a9140043be27e16b93c275413e9b4411f08f2cd8bef088ac
     nSequence: ffffffff
number of outputs: 01 (1)
output 0
     Satoshis to be spent (little endian): 20082f0800000000 (137300000)
     output script (scriptPubKey) length: 19 (25)
     output script (scriptPubKey): 76a9140b01599fd09ef602d71827601871e5a1081459f688ac
nLockTime: 00000000

At this point, we can notice that the scriptSig is incorrect. Analysing it carefully, we can notice that it has the structure of a P2PKH scriptPubKey instead of the corresponding signature that should complement the scriptPubKey of the previous transaction (T0 from now on):

76a9140043be27e16b93c275413e9b4411f08f2cd8bef088ac =
OP_DUP OP_HASH160 0043be27e16b93c275413e9b4411f08f2cd8bef0 OP_EQUALVERIFY OP_CHECKSIG

If we want to be definitely sure about this, we can check the scriptPubKey of the UTXO from T0 we are trying to spend, and analyse both scripts.

The UTXO from T0 we are interested in can be identified by (id:index):

12f62d034e795cc947b9d685d4c58664e426d2a1aed9b9175424f61671906489:1

If we look for the specific scriptPubKey that contains that UTXO, we will find:

OP_DUP OP_HASH160 0043be27e16b93c275413e9b4411f08f2cd8bef0 OP_EQUALVERIFY OP_CHECKSIG

That curiously matches with the scriptSig that we have found in T1.

Conclusion

T1 scriptSig (input 0) and T0 scriptPubKey (output 1) shared the sames script. T1 scriptSig must provide the signature required in T0 scriptPubKey in order to pass the validation:

scriptSig:  [signature]
sciptPubKey: OP_DUP OP_HASH160 0043be27e16b93c275413e9b4411f08f2cd8bef0 OP_EQUALVERIFY OP_CHECKSIG


Where is sum(vin) > sum(vout) check in Bitcoin Core?

https://github.com/bitcoin/bitcoin/search?q=bad-txns-in-belowout&unscoped_q=bad-txns-in-belowout

const CAmount value_out = tx.GetValueOut();
if (nValueIn < value_out) {
    return state.DoS(100, false, REJECT_INVALID, "bad-txns-in-belowout", false,
        strprintf("value in (%s) < value out (%s)", FormatMoney(nValueIn), FormatMoney(value_out)));
}


Why are some public keys prefixed with 0x00?

These are not keys, they are arbitrary data.

Until Bitcoin 0.16, an invalid public key was allowed in the bare multisig, as long as it's the right size. With the upcoming 0.17, this is no longer possible, and transactions like the ones you linked to will be considered non-standard (note that this does not prevent their inclusion in a block, and they are still valid if included).

People have often used such tricks to embed data in the blockchain. For instance, providing 1 valid and 1 invalid key in a 1 of 2 multisig allows someone to embed 33 bytes of data, without sacrificing the BTC locked up in the wallet.

A more extreme example of this is in tx fc200f9cef8faf8f76756b5d02081061a1fd22ec1d580f778c12373e12a56016, which contains "keys" like 100000000000000000000000000000000000000000000000000000000000000000.

(example tx from this issue)


I have had the same issue. Instead of deleting blockchain data, I found that you can run the application with commandline arg to reindex and rescan:

/Applications/Bitcoin-Qt.app/Contents/MacOS/Bitcoin-Qt -rescan -reindex


I sent bitcoin to the same address a second time, how can I recover it?

I accidentally sent $28 in bitcoin to this address 32o7Pt42rsUFupN9sNLYJdQc6MNji5rANg a second time, and it never posted to the account

It sounds like you are depositing to a service. You should get in contact with the admins at that website or service to see if they can credit your account.


What if I find my password, and not the wallet

It sounds like you are confusing two distinct objects: a password, and a seed phrase.

A password is used to encrypt a file, so that if you have the encrypted file but not the password, you cannot read the file's contents.

A seed phrase is used to derive a master private key that the rest of a wallet's keys will be based upon. So if you have the seed phrase, you can recreate the wallet.

From the sounds of it, you likely have a password that can be used to decrypt a specific wallet.dat file, not a seed phrase. A seed phrase will most commonly be a set of 12-24 words, while a password will be a (hopefully highly entropic) string of characters. If you created the wallet file many years ago, chances are the BIP 39 standard for creating HD wallets from a seed phrase was not widely used yet, furthering my suspicion that you indeed have a password, and not a seed phrase.


How do I make a Bitcoin "memory wallet" (or paper wallet without paper)?

step 1 - memorize all the private keys that would otherwise be stored in some sort of wallet file

step 2 - there is no step 2


How to Get Unspent Transaction Outputs from Node

listunspent will list all unspent outputs of addresses the wallets controls, it will not work for any arbitrary address.

You can importaddress to add any address as a watch-only address, but this may take some time as your node will need to rescan the blockchain to find all associated transactions. Also note that when you use importaddress, you will not be able to spend any funds held at that address, since your wallet will not hold the private keys for it.


How does a non-segwit full-node validate a SegWit input

0 and ab68025513c3dbd2f7b92a94e0581f5d50f654e7 in stack-based bitcoin
  script does not return true

They do return true. Here is some pseudocode:

push ( 0 );
push ( ab68025513c3dbd2f7b92a94e0581f5d50f654e7 )
return ( pop ( ) != 0 ); // evaluates to true


Mutlisig tansactions with trezor with multiple inputs and outputs not able to broadcast

@Sunny, looks like you just broadcast a valid TXN on those UTXOs, so I assume you figured it out.

For those reading at home, the problem was that there were three addresses in the redeem script:

48'/0'/2'0/0
48'/0'/3'0/0
48'/0'/1'0/0

But only one address is used (twice) to sign the TXN

48'/0'/2'/0/0

The result is that your script hash is correct, since you used the proper three addresses, but you don't meet the 2 of 3 requirement to spend since you've only proven ownership of the private keys for 48'/0'/2'/0/0

I assume you simply corrected the error and added a second address to your script.


Cannot Find Transaction from Blockchain Explorer

A bulk transaction on 2020-09-05 at 02:07 transferred funds to a large number of recipients including 0.01546751 BTC to 1FCF...WfbV (34th recipient on that list)
See https://www.blockchain.com/btc/address/1FCFLjBDk3BGbp2vtEPRNLcbGisZRUWfbV
Maybe the transaction was initially included in a block that became extinct and the transaction was subsequently included in a later block? All normal.


Running full node ( bitcoind ) without private key

You can simply add your addresses as "watch only" addresses to the wallet, which means that the private keys are not stored on the server, but the transactions are still listed by the RPC calls. You can then keep your private keys elsewhere, for example on a hardware wallet.


Surely your idea is appreciable but there is some subtle points one needs to consider, some of them I tried to put in brief. Similar ideas are in existence and the community is working to fix the holes. I will suggest reading about Casper(PoS for ethereum), Algorand(S Micali), Bitcoin-NG, CAP theorem, Byzantine agreement etc.

  2) The blockchain's protocol takes X and the next (say) 100 transactions and puts them in a block.

When you say the "blockchain's protocol" accumulates the transaction and puts into them into a block practically these needs to be done by some single miner(or validator or node). There are several questions one has to consider

Q1. Who will have the right to create the block and how to decide it? Also how to ensure the fairness among the miners that they will get in return proportional to the running cost.

Q2. Also what incentivises them to participate in the consensus protocol

  Distributed peer-to-peer nodes verify all the transactions in this block. They all work on the same consensus protocol block rather than creating individual competing blocks.

Q3: How the block will be distributed to the entire network and what consensus mechanism should they follow? Should it be Byzantine Agreement or PoS or PoW?

  Once 51% of nodes verify and sign that all the transactions in the protocol block are legitimate

Q4: What constitutes the 51% nodes in the protocol, for example in PoW it is 51% computation power. Surely it can't be the number of nodes in the network as a miner can create as many numbers of nodes as it want's gaining the absolute majority(Sybil Attack).

The above question will raise the question of the barrier to entry say monetary entry so we are going back to Proof-of-Stake.

Now considering the benefits that you are claiming.

  Costly calculations and energy consumption are eliminated

It purely depends on the consensus protocol miners follow to agree on the majority rule.

  Mining centralization (and it's regulatory threat) is reduced;

If the barrier to entry to the consensus protocol is quite low and if there is no randomization as it is, in this case, the chances that miners will come together till 51% size to gain more than the fair share by rejecting consensus from anybody outside the pool eventually taking all the reward.

  The Nothing at Stake (NoS) problem is minimized because miners simply can't create other blocks or chains;

  Chronological verification and instantly immutable blocks prevent double-spending;

The above two points implicitly assuming synchronization among the clients and does consider the CAP theorem in consideration.

  Coins are freed and spent instead of hoarded and staked like PoS systems;
  Miners are paid every time instead of sporadically over time;

The above two question is the consequence of immediate agreement among miners, which has issues like synchronization and also nothing at stake attack.

I am not certain I understood the following point quite clearly.

  Downward price pressure is reduced because miners don't have to sell block rewards for fiat to buy electricity for mining;


How to determine the coin amount needed for vin?

it seems the coin amount of vin calculated from vout.

It is. vin just references a vout from a previous transaction. Each output (vout) are referenced with the txid and an index (e.g. 0 or 1, because there can be multiple outputs in the same tx).

For more information about how transaction inputs and outputs work, see In getrawtransaction, what is the vout integer in the vin list?


To answer your question let me give you an example of what some people do in order to try and take advantage of market arbitrage with Bitcoin.

As you know, Bitstamp and BTC-E are two of the biggest exchanges that are trading Bitcoin. If you look at the BTC price on BTC-E you can see it is always lower than that of Bitstamp.

If you were to go to Russia (or know somebody in russia that trades bitcoins locally) they go by the BTC-E price there. So, if you find a guy in Russia that can sell you coins at BTC-E price, if you are located in the US you can sell your coins here at Bitstamp's price. Same goes for Huobi (which is in china).

In order for arbitrage to work you need to know people in different countries who can sell bitcoins locally for you at that market price.

So go out there and make those connections whether it be in the trollboxes, forums (bitcointalk) or other means.

Hope I helped.


Help understand multi-signature transactions

A multi-sig address is created in a deterministic manner using the parameters and addresses which can spend funds from the account.

For example:

I would like to sell you a GPU, but we do not know each other
We find an escrow service (or common contact to serve as escrow) we both trust
We create a multisig address with parameters 2 signatures required < your address > < my address > < escrow address>, the address is deterministic so we will both get the same address
You send coins for the GPU to this address, I verify the coins are received and ship the GPU to you
You receive the GPU and create a transaction paying out to < my address > and sign it with the key for < your address >, I sign the transaction with < my address > and broadcast it to the network
If there is any dispute (e.g. you don't receive the GPU or it arrived not as described), you contact the escrow agent and if he agrees with your case, he creates a transaction sending the coins to < your address > and signs it with < escrow address >, you sign the transaction with < your address > and broadcast it to the network

Since 2 signatures are required any dispute must be settled by the escrow, and you get to choose your own escrow. If we both agree to on where the funds should end up then escrow is not needed.


How does Bitpay.com getting transactions info as its open source?

You can check your transaction's confirmation status and other payment details on any blockchain explorer (like BitPay's block explorer Insight). Look up your transaction using your transaction ID or the sending or receiving bitcoin addresses, which can all be found in your bitcoin wallet that sent the payment. For your transaction to be considered fully confirmed by most BitPay merchants, your transaction will need to have six confirmations.

More info: https://insight.bitpay.com/


Yes, you could store encrypted wallet in the dropbox.
From the first glance into the source code, the encryption algorithm is AES 256 CBC. This is industry standard protocol that is NOT known to be brute-force crackable* (subject to correct usage). You can read up more on the B. Schneier blog AES tag, where the most recent post say

[...] Reading the above, the obvious question to ask is: can the NSA
break AES?
My guess is that they can't. That is, they don't have a
cryptanalytic attack against the AES algorithm that allows them to
recover a key from known or chosen ciphertext with a reasonable time
and memory complexity. I believe that what the "top official" was
referring to is attacks that focus on the implementation and bypass
the encryption algorithm: side-channel attacks, attacks against the
key generation systems (either exploiting bad random number generators
or sloppy password creation habits), attacks that target the endpoints
of the communication system and not the wire, attacks that exploit key
leakage, attacks against buggy implementations of the algorithm, and
so on. These attacks are likely to be much more effective against
computer encryption.

There are chances, that the satellite code around the algorithm wasn't used correctly, or that there is a back door. There are some talks on the general security concepts in this thread. Despite it being open-source, there is no guarantee there are no bugs.
As an alternative you can store your wallet on the encrypted TrueCrypt partition. TrueCrypt source code is currently being investigated by the independent body for the security flaws.
Personally, I would use default encryption and trust it provides sufficient level of protection. Make sure your pass-phrase is strong, long and random, and that it is stored securely.


How is a proof-of-stake block mined at the block level, and how does it accomplish it's goals?

Proof-of-stake mining is similar to Proof-of-work at a technical level. It involves a sort of lottery, similar to proof-of-work, but the difficult of this lottery is weighted depending on how many coins you are staking. The overall process for "attempting" to mine a PoS block is like so:

Add a coinbase transaction, and a staking transaction (in most coins, must be hardcoded as the second transaction)
Prepare block normally, with transactions from network etc
Compute the PoS "kernel"
Compute the "staking difficulty", which is the base difficulty, reduced by a ratio of how many coins you are staking (or in PoS version 1.0's case, the coinage of your coins)
Compare the kernel's hash against the staking difficulty
If the hash meets the difficulty then continue, otherwise go back to step 1 trying other UTXOs in your wallet that are suitable for staking
Now you have a valid PoS block. The final step is to sign the block header, proving that you own the staking transaction from step 1.

Now I'll try to go into a bit more depth.

First, the staking transaction is a special transaction that is not possible on the normal Bitcoin blockchain. It includes the concept of negative fees. Because all stakers know the reward, they add this reward to this transaction, meaning that there are more output coins than input coins. This kind of transaction is only valid in a staking context.

Next, the PoS kernel. This is a bit complicated, but the important part is that nothing in it can be easily changed in the context of this block. In the case of blackcoin, the kernel consists of "stake modifier"(I'll explain that in a bit), current block's timestamp, and data from the "txPrev". The txPrev is the transaction of the output which is spent by the staking transaction(ie, the input to the staking transaction). The data pulled from the txPrev includes blocktime, transaction time, hash, and output number (vout 'n').

Because the txPrev data has already been confirmed in the blockchain, it is immutable. The only piece of data that is mutable is the current blocktime. The current blocktime in PoS coins is actually masked though (ie, the bottom bits are set to 0), so that there is very little entropy that can be had by making minor modifications to it. And the blocktime can not be beyond certain network drift limits, or not all nodes will accept the block. Finally the stake modifier is a value generated by taking some entropy bits from the previous (iirc) 64 blocks and hashing it together to form a relatively random number. It's primary purpose is to make computing future block's (beyond the next block) kernel difficult.

Finally, all the data for the kernel is hashed together. The staking difficulty is computed simply. It takes the standard difficulty from Bitcoin, but makes it so that this difficulty is for 1 coin. If you stake 2 coins, then it's only half the difficulty. For 4 coins only a quarter of the difficulty, etc. There are some restrictions to this. In order to prevent someone from being able to control the network for a chain of blocks with a large number of coins, there is a limit to the amount of staking coins, and thus there is a limit on how much the base difficulty can be reduced by.

Finally, a signature is made, proving that the staking transaction actually belongs to the person creating this block. The signature itself goes into the blockheader so that the signature is part of the blockhash.

All of this put together causes the following effects:

PoS block "mining" does involve hashing and difficulty like PoW, but there are very few mechanisms to change the hash that is given, and so no matter how much computing power you have, it won't help any
The stake modifier prevents predicting which block you will be able to successfully stake, because it adds a lot of uncontrollable entropy to the kernel hash
The more coins you stake, the better chance you have at successfully creating a block, because of the weighted difficulty
In case the network gets stuck due to a sudden drop in the number of people staking, the low-entropy version of the blocktime will eventually allow new kernel hashes to be generated given enough time, giving stakers left on the network a chance to have a successful PoS block

I published this in a blog post, but figured it would fit the QA format of here well and help more people when searching for this answer


CDiskBlockIndex: NFile and NDataPos not defined

This is likely the case because you don't have the block.

Blocks are downloaded out of order, and the block index contains entries for blocks that are not in the main chain ("orphan blocks"). Many of those are clearly not in the best chain before they're even downloaded, in which case Bitcoin Core will not download them at all.


At what point is a new wallet known by the Bitcoin network?

TL;DR: The network is not made aware of address ownership, nor can anyone check if an address is owned unless it has been used previously (or is owned by himself). Anyone can send transactions to any valid (as in correctly shaped) address¹, the recipient doesn't have to be online for a transaction to take place.

Let me elaborate a little bit in order to explain:

Addresses are the public key of an asymmetric key pair

An address is the public key of an asymmetric key pair. The owner of the key pair can use the private key to sign transactions or messages (for example in order to prove ownership). Only by using the correct private key a valid signature may be created, which then anyone can verify as valid by using the associated address (which, again, is the public key).

Wallets are an abstraction

A wallet is an abstract construct, which contains a set of public and private key pairs randomly generated for the user. In a deterministic wallet, the keys are derived from a passphrase instead of a random seed.

The Bitcoin client software abstracts the wallet for the user such that it checks each of the addresses contained in the wallet, whether there are any balances (transaction outputs) associated in the blockchain with them. It sums the funds up and presents them as a single total balance. Underlying, however, these balances are stored publicly in the blockchain (that's right, the wallet doesn't contain your coins, it just allows you to spend them). They are split up to numerous addresses and transaction outputs:

  Address #15521³ has

  3 BTC in transaction output 1

  Address #23414 has

  1.2 BTC in transaction output 1
  0.7 BTC in transaction output 2

  ...

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

Transactions are public notifications of change in ownership

Now, when someone sends a transaction, he basically puts up a notice for everyone in the network to see in which he signs over some of his transaction outputs to recipient addresses. He signs this notice with his private key, so that everybody can check that he is the rightful owner of the outgoing balance (as they can see what address the balance is being sent from they know which public key to use to verify the validity). This can happen regardless of the recipient being online: The bitcoins will be available to spend to the owner of the new address, because only he has the private key, whenever he choses to do so.

It cannot be determined if an address is owned by someone

The public keys (Bitcoin addresses) fulfil a specific pattern with checksums, so that bitcoin software can easily assess whether an address is valid. However, unless an address has been used before there is no way for anyone to check whether a valid address has actually been claimed by anyone.

At no point the network is ever made aware of the creation of new wallets, nor does it have to be. Balances are just signed over to a recipient address and subsequently can only be spent with the associated private key. If the new addresses private key hasn't been found yet, it is very unlikely that anyone ever will do so – the coins would likely be lost forever.

¹ By creating raw transactions one can actually send transactions to an invalid address. This is for example used to leave messages in the blockchain or to validate the authenticity of documents.

³ Of course addresses really are alphanumeric strings with up to 34 characters.


Cryptocurrency Wallet Seed - mental backup?

Uninstalling the wallet will not make anything more secure. Deleting the wallet also does not guarantee that the wallet file is gone; it is usually still on disk for some time after it has been "deleted". You will be exposing your seed to a computer anyways any time you want to send Bitcoin and get new addresses to be receiving Bitcoin at. By only remembering your seed, you may be a little bit safer than if you had let the wallet do its thing (where it encrypts the wallet file and is still on your computer). I don't think you will actually a significantly more secure. All you are doing is just increasing the risk that you lose all of your coins (by forgetting the seed) and making it more of a hassle to send and receive Bitcoin.

  And I won't have any issues using the seed with other wallet when I choose to use my cryptos?

Not all seeds will work with other wallets or altcoin wallets. It depends on how addresses are derived, what standard the seed follows, etc.


As said on https://en.bitcoin.it/wiki/MtGox/API/HTTP/v1#Multi_currency_trades you can use:

https://mtgox.com/api/1/BTCUSD/trades?raw

or

https://mtgox.com/api/1/BTCUSD/trades?since=0

to get all the historical data.

There's also a non-official Python script (using this API) and a SQLite database with all the historical data, you can find it on:

http://cahier2.ww7.be/bitcoinmirror/phantomcircuit/

The 167MB SQLite database should already have all the data you need, and the Python script in the same directory allows you to update it in real time.


Problem getting bitcoins into Bitcoin Core on Mac

You would need a backup of the old wallet.dat from bitcoind, the bitcoin address and transaction information are available to the public. If you were able to recover funds with that information then anyone would be able to 'recover' your coins. Unless you have made a backup you have most likely lost your coins. In the future make sure you always have a backup of your wallet.dat or private keys/seed words (depending on wallet).


I would like to dig into the open Taproot PR to understand it, test it and possibly even review it. Any advice or recommendations?

Previous Bitcoin Core PR review club sessions
A good starting point is the various Bitcoin Core PR review club sessions that have been held thus far on specific commits of the Taproot PR. The latest one was on "Implement Taproot validation" (hosted by John Newbery) and there are various notes and a transcript of the meeting there. There are also links to the previous review club sessions on the Taproot PR on that page.
Build the PR
When reviewing a PR it is always a good idea to build the PR. For simplified guidance on building a PR see this StackExchange question. For more detailed guidance see this resource from Jon Atack.
Obviously the fork of Bitcoin Core you will want to clone is sipa's (Pieter Wuille's) and the branch you will want to check out is taproot.
There is no GUI or wallet support in this Taproot PR so you will want to use the following flags when configuring to save time.
./configure --without-gui --disable-wallet

Understand what the PR does (and what it doesn't)
On the PR Pieter Wuille states:

No signing or wallet support of any kind is included, as testing is done entirely through the Python test framework.

This is pretty limited scope. All signing and validation of (Schnorr) signatures is already handled by the libsecp256k1 library which has its own separate repo. But what Pieter is saying here is that with the current Taproot branch you can't create a Taproot (pay-to-taproot or P2TR) address or Taproot spend from your Bitcoin Core wallet or using bitcoin-cli. The only way you can create Taproot transactions is using the Python code in the functional test framework. So if you know some Python you can adjust the Python code to create different Taproot transactions but other than that you can't create Taproot UTXOs or spend from them.
Once Taproot transactions are created from the Python functional test framework this PR branch will allow you to validate Taproot spends with the C++ validation code.
Functional tests
Given the only Taproot transactions that are validated by your Bitcoin Core full node are coming from the functional test framework it is a good idea to start your code review there. Some existing functional tests are edited in this PR but there is a new functional test added called feature_taproot.py. This test generates random Taproot transactions and verifies they are accepted into the mempool (when appropriate) and accepted (when appropriate) into Python-constructed blocks.
You can run this new functional test directly by running:
test/functional/feature_taproot.py

After a few minutes this test will very likely pass. So here is where you can be creative in making changes to the test or the C++ code it is testing before running the test again to see what you need to do to make this test fail.
What to avoid
There are a few things to avoid on this PR. It is still possible that there is a conceptual problem with the Taproot design but at this stage it is unlikely. There was an in depth discussion of the evolution of the conceptual design of Taproot at this Socratic Seminar at London BitDevs covering years of discussions. I would recommend watching that or reading the transcript of that if you think you have discovered a conceptual problem. Alternatively, you are free to ask questions on the ##taproot-bip-review channel on IRC.
Another thing to avoid on this PR is discussion of activation (or deployment). This PR completely avoids any decision on activation method and so there should be no discussion of activation on this PR. If you look at the commit on Activate Taproot/Tapscript on regtest (BIP 341, BIP 342) there is a deployment date set of January 1 2008 for regtest but other than that no activation or deployment parameters are set. If you would like to discuss activation there is another IRC channel ##taproot-activation for that purpose.
// Deployment of Taproot (BIPs 340-342)
    consensus.vDeployments[Consensus::DEPLOYMENT_TAPROOT].bit = 2;
    consensus.vDeployments[Consensus::DEPLOYMENT_TAPROOT].nStartTime = 1199145601; // January 1, 2008
    consensus.vDeployments[Consensus::DEPLOYMENT_TAPROOT].nTimeout = 1230767999; // December 31, 2008

The PR is at a reasonably advanced stage and what it is really seeking is code review, testing and (maybe!) additional tests.
For guidance on debugging Taproot functional tests see this other StackExchange question.


Are Bitcoin ASICs good for anything else other than mining?

No, Bitcoin ASICs can not be reused for any other purpose, unless something were created that uses the exact same hashing technique.

Unlike what some ill-informed radio talk show hosts say, the mining network is cryptographically incompatible with SHA256 password cracking, the block chain itself is not a conspiracy by the Russians as a rainbow table.

Besides most hashed passwords use a salt, and the manner it is typically done is incompatible with what is being done in Bitcoin.

So, no.  The ASIC will forever be exclusive to the Bitcoin unless another RFC or standard requires a proof of work (a la Hash Cash) for some other purpose.


Should I try to get fuzz testing working on MacOS or should I stick to Linux?

If you have access to a Linux machine/VM you should probably do fuzzing on that rather than MacOS. It is likely you will need to do more troubleshooting getting set up on MacOS. However, people have got fuzzing working on MacOS e.g. robot-dreams during this Bitcoin Core PR review club session on fuzz testing:

I was able to get things work by following the "macOS hints for libFuzzer", but I had to remove the --disable-asm flag when running ./configure

In addition brakmic has some additional guidance for those trying to get set up on MacOS:

Take care of having an LLVM/Clang environment that contains fuzzing libraries. The default one from Apple is not enough, so that you will have to install it with brew, if not already done.
When executing ./configure you should put --disable-asm to avoid errors with certain assembly code from Bitcoin Core's code. There's an entry about it here and it seems to have something to do with sanitizers you have to compile for fuzzing.
Take care of giving the correct path for clang and clang++, like CC=/path/to/clang CXX=/path/to/clang++
If you run into problems with "boost sleep" or some of boost's libraries can't be found, like boost.thread or boost.filesystem, add this to your configure:

CXXFLAGS="-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk"

Notice: I am using Catalina 10.15.1, so your SDK might be different and you should adapt the path accordingly.
Here's my complete configure, just in case.

./configure --disable-ccache --enable-fuzz --with-sanitizers=fuzzer,address,undefined --with-boost CPPFLAGS="-I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include" CXXFLAGS="-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk" CC=/usr/local/opt/llvm/bin/clang CXX=/usr/local/opt/llvm/bin/clang++ LDFLAGS="-L/usr/local/lib/darwin/" --disable-asm

On the benefit to the Bitcoin Core project overall, I would say the greatest benefit would be onboarding fuzz testers and reviewers of the various fuzzing PRs as quickly as possible. Unit tests and functional tests need to pass on various operating systems but the ultimate aim of fuzz testing is examining for edge cases, the majority of which won't be dependent on the operating system. So whatever will get you up and running the quickest is the optimal approach.


Is there an open source tool to publicly destroy bitcoins?

The most secure way to destroy bitcoins is to send them to a script that can never return true, and which includes the reference code that confirms the goal of destroying these coins. I don't know of readily available software tools that can do that, and I'm not sure the network will accept these transactions.

Here's a simple method everyone can try at home: Take the reference code, apply RIPEMD-160 and encode it as an address. Do a transaction which sends a satoshi to this address, and the the coins-to-destroy to 1BitcoinEaterAddressDontSendf59kuE.

To demonstrate my point, here is me destroying 1 mBTC - http://blockchain.info/tx/f374fb91ea29b02d295d535da537c7770caa71c4937095c51467b4d8b1b60c1b. Address is hash of https://bitcoin.stackexchange.com/a/7443/575.

Signing a message with the address used to send can also be employed as extra verification.


How can market-based transaction fees scale?

The blockchain is public, and every block has (amongst other things) the following information for each transaction (or it can be calculated):

The size of the transaction, in bytes
The fee paid by the initiator of the transaction

Miners in future are likely to calculate the earnings per byte for each transaction when selecting which ones to include in a block, so that they earn the maximum profit from the block. At the moment they mostly just include them all, provided there is at least a token fee.

Furthermore, transactions that have not yet been included in a block are publicly available.

From this information a user could estimate the transaction fee they will need to pay to get their transaction included in the next block, or within one of the next few blocks. Of course in the long run, it won't be a user that has to seek out this information; it'll just be part of the information readily available as they initiate a transaction. At least, that's how I see it working.

The idea has also been floated that the receiver of a transaction could pay a small fee to get the transaction into a block sooner (to ensure they receive their payment).

Reporting on the level of fees needed to process a transaction is minimal at the moment because it's not particularly difficult to get transactions included in a block with either no fee or just a token fee (say 0.00001BTC). This is because we haven't hit the block size limit (at least, we're not constantly hitting it).