rootstock current state currently i am leading a benchmark between the smartcontracts platforms, and i am exploring the Rootstock platform.

I think this project has a lack of documentation. My question is what is the current state of this project? I've learned they've launched the GINGER TESTNET recently.

is there any relevant post or documentation about this project and about its recent news. If there is a post explaining the deployment of a smartcontract on the testnet it will be very helpfull.

I've contacted the Rootstock they provided me the following link https://github.com/RSKsmart/rskj/wiki

which provide a wiki for :

Install RskJ and join the RSK Ginger Testnet

Compile and run a RSK node locally

Getting started with Smart Contracts development

Convert your Testnet Bitcoins to Ginger Smart Bitcoins and viceversa

Besides there is a blog listing all the news : http://media.rsk.co/


Usage of Markov chains to improve bitcoin mining Discrete Markov chains have been used to approximate the probability distributions in games of chance in order to improve odds and do predictions e.g. winning numbers in a lottery. As long as the lottery,card game etc. meets certain conditions this will work or else the probability distribution will drift rendering the prediction useless.

Competing to find a nonce during mining is kind of like a lottery. Therefore theoretically Markov chains could be used to improve bitcoin mining as long as it satisfies conditions for discrete Markov chains. Has anyone ever explored this?

Thanks, Andrew

A Markov chain is a mathematical model for a random process that has only short-term dependence on its history: if you know the current state of the system (or perhaps its recent history), any further historical information will not improve any predictions about its future.

This could be a useful model for analyzing a (flawed) lottery in which there is some dependence between today's number and tomorrow's; it could help you determine the nature of that dependence, and let you use today's number to make a prediction about tomorrow's number that would improve your chances of winning.

However, in a truly fair and random lottery, no such dependence should exist.  Each number should be chosen in a manner that is not biased or affected in any way by past numbers.  In such a case, a prediction based on a Markov chain would be no better than a random guess; and indeed, given enough data, Markov chain techniques would tend to confirm that there is no dependence.  (In the short term, such techniques might appear to detect some dependence, but this would be erroneous.)  So if the lottery is in fact fair, you can't improve your odds using a Markov chain analysis or any other method.

My understanding is that the cryptographic community believes, based on all current evidence, that the Bitcoin mining algorithm behaves like a fair lottery.  Of course, the output of the SHA256 hash function does in fact depend on its input data, but it is believed that there is no computationally feasible way  to describe or gain information about this dependence short of actually computing the function.  If so, then SHA256 outputs are effectively independent of their inputs, and past history of Bitcoin hashing gives you no useful information about the future; it does not help you improve your odds compared to trying nonces in sequence or at random.

If you, or anyone else, is able to "improve Bitcoin mining" via Markov chain techniques, or any other method, it would mean that SHA256 is seriously flawed and should be abandoned.  Fortunately, as far as I know, there is no evidence to suggest that this is the case.


Can someone help me find the private key for my bitcoin wallet? I have a Bitcoin Wallet on Blockchain and i have a imported wallet there where my bitcoin is stuck please help.

By design, it is not possible to determine the private key for arbitrary addresses.

If you do not have a wallet file, seed phrase, or other form of keys that lead to that address, no one can help you.

If someone asked you to transfer Bitcoin to a watch only address claiming it will be accessible by you, you have been scammed.


Does Electrum support Ledger Nano? When you create a new wallet, there are 4 options, one being 'hardware wallet'. However, there is no mention of hardware wallets in the docs!
http://docs.electrum.org/en/latest/search.html?q=hardware&check_keywords=yes&area=default

How do it work? Does it communicate to the hardware wallet with a special protocol?

Yes, it does. There's a detailed guide on the Ledger site, and a bunch of videos on youtube explaining how to use your Ledger with a Electrum.


OP_RETURN with bitcoind not working I have created a raw transaction with the following hexstring which decodes to:

{
   "lock_time":0,
   "size":248,
   "inputs":[
      {
         "prev_out":{
            "index":1,
            "hash":"2fb04bcfcc164fbb9d5ad740c891e2599d904920386ab4e7f39bc1c87431218e"
         },
         "script":"483045022100c727a635fbd5e689888e60a10c6ce45855abb7ceeb2235004d815edae2555abb022059839448cdd52733280b6fdde09ee87b06ba090357e50fea178d8fe41d811ba9012103f515b50b5e7693b4d8fe3d5d25346f989b42ab43f65a0106808f844deff55f08"
      }
   ],
   "version":1,
   "vin_sz":1,
   "hash":"096328dc269ea7a060eb1c16ce8629cf81a5cff5766eb3f2ec97d81344854327",
   "vout_sz":3,
   "out":[
      {
         "script_string":"OP_DUP OP_HASH160 98ac2448db3e1a08cce87052513280cb20bafbf5 OP_EQUALVERIFY OP_CHECKSIG",
         "address":"1EvFvmzhiFWhaRfvvZupxxQvTMHJ79GGdb",
         "value":1,
         "script":"76a91498ac2448db3e1a08cce87052513280cb20bafbf588ac"
      },
      {
         "script_string":"OP_DUP OP_HASH160 f3223f468b6b81b4104b5b880d23b246c9c76711 OP_EQUALVERIFY OP_CHECKSIG",
         "address":"1PAaE9hEh1RNpoGuSJ6fw6wajziLptJSVv",
         "value":99998,
         "script":"76a914f3223f468b6b81b4104b5b880d23b246c9c7671188ac"
      },
      {
         "script_string":"OP_RETURN 68656c6c6f20776f726c64",
         "value":0,
         "script":"6a0b68656c6c6f20776f726c64"
      }
   ]
}

When I enter the command

bitcoind sendrawtransaction <hex-string>

I get the following message:

error: {"code":-26,"message":"64: dust"}

Will this be anything to with standard transactions? I am currently using 0.9.3 branch of the bitcoin client.

The issue is this output:

  {
     "script_string":"OP_DUP OP_HASH160 98ac2448db3e1a08cce87052513280cb20bafbf5 OP_EQUALVERIFY OP_CHECKSIG",
     "address":"1EvFvmzhiFWhaRfvvZupxxQvTMHJ79GGdb",
     "value":1,
     "script":"76a91498ac2448db3e1a08cce87052513280cb20bafbf588ac"
  },

See the "value":1? That means that the output is worth 1 satoshi. It's worthless, because it would cost more to spend this than it's worth. See this answer for more.

To solve this, remove that output.


Multibit backup created partial transactions Here's what happened. I took backup of the following:

   savings.wallet
   savings.info
   savings-data (and all its contents)

Then I connected to internet, started my MultiBit. The wallet was open by default. There was a new deposit transaction.
I closed the wallet. Opened my backup wallet, to see if it can pick up the new transaction.
When I opened the backup wallet, it can recognize only until when backup was created. It doesn't recognize the new transaction when synced.

When I have two copies of the same wallet file, one recognizes the new transaction while the other sees all transaction except the new one.
Why would this happen?

Try Tools -> Reset Blockchain and Transactions in the backup wallet.


For every new block, does the miner need to read through all historical transactions? Let's say I am about to send bob 5 bitcoins, but in the past I've done 1 million individual transactions. When a miner is putting my most recent transaction into a block, do they have to go through all 1 million transactions in order to "mine" this new block?"

I just don't understand how the miner would know how much BTC I have at the moment before this new transaction. It's not explicitly stored anywhere right?

The super naive implementation would require the miner to go through the entire blockchain. However software developers are smarter than that. Each node instead maintains a chain status. This includes it's blockchain tip (the most recent valid block), the UTXO set, and the verification status of all previous blocks. When a new block is created, the node only needs to consult its internal chain status. Using the UTXO set, it can verify whether each transaction in a block is valid. It also knows the previous blocks validity, do it does not need to go back through the blockchain and reverify those blocks.

There can be further optimizations too. Since most transactions in the block would have been unconfirmed, the node is likely to have seen them before. When it receives an unconfirmed transaction, it will verify it too. So once it receives a block, it can just check whether a transaction was one it had seen and verified before and skip its verification if it has.


How long does it take to perform a single SHA256? I'm not talking about hashes/s, but specifically, the amount of time required to perform a single SHA256 on the fastest computers known. How long does a very fast ASIC take to perform one SHA2? Is this evolving as time passes, like the hashrate, or is that value more or less constant, and only the hash/s increases with time?

Simply head over to https://en.bitcoin.it/wiki/Non-specialized_hardware_comparison#CPUs.2FAPUs and look it up.

For AMD, the columns nprocs and Mhash/s are important. Divide the latter by the former, sort by that value, and you find that A10-5800K is the fastest with 26.25 Mhash/s/core.

ARM is obviously not relevant. (So much for mining on a raspi.)

For Intel, the first number in the column p/t or the first number times the number before the slash if there is multiplication and the column Mhash/s is relevant. If I didn't mess it up, it's the Core i7 3930k with 11.1 Mhash/s/core (almost twice as fast as the second place).

So your answer is that a sha256 hash takes 3.8*10^-8 s on the best-suited non-specialized CPU. What you want to do with this value is rather unclear, though. You might have to account for pipelining, instruction fetching, or even a memory access, as with all instructions.

The fastest miner is the AntMiner S9 with 14 Thash/s. ASICs do their work in parallel in a highly optimized way and computing a single sha256 hash is just not something they do, so it's not possible to state how long 1 sha256 hash takes them.

The hash rate of CPUs per core stays pretty much the same and therefore the time a single sha256 hash takes. Individual cores can't really get much faster so manufacturers integrate more cores into a single chip, increase the cache sizes, etc., to make CPUs better for tasks they're usually used for.

Note that every time I talked about a hash or a sha256 hash, I meant a sha256 of the amount of data a Bitcoin block header has. Obviously, sha256summing the downloaded English Wikipedia or an entire HDD takes a lot longer than this.


What prevents a malicious user creating a new transaction using signatures of an old mined transaction if the inputs have the exact same balance? I am NOT talking about double spending. I am talking about this type of scenario:

Let's say address A has 1 BTC balance initially. A valid transaction is created and for simplicity's sake, assume all the balance is transferred to address B in a valid manner.

Okay, now that transaction has been confirmed and A has also received another 1 BTC from some other random address.

Now, what prevents a malicious user, to rebroadcast the old transaction as the same conditions are being met. The input has the exact same balance, the old signature is telling to send the balance to B etc.

Obviously, this would mean it would be the same transaction ID and the network would reject it. So my question is, what is the variable in a transaction that allows you to prevent this type of attack? I can't find any documentation.

The transaction ID and output index of the second 1 BTC that was sent to A's address will be different from the first 1 BTC that was sent there. Since transactions refer to inputs by their txid and output index, the signature used in the first transaction will not be valid for another tx trying to spend the second deposit.

Additionally, depending on the type of Signature, it may also restrict that the output can only go to B's address.


Standard CLI tool to calculate a public key out of a private key Is there a standard, or at least well-accepted, CLI tool that calculates the public key out of a private key?

I've done my homework erading How do you get a Bitcoin Public Key from a Private Key, but it's from May 2014, and hopefully tooling has improved since then.

To the best of my knowledge there is no standard CLI utility.
However, there are some tools which seem to be generally accepted, like bitcoin-bash-tools

Alternatively, you can use some script library, such as pycoin (written in Python), or bitcoinjs.

Personally I like Bitcore libraries (Bitcore is not Bitcoin Core, despite their names are similar). They are also written in Javascript.
I wrote a simple library for handling keys/addresses that can be used from the command line with the NodeJS interpreter: https://github.com/frz-dev/btcutils/blob/master/bitcore-keys-utils.js. In your case you can use the getPubKey function, passing the private key object.

Hope this helps


How do wallets receive the amount of Bitcoins I've always wondered how wallet clients can receive the corresponding amount of Bitcoins so fast.

If I want to know how muc Bitcoins I own, I have to parse the complete the complete blockchain to read all incoming and outgoing transactions. The current size is over 170 GB, wouldn't it take minutes (if not hours) to get all the transactions?

But when I use a web wallet for example, the correct amount of Bitcoins is loaded instantly. How does this work?

Thank you

You don't have to parse the whole blockchain for every transaction, this is why database indexes exist.

You parse the blockchain once and create a unspent-transaction-output set (UTXO) which is a mapping between all unspent outputs and their balance. This is around 2.5GB in size and much-much faster to process.


Regtest: One node nullifying other node's balance I'm running 2 bitcoind servers on the same machine, called node0 and node1.
In the following I'm listing steps I take and results I get and I'm wondering what is causing one node nullifying other node's balance by block generation?

Started two independent (by independent configuration files) servers
node0 generates 101 blocks
node1 generates 101 blocks
each node has a balance of 50 BTC
connected them by adding one by the other node via "addnode "localhost:port" add"
version messages are exchanged
getconnectioncount returns "1" on behalf of each node
node0 generates 1 block
node0: getbalance: 100 BTC
node1: getbalance: 0 BTC

...trying to figure out what's happening...

node1 generates 1 block
node1: getbalance: 0 BTC
node0: getbalance 150 BTC
node1 generates 100 blocks
node1: getbalance: 50 BTC
node0: getbalance: 5100 BTC

I guess this problem has to do with an error I get after generation of blocks - see my corresponding question here.

Or is it because of the settled connection which causes a conflict on which blockchain to work on and thus abandonning one node's blockchain - in this case, abandonning node1's blockchain?

You only see the balance of blocks that have at least another 100 on top. This is because coinbase outputs only become spendable after 101 confirmations (the maturity period).

After the nodes reconnect, and one block is mined by node0, node1's previous chain is reorganized away, and from that point on, both nodes work on the same chain.

However, whenever a new block is mined, the balance of the node who mined the block 100 before that is increased.

It has nothing to do with the nBits bug. This is an actual bug in the software which is being fixed now, but it does not affect you.


Why hasn't bitcoin mining been scaled / wouldn't that ruin the concept? I'm just learning/getting started with bitcoin and one thing that's obvious straight away, is that the more computational power you can throw at it (with the cheapest energy possible), the more coins you can make.

Lots of people mining coins (myself included) just appear to be hobbyists - maybe with some nice equipment, but nonetheless, not 'industrial-scale'.

So why aren't there companies investing millions in solar panels and ACIS machines to mine bitcoins? Wouldn't someone that invested a few million (or more) in a setup like that monopolize bitcoin, in a manner of speaking? (Until people investing equally large amounts?). It'd raise the difficulty beyond what hobbyists could afford to make BTC profitable for them to mine.

Maybe millions isn't enough, what if someone spent BILLIONS doing this? Would it have the effect I suspect?

The Bitcoin network automatically adjusts "difficulty" to produce a block every 10 minutes on average. As the difficulty rises it takes many more hashing attempts to find a block, so no matter how many exaflops in the network (we are already over 1) the number of coins will still be around 3600 daily (until the reward halves again.)

The only advantage to scaling is if you can scale faster and cheaper than the other miners, and even they you will only see an earning advantage until the difficulty changes and/or the competition steps up and matches their increase.

Technical Explaination of the mechanism:
https://en.bitcoin.it/wiki/Difficulty

More detailed and descriptive link for newcomers:
http://coin.furuknap.net/understanding-bitcoin-mining-difficulty/


cgminer not working on deepbit.net I installed Cgminer and created the batch file to run it

cgminer.exe -o http://pit.deepbit.net:8332 -u myemail@gmail.com_workerName -p s3cr3t

but when I run it I get

[2013-05-21 00:39:34] Started cgminer 3.1.1
[2013-05-21 00:39:34] Probing for an alive pool
[2013-05-21 00:39:38] Pool 0 slow/down or URL or credentials invalid
[2013-05-21 00:40:34] No servers were found that could be used to get work from .
[2013-05-21 00:40:34] Please check the details from the list below of the servers you have input
[2013-05-21 00:40:34] Most likely you have input the wrong URL, forgotten to ad d a port, or have not set up workers

Does anyone know what I'm doing wrong?

I'm the author of this question and it worked when I tried again next day.


Is there a way to retrieve my LTC that did not go into my wallet? Last night I tried to send LTC from my Binance account to my desktop wallet. I found out later that my wallet doesn't accept LTC so the transfer is lost. Is there any way I can retrieve it? I have the transaction ID and Blockcypher ledger with all the inputs consumed and outputs created. Is there any way I can recover my funds using that info? Green Address wallet said they can't help me, and the response from Binance is generic and non helpful. Please help?

No it is lost.

Basically because the transaction is now in the LTC blockchain with a send to address that no one has the private key for.


Technical analysis of Blockchain.info security breach I the news I read this:

  The firm was forced to make a security disclosure on its blog and on
  Reddit, admitting that a development error had led to a problem with
  the generation of private keys. Private keys (effectively the private
  addresses used to hold bitcoin) were generated with a low degree of
  entropy, making them easy for attackers to retrieve.

Is there a detailed analysis available of what exactly happened or perhaps you could share your thoughts on this? I understand a concept of information entropy just want to know what should be done and what should be avoided to achieve a high degree of entropy.

I have not seen a thorough technical review. However, after reading about the issue, my understanding is that the issue related to reusing the same k nonce value for ECDSA, not in generating private keys.

Blockchain.info's blog post about the issue is here.

Blockchain.info's GitHub commit that fixed the issue is here.

The individual who noticed its effect on transactions is a forum user by the name of "johoe" and you can see the discussion that unfolded beginning with this post.

It is a known requirement for ECDSA that for each signature with a particular private key, a unique k value must be used, otherwise with even just two signatures of the same k the private key used in the signature can be recovered. This issue is described in depth here.

Here is an open source project that discovers vulnerable private keys on the blockchain. This slide show discusses the issue, the open source project, and some investigation into which wallets are susceptible (Blockchain.info is among the unsafe ones listed).

The solution for this has been known for a while: use RFC 6979.


What is the point of including the scriptCode of the input in the transaction digest of segwit? BIP143 specifies "a new transaction digest algorithm".

  scriptCode of the input (serialized as scripts inside CTxOuts)

What problems could arise if the scriptCode of the input were not included in the digest?

What problems could arise if the scriptCode of the input were not included in the digest?

Almost certainly nothing.

The reason for doing this is a very intentional design choice to limit the number of changes SegWit makes. Given that it has script versioning, it would be easy to introduce different sighashing schemes later if desired, we had the option of only making intended changes, as opposed to redesigning it from scratch. The intentional changes to the sighash algorithm are:

Use shared precomputed per-transaction hashes to avoid O(n^2)
Commit to amounts spent

So the hash structure remains the same, and contains all the same data. The sighash flags still have the same effect. The only thing that changes in BIP143 is that some data is now organized under precomputed hashes, and the input amounts go into it. Everything else is the same, which includes a commitment to the scriptCode - even though there is no good reason for that anymore.

EDIT: Do see Russell O'Connor's answer below for a minor use case.


Is there anything called anonymous or private bitcoins? Are there different types of bitcoins? Is there anything called private or anonymous bitcoin which can not be traced?

This question may sound stupid but I am facing this question right now. I have a client who wants to pay in bitcoins. However the kind of bitcoins he is talking about I have never heard of.

For verification he opened a separate wallet for me from a website called www.fifthelement.io (I never heard of it). Then he transferred a bitcoin and 0.001 in that wallet. Then I transferred that bitcoin back to his wallet for testing. However the confusing part is that I checked these wallets

[![enter image description here][1]][1]

on blockchain.info, it does show the wallets but doesn't show any transaction history which I assume means no record on the ledger.

I am posting the image of that wallet. I know very little about bitcoins so help in this matter will be highly appreciated.

Edit: This is almost certainly a scam - I'm looking at the source right now, and they have replaced the actual Bitcoin seeds with IPs, so it is likely a cloned network that tries to trick you into accepting worthless coins. It may also steal your keys, but I don't have evidence for that yet.

Within Bitcoin, there is no form of private transactions (in the form that you will not see it on Blockchain.info).

Moreover, the website you linked to is almost certainly a scam - The footer claims that it is built by the Bitcoin Core Developers, which seems unlikely (archive.org). You can find the actual wallet/node built by them directly on Github -https://github.com/bitcoin/bitcoin.

It seems likely that they have either:

Created an altcoin network, and are distributing their own wallet that connects to their network while branding it as a Bitcoin wallet. This would trick you into believing you have received Bitcoin as payment, while you have actually received worthless coins from a cloned network. This would also explain why blockchain.info is not showing the transaction.
Distributed a malicious wallet client that is able to steal your keys in some way (or provide you with keys that are already compromised), so that if you receive actual Bitcoin, they can take it from you.

If your client wishes to pay in BTC, there are many safe ways to accept it. You simply need to download an actual, reliable bitcoin wallet, such as from the link above, or Electrum, or buy a hardware wallet such as a ledger or trezor.

Then simply provide the client with an address from your trusted wallet - As long as you receive BTC with multiple confirmations, you can be sure that it is valid. When dealing with someone who is already attempting to scam you, make sure you check multiple sources before considering the payment completed, such as checking your transaction on multiple, independent explorers, in addition to what your wallet shows you.


blockchain.info says my tx is double spend. Which tx use the same utxo? My transaction is marked as double spend. I don't remember when I spent it twice. How can I see what transaction used the same utxo?

https://blockchain.info/ja/tx/60821723b93e2ae5ed729e93c22ca824e7e91fe5a16cba3468139657dc953abc

You can find doublespends by looking at the addresses that the inputs were previously associated with. At least one of the "send-addresses" will show another transaction that spends one of in the inputs that your transaction is also claiming.

In this case, this is particularly easy, as there is only one input, and therefore only one previous transaction output to consider.

When you look at blockchain.info's page for the address 12sWrxRY7E7Nhmuyjbz4TtGE9jRewGqEZD, you'll notice that there are two competing transactions trying to spend the input.

In regard to which of the transactions may be confirmed:
Obviously, only one of them can ever confirm. In this case, their fee rates are 7.5 and 8.95 satoshi/byte, so likely neither will confirm. In other cases, it depends on the transaction selection strategy of the miner. AFAIK, first-seen remains the standard policy, i.e. nodes and/or miners accept, relay, and confirm the transaction that was first seen and shun the other as a doublespend. However, especially in a time with fee events and crazy mempool sizes, I'd expect more and more pools to adopt a replace-by-fee policy where they would prioritize the transaction with the higher fee. Not only do miners earn more that way, and the transaction will be up for confirmation quicker, but this also gives people a better chance to update urgent transactions that didn't have a sufficient fee the first time around.

Since this is the obvious direction transaction selection will progress, let me use this opportunity to reiterate that unconfirmed transactions are a payment promise and not a reliable payment. Accepting zero-confirmation transactions is a bet which becomes less reasonable by the block.


Traveling abroad with my Ledger In the next months I’m going to travel abroad with my Ledger Nano S. I’ll visit most of the EU countries, Russia, China, Brazil, U.S. and Canada. I’m an EU citizen.

I would like to know which is my right to refuse to unlock my Ledger whether I’m intimated to do so by a custom officer.

As far as I know as an EU citizen in the EU I can refuse to unlock my devices without violating any law.

Wrong path.

Check the advanced passphrase options. Look for plausible deniability. Add a second wallet with a different PIN and SOME SMALL AMOUNTS. DO NOT rely on being able to refuse unlock unless you are willing to carry the consequences - which may mean spending hours arguing. Much easier to show them some small funds and be done.


Address change confusion I registered to a client with a Bitcoin address on Blockchain.info and after some time that address I registered with was changed. I need to pay a fee to the client. Will it reflect to them that even though the address they are receiving from is different but it is the same wallet?

No, they would not. In Bitcoin, wallet is an abstract concept as it is just a software that manages your private keys and addresses. The addresses generated from the private key in your wallet bear no resemblance to others. Unless you explicitly mention it to them that it is your address, there is no way of knowing whether it is you who has sent the bitcoins to your client. From their perspective it might be as they received a 'donation' of bitcoins from some random person.


Alternative to run Bitcoin over Tor I know running Bitcoin over Tor isn't a good idea: Bitcoin over Tor isn’t a good idea. My question is: there are any alternative to hide the IP to the network safely? Using a proxy, if you don't full control / trust it I guess a similar attack can be done. The IP reveals your geographical position. So, how to hide your geographic position and keep running a full node?

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

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

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


sending an order through BTC-e API incorrect field error I get the following message when trying to send a buy/sell order through btc-e api using a variable:
"you incorrectly entered one of the fields".

This is the line of code I use for sending an order:

APIMain.Trade(BtcePair.BtcUsd, TradeType.Sell, Math.Round(myAskP, 4), Math.Round(myAskQ, 4));

Sending an order via api does work when I enter it like this:

APIMain.Trade(BtcePair.BtcUsd, TradeType.Sell, 800m, 0.5m);

How do I force a decimal variable to be formatted like the line above?
Anybody experienced similar problems?

The exact problem you're facing regards the number of acceptable decimal digits in the rate field.

You're trying to submit an order on the BTC/USD pair, which happens to have a max decimal allotment of 3. Meaning, you can submit an order for example 800.123, but NOT 800.1234 Not all pairs are the same. LTC/USD can have 6 digits, most BTC based pairs can accept 5 digits.

To get a list of exact information regarding the individual pairs, use this public endpoint for a JSON object that gives you all the values:  https://btc-e.com/api/3/info

As far as I know, all pairs' amount fields can have a max of 8 decimals. You are rounding both the amount and rate to 4 digits. Fix the rate field and it should work.

Please keep in mind when I say "decimal places" I mean actual number of digits after the period in a number. Not the numerical type decimal that you are using. Using a double or float will work as well, provided they are rounded properly.


Error: Non-canonical DER signature when attempting to broadcast signed Segwit Transactions I'm trying to build a native Segwit transaction programmatically, however, whenever I attempt to broadcast the transaction, it returns this error:
non-mandatory-script-verify-flag (Non-canonical DER signature)
My raw, unsigned tx (testnet) is here:
0200000001fd45159c94d5dcf0804e7aba6e5862445a3c41fb5ec21184fe3a41a1a6dbb5b40000000000ffffffff02a351000000000000160014d1ca74222bb5a5c1b43fae117e811b2320a286a66500000000000000160014d1ca74222bb5a5c1b43fae117e811b2320a286a600000000

My signed tx here:
02000000000101fd45159c94d5dcf0804e7aba6e5862445a3c41fb5ec21184fe3a41a1a6dbb5b40000000000ffffffff02a351000000000000160014d1ca74222bb5a5c1b43fae117e811b2320a286a66500000000000000160014d1ca74222bb5a5c1b43fae117e811b2320a286a6024630440220465c93c725454f7bda3e3453ce09e99f7636560935be9377c3ae1138cfa0bb4702206f45290b2c06fc7e2298c6778fbccd1a805e34535247c49e098bc7229e74533421034ac1bb1bc5fd7a9b173f6a136a40e4be64841c77d7f66ead444e101e0134812700000000

Both decoded look okay to me, so I I think it it's either the sighash or signing of the sighash that's going wrong.
The sighash I get of the unsigned tx, for the only input is:
e54c499bfef6f5f0b12b819de82220aa7de532f9b72ae0f74638a647e147f884
This is created using:
https://docs.rs/bitcoin/0.25.1/bitcoin/util/bip143/struct.SigHashCache.html#method.signature_hash
using SigHashType::All passing the pubKeyScript and value (22,000)
and when signing the sighash I get:
30440220465c93c725454f7bda3e3453ce09e99f7636560935be9377c3ae1138cfa0bb4702206f45290b2c06fc7e2298c6778fbccd1a805e34535247c49e098bc7229e745334
I am completely stuck on what to try next. Any direction would be appreciated.

You're missing the sighash flag byte at the end of the signature.
"Signature" objects in Bitcoin Script consist of the actual DER-encoded ECDSA signature, plus the sighash type byte (in your case, 0x01 for SIGHASH_ALL).


Send bitcoin raw transaction to network via webserver? What is the best way to send a raw transaction via a webserver, what role does a RPC play in this? Is a bitcoin-RPC used to send/transmit a raw transaction to the bitcoin network? Can the process of signing/creating a raw transaction be done with a RPC too? Assuming I attempt to transmit a signed raw transaction via a webserver to the bitcoin network, what do I have to keep in mind?

If you have a local bitcoin node (i.e. bitcoind running on the webserver), you can use the RPC command sendrawtransaction in order to send a transaction through your node to the network. Alternatively you can use a third party transaction broadcasting service like those offered by blockchain.info and blockcypher.com. Lastly, you could attempt to speak the Bitcoin P2P protocol and send the transaction directly to nodes on the network.


Bitcoin core config explanation I'm just not understanding what does the following arguments do!

-dbcache : Set database cache size in megabytes (4 to 16384, default: 300)

  which database is that? and what may happen if the file size excessed
  16384 megabytes.

-par=N  Set the number of script verification threads (-2 to 16, 0 = auto, <0 = leave that many cores free, default: 0)

  What is script verifications threads? may this affect performance?

-pid= Specify pid file (default: bitcoind.pid)

  what is this for?

-bind=    Bind to given address and always listen on it. Use [host]:port notation for IPv6

  is this for RPC calls, so bitcoin core listens only to given IP address?

-discover   Discover own IP addresses (default: 1 when listening and no -externalip or -proxy)

  what do they mean?

-upgradewallet  Upgrade wallet to latest format on startup

  what is the wallet formats?

-rpcbind=<addr> Bind to given address to listen for JSON-RPC connections. Use [host]:port notation for IPv6. This option can be specified multiple times (default: bind to all interfaces)

  when we Bind to IP address, will the software listens to this IP address only?

-rpcthreads=<n> Set the number of threads to service RPC calls (default: 4)

  how many connections can a thread afford? and how the connections counted? is it per IP address or command?

-dbcache: bitcoin is doing heavy disk I/O, you can reduce disk I/Os with increasing this parameter and thus increase memory usage

-par: if your system is so slow, you can't use it anymore, limit the number of threads or CPU/cores that are used

-pid: this is usually the process ID on your unixoide system. if you start a single instance, there is nothing to play with...

-bind: if you have several network cards in your system, you can bind the process to one of the many IP addresses in your system

-discover: discover IP addresses in the network. Set to 1, else set to 0, e.g. if you are using connections over TOR.

-upgradewallet: - someone else please :-)

-rpcbind: if your system is multihomed, and you want to talk from several networks to your machine, you can tell the bitcoin daemon, to listen to only a specific address for remote procedure calls

-rpcthreads:

  how many connections can a thread afford?

good question, I don't know. Experts please. I was of the opinion, that one thread can handle one connection...

  and how the connections counted?

not sure what you mean by this - if you have 4 clients, that connect to your system, then you have 4 connections. Or 5... or 6 ... and you can have 4 different systems talk to your bitcoind.

  is it per IP address or command?

per IP address.

I know my answer is not 100%, so I am asking for additional help as well.


What happened to the bootstrap.dat provided by bitcoin.org? I could download a bootstrap.dat.torrent from  bitcoin.org before, but it is no longer available. Does bitcoin.org still maintain it?

Is there another source for downloading a bootstrap.dat? I am stuck with a 0.9.x version of BitcoinCore for testing purposes, and the bootstrap.dat would improve synchronization for me.

As user Bitcoin has already pointed out, using a bootstrap.dat is no longer recommended—you can see the release notes for the new faster-synchronization feature here.

As a result, the bootstrap.dat torrent links were removed from bitcoin.org after a short discussion.

The bootstrap.dat file is still available here on the bitcointalk.org forum, and jgarzik has indicated that he will continue to occasionally update it "for academic research and development purposes."

Another alternative is the version which has been maintained by Armory Technologies, available here. At the time of this writing, it is more up-to-date than jgarzik's bootstrap.dat, however it's not clear if it will receive any future updates.


Does any documentations with mathematical description of Bitcoin exist? Does any documentations with mathematical description of Bitcoin exist? Some documentations like YellowPaper in Ethereum?

Etherium Yellow paper, Wood
Bitcoin Whitepaper, Nakamoto
Mastering Bitcoin, Antonopoulos
The Fallacy of Selfish Mining in Bitcoin: A Mathematical Critique, Wright
Research Perspectives and Challenges for Bitcoin
and Cryptocurrencies, Bonneau et al

etc.


How does IBLT_diff reveal the transactions that needs to be retrieved? I understand IBLT (Invertible Bloom Lookup Tables) and as far as I know it is used to increase propagation speed by only sending the transactions to a full node that its missing instead of sending all transactions. In Gavin's specification it is mentioned that we do:

IBLT_diff = IBLT_new - IBLT_us

What I understand from this is that the full node checks and after comparing its IBLT with the miner's IBLT, the full node figures out which transactions are missing.
Then full node requests the transactions missing from the miner. Is this correct?
In the middle of the specification, it says that they are not using the full transaction hash and then it says that in order to prevent brute forcing it adds a salt to it. May I know why they are doing this and if so then how does full node know the transaction hash to request from if its truncated.

Then full node requests the transactions missing from the miner. Is this correct?

No. All transactions (including the missing ones) are already encoded into the IBLT (that the miner sent).

It's a little like a Sudoku puzzle. The miner sends you an empty sudoku with only the totals filled in. You throw in the transactions that you already know. And then you can work out all the remaining empty spots on your own.

And the main benefit is exactly to prevent having to ask the miner anything, because that adds round-trips around the internet and thus latency.

  not using the full transaction hash

Probably because the hashes are large and the chance of a hash collision is not very high and not really a problem if it happens once a year (that's a number I just made up). So to save some space and/or make the calculations faster.

  and then it says that in order to prevent brute forcing it adds a salt to it.

That's so an attacker can not generate 2 transactions on purpose that cause such a (trimmed) hash collision. If an attacker could do that, you would be unable to solve the Sudoku and you would be forced to get the transactions or block in a different manner (adding round trips and latency).

Note that there are other situations that would cause you to get stuck with an unsolved Sudoku. For example if you have just restarted your node, your mempool would be near empty so you don't have any transactions to start with.

Note that Rusty Russel also made a few blog posts on IBLT, those are more recent than Gavin's and might give you another perspective.


Do transactions including CHECKLOCKTIMEVERIFY get mined immediately? As I understand it, nLockTime prevents transactions from being included in a block, or even relayed. The problem is, if I pre-sign a transaction, and give it to someone, they have no guarantee that I won't invalidate that transaction by spending its inputs somewhere else before the nLockTime enables the transaction I gave them.

If I create a transaction with CHECKLOCKTIMEVERIFY, that gets mined immediately, right?

What is an example CLTV pair of transactions, including the one that sets the condition, and the one that spends it? It would be helpful to see example sequence numbers, transaction nLockTime, CLTV value, and block numbers for the two transactions.

The following question contains the relevant CLTV code:

Why is OP_CHECKLOCKTIMEVERIFY disabled by maximum sequence number?

Here's the OP_CHECKLOCKTIMEVERIFY BIP: https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki

Taking a stab at answering my own question.

Both the transaction using OP_CHECKLOCKTIMEVERIFY in its output script and the one spending OP_CHECKLOCKTIMEVERIFY can be mined immediately in most cases. The output script will probably be used in a P2SH (pay to script hash) so no one will even know that CLTV is even used--only the hash will be visible.

On to spending that CLTV output...

The goal of CLTV is to lock up funds until a certain time. For instance, I want to have a joint account with a business partner that requires two signatures to spend, but after a certain time the funds are spendable by just one signature (in case one of us disappears).

So I was expecting to see a comparison between the CLTV time and the current block time, but all I found was a comparison to nLockTime:

if (nLockTime > (int64_t)txTo->nLockTime)
        return false;

Traditionally, there's no reason to create a transaction with nLockTime set (non-zero) because that transaction would only be spendable in the future. In the case of a CLTV input past its expiration, I can spend it immediately:

Create a transaction that sources the CLTV output (that's already been in the block chain for some time).
Set the nLockTime to the current block time. We're basically using nLockTime to pass in the current block time.
Set the seq number to something other than the max. This handles a special case where max'd seq numbers allow transactions with nLockTimes set earlier than the current block time to be mined.
The transaction will pass verification because txTo->nLockTime > nLockTime (the CLTV time in the script).

Note that a transaction with OP_CHECKLOCKTIMEVERIFY in a scriptSig input may have nLockTime set to 0, because it's not using that code path in the script. Many protocols have logic like

  spendable with 2 signatures or just 1 signature after x date.

So 2 signature might be used rather than waiting for the date.

For instance: https://api.blockcypher.com/v1/btc/main/txs/7b8846797d9c43c7c89543dda13ad5f8742f0068c56c0fa884692a62fe81a79c?limit=50&includeHex=true has a script with OP_CHECKLOCKTIMEVERIFY, but its nLockTime is 0, and seq is max. (2^32 -1 ).

For reference: locktime and sequence specification: https://bitcoin.org/en/developer-guide#locktime-and-sequence-number


Monitor paper wallet balance without importing private key? I generated a paper wallet offline and running from fresh OS, and I'm not going to ever type that private key into a computer until it's time to spend the coins.

But I will send coins to this address as a 'piggy bank'

My question: can the Qt client be configured to track an address and update the available balance for an address, without the private key ever being entered?

Try using BlockChain.info - you can add a watch only address and then receive email or SMS alerts every time it does anything - so you don't even have to consciously keep an eye on it.

Edit: I apologise, I didn't see that you wanted to use QT for it. I don't know of any way to do this, so propose blockchain as an alternative.


Can there be more than one result of decoding a raw transaction? I was looking in rpcrawtransaction.cpp and came across the signrawtransaction rpc method. While reading through this method, I thought these lines seemed strange:

    vector<CTransaction> txVariants;
    while (!ssData.empty())
    {
        try {
            CTransaction tx;
            ssData >> tx;
            txVariants.push_back(tx);
        }
        catch (std::exception &e) {
            throw JSONRPCError(RPC_DESERIALIZATION_ERROR, "TX decode failed");
        }
    }

Why is a vector of transaction variants needed here? Could decoding a raw transaction ever have more than one solution?

Maybe this has something to do with unfinished transactions, specifically?

I noticed that sendrawtransaction doesn't have the same loop, but rather just has:

    CTransaction tx;

    // deserialize binary data stream
    try {
        ssData >> tx;
    }
    catch (std::exception &e) {
        throw JSONRPCError(RPC_DESERIALIZATION_ERROR, "TX decode failed");
    }

The below seems relevant, too. It happens near the end of signrawtransaction.

    // ... and merge in other signatures:
    BOOST_FOREACH(const CTransaction& txv, txVariants)
    {
        txin.scriptSig = CombineSignatures(prevPubKey, mergedTx, i, txin.scriptSig, txv.vin[i].scriptSig);
    }

Maybe this has something to do with multisig?

Could decoding a raw transaction ever have more than one solution?

Decoding raw transaction is just a human-readable representation of transaction data. So, the answer is "no" and "yes"

There is only one decoding for transaction.

But another client/version may add some other fields for json


Mining Pool Hub: how to understand if it is mining? I have just set up Mining Pool Hub, how can I understand if it is actually mining bitcoins (or other crypto-currencies)?

Because sometimes I see yellow alerts
PoolApi  AHashPool has failed
PoolApi NiceHash has failed

Also sometimes it appears "Status: Failed"

Could you explain, for beginner users, how to understand if the software is mining or not? And better, how to understand if the software it's mining at its best?

Right now this is what I see:

From your screenshot, I can see that you are using MultiPoolMiner. When you took the screenshot, MPM was busy running a few benchmarks in order to determine what algorithm is the best to mine with your hardware.

The Nicehash API probably failed due to the hack that they had in December 2017.

The software does not mine Bitcoin. It mines other currencies such as Ethereum, ZCash, Monero and a few others. In Mining Pool Hub, you have the option to setup auto exchange to a specific coin. Just log into MPH and look for "Auto Exchange" on the left hand side menu.

The simplest way to determine if the software is mining, is to have a look for another console window, and then scroll through that window to see if shares were submitted. You can also have a look in MPH at the "Balances" section in the left hand menu to see if you are getting balances in. For a more granular view, you can click on the currency in the balances view, that will take you to the currency pool, where you can view a dashboard with info.

How to understand if the software is mining at its best - it really comes down to how often you cash in and if you have the auto switch on. As the currencies fluctuate, you might get a less favorable exchange rate, so although you mined a coin that was most profitable a while ago, it might not be the case anymore. The best is to do your own research, and to monitor your miner. There are a few websites that can help you with crypto currency related info:

https://whattomine.com/

https://coinmarketcap.com/

You can also check on the Mining Pool Hub home page what currencies are more profitable.


How to track bitcoin transaction on PC I am still quite new to Bitcoin, and my question may be a little bit stupid. So I am wondering how can I track the transaction or the newest block on my computer. I know there are tons of websites showing the real-time information, so I guess my question is like is there any way I can type something on my terminal of the PC and shows the data on it? Something like constructed the dataset on my own.

how can I track the transaction or the newest block on my computer.

You can run a full-node Bitcoin client such as Bitcoin core. It will collect the full blockchain - it can take a long time (weeks) to download the full blockchain, but you should be able to examine early blocks and transactions without waiting.

In the case of Bitcoin Core, you can use the API to examine blocks (GetBlock etc) and transactions (GetTransaction etc).

  is there any way I can type something on my terminal of the PC and shows the data on it?

For example

./bitcoin-cli getblockcount

./bitcoin-cli -testnet getblockhash 240886

./bitcoin-cli getblock 00000000000000000d2347b601158f40c741dbd9353918903f057cedd82f49de 2


What are "confirmations"when selling Bitcoins? Bitcoin confirmation. When and how do I make a conformation of a sale. Do I receive a emaIl from you when I sell.

It depends where you are transacting with the bitcoins. If you are on a website like coinbase and selling or sending coins. You might get an email from them depending if you have notifications on. This is a 3rd party that holds your bitcoin and has setup email system for it. But if you have your own Bitcoin wallet that is not controlled by a 3rd party company, you won't be getting any emails as the "bitcoin blockchain" isn't a 3rd party company.


What is the state of the Wasabi wallet - when will it be ready for mainstream mass usage? The wasabi wallet https://twitter.com/wasabiwallet

Is still under development. Anyone here who can tell about the roadmap? Whats the status currently and when is expected to be ready for mass mainstream usage (when devs are comfortable to have rigorously tested it)?

And who is validating the transactions in the wasabi wallet ?  Is it a SPV concept or full node, or centralized, owned by wasabi company servers?

And is it a HD (hierarchical deterministic) wallet??

Thanks

Wasabi Wallet is usable right now.

"When will it be ready for mainstream use" is a question of opinion / service availability, and those are off-topic here. See the help centre for more info.

  And who is validating the transactions in the wasabi wallet ? Is it a SPV concept or full node, or centralized, owned by wasabi company servers?

The Wasabi server validates the blocks. It creates block filters out of them and sends them to the client. From those filters the client can figure out which blocks it is interested in and it downloads those blocks from the Bitcoin P2P network, one block from one peer over new Tor stream. Optionally one can use his own full node for block downloading, but the ultimate source of truth is still the Wasabi server.

  And is (Wasabi) a HD (hierarchical deterministic) wallet??

Yes


Can side chains or "pegged" chains negatively affect the security of Bitcoin? Regarding the concept of side chains or "pegged" chains which has been discussed since as early as 2011 and explored in this white paper, how can these negatively affect the security of Bitcoin?

Before answering that question, I think it's important to determine if these concepts are possible without any change to the Bitcoin protocol.  Assuming changes are required, would Bitcoin suffer from side chains?  If no changes are required then the Bitcoin protocol should be as solid as it ever was and, it would seem that it would benefit from the usage, support and attention that side chains bring.  Perhaps different implementations of side chains matter and it's important to look at examples.

This particular proposal only requires one change to Bitcoin: Simplified Payment Verification (SPV) proving.

SPV proving is required when you want to move Bitcoins from the sidechain to the mainchain. The idea is that rather than putting all of the rules to validate transactions on the other chain into the original Bitcoin client, Bitcoin clients would look at how much hashpower was used to secure the transaction. It's pretty clever, actually.

The sidechain proposal described in that paper glosses over the changes to make SPV proofs work:

  To use Bitcoin as the parent chain, an extension to script which can recognize and validate such SPV proofs would be required. At the very least, such proofs would need to be made compact enough to fit in a Bitcoin transaction. However, this is just a soft-forking change, without effect on transactions which do not use the new features.

It would be more than an extension to script. Script currently has no way of looping or signaling to other scripts, which you would need. I'm pretty sure this would require a hard-fork. (Could someone more familiar with Bitcoin's internals chime in here? Could adding looping/signalling be done without a hardfork?)

I think it would make a lot more sense to not track the UTXO's of the coins moved to the sidechain at all, and just keep a running total. Then, have a hardcoded validator for each sidechain.

One issue that I see is that I don't think there would be enough hashpower to secure the network from double spending; merged mining could probably fix that though.


What exactly happens to leaves when forming nodes? If you hash TXIDs with sha256 twice, you get the leaves of the merkle tree. As far as I understand the two outputs of the TXIDs are concatenated / paired. What does that mean? Are they added together?

Concatenation means the joining of the second sequence at the end of the first sequence. For example, with strings, the concatenation of "hello, " and "world" produces the string "hello, world".
For TXIDs, they are taken as a 32-byte array. The concatenation of the two TXIDs produces an array of 64 bytes, which then becomes the input for another round of double SHA256. The resulting hash becomes the parent hash of the two TXIDs in the Merkle tree.
Each pair of transactions is hashed in such way, and if the number of transactions is odd, the last TXID in the sequence is duplicated (concatenated with itself). The parent hashes are then recursively treated in the same way, concatenated pairwise, until a single hash remains, which is the Merkle root.


Is it possible to rename & move a MultiBit wallet I would like to reorganise a wallet I created with MultiBit. It seems to be composed of the XYZ.wallet file, plus a XYZ.info file and a XYZ-data folder. Can those be freely moved around into another directory? Can I rename the XYZ-part of these 3 items without causing MultiBit any problem?

Thanks for any advice and many greetings!

Yes, they can be. But you will want to close MultiBit first, and then when you open MultiBit again you will need to tell it where you moved your wallet using File->Open Wallet.


If two parties submit a conflicting transaction between each other, how does the network decide which one is correct? Let's say parties A and B both submit a transaction to the blockchain with a different version of what happened. Party A submits a transaction saying Party B gave him 3 BTC and Party B submits a transaction saying he gave Party A only 1 BTC. How does the network decide which one to put in the next block?

Don't you have to trust a third party? A wallet or some kind of transaction application? How does that work?

If two transactions spend the same coin (utxo) only one is allowed in each node's mempool. That may not be the tx that gets actually confirmed by a miner though and inserted into a block. In that case, the confirmed transaction "evicts" the double-spend from the mempool.

It is possible that two competing miners each mine different blocks at the same height with conflicting transactions. This is a split blockchain and a split network, but it's not a problem. Eventually one of these blockchain branches will be extended by an additional block. The chain with the most accumulated proof of work is the only one that matters, and the other branch (with the conflicting TX) will again be wiped out.

If you are running your own full node you don't need to trust any other source of truth. If you are a vendor accepting bitcoin, this is why "waiting six confirmations" is generally accepted as best practice.


SPV Bloom filter construction, are false positives taken from the blockchain or just due to matching with other addresses It is my understanding that the false positive addresses generated by an SPV bloom filter do not need to necessarily be on the blockchain (ie. be addresses that have been used already).
Is that a correct way of thinking about SPV bloom filters?

Bloom filters are probabilistic, each attempted match you make with it has a specific chance of being a false positive. The rate of false positives is determined by the construction of the filter (how wide it is and how many elements have been added to it). A transaction either probably matches, or certainly doesn't match a given bloom filter.

BIP37 does not include Bitcoin addresses in the filter matching system, instead for every transaction in the block a given filter is matched with the TXID, every output script, every input script, and every data element in the input script. If any element matches the transaction is sent to the client, false positive or not is up to the client to decide.

  It is my understanding that the false positive addresses generated by an SPV bloom filter do not need to necessarily be on the blockchain (ie. be addresses that have been used already).

BIP37 SPV filtering will only ever return either transactions from a block (including the merkle tree path to the block header), or transactions from their memory pool which match the given filter. False positives aren't created out of nowhere, they just happen to be other transactions which fit a criteria given by the client.

The intent was originally that clients would tune the level of false positive transactions to obscure their real intention from the peer they are talking to, but in practice this appears to be completely ineffective.


RPC calls to LND using curl? I have a bitcoind and LND server running. I can make RPC calls to bitcoind using curl, like this:

curl http://XXX:YYY@localhost:8332 -H 'content-type:text/plain;' --data-binary '{"jsonrpc":"1.0","id":"curltext","method":"getblockchaininfo","params":[]}'

However I can't find out how to make RPC calls to LND using curl.

My lnd.conf contains a [Bitcoind] section like this:

[Bitcoind]
bitcoind.rpchost=127.0.0.1:8332
bitcoind.rpcuser=XXX
bitcoind.rpcpass=YYY
bitcoind.zmqpubrawblock=127.0.0.1:28332
bitcoind.zmqpubrawtx=127.0.0.1:28333

However, what I'm struggling with is finding out or configuring how to actually connect to LND itself with RPC.

Can't find clear documentation about this. I figured out that apparently I need to use port 10009, but this doesn't work:

curl http://XXX:YYY@localhost:10009 -H 'content-type:text/plain;' --data-binary '{"jsonrpc":"1.0","id":"curltext","method":"getinfo","params":[]}'

(result is empty, no error, nothing)

I guessed perhaps I need to set a separate RPC username and password for LND, but I can't find out how or where, i.e. what the settings are in lnd.conf?

Also, do I have to add a config line to make sure the LND daemon is listening to RPC calls?

Also, do I have to add a config line to make sure the LND daemon is accepting RPC calls from specific IPs? (localhost in this case, or adding external IPs later)

The lnd.conf information you shared above is required for the LND instance to query your local bitcoind node (to detect or follow on-chain/mempool events), and does not represent the LND user interface.

LND has a REST API which you can query with curl:
https://api.lightning.community/rest/index.html#lnd-rest-api-reference

The REST interface listening port can be configured here:
https://github.com/lightningnetwork/lnd/blob/master/config.go

The LND documentation describes it in more detail, but you will need to generate valid macaroons for LND https calls.


Can a bitcoin bank solve the problem of intensive value fluctuation caused by hoarding? Let's assume a bank dealing in bitcoins is not any central of government bank that could control the money supply.

Instead, let's say there was a bank where the people would deposit money at some interest rate, and also the bank would give loans to the people at some interest rate.

The intention of the bank would be to keep the bitcoins in the circulation (by taking and giving benefits to the people with some interest rate) instead of hoarding, as we know hoarding may hurt the Bitcoin economy.

Or, suppose I deposit some BTC in HSBC bank (or some kind of reliable online bank), and HSBC will give the interest every month.

Saying people are hoarding bitcoins is out of focus: they are simply "not spending them" because there aren't enough ways to spend them.

Allowing loans wouldn't improve the situation, since there still wouldn't be many ways to spend those loaned bitcoins.

Finally, bitcoins already are a currency subject to deflation, and they are also (more or less) constantly gaining value against traditional currencies, so just holding them increases their value.

To sum it up, not a terribly good idea, and definitely not ground-breaking.


Multisignature Demographics Has there been any demographic analysis of multisignature operations?

If so, who's using them?  Is it true that multisignature operations are limited mostly to exchanges?

This article from coindesk may answer some of your questions although it is almost a year old now http://www.coindesk.com/year-multisig-so-far/

There's no information attached in multisig transactions to tell us what it is being used for so you can only guess. There are not any exchanges that uses multisig for any customer facing applications. There are however many online wallets, such as the one offered by Coinbase or Greenaddress , that uses multisig for better security.


Backing up an Electrum wallet I have just installed an Electrum wallet on my Ubuntu machine, and transferred some funds into it.  I wish to back up the wallet, so if my computer is dead or stolen, say, I will be able to install Electrum again and restore the wallet.

(In fact, it would be best to be able to restore the wallet from other software, not necessarily Electrum, if that's possible).

My wallet has a name (btc1) and a password. After opening it, in the wallet menu, I have the seed option grayed out. I am able to export private keys, however. If I understand correctly, the wallet itself is located in the file ~/.electrum/wallets/btc1. If I copy that file, say, to a different machine - then the wallet is also there?

I'm a bit confused about all of that.

There are 3 approaches to backup/restore your Electrum wallet with Bitcoin, depending on whether you use Electrum to manage a HD or non-HD wallet, you may or may not have a 'seed'.

If your wallet is a HD wallet, to restore/backup your wallet, simply use the 'seed' (12 words).

If your wallet is not HD, to restore/backup your wallet, simply restore/backup your wallet via private keys.

If you don't know/care whether your wallet is HD or not, simply backup (save a copy of) the whole Electrum wallet's data file to you USB drive and move it to another computer. You can use Electrum on other computers to open the data file.

I wrote this 3 Approaches to Backup Electrum for your reference with some screenshots in more details. Hope it helps.


Is there a point where bitcoin mining will not be profitable? A lot of news accounts are pointing out that bitcoin mining is getting more difficult over time, murch even said recently in chat its getting "exponentially harder". I am not sure if that is the case, but has anyone studied the economics and difficulty/hardness of bitcoin mining over spans of time? it appears clearly & by design to be subject to "diminishing marginal returns".

Is there a forecast when bitcoin mining will reach "break-even" level & be exactly as expensive as the hardware/energy required to mine it?

I am looking for quantitative/scientific analysis where possible. By the way, its a completely separate question of whether this would mean that bitcoin is no longer usable as a currency. (To me that is very likely not the case.)

It's already here. At present, you're simply not going to be able to mine Bitcoin with consumer grade hardware. Even with ASICs, you're still looking at returns that would have been laughable just a year ago. You're better off mining something like Mint or Aurora, or Doge, and turning them in for Bitcoins. Just my 2400 satoshis.


Does Bitcoin-QT use more CPU when its idle than during synchronization? I am running the standard client on a micro Amazon EC2 instance. When I am synchronising Bitcoin with the network, it uses about 50% of the available CPU. After it is fully synchronised, I leave it alone and it cranks up to 100% by itself.

What can be causing the standard client to behave in this manner? Is it due to possibly high transaction volume, sharing information with peers, or perhaps something else?

No, according to the information on small and micro instances at this link.
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts_micro_instances.html
Bitcoin.conf ( the Bitcoin Configuration file ) may have an option set to 1 to activate mining within the client software.  If you have it set as ' gen=1 ' it will try and ' generate ' coins ( mine on it's own ) and that drives CPU usage up.  Also, according to the graphs on that link, it should not ' jump ' to 100 percent use, each instance should drop down to a low usage level for small and micro Amazon EC2 instances.  There may be other programs running on your Amazon EC2 instance that can also drive up CPU usage so I recommend checking your files starting with looking for any instance of Minerd ( cpu miner ) and removing it.


How does a Bitcoin block get generated and 'agreed upon' by everyone? When a set of new transactions is broadcast to all the Bitcoin mining pools, my understanding is that they all start working on a new block to include all those transactions.  But how is it agreed upon which block is the next one to be included in the Bitcoin blockchain?  Is it just the first mining pool to generate the block?  And if that's the case, isn't it going to be tremendously wasteful if all but one mining pool have been working on generating a new block but all that work is wasted because their block wasn't chosen to be the next one in the chain?

Miner ASICs have one job: Change the meaningless parts of the block until the difficulty target (related to the hash of the block) is satisfied.
ASICs connect to the pool to first download the block template (they regularly do that - maybe every few seconds?). The block template contains the transactions. They calculate the merkle hash of the transactions, embed it in the block header, and hash the block header many times.
When the target is satisfied, the block is published. From then on, no one can change the transactions in the block.

all that work is wasted

This is a lottery where everyone's chances of finding the next block is proportional to their hashrates. If you need to mine all day to find one block per day -- congratulations! You can afford solo mining and you don't lose anything, and your reward is fair.
Trivia: Block mining is a Poisson process. One property of this is memory-less-ness. That is, given that the average time until the next block is 10 minutes (it is for Bitcoin):

After about how many blocks will someone find a block if everyone started just now: 10 minutes (t = 10)
What if you all had been mining for 2 minutes? Still 10 minutes (block to be released at t = 12)
What if you all had been mining for 20 minutes? Still 10 minutes (block to be released at t = 30)

Here's a fun puzzle by Russel O'Connor and Pieter Wuille.
So, there is no wasting in mining: it's memoryless. If you fail, you just keep trying, and everything works as intended in the end.


Is there any argument to be passed to CGMiner\AntMiner S2 to reserve amounts of hashing power for specific workloads? I have an AntMiner S2 (1TH/s) and I'd like to mine both on BTC and NMC.
Would that be possible, for instance, to use 50% of power just for BTC workloads and the other 50% for NMC?
EDIT:
What exactly is the Intensity parameter?

ckolivas says:
Intensity is the amount of work in one go the GPU has to do before it can return its results.

But I'm still confused: what is it in practice?

It seems like the easiest way to achieve this would just be, e.g., to mine BTC at full speed for 12 hours hours, then stop it and mine NMC for 12 hours. A simple cron job or something similar could accomplish this.


Reuse of payment hash in Lightning Network Suppose there exist two such payment transfer request: A transfers 1 msat to R via A->B->C->R and S transfers 5 msat to R via S->B->C->R. Let the two HTLCs be formed across both the paths simultaneously and let both the payment use the same payment hash say H. Now channels B-C and CR has two HTLC using the same payment hash. As mentioned in https://github.com/lightningnetwork/lightning-rfc/blob/master/04-onion-routing.md#failure-messages it is stated that "An intermediate hop MUST NOT, but the final node: if the payment hash has already been paid: MAY treat the payment hash as unknown or MAY succeed in accepting the HTLC." It seems that R can release the preimage of H and settle both the payment if R has received both the HTLC request at the same time. However, is it so that R will settle one payment and fail the other so as not to encourage the reuse of hash?

R cannot fail the payment once they have released the preimage. The commitment transactions which were agreed before R released the preimage contain a condition where the payment_hash is embedded in the script. By providing the preimage as part of the witness to this script, each party can claim the amounts due to them without cooperating with the other party.

In the case of C forwarding a payment from B to R, C will agree their commitment transaction with B before they negotiate their commitment transaction with R, and so forth.

The commitment transactions are only invalidated when a new state is agreed where the relevant HTLCs have been removed, which no party will agree to unless they have received the corresponding preimage or had the HTLC removed by the party they are forwarding payment to.

R doesn't need to try and invalide a transaction to not encourage reuse of a payment_hash, because R creates the payment_hash to begin with. If he uses a proper DPRNG, the chance of two payment_hash colliding are unimaginably small.

Intermediate nodes are not required to keep track of the preimages which have previously been used, and it would be unreasonable to expect them to. Most of the time, they will just forward the payment because they have nothing to lose by doing so - the party who sends them the money commits to the funds before this intermediate party commits to forwarding them.

It is possible that a node keeping track of previously used preimages could steal funds if they see one reused. They could use their knowledge of the preimage to remove a HTLC and receive the money from the sender, but not forward anything on to the remaining nodes in the path.

If a node such as B or C does keep track of previous preimages, and R fails a second payment using the same payment_hash, then B or C could decide not to forward this failure on to the sender of funds, and instead claim the money by fulfilling the HTLC or broadcasting the commitment transaction agreed with the sender.


By byte size and number of inputs/outputs, what are the largest transactions in the block chain so far? Disregarding value, but instead going by size in the protocol, what are the largest transactions so far in the history of Bitcoin, in terms of:

byte size
number of inputs ("vin")
number of outputs ("vout")
total number of inputs and outputs

The largest single transaction to date is 465,554 bytes.  It's hash is 659135664894e50040830edb516a76f704fd2be409ecd8d1ea9916c002ab28a2.
The same transaction has the largest number of inputs: 2,585.
Two transactions tie for the largest number of outputs: 623463a2a8a949e0590ffe6b2fd3e4e1028b2b99c747e82e899da4485eb0b6be and 5143cf232576ae53e8991ca389334563f14ea7a7c507a3e081fbef2538c84f6e both have 3,075 outputs
The same two transactions have the largest number of inputs plus outputs, although they only have a single input so the total is 3,076 inputs plus outputs.

Note, however, that the blockchain has been used to store information by manipulating output addresses so it is more than likely that the transactions listed in 3) are not "real", in that they do not contain spendable outputs.


Why are the drops in mempool unconfirmed transaction count not of constant height? I was just browsing the following mempool visualization and couldn't come up with a good explanation why the drops in unconfirmed transaction count are not of pretty much constant height but vary wildly.
My assumption is that every drop represents a newly mined block. Why are there apparently some blocks which contain very few or almost no transactions while others in contrast contain a relatively large number of transactions?
My only theory that miners are just too stupid to include all the available maximum fee transactions up to the maximum block size they can find seems .. too stupid to be true.
Please explain! Thanks :)

A transaction is not a fixed size. Removing one large one will have no impact on the count, but removing ten thousand small ones will.


Convert EC PRIVATE KEY from .pem into WIF I have a openssl generated private key in the following form:

$ cat priv.pem
-----BEGIN EC PARAMETERS-----
BgUrgQQACg==
-----END EC PARAMETERS-----
-----BEGIN EC PRIVATE KEY-----
MHQCAQEEIDTijUe0yc3orw5+hElM2WZPWWawO6yTymJZagaStSxIoAcGBSuBBAAK
oUQDQgAE81+mTl3Pyzy41kCg8xgnV3lokrYJ/iUAGda0JUpx99aExBk1kD9Heera
5ndWARwUTa6T1Cfi7c1U6Nf81IEAQQ==
-----END EC PRIVATE KEY-----

How can i convert this (preferably using bash/Perl/python) into a WIF that can be imported into (preferably) Electrum? Also Electrum confuses me a bit, it says

WIF keys are typed in Electrum, based on script type.

A few examples:
p2pkh:KxZ...->
1Dck

What does this mean? Wallet import format does not say anything about typing

How can i convert this (preferably using bash/Perl/python) into a WIF that can be imported into (preferably) Electrum?

OpenSSL .pem files contain base-64 encoding of the values encoded using DER. In case of private keys they use PKCS#8 explained in RFC5208. To extract the key itself, you first have to decode the base-64 string and get the key out by reading the DER encoding (the posted example is missing 1 byte since the sequence length is 0x74 but the remaining bytes that come after it is 0x73 bytes). If you want to use OpenSSL itself, try using this command:

openssl pkey -in priv.pem -out priv.key

This should give you the key bytes. Now you have to convert them to WIF (base-58 with checksum). Use your favorite bitcoin library (I don't have any python suggestion but there are many you could find on GitHub) that has byte-to-Wif functions.

  What does this mean? Wallet import format does not say anything about typing

Your one private key gives you one public key that could be used in both compressed and uncompressed form in many different output scripts which then you will see as a different type of address (P2PKH script -> address starting with 1; P2WPKH script -> address starting with bc1; ...). So when the private key is imported in a wallet, the wallet either has to look for all the output script types (like what Bitcoin-Core does) or ask the user to explicitly include the script type (which is what Electrum does).
In other words when you import a private key in Electrum with p2pkh:<key> the wallet only checks the address starting with 1 (legacy or base58) and when import it with p2wpkh:<key> it only checks the address starting with bc1 (native SegWit or bech32) and so on.

As a side note, there is BIP-0178 that proposed extending WIFs to address this and also Electrum briefly used a different way similar to this BIP but stopped because of incompatibility with other clients.


Bitcoin sent to a defunct address - what happens to it? I got the address for my account on a site and wrote it down. As I had had a huge hassle buying my bitcoin that morning due to problems with the vendor's site (and which they denied was at their end for 3 or more hours, nearly drove me spare) I was flusterred quite badly.

Anyway, for some reason that is still not apparent to me I clicked on a button saying "generate new account". However, as the site kicked me out due to poor connectivity and it flagged me that "your request could not be processed", I sent the bitcoin off to the address I had written down.

Some hours later I went to the site to check my balance...my funds were not there. There was A NEW ADDRESS for sending bitcoin to in my account details.

So, it would appear that I have sent my bitcoin to a valid address that is now redundant.

What will happen to my bitcoins? Will they bounce around for a few days before coming back or will they just disappear into the ether?

If the address is valid then the bitcoins will stay there until spent.  If you don't have the private key for that address they are now unspendable.

However, in general Bitcoin uses addresses in a different way to that which might be considered immediately obvious.  An address is generally considered a single-use item and as such it is entirely possible that your wallet contains the private key for the address to which you sent these coins, as well as any other addresses which you might have created.  Take a look at your wallet to see if it is present.


Bitcoin Wallet Creation I'm new to this Bitcoin and everything seems confusing to me.

I have a requirement where I need to create wallets for every user in my application screen. So, he will transfer some Bitcoins from his personal account to the newly created account and then purchase the items present in my application.

Now, I have come across a website blockchain.info where we can create wallets by using their API.

For using that API, we need to run a local service and use the API.

My question is, if blockchain.info goes down, then do all my accounts go down?
Or, it doesn't matter if blockchain.info goes down, because the accounts are created on Main Net of Bitcoin?

Can someone, explain me this?

You would be using blockchain.info's wallet. If they were to stop providing their wallet service, you may not be able to access your Bitcoin at all (depends on your backup situation) although the Bitcoin is still present on the blockchain.

If you have proper backups of your blockchain.info wallet (you have the mnemonic for your wallet), then you can restore it to another wallet software and be able to access your Bitcoin from there.


Why use DER encoding for signatures? A signature in secp256k1 is two 32 byte numbers. DER encoding a signature adds about 6-7 bytes.  It also needlessly complicates things (is DER encoding used anywhere else?).  In a transaction format that seems to try to squeeze every byte out, this is very strange to me.  Why not just use a 64 byte string to represent sigs instead?

My guess is that Satoshi did not know about the internals of ECDSA signatures, and simply used what OpenSSL gave him.

If it didn't require a hard forking change (requiring every wallet and verifying node on the network to upgrade), we'd have changed it long ago.


Electrum TESTNET public key I'm running Electrum in test mode (electrum --testnet) and have therefore created a new wallet for it. I've also successfully received some coins via Faucet. But when checking the public key for the wallet, it starts with xpub, which doesn't make sense as according to this site it should start with tpub. How can I get the right public key, as I need it for some online service (mycelium GEAR) and it's complaining that this is a key for MAINNET.

This looks like a bug in Electrum's software.

What you can do is manually convert the encoding to match Testnet's encoding.

Go to http://lenschulwitz.com/base58 and enter the master public key into the Base58 Decoder
Take the hex and change the first four bytes (first 8 characters) to match the testnet prefix: 043587CF.
Remove the last 4 bytes (last 8 characters) from the hex string.
Copy the modified hex and go to http://www.fileformat.info/tool/hash.htm. Enter the copied hex string into the Hex String field under Binary Hash and click Hash.
Scroll down and copy the SHA256 hash. Enter that copied hash into the Hex String field under Binary Hash and click Hash.
Scroll down and copy the first four bytes (first 8 characters) of the SHA256 hash.
Append the four copied bytes onto the end of the modified hex string from earlier.
Enter the full modified hex string (with changed prefix and changed suffix) into the Base58 encoder on http://lenschulwitz.com/base58 and Encode it. The result will be a tpub which is valid.


old wallet.dat with only incoming tx from mining, now shows 0 coins even after rescan and all the transactions are there I found an old wallet.dat it contained hundreds of transactions while i was mining.

I've replaced the wallet.dat in a new Bitcoin Core wallet, rescanned, all the txid are showing but the amount of bitcoin stored there is not! It now shows 0 coins

I know i never sent them out + all the tx are inputs nothing is out, so far i tried rescan.

any idea how can i extract for example a master privat key for the entire wallet, and import it somewhere ?

If you found an old wallet (prior to Core 0.13 which was released in August 2016), it wasn't using BIP32 HD. So there is very very likely no master private key,... instead, there are a large number of private keys.

You can use dumpwallet <filename> in the GUI console or via RPC to extract your private keys to a text file and import them into a different application.

But if you see transactions in Bitcoin Core and your balance is zero, this mostly means that there must be one or multiple spending transactions that have spent your mined bitcoins.


How to create an new account on a bitcoind server What is the correct rpc call to start a new account on a bitcoind server?

You can do one of the following:

create an address using getnewaddress
send some coins with a move command

Those commands will automatically create the target account if it doesn't exist.


US Taxable Events for using Bitcoin for purchases Is there any initiative to try to deal with the way Bitcoin is taxed in the United States with respect to using Bitcoin to pay for things without triggering a taxable event? Possibly a threshold being set for purchases below a certain amount?

HR 3708, which was introduced in the House of Representatives in September 2017, would do exactly that, with a threshold of $600 (to be adjusted for inflation).  It has five cosponsors.

It was referred to the Committee on Ways and Means, and there is no record of further action, so apparently the Committee decided not to move forward with it.


How to determine estimated block or transaction time I would like to know if there is any possible way to determine the estimated block time for a special cryptocurrency at the present time so I can estimate the transaction time it takes to send coins from one to another wallet.

Any help in this matter?

The target block time is usually hard coded. Block time is a function of the current difficulty and the current network hash rate. In Bitcoin, the target hash rate is ten minutes and the difficulty is regularly adjusted to maintain this block time on average.

Whether or not a particular transaction will be included in a particular block is speculative since it is up to miners to include the transaction, however, it is generally considered that transactions with relatively higher fees are more likely to be included.


I have set blockgeneration time to 15 second but blocks are generated with the speed of 1 block per min(avg) I have forked Litcoin 0.8v to make my own costomized coin(learning purpose), with some changes in parameters:

1. Total no of coins to be mined = 270,000,000.
2. Block formation time = 15sec.
3. Time for halving = 2 years.
4. Life span for mining = 20 years.
5. Mining reward coins per block for first 2 years = 32.16899445.
6. Total no of coins to be mined in first 2 years = 135264187.8669276

Every thing is working ok but blockgeneration time seems to be too slow. Though conformation time of 15 sec is just an avg value but in my case i am getting conformation in every 2 to 3 min which is far beyond expected

Edit:I have set my difficulty to be as low as possible which is around 0.002 and retargeting time is set to  10 min, but even after of 3 days of minning i got somewhere around 3400 blocks,and also its difficulty is same in every block though i am doing number of transaction within nodes.

{
    "version" : 80705,
    "protocolversion" : 70002,
    "walletversion" : 60000,
    "balance" : 17474.98800000,
    "blocks" : 3407,
    "timeoffset" : 0,
    "connections" : 2,
    "proxy" : "",
    "difficulty" : 0.00024414,
    "testnet" : false,
    "keypoololdest" : 1516853983,
    "keypoolsize" : 102,
    "paytxfee" : 0.00000000,
    "mininput" : 0.00001000,
    "errors" : ""
}

Changing just the target block generation time does not mean that the average block interval will be that time. The block interval is governed by the Proof of Work target, and there is a limit to what that target can be. If you do not increase that target's limit, then the target will not be able to increase to the point where your blocks are being mined at the rate you want them to be mined at. You need to increase your target limit (it can be found in chainparams.cpp and is called powLimit) so that blocks can be found more quickly.


real time number of transactions world wide https://blockchain.info/unconfirmed-transactions?format=json

I have been given an api key, I would like to call the above url every second to count the number of tx in real-time.

I don't think that this though is the best way to do this as the data might be delayed by the response time and I don't like the idea of calling them that often (I would count that as sort-of abuse of service, though I don't know for sure). Also in a call I would have to filter out any tx with the same id that may have been listed in the previous call.

I would prefer to get a list showing all unconfirmed, and to not miss any at all, to see them as they happen.

I was looking at the bitcoind rpc call 'listtransactions'. I think that this would let me count quicker but, I would like to know if there is a way/api that will push me the world wide unconfirmed tx as they happen (so that I am always 100% accurate to count the real time number of transactions world wide).

Note: I only need to count the precise 'number of'.

You would have to monitor the block chain yourself, like you say I think it would count as abuse if you poll blockchain.info every single second of every day. The block chain is just a database so if you have programming skills or are willing to pay someone with the skills it wouldn't be too difficult.

There are probably tools out there already that could do this such as libbitcoin, bitcoinj, etc. I'm not sure. You could even modify the official bitcoind client to log every transaction it receives to a database/textfile/whatever.

FYI the listtransactions RPC call will only list your own transactions, not everybodys.


Using importmulti with internal set to true does not add any change keys. What am I doing wrong? First I call:

curl --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "createwallet", "params":["ColdWallet", true] }' -H 'content-type: text/plain;' http://user:password@127.0.0.1:18332/

Which returns:

result = {
    name = ColdWallet;
    warning = "";
}

I then import keys to the keypool:

bitcoin-cli getdescriptorinfo "wpkh(tpubDFLL8VNUhpLNVLw8179WCEuMZtKtTDd7EeYeFDtThzisj6wfJ4Zi43qUvCE7ciCFxVKZYssRr9P9PerLefkVEjKL6CphUvbGv1CrSCS2KUB/*)"

responseString = {

  "descriptor": "wpkh(tpubDFLL8VNUhpLNVLw8179WCEuMZtKtTDd7EeYeFDtThzisj6wfJ4Zi43qUvCE7ciCFxVKZYssRr9P9PerLefkVEjKL6CphUvbGv1CrSCS2KUB/*)#udrnh6f5",
  "isrange": true,
  "issolvable": true,
  "hasprivatekeys": false

}

bitcoin-cli -rpcwallet=ColdWallet importmulti '[{ "desc": "wpkh(tpubDFLL8VNUhpLNVLw8179WCEuMZtKtTDd7EeYeFDtThzisj6wfJ4Zi43qUvCE7ciCFxVKZYssRr9P9PerLefkVEjKL6CphUvbGv1CrSCS2KUB/*)#udrnh6f5", "timestamp": "now", "range": [0, 99], "watchonly": true, "label": "Fully Noded Cold Storage", "keypool": true, "internal": false, "rescan": false }]'

result = (
        {
        success = 1;
    }
)

I then set keypool to false and internal to true:

bitcoin-cli -rpcwallet=ColdWallet importmulti '[{ "desc": "wpkh(tpubDFLL8VNUhpLNVLw8179WCEuMZtKtTDd7EeYeFDtThzisj6wfJ4Zi43qUvCE7ciCFxVKZYssRr9P9PerLefkVEjKL6CphUvbGv1CrSCS2KUB/*)#udrnh6f5", "timestamp": "now", "range": [100, 199], "watchonly": true, "keypool": false, "internal": true, "rescan": false }]'

result = (
        {
        success = 1;
    }
)

I can use getnewaddress -rpcwallet=ColdWallet without issue but if I try:

curl --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "walletcreatefundedpsbt", "params":[[],[{"mxV3ojsAHKuYHoDVqYczs6iPAfCCYESEDc":0.0001}]] }' -H 'content-type: text/plain;' http://user:password@127.0.0.1:18332/wallet/ColdWallet

result = {

    error =     {
        code = "-4";
        message = "Can't generate a change-address key. No keys in the internal keypool and can't generate any keys.";
    };
    id = curltest;
    result = "<null>";

}

Furthermore calling bitcoin-cli rpcwallet=ColdWallet getwalletinfo

returns:

{
  "walletname": "ColdWallet",
  "walletversion": 169900,
  "balance": 0.00000000,
  "unconfirmed_balance": 0.00000000,
  "immature_balance": 0.00000000,
  "txcount": 1,
  "keypoololdest": 1561077339,
  "keypoolsize": 98,
  "keypoolsize_hd_internal": 0,
  "paytxfee": 0.00000000,
  "private_keys_enabled": false
}

Is this a bug? Or am I doing something wrong?

I am using Bitcoin Core as a back end for an app I am developing and want the user to easily be able to create cold transactions using the keys they import into the wallet without having to specify a change address every time.

I then set keypool to false and internal to true:

This is what you are doing wrong.

Bitcoin Core has a separate change keypool. By not setting keypool to true, the imported pubkeys won't be added to the change keypool.


How do miners decide when to give up on a block? So in my understanding, miners bundle a list of transactions into a block and begin working on it until they can generate a valid proof of work. There are various reasons to group fewer or more transactions together into a block, but it's ultimately up to the miner.
I'm assuming that different miners may group the same transaction into different blocks and begin working on them. One miner might group transaction A into a block of 100 transactions and start working while another miner might group transaction A into a different block of 250 transactions and also start working.
When one miner finds a valid proof of work and broadcasts the new block, do all the other miners who included even a single transaction from the valid block in their own block have to drop what they're doing and start over?
Is there some system in place to ensure that most miners are working on blocks with the exact same set of transactions except for the miner's reward transaction?

You're right, miners can freely choose among the unconfirmed transactions when they're building their block template. However, miners are optimizing for revenue, so they'll be mostly selecting transactions in order of descending feerate.
Since transactions propagate quickly on the network, most miners will have a largely overlapping view of the queue, and their block templates should be almost the same.
Since each block commits to a specific predecessor, the best chain can only have one block at each height. Mining is progress-free in that each hash independently has a (tiny) chance of yielding a valid block. So, when a new block is found, miners do not have any sunk cost, they just update for the new predecessor, pick a new set of transactions, and go right back to mining at the new height.


Bitcoin RPC. How to close wallet files opened by bitcoin? Bitcoin RPC unloadwallet command does not close files opened by bitcoind process.
I want to generate addresses for multiple wallets (over 1000) and get 'Too many opened files error'.
Is there a way to close files, associated with unloaded wallet?

.bitcoin/testnet3/wallets/3f7b93e26b498be43235a9beda796d8d/.walletlock
.bitcoin/testnet3/wallets/3f7b93e26b498be43235a9beda796d8d/db.log
.bitcoin/testnet3/wallets/3f7b93e26b498be43235a9beda796d8d/database/log.0000000001

This is a known bug and has been fixed for 0.18 which will be released in the coming weeks.


If I backup my wallet.dat once, am I forever safe? I have a dogecoin (though should be similar to bitcoin/altcoins) wallet and I encrypted and backed up my wallet.dat file to a few different places (different cloud providers).

Now, assuming I never create a completely new wallet, do I ever need to update the wallet.dat file that I have backed up?

TL;DR: If you have a frequent recurring backup you are safe, otherwise use a deterministic wallet.

No, you are not safe in that scenario.
Let me rephrase that, you are not safe if you really want to use your the coins from your addresses.

Wallet.dat file stores all public and private keys of your current addresses but standard client generates a new address every time you generate some change spending your money and those addresses will not be saved in your distributed copies.
Also if you generate a new address manually it will not be in your backups.
So if you recover the file from a backup those "change" addresses will be lost and you will not be able to use that coins.

Well that is not really true :D indeed to leverage this kind of problems with recent backups standard client (and probably doge client) pre-generates a bunch of addresses (100) in a qeue and when it needs a new one (used for change or when you ask for it) it just take the first one and add one to the end of the qeue.

So while it is not really safe to store a backup forever if you backup frequently you will have no problem recovering all your coins when you recover a backup.

Another option is using a deterministic wallet, it is a system that given a unique passphrase, file, code or whatever will generate always the same addresses with their private keys, so as long as you save or memorize the seed you can recover everything.
bitcoin-qt (and dogecoin-qt) does not support this but clients like Armory and other online wallets do.


When downloading the blockchain for the first time using bitcoind, how do I know when it's done? I'm using bitcoind on Ubuntu, headless. So there's no GUI to tell me when it's done.

So how do I know?

Run bitcoind getinfo in your shell of choice and compare the block count, listed after "blocks", to the block count listed here. If the two numbers are the same, your client is up to date.


How can I import blockchain.dat into bitcoind? I'm getting the latest torrent and I'm running bitcoind on my linux box. How can I import this once it's downloaded?

If you are downloading the blockchain from scratch I strongly recommend using the bootstrap.dat file, which allows your computer to simply verify blocks and import them without needing to download for days or even weeks on end.

The main issue with downloading from the network is that your client will only download one block at a time. It starts with block #1 and will not try to download anything except for block #2 after block #1 is verified, and so on. As you can imagine, with network latency this can become a rather painful process, as you have endured.

The bootstrap.dat file is widely available on bittorrent, torrent files can be found here: http://sourceforge.net/projects/bitcoin/files/Bitcoin/blockchain/

Direct torrent link: http://sourceforge.net/projects/bitcoin/files/Bitcoin/blockchain/bootstrap.dat.torrent/download

Downloading the bootstrap.dat file is just as secure as downloading the blockchain from peers, but since all the data is already there, the only latency you suffer between blocks is going to your hard drive and finding the next block.

You simply need to place the bootstrap.dat in your %appdata%\Bitcoin folder, (on linux/unix in your .bitcoin folder). The file will be renamed to bootstrap.dat.old when the data import is complete. Using this, it took me only 4 hours to catch up with the network, as opposed to the 1-2 weeks it took me before reformatting on the same computer.