Can I generate multisig addresses directly in the coldcard? According to coldcard's multisig video tutorial: https://www.youtube.com/watch?v=OMpZ5heLsRg I need to export the 3 xpubs and then create a multisig wallet in each coldcard using these 3 xpubs. Then it exports a list of addresses that can be plugged into Electrum.
However, I don't wanna trust seeing this list on the computer. Can I see these addresses on the coldcard itself?
Like, generate/visualize one address at the coldcard and then compare it with the electrum one just to be sure I'm sending to my wallet?

After digging the source code for 2 days I found it. YES, it's possible.
When you power your coldcard, select Address Explorer, then CC 2-of-2 (in my case) and then you'll be able to see your addresses. However I think you cannot see them entirely, just the beggining and end.
PS: these are testnet addresses for a disposable wallet for my tests


Retrieve old addresses with coins that were given away for free to friends and family? Looking for a solution where if I wanted to give away bitcoins or other coins to friends and family for free and being able to retrieve them back if they don't claim it or move it.

Many times I gave away a few cents worth of btc a few years ago to friends and family, now those cents are worth a few dollars. Some of them didn't take it seriously and just lost the keys that I made for them on paper wallets.

Has there been a solution to solve this reoccurring problem when introducing newbies to bitcoin?

Just save a copy of the private key.  Then you can import it into your favorite wallet client to retrieve the coins (and sweep them to a new address, so that the key on the paper will no longer work).

When you give the paper slip to the recipient, you should tell them to import it into a wallet and sweep to a new address, so that they don't have to trust you not to steal the coins back.  (Also, this way their coins are secure even if your copy of the key is later hacked or stolen.)  But if they don't do it, you have the ability to take the coins back.

If you didn't save a copy of the private key, and all other copies have been lost, then it is not possible to retrieve the coins.


Run multiple wallets on the same system Setup:

10 clients.
Each client has his own wallet on my secured system.
An API service manages these wallets.

Leading Questions:

Each wallet should run as a separate process of "bitcoind"?
If so, each "bitcoind" can use the same blockchain files?
There is a best practice of running multiple wallets on the same system?

Using multiple wallets on one "bitcoind" process

Follow this steps:

Run the bitcoind process.
Create a wallet for each of the clients using:

bitcoin-cli.exe createwallet <client_uniq_id>

When you want to perform any action on any wallet simply use:

bitcoin-cli.exe -rpcwallet=<client_uniq_id> <your_rpc_method>

Use "" for <client_uniq_id> in order to refer to the default wallet, created by the bitcoind.


Would I be able to recover coins if Trezor went out of business? I'm considering a Trezor wallet. I've read through their info about recovering if I lose the device or forget my PIN. What if the company were to go out of business. Would I still be able to recover my coins?

Yes. Trezor uses BIP39 and is compatible with any other wallet  that would. You can in fact import your seed into electrum, though this to some extent defeats the purpose of having a hardware wallet.


fundrawtransaction causing bitcoind 0.17 to crash I've updated to bitcoincore 0.17 and I'm trying to create a raw transaction to be signed on an offline wallet.

I'm creating a raw transaction with createrawtransaction with no inputs and the desired outputs. With the hex generated I'm using fundrawtransaction to match inputs.

Since the online wallet is watch only I need to pass includeWatching as params. Also I want to send the change amount to a different address, so I add changeAddress the the options hash. This kills the entire bitcoind process with no warnings and no log messages

This is the commands I've tried and their output:

$ bitcoin-cli createrawtransaction '[]' '{"14XbnUUvc2Kt8TrnnEG9zjF1XM2jYD1h8x":0.001}'
020000000001a0860100000000001976a91426b1e477be0f7bc5e2cf12dd5b973e57e7fab5bf88ac00000000

$ bitcoin-cli fundrawtransaction 020000000001a0860100000000001976a91426b1e477be0f7bc5e2cf12dd5b973e57e7fab5bf88ac00000000
error code: -4
error message:
Insufficient funds

$ bitcoin-cli fundrawtransaction 020000000001a0860100000000001976a91426b1e477be0f7bc5e2cf12dd5b973e57e7fab5bf88ac00000000 '{"includeWatching":true}'
{
  "hex": "02000000016c4262fe490eb44becac4d4aa37f86b4433327ffa40a00a5498006c6ec5b0b240100000000feffffff02089a03000000000017a914ab7dd53603b6b64d3851569b90eeae8f39fd9f0087a0860100000000001976a91426b1e477be0f7bc5e2cf12dd5b973e57e7fab5bf88ac00000000",
  "fee": 0.00000675,
  "changepos": 0
}

$ bitcoin-cli fundrawtransaction 020000000001a0860100000000001976a91426b1e477be0f7bc5e2cf12dd5b973e57e7fab5bf88ac00000000 '{"includeWatching":true,"changeAddress":"185pJS3yVizdE3RtXKALtVbGRv9gzzypT1"}'
error: Could not connect to the server 127.0.0.1:8332 (error code 1 - "EOF reached")

Make sure the bitcoind server is running and that you are connecting to the correct RPC port.

How can I see the error that killed bitcoind?
Am I doing something wrong?

UPDATE

After using GDB I've found that this is the problem:

bitcoind: policy/feerate.cpp:25: CAmount CFeeRate::GetFee(size_t) const: Assertion `nBytes_ <= uint64_t(std::numeric_limits<int64_t>::max())' failed.

Thread 7 "bitcoin-httpwor" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffebfff700 (LWP 22448)]
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.

Any hints?

This is a known crasher in 0.17.

You need to either:

downgrade to 0.16.3
apply the patch given in the pull request and build Bitcoin Core yourself
wait until 0.17.1 is released to fix the issue.


Why does Litecoin have lower transaction fee than Bitcoin? Is it only because LTC doesn't have as many users as BTC? Or do the faster confirmation times also help with lowering fees?

Thanks

Litecoin's blockspace supply is greater:

Litecoin's block interval is a fourth of Bitcoin's at 2.5 minutes
SegWit is activated, limiting blocks to 4MB weight instead of 1MB size. With leisurely adoption of the new segwit transaction format this would eventually allow a capacity equivalent of blocks with ~1.7-2.3 MB size.

Litecoin's blockspace demand is much lower:

Bitcoin does about 250k transactions per day with the mempool never completely flushing out, Litecoin has just slightly over 19k, while it could do about 2,000k.

Bitcoin is operating with demand exhausting the supply continuously, thus finding actually a price for blockspace. In the past months we've seen feerates move between 1 and 540 satoshi/byte. Now that the latest hype has cooled down slightly, we can observe a daily and weekly cycle, under the week going from ~8 to ~400 satoshi/byte, dropping down to as low as 2 satoshi/byte on weekends.

On the other hand, Litecoin is operating with demand at approximately 1% of the supply. Miners appear to be observing a hard coded minimum fee of
100 litoshi/B.


Is there a reason big Bitcoin companies wouldn't use only SegWit transactions? As I understand, SegWit allows anyone to create a SegWit address where they can send their bitcoins and transact from that wallet just as easily as they would with a traditional address. The SegWit inputs, however, would have a lower "weight", therefore they would appear smaller to the miners and thus would need lower fees to be included in a block. This would be despite the transaction itself being a bit bigger byte-wise due to the extra data required for the Witness part of the transaction.

So given all of that, is there any reason big Bitcoin companies that create a lot of transactions on daily basis wouldn't switch to SegWit addresses for the majority of their operations? It looks to me that if they would move their hot wallets onto SegWit addresses they could potentially cut down their transaction fees by a noticeable margin.

Is there any reason this isn't a standard way of doing things yet?

I would like to give one of the reasons (Disclaimer: I am associated with Blockonomics).

There is no support of segwit change addresses yet in bitcoin core. There are workarounds that need to be done to achieve this; as was done by Yodice in this thread. Also to create segwit receiving address one needs to use addwitnessaddress. Lot of businesses just directly use the core wallet without doing lot of programming (there is fear of what may go wrong).

What is needed is that bitcoin core wallet works by default segwit without lot of tinkering. I hear 0.15.1 is better. Looking forward to that


How to fix CoinBase pay too much error ERROR: ConnectBlock() : coinbase pays too much (actual=20000000 vs limit=20000000)

I got this error at my debug.log

anyone know how to fix this issue? I am coding a new coin, changing its rewards, which parametter I need change to increase the limit.

on the line:

 if (vtx[0].GetValueOut() > GetBlockValue(pindex->nHeight, nFees, pindex->nBits))
        return state.DoS(100, error("ConnectBlock() : coinbase pays too much (actual=%"PRI64d" vs limit=%"PRI64d")", vtx[0].GetV$

I changed my nsubsidy for the code

int getrandint(int min, int max)
{
    int num;
    num=rand();
    num=num%(max-min+1)+min;
    return num;
}

int64 static GetBlockValue(int nHeight, int64 nFees, unsigned int nBits)
{
    if (nHeight == 0)
    {
        return nGenesisBlockRewardCoin;
    }

   unsigned int i, iMax, iMin;

   iMin = 1;
   iMax = 50;

if(nHeight<500)
{
iMax = 3;
}
if(nHeight > 8000)
{
iMax = 30;
}
if(nHeight > 20000)
{
iMax = 20;
}
if(nHeight > 100000)
{
iMax = 10;
}

  i = getrandint(iMin, iMax);
    int64 nSubsidy = nBlockRewardStartCoin * i ;

    // Subsidy is cut in half every 60480 blocks (21 days)
    //nSubsidy >>= (nHeight / 60480);

    // Minimum subsidy
    if (nSubsidy < nBlockRewardMinimumCoin)
    {
        nSubsidy = nBlockRewardMinimumCoin;
    }

    return nSubsidy + nFees;

}

The code originally was

int64 static GetBlockValue(int nHeight, int64 nFees, unsigned int nBits)
{
    if (nHeight == 0)
    {
        return nGenesisBlockRewardCoin;
    }

    int64 nSubsidy = nBlockRewardStartCoin;

    // Subsidy is cut in half every 60480 blocks (21 days)
    nSubsidy >>= (nHeight / 60480);

    // Minimum subsidy
    if (nSubsidy < nBlockRewardMinimumCoin)
    {
        nSubsidy = nBlockRewardMinimumCoin;
    }

    return nSubsidy + nFees;
}

Because of what I change, my code give the error coinbase pays too much

root@eatSushi1:~/dogequark/src$ ./dogequarkd
dogequark server starting
root@eatSushi1:~/dogequark/src$ terminate called after throwing an instance of 'std::runtime_error'
  what():  CreateNewBlock() : ConnectBlock failed

I also got this error when I run the coind at another server after cloning through github.

You should not be tampering with any code that has anything to do with determining block validity if you don't thoroughly understand the security model that proof of work coins use.

i = getrandint(iMin, iMax);
int64 nSubsidy = nBlockRewardStartCoin * i ;

You can't use any randomness in any code that involves block validation! The entire security model of the blockchain absolutely requires that servers agree on whether blocks are valid or not. Whatever it is you are trying to do, this is not how you do it.


Why is there no such thing as a redirected, forged, or fake transaction? In the past, we had numerous questions about "fake" or "forged" transactions. Such transactions could supposedly be created even without holding any bitcoins, yet would end up in the mempool or even get accepted by the network once they are mined into a block. Other times, the recipient creates a conflicting version of the sender's transaction, or a majority attacking miner would simply redirect all transaction outputs to themselves.

With this topic I mean to create a canonical question for a topic which is described by the following variants of a questions:

Why can I not just make up bitcoins?
Why will fraudulent transactions not get relayed on the network?
Why can only the owner spend their funds?
Why can a third party not alter the recipients of a transaction?
What prevents a miner from taking the funds of your transaction when creating a block?

In other words, let's comprehensively explain:

What makes a transaction valid, how is a transaction protected against tampering, and how can nodes tell?

Here are some examples of topics that might be redirected here in the future:
1,
2,
3,
4,
5,
6,
7,
8,
9,
10,
11,
12,
12,
13,
14,
15,
16,
17,…

The Bitcoin protocol follows a Unspent Transaction Output system to track the existence and state of all Bitcoin in the system. These are known as UTXOs.

All transactions that transfer Bitcoin do so by consuming one or more UTXOs, and create one or more new UTXOs. The only exception to this is the Coinbase transaction, which is limited to being the first transaction in a block, and is only allowed to create UTXOs that total block reward + block fees or less.

Due to this basic structure of a transaction, it is impossible to create a bitcoin transaction that spends non-existent bitcoin. As the UTXOs being consumed do not exist, the transaction is rendered invalid the moment it is created.

Although this is impossible, why it is impossible is not immediately obvious to people unfamiliar with the details of how Bitcoin works - thus, many people, especially newcomers to the space, seek out such things as a way to quickly get some Bitcoin at no or low cost. Several scammer groups are aware of this, and put out videos showing edited block explorers/wallets that seem to allow them to initiate fake transactions.

These groups then offer to give you access to this software for a small fee, or just let you download it for free - however, not only does it not work as advertised, most of these programs are trojan horses, and contain code to steal Bitcoin wallets on your system, or grant the scammers persistent remote access to your machine.

Answering each point directly:

  Why can I not just make up bitcoins?

As all bitcoin in the system are the result of either a coinbase transaction, or the outputs of a transaction that moved previously extant bitcoin, it is not possible to introduce new Bitcoin into the system without being detected. Any UTXO at any point of time must always be traced back to one or more coinbase outputs.

  Why will fraudulent transactions not get relayed on the network?

All well behaved nodes on the network validate transactions before accepting them to their mempool, or rebroadcasting them further - part of this validation is checking all utxos in the transaction against the node's own list of valid utxos. If the transaction claims to spend a UTXO that does not exist in the node's list, the transaction is deemed invalid and dropped.

  Why can only the owner spend their funds?

Standard Bitcoin addresses rely on one (single key addresses) or more (multisig addresses) private keys. The public keys corresponding to these private keys are encoded into the address itself, inside its locking script (also known as the scriptPubKey). During the evaluation of these scripts, the signature on that input is matched against the embedded public key(s). If the signature does not match, the transaction is deemed invalid.

Note that it is possible to create outputs with no "owner" - The Bitcoin script does not require all locking scripts to include a key check, and it is possible to construct a non-standard script that requires no signatures to spend. However, no consumer wallet does this, and essentially all addresses a normal user will encounter will be backed by one or more private keys.

  Why can a third party not alter the recipients of a transaction?

Standard transactions are signed using the SIGHASH_ALL signature flag. This means that the signature for any one input signs all inputs and outputs (in effect, signing all material aspects of the transaction). If any input or output is altered, removed, or otherwise changed, the signature is no longer valid as the data it signs has changed.

It is possible to construct a transaction using other signature flags, as described in my blog post here. However, once again, no consumer wallet uses anything except SIGHASH_ALL.

  What prevents a miner from taking the funds of your transaction when creating a block?

Similar to the previous point, a miner is also unable to alter the outputs of your transactions due SIGHASH_ALL signing the entire transaction. If a transaction is intentionally signed with SIGHASH_NONE, a miner could very well take the funds. However, as no sane wallets performs such a signature, this does not happen.


Stratum protocol - problem with mining.submit method code was written according to documentation.

I have following lines for submit method

submit() {
    // ["<worker.name>", "<jobID>", "<ExtraNonce2>", "<ntime>", "<nonce>"]
    return this.call('mining.submit', [this.worker.name, this.worker.jobId, this.worker.extranonce2, this.worker.ntime, this.worker.extranonce2]);
}

According to documentation "When miner find the job which meets requested difficulty, it can submit share to the server" and the result should be following

{"error": null, "id": 4, "result": true}

But test was failed (result in the image)

QUESTION: Could some one clarify, waht is wrong and how to solve the problem? What does mean "low difficulty"? Why did I get that message?

The error is pretty self explanatory: you submitted a share that does not meet the requested difficulty. The pool requires that shares you submit meet a particular difficulty. If your shares do not meet that, then the pool will reject them. The shares that your software is sending to the pool do not meet the pool difficulty.

To fix this, either you are creating the submission incorrectly, or your miners are not mining at the correct difficulty.


Using the Merkle Root to prove the integrity of a block's transactions I understand that a Merkle Root is the hash of hashes of hashes (etc.) of transaction pairings within a block that ultimately results in one 'Root' hash.  Changing anything about any of the original transaction hashes would result in a completely different root hash.

What I'm still confused about is working backwards starting with the root hash to prove a certain transaction was included in the block.  From the 'What is the Merkle Root?" thread, I understand the example of only needing 4 hashes to prove that Tk was included in the block (16 transaction block).

My questions are:

If every transaction is to be verified that it's included in the block, wouldn't you ultimately need to know all of the hashes anyway if you're going to trace back to each transaction separately?
Are these verifications only happening on request? or is it automatic before the block is added to the blockchain?
When verifying one specific transaction, where do you go to get the various sub-hashes for the necessary merkle branches?

If every transaction is to be verified that it's included in the block, wouldn't you ultimately need to know all of the hashes anyway if you're going to trace back to each transaction separately?

A full node downloads the entire contents of the block, which includes all of the transactions. Having done that, the node can easily compute the merkle root for the block (this is required to ensure the block is valid). Note that the intermediate level hashes in the merkle tree (between the leaves and the root) do not need to be communicated, a node with the full tx list can generate and verify the entire merkle tree itself against the merkle root listed in the block header.

  Are these verifications only happening on request? or is it automatic before the block is added to the blockchain?

A full node will verify a block's contents, and only accept valid blocks. A wallet that uses spv will not perform the full block verification (that would entail downloading the full block), and instead trusts that the valid block headers it is receiving from full nodes in the network are indeed representative of the longest valid chain.

  When verifying one specific transaction, where do you go to get the various sub-hashes for the necessary merkle branches?

A wallet using spv will request the relevant info from the full nodes it pulls network data from.


Where did the idea of blockchain come from? Git was already using it since 2005 With bitcoin's blockchain, each block's hash is computed with the previous block's hash. That makes all blocks an immutable chain.

This is not the first time people used a hash-chain. As far as I know, Git was already used it since 2005 for the commit-hash computing.

So, what is the earliest use of hash chains? Where did the idea of blockchain come from?

According to Bitcoin and Cryptocurrency Technologies (BaCT), the Princeton Bitcoin textbook, the block chain dates back to a "paper by Haber and Stornetta in 1991. Their proposal was a method for secure timestamping of digitaldocuments, rather than a digital money scheme." (BaCT p.15)

The chaining of Merkle trees instead of single documents was proposed in a later paper. (BaCT p.16)


Creating watch wallet from master public key at command line? I know that by electrum -w WALLET_PATH create a usual wallet can be created.  I'm now looking for way to create wallet file from master public key.

Question

Given I have master master public key, e.g. xpub12345...ABCDE, how can I create its watching wallet file?

electrum -w wallet_path restore <mpk>

Above created watch wallet from master public key.


What are the pros and cons of Ripple's consensus as compared with Bitcoin's proof-of-work? One of the major differences between Bitcoin and Ripple is how they process transactions. I can think of three ways in which Ripple's "consensus" scheme is superior to Bitcoin's proof-of-work:

Less energy-intensive
No 51% attack
Faster transactions

What are the other pros and cons of Ripple's consensus as compared with Bitcoin's proof-of-work?

The big advantage on the Bitcoin side is that its technology is now well-proven. Ripple's consensus system is the newcomer. Ripple was designed by people who had the benefit of seeing exactly what Bitcoin was doing and its strengths and weaknesses.

Ripple's consensus process can validate a transaction such that irreversibility is reasonably assured much more quickly. When a validator processes a transaction it signs the resulting final ledger. Those signatures are provided within seconds.

Bitcoin's proof of work scheme isn't path dependent. Ripple's consensus scheme is. This has advantages and disadvantages on both sides. Because proof of work is not path dependent, someone with sufficient hashing power can rewrite the past. However, the lack of path dependence also means that no state is required to determine the right chain. The rule for the winning chain is very simple -- the valid chain with the most work wins.

The biggest difference is how trust works. With a proof of work scheme, you must trust the majority of work. So long as the majority of hashing power remains in the hands of a large number of disjoint organizations, that's fine. However, if hashing power become consolidated, it's not clear what the fix would be.

With Ripple's consensus scheme, you choose who you want to reach a consensus with and declare the system unusable if you cannot. One advantage here is that you can reliably detect if you can't reach consensus. With Bitcoin, if the Internet splits in half and you're on the side with less hashing power, you can only infer it as a statistical probability. With Ripple, if you're not reaching consensus with people, you know it immediately.

Another advantage is that if you ever do have an attack or disruption, you have signed cryptographic proof showing who did it and what they did. You can simply stop trying to reach a consensus with them and then they would have to start over from scratch to attempt such an attack again. Because the effort required is so great and the payoff so low, it's much less likely people will try.

The disadvantage here is that UNLs (lists of who you want to reach consensus with) must be maintained and if your UNL is broken, you can fail in various ways that get worse the more broken your UNL is. The downside of being in control is that you can shoot yourself in the foot. The upside is that you can do something if someone else tries to shoot you in the head.

Bitcoin could fairly easily adopt some of the principles of Ripple's consensus scheme and gain many of these benefits. For example, mining pools could sign a statement indicating which chain they are building on. In the event of a network split, this would make it rapidly clear whether you were still on the same chain as those pools. In the event of a bug-induced chain split, you'd quickly know that something was wrong and would be able to stop relying on transactions automatically rather than having to wait for a manual warning to go out.


How does total cost of mining affect the price of coins? The goal of this question is to explore what the correlation is between the cost of the total energy consumption behind a PoW-based cryptocurrency and its price.
Obviously, the cost of mining cannot be lower (in the long run) than the price of the coin, because more and more miners would join.
But is the converse (empirically) also true?

Has the price of coins been historically bounded from below by the cost of mining?

Of course, the cost of mining is hard to compute, because of differences in hardware, electricity price and cryptojacking.
Yet, one can find some nice charts here about Bitcoin, so some estimates can be made.
Has anyone looked at this?
For example, the market cap of Bitcoin is about twice the market cap of Ethereum.

Is it true that about twice as much energy is/has been spent on Bitcoin than on Ethereum?

I was just thinking about this today and created this spreadsheet to model my question.


Which approach is better to interract with Bitcoin node : Rpc call or Library? I think library like BitcoinJ or python-bitcoin does the same (rpc call in the background). If that is true is there any reason behind using such  libries in place of rpc call
For example:

(in case of python)

rpccall:

import requests
payload = {"jsonrpc":1,"id":"curltext","method":"getblockchaininfo","params"=[]}
response = requests.get(url,  data=json.dumps(payload))

Library call:

import bitcoinrpc
conn = bitcoinrpc.connect_to_local()
info = conn.getblockchaininfo()

Why should i choose one approach over the other when they are working the same way? What is the diffrence in between them? And which approach executes faster?

I think library like BitcoinJ or python-bitcoin does the same (rpc call in the background)

No, they do not.

BitcoinJ is an implementation of a Bitcoin client. It connects directly to the Bitcoin network and speaks the Bitcoin Peer-to-Peer protocol. It does not call RPCs for a node.

  f that is true is there any reason behind using such libries in place of rpc call

Libraries that do use the RPCs in the background allow you to abstact away the need to understand how the JSON-RPC protocol works. You don't need to have something that can send HTTP requests; you don't need to have something that can compute the basic authorization stuff; you don't need to have a JSON parser. Those libraries abstract those things away so that you can just deal with the RPC commands and the data they return.

There are no performance benefits. The only benefits are that the code is cleaner, easier to read, and easier to write.


When does a miner decide to stop collecting transactions and start calculating hashes to try to win? I am confused about whether a miner chooses to wait for more transactions (more fees) or starts as soon as it receives the first transaction from the network. Once a miner has started calculating the hashes, it will queue the new transactions, correct?

My confusion is: each miner node will be calculating the hash for a different block. Some will have more transactions than others. Does it matter?

If I am lucky to find the solution for a block with just one transaction, but someone else finds the solution for a block with my transaction and one more, so he wins, correct?

So the more transactions there are in a block the more difficult it is to solve the hashing puzzle, is that correct? If yes, why?

Can someone clarify how this transaction grouping is done by mining nodes?

I am confused about whether a miner chooses to wait for more transactions (more fees) or starts as soon as it receives the first transaction from the network. Once a miner has started calculating the hashes, it will queue the new transactions, correct?

Yes, they can begin mining as soon as they see the previous, and update the block template with new transactions they see whenever they would like. The early Satoshi client updated the template every few seconds, modern miners seem to do it every half a minute or longer depending on the software. There's no advantage for them to update the block template other than that they might get more fees if they do, if they miss transactions there's no real harm done.

  If I am lucky to find the solution for a block with just one transaction, but someone else finds the solution for a block with my transaction and one more, so he wins, correct?

No, this isn't correct, no miners break ties with the number of transactions in a block. First seen is generally going to be the behavior most people use if they can see two competing blocks at an equal height with an equal difficulty target. If they did tie break with the number of transactions then miners could make blocks stuffed with their own fake ones and always win any races.

  So the more transactions there are in a block the more difficult it is to solve the hashing puzzle, is that correct?

No, the header of a block is always 80 bytes long irrespective of the number of transactions the block actually contains. This is because the block header only includes a hash of the transactions, rather than the transaction contents themselves. The difficulty is the same for a block with no transactions other than the one paying the miner or a block with thousands.

  Can someone clarify how this transaction grouping is done by mining nodes?

Hard to answer this because most pools run completely custom software, they have their own criteria and their own optimizations which they perform. Generally they will collect all valid transactions which have the fee they want to accept, and assemble them into a block of the maximum size they wish to create, any which are not included are left in the memory pool for later or for someone else to mine.


Unconfirmed transaction I received a transaction which has been unconfirmed for 36 hours with 0 confirmations. I'm relatively new to btc and having had a relatively speedy, problem free experience so far I'm not sure what to make of it.

Any help would be welcome.

Thanks.

https://blockchain.info/tx/751bd6c180fac5c1b54ba428d2b4416a13ecefd978193e5dc8138f5b0de56f86

The transaction doesn't seem to have propagated through the network, meaning that not many nodes know about it.  I personally am not sure what to do about that, if there is anything you can do about it.

You could try having the person who sent you the coins restore their wallet from a backup, rescan the blockchain, and send you the coins again.  I think you might be able to get them through like that.  I would recommend having them put a transaction fee on it, though.  That should help it get put into a block quickly.


What precautions should be taken to protect a Ripple wallet? What if a Ripple wallet gets hacked?
What are the suggested precautions for the average user?

What precautions should be taken to protect a Ripple wallet?

You can keep your wallet offline most of the time. See this. You'll need to go online to check your balance or spend.

Beyond that, I'd also advise you to only use the client while online with that computer.

For Bitcoin, you can keep your wallet airgapped permanently with Armory, but I don't think there's an equivalent solution for Ripple.


Can an old bitcoin rig mine XVG? I have an old block erupter, used to mine BTC with on Slush's pool.
To operate it, I had to download their mining proxy onto another computer on my home network and configure the ASIC so it would point to my computer's IP address.
Is there any way to configure the block erupter to mine XVG with a pool (i.e thecoin.pw)?

No. Verge uses the Scrypt mining algorithm, not the SHA256d algorithm that your block erupter implements.


From where does a node download a copy of the ledger From where does a node download the latest copy of ledger initially? Is this information stored in a 'central server'?

Let's say a node is offline for a while, after coming back how will the node get to know the ledger is up-to-date or not?

The very word 'node' means there's no servers and clients, every running software is equivalent. No 'central' anything, Bitcoin was created to be a decentralized system. The initial copy and any future updates can be donwloaded from any other node.


help can I recover ltc sent to a btc address Im super new like a lot of people. I have a nano s ledger and I attetpted to send ltc from coinbase to the ledger only to realize I used the btc address on my ledger. Is this recoverable?

If you send some criptocurrency to an address that is of another criptocurrency that is a valid address in the first one too you have lost your money if you don't own that address in the criptocurrency you made the transaction from.

The only way I can think you could recover the money sent is to make another transaction to an address you own while the wrong transaction still have not been confirmed, maybe with an higher fee hoping to have it confirmed first.


txout script criteria (scriptpubkey critieria) what is the criteria for a txout script to be accepted into a mined block? is there any criteria at all? the reason i ask is that OP_RETURN is regularly used in txout scripts yet it is not spendable:

case OP_RETURN:
{
    return set_error(serror, SCRIPT_ERR_OP_RETURN);
}

and i have also seen transactions which push elements to the stack which are more than MAX_SCRIPT_ELEMENT_SIZE bytes.

i'm guessing that a syntactically incorrect script such as:

05aa
(ie OP_PUSHDATA(5) <aa>)

would not be permitted?

could someone point me to the code which miners use to validate whether a tx will be included or discarded as invalid (due to its txout scripts). i'm guessing it lies in main.cpp, but i would like to know where exactly, thanks.

obviously anybody can mine a block that is set up any way they like, but presumably there are fixed rules for whether it is considered valid or not - so other miners will know whether to use its hash as their prev-header-hash when mining the next block?

Absolutely no consensus validity checks are done on a scriptPubKey. Nodes have soft requirements called IsStandard for what they will relay to their peers as a transaction (a completely junk script or very large OP_RETURN output for example will not pass) but these are not consensus rules. Some miners will mine non-standard transactions into their blocks, but generally to get a transaction to them a transport other than the P2P network needs to be used.

OP_RETURN is a special case refereed to as "provably un-spendable", this is a response to people jamming hashes and other data into PubKeyHash outputs as a way of pegging them in time to the block chain. Due to there being no way of knowing if the output is actually valid or not these outputs must be stored forever in the UTXO pool. An OP_RETURN prefixed output can absolutely never be spent, so nodes can safely forget that they ever existed.


Security concerns when downloading the block chain from a 3rd party source? It takes very long until bitcoin-core has downloaded the whole block chain. So I decided to download the block chain files via a bittorrent published by this website: http://www.getbitcoinblockchain.com

After the download was finished I noticed that the md5 checksums of the files from the torrent were different then of the files from bitcoin-core.

Why could that be?

Are there any security related concerns of using a block chain from a 3rd party source?

After the download was finished I noticed that the md5 checksums of the files from the torrent were different then of the files from bitcoin-core.
Why could that be?

The download they provide is a Bitcoin Core data directory. The data directories of two nodes are not likely to be the same.
This is because blocks are downloaded out of order. Since blocks are written to disk in the order that they are received, the blocks will be in a different order from node to node and thus the hash of all of the data will be different.
Furthermore, orphan blocks causes the data to be different because some nodes might have heard of an orphan block but another node did not.

Are there any security related concerns of using a block chain from a 3rd party source?

Yes. They could be providing you a false blockchain, i.e. one that is valid but not the blockchain that all other nodes are following.


Takes longer to download newer blocks? I have been downloading the blockchain to a new client and it has been at it now for almost a week. One thing I notice is that as it is getting close to the end, it is slowing down a lot.

For example, it just downloaded 93 blocks in 488 seconds or 1 block per 5.25 seconds. If the entire block chain had downloaded at this speed then it would take: 418950 x 5.25 = 2,199,488 seconds or 25 days. Since, it has taken less than a week to do it, the older blocks must have downloaded faster.

What is the explanation for this?

There are a few different factors for the synchronization time:

You're not only downloading data, but the data is also being validated. There is a lot of I/O going on. Disk speed is a significant factor.
The earlier blocks are much smaller than the later blocks. Validation time roughly scales linearly with the data size.
Complexity of transactions may have increased over time, transactions with more inputs take significantly more time to validate.
The UTXO database grows larger as you parse the blockchain, and every input for every transaction has to be looked up in the UTXO database.


Unconfirmed transaction: does the receiver know about it? I just sent someone some bitcoins, but it's still at the unconfirmed transaction stage.  But does the receiver know this information yet, i.e., that I have sent and we are merely waiting for it to go through?

depends on the software. yes, the receiver is able to know this information


Why do bitcoin: URLs not use "//", breaking "clickability"? I want to have something like this in a plaintext e-mail:
Pay directly: bitcoin:addresshere?amount=0.001&label=Blablabla&message=Blablabla

But if I do that, it won't be "clickable", because the standard URL format would be:
Pay directly: bitcoin://addresshere?amount=0.001&label=Blablabla&message=Blablabla

Why does the bitcoin: URL scheme not use the // part? Is it intentional to not be clickable? Or am I wrong in my assumption that e-mail clients will not make it "clickable"?

The Bitcoin URI scheme is defined in BIP21:

Bitcoin URIs follow the general format for URIs as set forth in RFC
3986. The path component consists of a bitcoin address, and the query component provides additional payment options.

You can read through the entire RFC document or the summary on Wikipedia which answers your question:

An optional authority component preceded by two slashes (//),
comprising:

An optional userinfo subcomponent that may consist of a user name and an optional password preceded by a colon (:), followed by an at
symbol (@). Use of the format username:password in the userinfo
subcomponent is deprecated for security reasons. Applications should
not render as clear text any data after the first colon (:) found
within a userinfo subcomponent unless the data after the colon is the
empty string (indicating no password).
A host subcomponent, consisting of either a registered name (including but not limited to a hostname), or an IP address. IPv4
addresses must be in dot-decimal notation, and IPv6 addresses must be
enclosed in brackets ([]).[24][c]
An optional port subcomponent preceded by a colon (:).

Conclusion: the Bitcoin URI scheme is RFC-compliant and does not require the optional "authority" component which is what the // deliniates.


Can Scripts be used to implement Chargebacks? I went ahead and wrote this semi-detailed post about how to implement Chargebacks, when I hit my head and said "Doh, maybe this can just be implemented more cleanly with Scripts".

So ... is there a way to use scripts to create a chargeback mechanism in Bitcoin? Has this been discussed before? (please provide links)

The discussion on Bitcoin Talk pretty much convinced me that "elective Chargebacks" (where some tx be reverrsed, but not all) is essentially meaningless.

If a shop would choose to give a customer the ability to do chargebacks for a limited time, this is equivalent to just postponing the payment. Since this is the main use case, and the other use case of chargebacks is personal wallet security, for which there are better alternatives, I'll accept this answer and consider the matter closed.


What is the longest time gap between blocks in 2010 - 2011? I notice on blockexplorer that block 159531 was mined at 2011-12-28 10:53:53 and the next block was mined at 2011-12-28 11:24:58 - a gap of more than half an hour. I know the 10-minutes-per-block rule is just an average that the network tries to maintain, thus outliers are possible. So what's the longest we've had to wait for the next block to be mined, in the last year (2010 to 2011)?

Edit: clarifying that I'm interested in the longest gap between blocks in "recent history", which I arbitrarily define to be the last year.

I wrote a program that extracts the blockchain into an SQL database and ran a query. The answer is that block 152218 followed block 152217 after a delay of 1 hour 39 minutes 7 seconds. This was the longest inter-block interval in 2011. There were many longer interval in the early history of the blockchain, often multiple hours or days.

Edit: I also find it interesting that there have been 78 blocks where the inter-arrival time was less than one second.


Uptime and other service performance levels Other payment networks have scheduled maintenance periods as well as unscheduled outages but Bitcoin's network, being decentralized, can have varying service levels depending on:

which versions of the software and which nodes are used
the nature of the transactions (e.g., microtransactions or those originating from an eWallet sans fee, etc.)
several other factors.

What are key performance measurements that can be made for the Bitcoin network, and how can they be measured? If measurements are being made already, where are they available?

You seem to conflate several issues in your question. If you are just talking about "uptime", which your question title implies, then speed of transaction propagation or confirmation is not relevant. As long as your node is can connect to other nodes and send/receive data, the network is "up". If you send transactions that require fees and they don't confirm for a long time, that's your problem, not the network's.

That said, the "gist" of your question, about network health, transaction processing speed, etc, is not unimportant. There is a bunch of useful data on this site, dedicated to monitoring the bitcoin network: http://bitcoinstatus.rowit.co.uk/ that would probably get you started in the right direction. :)


Why is my client software not receiving bitcoins? I've just installed the official bitcoin client for the first time on my PC and have visited a website that gives free bitcoins. I've been waiting for more than an hour, but the amount given to me is still not showing in my bitcoin client. Have I missed anything in setting up and configuring the client software?

There are a few things that you should check:

Your client is connected (it shows N connections in the status bar). If it doesn't, you have connectivity problems.
You have downloaded the whole blockchain (the N blocks in the status bar is not increasing rapidly). You need to wait until you have downloaded all blocks.
Blockexplorer can tell you if the payment has been sent to your address. Just type your address in the search box. If it doesn't show up in there, it's because it wasn't sent yet.

These websites give very small amounts of money for free so they usually group transactions (instead of making many small ones). You probably need to wait a while before the payment is sent.


Can miners choose which transactions to mine? I'm curious if miners can choose which transactions to mine?  I know that there are limits to the minimum size of a transaction fee (around 5400 satoshis) but I'm wondering if miners can ignore those limits for certain transactions.  For example, if I gave a mining pool a list of addresses and offered an incentive to them to mine them even though the transaction was non-standard, could they do it?

I know that there are limits to the minimum size of a transaction fee (around 5400 satoshis)

Actually, some transactions can sent for free.

  For example, if I gave a mining pool a list of addresses and offered an incentive to them to mine them even though the transaction was non-standard, could they do it?

Absolutely. A miner can include any transaction that doesn't break network rules, for any reason.


Why does Bitcoin store keys in a database? According to this Bitcoin stores the user's keys and some additional data in a file called wallet.dat, which is a Berkley DB. Let's suppose the wallet.dat contained only the user's keys. Let's also suppose we're using linux.

What is then the main reason for Bitcoin to store keys in a database? Wouldn't it have the same effect if keys were stored as flat files: the public key would be the filename and the private key would be the content of the file?

Even if we had millions of keys, and therefore millions of files in a single directory, the i-node limit (maximum number of files in a directory) and file lookup speed shouldn't be a problem. The majority of linux systems use the ext4 as its filesystem and according to this the number of i-nodes in ext4 is unlimited (limited only by the disk memory). Also according to this the EXT4 uses a structure called HTree, which allows for file lookups to have a constant time complexity.

Historically bdb was used for the UTXO as well, so you could justify using it for the wallet as well for consistency. It makes absolutely no sense today, other than that it will always need to be supported to some extent for compatibility.

Really the wallet could be replaced with any key value store at all and it would function completely fine. You would not want a single key per file because this tends to be incredibly inefficient and difficult to deal with from a filesystem, and a human interaction perspective. It's easier to back up a single file than tens of thousands in a directory.


What exchanges trade with Unicoin right now? I absolutely LOVED the new Stack-Exchange-specific cryptocoin, "Unicoin", mineable by humans and unicorn-themed.

As well as the diverse options to pay for it (gold, silver, BTC, LTC, DOGE, reputation on this site and Reddit, bacon, among others) and the incredibly useful, succint and accurate legal disclaimer message.

But then, I haven't found an exchange that trades it. Is there one?

May be http://newchg.com/unicoin/ can be usefull but I have never used this exchange.


How would one monitor an address for a transaction and 1 confirmation in PHP? I have a small PHP script with my static bitcoin address shown. When someone sends any btc to that address, how can I get the PHP script to check if the transaction has had 1 confirmation? Do I have to run something on cron to have it check every second? Or is there another elegant way to do this in PHP? Any examples?

Cron Jobs and 3rd Party API:

You could try with cron jobs, but I wouldn't run it every second, that's rather exhaustive. Maybe every 5 or 10 minutes, and then have it check the current total received vs the previous amount using a database.

$addy = "1somebitcoinaddress";
$bcinfo = json_decode(file_get_contents("https://blockchain.info/address/".$addy."?format=json"), true);
$balance = $bcinfo["total_received"];
$query = $db->prepare("SELECT previous_balance FROM address WHERE address = :addy");
$query->bindParam(':addy', $addy);
$query->execute();
$result = $query->fetch(PDO::FETCH_ASSOC);
$prevBal = $result["previous_balance"];
   if($balance > $prevBal){
   //balance changed, do something
   }

That way seems rather less than elegant though, and it's not instant.

3rd Party Webhook:

A better way would be with a webhook. Blocktrail offers a free webhook service, and you can even do it all in their UI after creating an account. Just sign up as a developer, then once logged in click on the webhooks tab and then create a new webhook that monitors your bitcoin address. It will ask for a callback url, that's where you provide a link to your PHP script to run.  When you provide the callback url I would add a secret to help prevent unauthorized calls like: yourdomain.com/callback.php?secret=12345

Your callback PHP script can look something like this:

$secret = "12345";
$verify = $_GET["secret"];
if($secret != $verify){
die();
}

$data = json_decode(file_get_contents("php://input"), true);

//get estimated value of transaction
$amount = $data["data"]["estimated_value"];
$confirm = $data["data"]["confirmations"];

if($confirm >= 1){
//do something, like send an email notification
$email = "your@email.com";
$sub = "New Transaction";
$body = "Amount: ".$amount;
mail($email, $sub, $body);
}

Bitcoind and Wallet Notify:

Lastly, there's run bitcoind and use walletnotify.

Make sure the address you are monitoring is imported into your bitcoind wallet. Set wallet notify up in your bitcoin.conf

walletnotify=curl https://yourwebsite.com/script.php?txid=%s

Now anytime there is activity on your bitcoind wallet your script will run, with the transaction id stored in a GET under ["txid"] and then you can do a script like:

require("easybitcoin.php");
$bitcoin = new Bitcoin("someusername", "somepassword");

$txid = $_GET["tx"];
$txinfo = $bitcoin->gettransaction($txid);
$details = count($txinfo["details"]);

for($i=0;$i<$details;$i++){
$check = $txinfo["details"][$i]["address"];
$addy = "1SomeAddressToMonitor";
    if($check == $addy){
    //activity on your address, do something
    }
}


Why should I use multiple workers? Why should I use multiple workers for different computers? In which case should I create another worker?

You should use multiple workers if you want separate statistics for them, or if the pool you are using limits the number of connections that are allowed per worker.


The Legit & Safe—Windows Command Line Miner I read over the "Is there a command line Bitcoin CPU miner for Windows?" post and GCMiner looked promising for a Windows command line scriptable solution that allows pool mining.

I tried downloading the GCMiner client right from GitHub links from Windows via the Chrome, Firefox, and Internet Explorer web browsers and all of them say something is unsafe and prevents me from downloading the CLI tool. I tried to download from Linux Mint via the Firefox web browser from the GitHub links and got the same unsuccessful result.

Question

Is there a safe Windows client that is command line that I can use to mine in a pool such as SlushPool for CPU mining I suppose?

I'm setting this up to play with and become familiar with the pool management side more than the configuration so I'm not worried about CPU being ineffienct over GPU.
If I can safely download CGMiner to start playing with it on Windows that'd even work.

Note: I'd prefer to use a pool like SlushPool where I can put in my unique username and whatever miner names I define only. I don't want a client that requires an email address in the logic to mine.

There are no official CGMiner binaries being distributed anymore specifically because of this problem. You will need to download the source code and compile it yourself. Instructions for doing that are available here.

The reason that CGMiner is flagged as Unsafe is due to Anti-Virus software and malware that use CGMiner. Anti-Virus have performed analyses of the CGMiner and determined it to be a cryptocurrency mining software - which it is. Unfortunately, a lot of malware are also capable of mining cryptocurrencies once they infect someone's computer, so AVs have taken to flagging everything that can mine cryptocurrencies as unsafe. This then reaches the browsers which do the same.


Can "Digital Signature of the Block by the Miner" be used in place of "Nonce"? As it is understood that arriving nonce is very resource intensive, whether "Digital Signature of the Block by the Miner" can be considered in place of "Nonce"? Its Shortcomings, if not suitable.

This only raises the question of which miners' signatures are considered acceptable.  If anyone can be a miner and provide a signature, then there is no security and no way to objectively determine which of many conflicting blocks is authoritative.  If there is a fixed list of authorized public keys, then the currency is no longer decentralized.


How to sign a transaction with multiple inputs? I have been able to program an application in python that sends valid transactions that spend 1 input, but I really can't get it to work with 2 or more inputs.

So my question is, how exactly is the hash that has to be signed for each input calculated?

What I have been doing so far, is, for example, if we have 2 inputs, we generate a transaction that spends only that first input, and thats the hash that has to be signed for the first input. And the same with the second input, we generate a transaction that only spends that second input. Both transactions need to have the same outputs.

Is that correct? For example, we want to spend input aaaa:0 and input bbbb:1 and we want to send them to some address:

To calculate the hash that the first input has to sign, we need to generate this transaction:

'version': 1,
'inputs': (1)
    'output_tx_hash': 'aaaa',
    'output_position': 0,
    'script': the original script, like: '76a914' + hash + '88ac',
    'sequence': ffffffff,
'outputs': (1)
    'value' : 100000
    'script' : '76a914' + hash of btc pub key + '88ac'
'locktime': 0

And to calculate the hash that the second input has to sign:

'version': 1,
'inputs': (1)
    'output_tx_hash': 'bbbb', # this changes
    'output_position': 1,     # this changes
    'script': the original script, like: '76a914' + hash + '88ac',
    'sequence': ffffffff,
'outputs': (1)
    'value' : 100000
    'script' : '76a914' + hash of btc pub key + '88ac'
'locktime': 0

We serialize them, add them 01000000 (SIGHASH_ALL), double sha256 that, sign it, and add 01. That way we get the two signatures that we will use on each input respectively. My application does exactly that and doesn't work. What am I missing?

I found the way to do it, so, if anyone is interested, here is how to do it:

When you have more than 1 input, you don't have to remove the inputs that you are not going to sign, you have to remove only their scripts. So, if you want to sign the transaction posted in the question, the first hash would be calculated like so:

'version': 1,
'inputs': (2)
    {
    'output_tx_hash': 'aaaa',
    'output_position': 0,
    'script': the original script, like: '76a914' + hash + '88ac',
    'sequence': ffffffff,
    }, {
    'output_tx_hash': 'bbbb',
    'output_position': 1,
    'script': '', # Nothing
    'sequence': ffffffff,
    }
'outputs': (1)
    'value' : 100000
    'script' : '76a914' + hash of btc pub key + '88ac'
'locktime': 0

And the second hash:

'version': 1,
'inputs': (2)
    {
    'output_tx_hash': 'aaaa',
    'output_position': 0,
    'script': '', # Nothing
    'sequence': ffffffff,
    }, {
    'output_tx_hash': 'bbbb',
    'output_position': 1,
    'script': the original script, like: '76a914' + hash + '88ac',
    'sequence': ffffffff,
    }
'outputs': (1)
    'value' : 100000
    'script' : '76a914' + hash of btc pub key + '88ac'
'locktime': 0

Hope it helps anyone.


Is there a convention for how to order UTXOs in a transaction with multiple inputs? I am not sure it matters to produce a correctly formatted transaction, but I am playing around with a wallet that does not keep its own private keys, but produces the raw txs to sign and want to give the user the ability to verify the details of the raw txs with a third party or some control libraries. Assume, Bitcoin Core sets the standard, but I am unfortunately C illiterate. Thanks, Kyle

The convention is to have the outputs in random order. This is specifically done in an effort to conceal which output is the change output. The change is by default sent to a new address that is owned by the sender, and as such has no history associated with it.

The majority of bitcoin's code is actually c++. Here is a link to the relevant transaction creation code, maybe there are a few comments that could point you in the right direction.


Lost computer with bitcoins I had purchased bitcoins several years ago.  I installed the version of this software that was available at the time and I think everything was saved on the computer I was using it at that time.  The computer that had my bitcoins on it has disappeared.  I am installing the latest version of the Bitcoin Core wallet now but how would I go about getting my bitcoins back.

I couldn't seem to find an exact answer on how to restore my bitcoins.

If the computer "disappeared", there is no way to get your Bitcoins other than finding the computer again.

You had a "wallet.dat" file on the there which stores the information necessary to access your Bitcoins. Without it you cannot access your Bitcoins.


Can't import BIP32 key into electrum I always struggle here and tried both ways plenty of time

i use the rubygem "moneytree" and electrum 3.3

@master = MoneyTree::Master.new
@master.to_bip32(:private)

this will give me tprv8ZgxMBicQKsPe8hnfLVQdtZk2qMKnnDQs2ZKLgoJQBhedKQ5vB7srAb6Tk2iUYNkhaacTjNP9WzkbjCqPjk8ExUFGECbiR1Z8tZDs76jytn

however, i can't import this in electrum. the next button is just non active.

i tried the other way around and created a wallet with seed fabric body bright coffee special music virus raccoon side double shield shrug and exported the master public key which will gives me xpub661MyMwAqRbcGq54zC5FfD3rTjgcAGd36JvtW6r4RGheQjSdUVqAS9Q1DLAvzyvvxdYziZced4Y6kHLCqo73vuB4gGSpt6tJwtCWYm8zsBb

now i'll run the following

master_pub_key = "xpub661MyMwAqRbcGq54zC5FfD3rTjgcAGd36JvtW6r4RGheQjSdUVqAS9Q1DLAvzyvvxdYziZced4Y6kHLCqo73vuB4gGSpt6tJwtCWYm8zsBb"
$bitcoin_root_node = MoneyTree::Node.from_bip32(master_pub_key)

i = 0
20.times do
  p $bitcoin_root_node.node_for_path("m/0/#{i}").to_address
  i+= 1
end

all generated addresses will look like this

mpQPcBLyTqPPCw9dhdXYm3Dvnnn58Y4dwA
mt6UdprJNAuJUtG3BYWTy3dZrST7nZTwtZ

starting with a small M

however, in electrum all the addresses are starting with 1xxxxx

what am i doing wrong?

It looks like in some places you're using testnet addresses (tprv.., m..) and in other places you're using mainnet addresses (xpub.., 1..). If your software is expecting one and gets the other, then you'll likely have some problems (like Electrum not letting you click 'next'). Check to make sure all the software you're using is configured to give you the desired outputs.

See: https://en.bitcoin.it/wiki/List_of_address_prefixes


Understanding the receive tab in electrum I've downloaded Electrum and have successfully transferred my first small amount of bitcoin to my wallet (after purchasing some through an exchange). I used the receiving address (by copy pasting it to the exchange) but what are the other options in Electrum's receive tab for 'description' 'requested amount' 'request expires'? In what circumstances should I fill in these fields... and in what circumstances should I save or create a new address? Thanks for your help, (I've searched online but doesn't seem to be a lot of information on these type of details)

Those fields are encoded into the QR code, so that it is easy for the person to pay you. The payer just scans the QR code, and if their wallet knows how to read BIP21 URIs, then they will already have the amount, description, and address filled into their payment form. In addition, if the offer is only available for a limited time, the wallet will prevent/warn the user from completing the transaction.


Block Broadcasting - Unsolicited Block Push Can someone, please, direct me to the source code section(s) relevant for an Unsolicited Block Push as described in the Bitcoin Developer Guide?

I've been going through main.cpp and searched for the term MSG_BLOCK, serving as a beagle for finding the correct place in the code. But as I'm reading further, it seems to me as if a freshly mined block is not appended to a inventory message, with MSG_BLOCK, in order to send it as a "package" as response to a request (GetData Response) BUT is sent as a single message of this structure:

To me, up to now, the best canditate for Unsolicited Block Push seems to be main.cpp#L2393 part of main.cpp but I'm confused since I don't know if there is more of possibly relevant code (like main.cpp#L3830) for Unsolicited Block Push in /src/.

So: In a first step, I'm looking for code that is relevant for broadcasting a newly found block. Can someone please help?

We can find all instances in the code where the client will send a block message by searching for PushMessage("block". This is the only match:

void static ProcessGetData(CNode* pfrom)
{
[...]
    pfrom->PushMessage("block", block);

(Source.)

This means that the standard client only ever sends a block message when specifically asked for it. That incoming getdata message is probably triggered in turn by sending the remote node an inv message. (Though that's not necessary - you can ask for a block that the other node hasn't advertised.) This is the code that sends inventory messages:

//
// Message: inventory
//
vector<CInv> vInv;
vector<CInv> vInvWait;
{
    LOCK(pto->cs_inventory);
    vInv.reserve(pto->vInventoryToSend.size());
    vInvWait.reserve(pto->vInventoryToSend.size());
    BOOST_FOREACH(const CInv& inv, pto->vInventoryToSend)
    {
        // If the other node already knows the message, don't send
        if (pto->setInventoryKnown.count(inv))
            continue;

        // trickle out tx inv to protect privacy
        [...]

        // returns true if remote node hasn't seen it
        if (pto->setInventoryKnown.insert(inv).second)
        {
            // Add to the list of inventory messages to send
            vInv.push_back(inv);
            // If there's 1000 inventory messages queued up, send them
            // (Protocol limit is 50000 at a time.)
            if (vInv.size() >= 1000)
            {
                pto->PushMessage("inv", vInv);
                vInv.clear();
            }
        }
    }
    pto->vInventoryToSend = vInvWait;
}
// Send any that are left over.
if (!vInv.empty())
    pto->PushMessage("inv", vInv);

(Source.)

(pto represents the remote node in the above code.)

So the page you're looking at describes a behavior that you could implement, and that other clients will accept, but it doesn't describe the current core client behavior.


bitcoind synced more blocks than in the blockchain? I just installed bitcoind on a fresh Ubuntu server and synced.

However, it seemingly have synced more blocks than there are in the blockchain!

$ bitcoind getblockcount
309905
$ curl http://blockexplorer.com/testnet/q/getblockcount
26787

How is that possible?

Is there something wrong with my installation?
Do I have to remove it all and restart from scratch?

Here is my bitcoind config:

#testnet=1
server=1
#daemon=1
rpcuser=[redacted]
rpcpassword=[redacted]
rpctimeout=30
rpcallowip=127.0.0.1
rpcport=19332

addnode=95.85.39.28:18333
addnode=46.4.106.234:18333
addnode=94.102.53.181:18333
addnode=5.135.159.139:18333
addnode=188.226.138.211:18333
addnode=188.165.238.173:18333
addnode=46.28.204.15:18333
addnode=109.201.135.216:18333
addnode=5.9.2.145:18333
addnode=46.182.106.2:18333
addnode=109.201.154.201:18333
addnode=188.165.246.217:18333

You requested the amount of blocks in the testnet. In the 'real' blockchain, there are currently 309913 blocks, which is in agreement with your blockcount.

Change

$ curl http://blockexplorer.com/testnet/q/getblockcount

into

$ curl http://blockexplorer.com/q/getblockcount

So no need of removal of anything. Everything is perfectly fine.


Importing an arbitrarily created Master Private key to Bitcoin Core I've created a Master Private key (xpriv) on an airgapped machine along with an Master Public key (xpub). Now I'm running Bitcoind on my Ubuntu server and I want to use my newly created keys on a new wallet rather than the one that Bitcoind created for me when I started running bitcoind.

Is this possible to do? If so what is the way to go?

It is currently not possible to import a master private key into Bitcoin Core.


Building Signed Bitcoin Transaction in Java I have been attempting to build my own raw transaction generator in Java which I can then broadcast on the testnet network. The problem is when I attempt to broadcast the transaction it says there is an error in the redemption script, which I do not understand.

Here is an example testnet transaction:

  0100000001e468833270cf713f3bbccc62b7b5b0fc0b0a4570608718530816795a6589f322000000008a473044022051646b77924f6bb7c411c5aa890110ab55db8812b8998fe24c8bdce39795ebd602200bc4de18fd5524ad8b946ee57604424e2b943ef2a14fc7199a7853dda0743cbe014104b97c679207532e0f4ee2515aedaba5f87700bbe0138f7457baa58e89a53153823ab29632e6c3c804ecaab5913656512339792479a1b898b7e5dc31f075ff8660ffffffff0176df1710000000001976a91448ddfd3891f3f422d5c3c9c25e35b382667fc6e688ac00000000

The script I am attempting to unlock:

  76a91448ddfd3891f3f422d5c3c9c25e35b382667fc6e688ac

With the redemption script being:

  473044022051646b77924f6bb7c411c5aa890110ab55db8812b8998fe24c8bdce39795ebd602200bc4de18fd5524ad8b946ee57604424e2b943ef2a14fc7199a7853dda0743cbe014104b97c679207532e0f4ee2515aedaba5f87700bbe0138f7457baa58e89a53153823ab29632e6c3c804ecaab5913656512339792479a1b898b7e5dc31f075ff8660

This is the Java code to sign the reverse double sha256 hash:

  public static byte[] sign(byte[] hash, BigInteger priv){

        ECDSASigner signer = new ECDSASigner(new HMacDSAKCalculator(new SHA256Digest()));
        signer.init(true, new ECPrivateKeyParameters(priv, domain));

        BigInteger[] signature = signer.generateSignature(hash);
        ByteArrayOutputStream s = new ByteArrayOutputStream();

        try {
            DERSequenceGenerator seq = new DERSequenceGenerator(s);
            seq.addObject(new ASN1Integer(signature[0]));
            seq.addObject(new ASN1Integer(signature[1]));
            seq.close();
            return s.toByteArray();
        }
        catch(IOException e){
            return null;
        }
    }

What is wrong?

Quickly decoding the tx:

 VERSION      01000000
 TX_IN COUNT  hex=01, decimal=1
 TX_IN[0]
  TX_IN[0]    OutPoint hash 22F389655A7916085318876070450A0BFCB0B5B762CCBC3B3F71CF70328368E4
  TX_IN[0]    OutPoint index hex=00000000, reversed=00000000, decimal=0
  TX_IN[0]    Script Length hex=8A, decimal=138
  TX_IN[0]    Script Sig  473044022051646B77924F6BB7C411C5AA890110AB55DB8812B8998FE24C8BDCE39795EBD602200BC4DE18FD5524AD8B946EE57604424E2B943EF2A14FC7199A7853DDA0743CBE014104B97C679207532E0F4EE2515AEDABA5F87700BBE0138F7457BAA58E89A53153823AB29632E6C3C804ECAAB5913656512339792479A1B898B7E5DC31F075FF8660
        47: OP_DATA_0x47:     push hex 47 (decimal 71) bytes as data
        30: OP_SEQUENCE_0x30: type tag indicating SEQUENCE, begin sigscript
        44: OP_LENGTH_0x44:   length of R + S
        02: OP_INT_0x02:      type tag indicating INTEGER
        20: OP_LENGTH_0x20:   this is SIG R
            51646B77924F6BB7:C411C5AA890110AB:55DB8812B8998FE2:4C8BDCE39795EBD6
        02: OP_S_INT_0x02
        20: OP_LENGTH_0x20:   this is SIG S
            0BC4DE18FD5524AD:8B946EE57604424E:2B943EF2A14FC719:9A7853DDA0743CBE
        01: OP_SIGHASHALL:    this terminates the ECDSA signature (ASN1-DER structure)
        Minimum and maximum size constraints                        - ok
        scriptsig always starts with 0x30                           - ok
        length 136 chars is less than actual sig length (140 chars) - ok
               (hex 0x44, decimal 68, 136 chars)
        length of R coordinate (64) >= 0                            - ok
        length of S coordinate (64) >= 0                            - ok
        S-Value is within scriptsig boundaries                      - ok
        Make sure the R & S length covers the entire signature      - ok
        S-value must be smaller than N/2                            - ok
        strictly check DER-encoded signature                        - ok
        41: OP_DATA_0x41:     push hex 41 (decimal 65) bytes as data
        04: OP_LENGTH_0X04
            B97C679207532E0F:4EE2515AEDABA5F8:7700BBE0138F7457:BAA58E89A5315382
            3AB29632E6C3C804:ECAAB59136565123:39792479A1B898B7:E5DC31F075FF8660
        * This terminates the Public Key, corresponding bitcoin address is:    mnAEswb3Aiz5YTsfCJc8vQETnSe19mc5Am
 TX_IN[0] Sequence FFFFFFFF

TX_OUT COUNT, hex=01, decimal=1
 TX_OUT[0] Value hex=76DF171000000000, rev_hex=000000001017DF76, dec=269999990
 TX_OUT[0] PK_Script Length hex=19, dec=25
 TX_OUT[0] pk_script 76A91448DDFD3891F3F422D5C3C9C25E35B382667FC6E688AC
        76: OP_DUP
        A9: OP_HASH160
        14: OP_Data14 (= decimal 20)
            48DDFD3891F3F422:D5C3C9C25E35B382
            667FC6E6
        88: OP_EQUALVERIFY
        AC: OP_CHECKSIG   This is a P2PKH script and translates base58 encoded into this bitcoin address:    mnAEswb3Aiz5YTsfCJc8vQETnSe19mc5Am
 LOCK_TIME 00000000

So the transaction is correct, and the signature is assembled correctly. It also follows the "strict sig check" rules. The tx is trying to  spend from mnAEswb3Aiz5YTsfCJc8vQETnSe19mc5Am to mnAEswb3Aiz5YTsfCJc8vQETnSe19mc5Am.
So I checked the signature against the double hash of the tx (see the famous pizza transaction run-through: How does the ECDSA verification algorithm work during transaction?):

The raw_tx.txt is:

0100000001e468833270cf713f3bbccc62b7b5b0fc0b0a4570608718530816795a6589f322000000008a473044022051646b77924f6bb7c411c5aa890110ab55db8812b8998fe24c8bdce39795ebd602200bc4de18fd5524ad8b946ee57604424e2b943ef2a14fc7199a7853dda0743cbe014104b97c679207532e0f4ee2515aedaba5f87700bbe0138f7457baa58e89a53153823ab29632e6c3c804ecaab5913656512339792479a1b898b7e5dc31f075ff8660ffffffff0176df1710000000001976a91448ddfd3891f3f422d5c3c9c25e35b382667fc6e688ac00000000

Removed sig, and entered your pubkey script into raw_tx_SIGHASH_ALL.txt:

0100000001e468833270cf713f3bbccc62b7b5b0fc0b0a4570608718530816795a6589f322000000001976a91448ddfd3891f3f422d5c3c9c25e35b382667fc6e688acffffffff0176df1710000000001976a91448ddfd3891f3f422d5c3c9c25e35b382667fc6e688ac0000000001000000

and double hash (the binary values, hence some conversion first!)

  result=$( cat raw_tx_SIGHASH_ALL.txt | sed 's/[[:xdigit:]]\{2\}/\\x&/g' )
  printf $result > raw_tx.hex
  hexdump -C raw_tx.hex
  openssl dgst -binary -sha256 <raw_tx.hex >ssha256.hex
  openssl dgst -binary -sha256 <ssha256.hex >dsha256.hex
  hexdump -C dsha256.hex

So the dsha256 is in readable form:
  6b37475a5388fb52f227817a0ddec00e7b69495b492cd7cdc6aff2afc44810e4

I use openssl to verify the double hash hex file (dsha256.hex), with the signature and a "pem" key (need to convert pubkey from hex to pem), I always get an error:

openssl pkeyutl -verify -pubin -inkey pubkey.pem -sigfile tmp_sig.hex -in dsha256.hex

whereas running through the pizza example, it returns a "Signature Verified Successfully".


How to accept BTC payments I'm developing a website that will be accepting BTC as a form of payment.

I (technically) know how to accept payments, I'm currently experimenting with the daemon and the Python-BitcoinRPC library and everything seems to work well.

What I'm asking here is what is, in the opinion of Bitcoins experts, the best way to actually handle the transactions.

I'm currently testing this method:

Payment requested
Script asks the Bitcoin daemon to generate a new address
Show the new address to the user, ask to pay to that address
Script monitors the address
When the confirmed amount on that address is equal or greater that the amount to pay, mark the transaction as Payed
Transfer the amount from the address to another "main" address where all the payments end up

Is this method good and secure? I'm particularly unsure about the last point.

Do you have any experience in this field?

Thank you in advance!

EDIT: I'm having some issues in sending BTC moved to a address from another address in local (without paying fees).

Your work flow looks good, you should wait for a sufficient number of confirmations before  you transaction is fully accepted.  Not sure if you are delivering physical products or digital products,  that could impact how many confirms you choose to wait for.

Check out the following RPC API call:

 move <fromaccount> <toaccount> <amount> [minconf=1] [comment]
 Move from one account in your wallet to another

This will allow you to move funds from one address to another within the same wallet.


Best way to calculate difficulty of generating specific vanity address? I'm now working at small tool, which purpose is to calculate difficulty (like number of attempts) of getting vanity address, like vanitygen (https://github.com/samr7/vanitygen) does. I've read some materials (https://en.bitcoin.it/wiki/Vanitygen#Difficulty_of_finding_a_vanity) and now i'm wondering about exact algorithm of how such calculation must be proceeded.  There is no precise answer in the article at bitcoin.it wiki, so a look through the sources of vanitygen and ended up with some very basic ideas:

All addresses are in a nutshell base58 numbers which can be converted to biginteger if needed.
There is one final "biggest" address (like biggest number in the end of some range)
Vanity address is any address from the range of addresses (if we think about them as numbers), that starts with specific pattern.

So what is the best way of finding difficulty of getting specified vanity address?
I ended up with such idea:

Find the biggest possible address and convert it to bigint.
Find addresses range for given vanity pattern. First of all find the biggest possible address in the range by adding z to the end of the pattern while it is smaller than biggest possible address. Then to get smallest address in range i decided to add 1 (base58 representation for 0) to the vanity patter and i failed to determine when i must stop. Clearly address could not be longer than 34 symbols, but when i must stop? I think that i must take length of the biggest address in the range and that will be the same length for the smallest. But please, correct me if i'm wrong.
When we have range of addresses, we can calculate it's length by subtracting smallest one from biggest one and then divide biggest possible address by range length and the result will be our difficulty.

So is it all correct?
What shall i do when pattern starts with "1"?

What additional materials you can suggest to read?

So things turned out to be a little bit different. But now i have a solution, that seems to be workable and adequate.
Original task was to calculate difficult of finding specific vanity address (like vanitygen does).

Difficult is basically
number_of_all_possible_addresses / number_of_addresses_with_vanity_prefix rate.

So, for example if we have only dec addresses between 0 and 9999, difficult for finding vanity address, that starts with "1" will be 10, because 10000 is the number of all possible addresses and only addresses from 1000..1999 will match, so there are 1000 of them.

With bitcoin addresses things are little bit more complicated, but principal is the same.

First let's find out how bitcoin address is formed: in a nutshell there is a couple of steps, that are important for  our task:

Take one 0x00 byte (that will be first byte of address to represent it's version)
Take ripemd160 result (20 bytes, 160 bits).
Take first four bytes of sha256(sha256(ripemd160)) as checksum
Concatenate 0x00+ 20 bytes of ripemd + 4 bytes of sha256 of sha256 of ripemd
Now you get a 25-byte long something which you must treat as a long integer. We will call this number a "proto-address".
Base58Check it (but this is not very important now) and result will be the bitcoin Address.

However, what is important is understanding of the fact, that we can change only ripemd part. That leads us to two conclusions:
first is that there are only 2^160 bitcoin addresses and second is a little bit more complicated.

Let's find answer to an important question: If A and B are numbers that starts with the same digit and there is an X such as A < X < B does it mean that X starts with the same digit?
If A is 1000 and B is 1999 - yes it does. X can be any number from 1001 to 1998. But what if A is 100 and B is 10000? X can be any number between them and it must not start with the same digit. So A, X and B must have the same digit in the beginning only if they have equal number of digits. Keep it in mind, it is important.

Let's  figure out, what is vanity address and what is base58 encoding.

Base58 is like base16 and base2 and base10 and like every other base.
Symbol "A" for example is "A" in base58 and 0x09 in base16 or 9 in base10. That is a good point to start.

Let's decide that our address starts with "1A". We know that address is basically an integer of 25 bytes. What is "1A"? It is a "1A" in base58 and 0009 in base10. Or just 9.

That means that every number, which can be divided by 58 and will have a quotient equal to "9" will give us an "A" symbol during base58.
For example 522/58 == 9. 30276/58/58 == 9. But not only those numbers will end up with 9, but these ones too:

9*58 + 58 -1
9*58^2 + 58^2 - 1
9*58^3 + 58^3 -1
or just any (9 + 1)*58^N -1 number

So the formula is for the beginning of the range:

prefix*58^n

for the end of the range:

(prefix + 1)*58^n -1

Here comes an idea: we must find all ranges of numbers that will meet those requirements:

Number in the beginning of range and number in the end of range have equal number of digits
Lengths of these numbers must be equal to the length of proto-address. This is important because we must have an integer 25 bytes long that starts with a zero byte, it is the law!
Their values must be less than 2^192, because leading byte is always 00 and we have only 25 bytes, which leaves us with only 24 bytes or 192 bits which value we can change.

When we find all these ranges, we can find, how many numbers there are in the range by simply subtracting beginning of the range from ending of the range.
The sum of all lengths of our ranges will be how many possible proto-addresses we can get.

But this is not the end. As we remember, proto-addresses are just all possible big numbers so not all of them can be converted to valid bitcoin addresses. But it is very simple to calculate how many of them can. Answer is 1/256^4. Why?

Because when we are generating bitcoin address, all we can change is the result of ripemd which gives us 20 bytes. Other 4 bytes are just checksum. Easy way to think about it is that we can have 2^192 proto-addresses and only 2^160 of them will be valid, because we can have only 2^160 valid bitcoin addresses. This gives us a 1/256^4 rate.

Final part: take sum of all our ranges lengths, divide it by 256^4 and this will be number of all possible bitcoin addresses with given vanity.
Just divide 2^160 by this number and this will be the result.

Lets illustrate it by finding difficult of A prefix.

A is just 9. Ok, lets find out all ranges, that will give us 9 as a quotient.
522 - 579
30276 - 33639
1756008 - 1951119
.......
we must go and go until length of our numbers will not reach 24 bytes (mind the leading 00 byte)
........
41735950621193504130037849728691446275009901558579068928 - 46373278467992782366708721920768273638899890620643409919

Both this numbers have length of 24 bytes.
This is our first range.
Next is

2420685136029223239542195284264103883950574290397585997824 -
2689650151143581377269105871404559871056193655997317775359

This numbers also are 24 bytes long.

Next pair will be
140399737889694947893447326487318025269133308843059987873792 and
155999708766327719881608140541464472521259232047844430970879

Both are larger than 2^192 so now we must stop.
lets sum our results:

46373278467992782366708721920768273638899890620643409919 - 41735950621193504130037849728691446275009901558579068928 + 2689650151143581377269105871404559871056193655997317775359 - 2420685136029223239542195284264103883950574290397585997824 = 273602342961157415963581459332532814469509354661796118526

This is how many possible proto-addresses we can have. But do not forget to divide it by 156^4 and get:
63703009616853067642911677093369144589991624155

And this is how many possible bitcoin addresses we can have.
Now just divide 2^160 by this number and the result will be 22

This is difficulty for prefix "A" or "1A".
Now let's talk about some special cases. What you must check, when working with ranges is:

length. Length of range must be equal to the length of proto-address and you must count all suitable ranges.
2^192. if end of the range is more than 2^192 you must cut this range from the top by value of 2^192 - proto-address can't be larger than 2^192. Also remember that beginning of the range must be always less than 2^192 (if not that does not make any sense).

What about special cases? Like patterns that start with more than one "1"? it is a little bit tricky, but not very complicated. "1" is a special case in base58 cos it is equal to 0. That means, when there are some "1"s in the beginning - all this bytes must be zeroed and can not be used. So our proto-address, if we want to start it with two "1" must have two zero bytes in the beginning. Like 0000XXXX....
if we want to have 111 we must leave 3 bytes as zero bytes in the beginning and so on.

What does it mean? Each 1 will cut one byte from our proto-address, so it will cut length of our possible biggest proto-address number by 8 bits or by one byte. That will make it 256 times harder to find and one byte shorter.

Like if we want to have 11 in the beginning we will have only 23 bytes to generate our ranges and if we want to have 1111 it will give us only 21 byte. So our ranges will be much smaller and difficult will be much higher. And obviously it is not possible to find any address if we have more than 19 "1" in the pattern, cos we must leave something to the ripemd result :)

If pattern starts only with 111, just count number of  "1" and assume that beginning of range is 0 and end of range is 2^(200-8*number_of_1's) because we have only 200 bits for proto-address and some of them must be zeroed in case of our 111(1)-like pattern.

if we have pattern like 11(1)X(X) where X is non-zero symbol, just short max possible proto-address by number of bytes equal to number of 1's and do ordinary calculations.


bitcoinaverage.com price precision i noticed that from the 13th of feb 2015 the bitcoin price becomes a lot more "noisy" on bitcoinaverage.com:

does anybody know whether this is actually due to bitcoin price movements becoming more rapid, or whether its just that bitcoinaverage.com increased their sampling frequency?

I don't think the issue is that they don't have the data. I think they're just showing the data at a lower sampling rate.

This chart draws data from three locations:

https://api.bitcoinaverage.com/history/USD/per_minute_24h_sliding_window.csv
Updates once per minute, but only has 24 hours of data.
https://api.bitcoinaverage.com/history/USD/per_hour_monthly_sliding_window.csv
Updates once per hour, but only has a month of data.
https://api.bitcoinaverage.com/history/USD/per_day_all_time_history.csv
Updates once per day, but has all data.

Note how the data that goes back further is less precise.


Explain this comment on nNonce from the bitcoin miner.cpp source? This comment is in the 0.9.3 miner.cpp bitcoin source, right above the ScanHash_CryptoPP definition.

//
// ScanHash scans nonces looking for a hash with at least some zero bits.
// It operates on big endian data.  Caller does the byte reversing.
// All input buffers are 16-byte aligned.  nNonce is usually preserved
// between calls, but periodically or if nNonce is 0xffff0000 or above,
// the block is rebuilt and nNonce starts over at zero.
//
unsigned int static ScanHash_CryptoPP...

What does it mean that the input buffers are 16-byte aligned? Is that important for calculating the hash?

I notice that some of the parameters to this method are defined as follows:

char pmidstatebuf[32+16]; char* pmidstate = alignup<16>(pmidstatebuf);
char pdatabuf[128+16];    char* pdata     = alignup<16>(pdatabuf);
char phash1buf[64+16];    char* phash1    = alignup<16>(phash1buf);

All of the arrays already have a length that is divisible by 16, what's the need for the extra 16 chars?

And why only try 0xffff nonces? Is this just an artificial limit put so that the hashing doesn't take forever?

What does it mean that the input buffers are 16-byte aligned? Is that important for calculating the hash?

It means that the lower four bits of the starting address are always zero. I assume that this was done for speed reasons. There are instructions that won't work on non-16 byte aligned addresses. Also, some CPU caches might prefer it. I don't know.

It doesn't affect how mining is done, though.

  All of the arrays already have a length that is divisible by 16, what's the need for the extra 16 chars?

Not quite. Notice how it gets those addresses. It declares an array, then manipulates the pointer to that array. There's no platform-independent way to ask the OS for an aligned section of memory. Instead, you have to ask for something slightly larger than what you want, and increment the pointer until it lands on the boundary that you want.

Side note: This is an off-by-one error. Really, the array only needs to be 15 bytes larger than normal. Probably not worth fixing.

  And why only try 0xffff nonces? Is this just an artificial limit put so that the hashing doesn't take forever?

It tries all nonce values. However, it returns from the function every 65536 iterations, so the parent function can check

that it's still mining on the top of the chain,
that it's still actually connected to the network,
that the transactions are not out of date, and
that the nonce is not going to wrap around.

Basically, all of the complicated logic is implemented in its caller, BitcoinMiner.

PS: That comment is wrong. It appears to describe ScanHash, but it's actually talking about this section of code within BitcoinMiner:

    // Check for stop or if block needs to be rebuilt
    boost::this_thread::interruption_point();
    if (vNodes.empty() && Params().NetworkID() != CChainParams::REGTEST)
        break;
    if (nBlockNonce >= 0xffff0000)
        break;
    if (mempool.GetTransactionsUpdated() != nTransactionsUpdatedLast && GetTime() - nStart > 60)
        break;
    if (pindexPrev != chainActive.Tip())
        break;

Somebody should probably move the comment.


Bitcoin JSON RPC not working on Remote IP i cannot get it to work firstly i was able to use bitcoind in my vps (locally) but when i added rpcbind and allowip to my bitcoin.conf i cannot even use bitcoin-cli its giving me this error:
error: Authorization failed: Incorrect rpcuser or rpcpassword
while I'm using the same exact user pass as in my config

curl is giving me empty response on port "8333" and connection refused on port 8332

here is my bitcoin.conf [stripped ip and user/pass]

(i was using this one before when it was working locally)

listen=1
server=1
rpcport=8332
prune=600
maxconnections=12
maxuploadtarget=20
rpcuser=XXXXX
rpcpassword=XXXXX
daemon=1
keypool=10000

now When I'm trying to get it to work on my remote server with this config

# Generated by https://jlopp.github.io/bitcoin-core-config-generator/

# This config should be placed in following path:
# ~/.bitcoin/bitcoin.conf
server=1
# [core]
# Maintain a full transaction index, used by the getrawtransaction rpc call.
# Run in the background as a daemon and accept commands.
daemon=1
# Reduce storage requirements by only storing most recent N MiB of block. This mode is incompatible with -txindex and -rescan. WARNING: Reverting this setting requires re-downloading the entire blockchain. (default: 0 = disable pruning blocks, 1 = allow manual pruning via RPC, greater than 550 = automatically prune blocks to stay under target size in MiB).
prune=600

# [rpc]
# Accept public REST requests.
rest=1
# Bind to given address to listen for JSON-RPC connections. This option is ignored unless -rpcallowip is also passed. Port is optional and overrides -rpcport. Use [host]:port notation for IPv6. This option can be specified multiple times. (default: 127.0.0.1 and ::1 i.e., localhost, or if -rpcallowip has been specified, 0.0.0.0 and :: i.e., all addresses)
rpcbind=~MY REMOTE VPS PUBLIC IP~
# Username and hashed password for JSON-RPC connections. The field <userpw> comes in the format: <USERNAME>:<SALT>$<HASH>. RPC clients connect using rpcuser=<USERNAME>/rpcpassword=<PASSWORD> arguments. You can generate this value with the ./share/rpcauth/rpcauth.py script in the Bitcoin Core repository. This option can be specified multiple times.
rpcuser=XXXXXXX
rpcpassword=XXXXXXXX
# Allow JSON-RPC connections from specified source. Valid for <ip> are a single IP (e.g. 1.2.3.4), a network/netmask (e.g. 1.2.3.4/255.255.255.0) or a network/CIDR (e.g. 1.2.3.4/24). This option can be specified multiple times.
rpcallowip=~MY HOST IP~
# Number of seconds after which an uncompleted RPC call will time out
rpcservertimeout=60

# [wallet]
# Legacy
addresstype=legacy
# Legacy
changetype=legacy
# Set key pool size to <n>. Recommended to use a large number for high volume non-HD wallets.
keypool=10000
# If paytxfee is not set, include enough fee so that transactions should confirm within <n> blocks
txconfirmtarget=3
# Broadcast transactions created by the wallet.
walletbroadcast=0
# Run a thread to flush wallet periodically.
flushwallet=0

# [Sections]
# Most options automatically apply to mainnet, testnet, and regtest networks.
# If you want to confine an option to just one network, you should add it in the relevant section.
# EXCEPTIONS: The options addnode, connect, port, bind, rpcport, rpcbind and wallet
# only apply to mainnet unless they appear in the appropriate section below.

maxconnections=12
maxuploadtarget=20

# Options only for mainnet
[main]

# Options only for testnet
[test]

# Options only for regtest
[regtest]

Try to allow RPC calls on particular IP or whitelist all IP's, for example:

rpcallowip=0.0.0.0/0

Plus try to check debug.log if the connection appeared on daemon it should report. If not, probably firewall issues on a system itself.


What is meant by transaction 'pinning'? What is meant by the term 'transaction pinning'?

Transaction pinning happens when:

I broadcast a transaction that signals opt-in RBF
the transaction does not get confirmed because the feerate is too low
someone else broadcasts a new (child) transaction spending one of the outputs of my transaction
I now can't bump the fee on the transaction unless I include a fee greater than that of the combined original transaction + the child transaction (BIP 125, rule 3).

If the child transaction in (3) is large (eg a commercial service sweeping up lots of transaction outputs), then the total fee that I'd need to pay for a valid RBF would be very large.

In this scenario, my original transaction has been 'pinned' by the child transaction.

Russell O'Connor has proposed changing the RBF policy rules to alleviate this problem.


Why is bitcoin written in C++? What made the core developers choose C++ as the main programming language for implementing bitcoin? Was this because of their personal preference? Or another reason?

The most important reason is that the original Satoshi codebase was written in C++. A system like Bitcoin has extremely strong requirements about consistency in behaviour: all nodes on the network must accept and reject the exact same blocks, or we risk a fork. The first choice to avoid bugs that risk introducing inconsistency is to not rewrite the code from scratch.

Although all programming languages have flaws, and C++ is no exception, there are various reasons that make it an appropriate choice. An easily-overlooked one is that it provides very tight control over memory usage. Many modern languages (especially those that rely on garbage collection) make it hard if not impossible to reason about tight bounds of memory usage. Since Bitcoin Core is a security-critical application that is directly exposed to the Internet, it is nontrivial to guarantee that there is no way to trigger it to allocate large amounts of memory, thrashing the machine's swap space, or worse, killing the process.

This is in addition to a good balance between high-level where desired but also many avenues for performance optimization. Performance may be more important than is immediately obvious, as the convergence of the network relies on quick validation and propagation of blocks. If blocks take too long to validate compared to their creation frequency, economic factors start to unfairly advantage larger/faster miners (see the Selfish Mining attack, for example). Under extreme conditions, if blocks would take ~minutes to validate, the network may fail to converge at all, as nodes simply don't hear about blocks in time anymore.


Lost my Bitcoin wallet and have only 11 out of 12 mnemonic seed phrase words. How can I get my Bitcoins? I am new to the whole Bitcoin thing, and I am having my first attempt almost going sour. I lost where I created my wallet. I have my Bitcoin address and only 11 of my mnemonic seed phrase words (of 12). I attempted using a word I thought was it and then recovered a wallet on bread wallet, but after sync in, it was still zero balance for hours. I contacted the support group and they told me that I had probably made a mistake.

What can I do?

If you are missing the first word and you know the rest of the 11 words, there are 2048 possible mnemonics but only ~128 of them are valid.
Using Python and this library you can print all the valid ones with this simple script:
from cryptotools.BTC.HD import check, WORDS

phrase = "{x} decrease enjoy credit fold prepare school midnight flower wrong false already"

for word in WORDS:
    mnemonic = phrase.format(x=word)
    if check(mnemonic):
        print(mnemonic)

The output is:
alcohol decrease enjoy credit fold prepare school midnight flower wrong false already
alien decrease enjoy credit fold prepare school midnight flower wrong false already
ancient decrease enjoy credit fold prepare school midnight flower wrong false already
animal decrease enjoy credit fold prepare school midnight flower wrong false already
apple decrease enjoy credit fold prepare school midnight flower wrong false already
baby decrease enjoy credit fold prepare school midnight flower wrong false already
bamboo decrease enjoy credit fold prepare school midnight flower wrong false already
become decrease enjoy credit fold prepare school midnight flower wrong false already
blanket decrease enjoy credit fold prepare school midnight flower wrong false already
body decrease enjoy credit fold prepare school midnight flower wrong false already
...

Then you can try them one by one to a wallet that support BIP39. Obviously change the last 11 words in my example with your words.
Good luck!


Effect of price increase on usage of Bitcoin I was just about to pay for something with Bitcoins today and I hesitated for an instant thinking that the price might be $10 more next week.

Is it possible that Bitcoin holders will be less likely to spend their Bitcoins on actual goods or services given the wild increase in prices? Or if the prices suddenly start to drop, will people be more likely to spend their Bitcoins?

Both inflation and deflation are bad for currencies, because they cause people to make decisions that don't really make sense.
Let me give you two examples. I sell toasters for bitcoin; you have bitcoin.

Inflation: You know that the price of toasters in bitcoins is going to go up, so you start buying toasters in bulk. You didn't really want all of these toasters, but at least your money isn't going to go down in value.
Looked at from your perspective, what you did makes complete sense; From a societal perspective though, nothing was gained through this transaction.

Deflation: You really want a toaster, but you know the value of bitcoin is going to double next week, so you hang on to your money. This sucks, because microwaving your bread just isn't the same.
Again, from your perspective, what you did makes complete sense. But from a societal perspective, it doesn't.

And that's how inflation and deflation - or even the threat of it - can damage an economy.


Buying stocks or bonds with bitcoin Is it possible to buy stocks online with bitcoin.. the stocks listed on  NYSE, NASDAQ and London Stock Exchange among others ?

Not that I'm aware of, in terms of dealing with traditional publicly-facing companies on the exchanges you mention. There were a number of attempts to create new, bitcoin-only exchanges for privately held companies, but few have gotten much traction. This reddit comment goes into great detail about the history of private stock exchanges in bitcoin, which might provide useful context:

https://www.reddit.com/r/Bitcoin/comments/3jh9t5/are_there_any_private_stock_exchanges_that_deal/cuphn6y

Edit: Also this previous SX Bitcoin thread might answer your question:
Can I buy stocks with Bitcoin?