Why do two different fully synced Bitcoin Core nodes differ in the blockchain size? The size_on_disk printed when executing getblockchaininfo is 1.2 GB smaller than other nodes are reporting at the same time/block.

txindex=1

What could it be??
I've asked to other peers on twitter to check if anyone else experiencing the same and everyone has more data in their ledger than me. (https://twitter.com/bitdov/status/1231915231368163328)

Here's all the info printed with getblockchaininfo on my node:

{
  "chain": "main",
  "blocks": 618824,
  "headers": 618824,
  "bestblockhash": "0000000000000000000a1fb0ec42e380215bb58698a1321d2953ee5d1b7b                                                                                685d",
  "difficulty": 15546745765529.37,
  "mediantime": 1582569829,
  "verificationprogress": 0.9999950821417113,
  "initialblockdownload": false,
  "chainwork": "00000000000000000000000000000000000000000cfea65b1b3c9262e87778b8                                                                                ",
  "size_on_disk": 299006763199,
  "pruned": false,
  "softforks": {
    "bip34": {
      "type": "buried",
      "active": true,
      "height": 227931
    },
    "bip66": {
      "type": "buried",
      "active": true,
      "height": 363725
    },
    "bip65": {
      "type": "buried",
      "active": true,
      "height": 388381
    },
    "csv": {
      "type": "buried",
      "active": true,
      "height": 419328
    },
    "segwit": {
      "type": "buried",
      "active": true,
      "height": 481824
    }
  },
  "warnings": ""
}

The size of the blockchain on disk can vary depending on how many stale blocks your node has seen. Stale blocks are not part of the main chain, but they are still stored on disk by your node. A new node will have fewer stale blocks than an old, long running, node. Well connected nodes are more likely to see stale blocks than less well connected nodes. So it is possible that your node simply has not seen as many stale blocks as other people's nodes.


Coimarketcap api data different from coinmarketcap.com I am using popular Coinmarketcap API request:

https://pro-api.coinmarketcap.com/v1/cryptocurrency/listings/latest?limit=100&convert=ETH

In response percentChangeFor24h and some other parameters are always different from what is show on coinmarketcap.com. Do I miss something or data is just irrelevant? Could it be from timezone? I have not found any way to change timezone into requests itself.

This is likely due to the update frequency of the API and website.

They certainly use the same source to get data for their website and API.

One might be lagging a few minutes sometimes. I'd assume the API data is the most up to date and it's safe to rely on it.


Where should a miner get the most current block from? Where does a miner get the most recent/current block from, to work on confirming new transactions and building the next block?

Obviously it's the 'top' block on the blockchain - where can a new miner 'get' the blockchain from? As I understand it, it's P2P, but how do you connect to those peers in the first place?

You've asked two different questions and already answered one of them.

Solo miners get blocks from their peers on the network.

Discovering peers is done by a bootstrapping process. Basically, the software comes with a default list of known nodes, and from these nodes the client learns about other nodes. More details are at https://en.bitcoin.it/wiki/Satoshi_Client_Node_Discovery.


Help With Raw Transaction Fee - Absurdly High Fee I've been working on my Litecoin wallet for a while now. But I can't seem to control the transaction fee when I make raw transactions.

I know how to send transactions with Litecoin-Qt GUI:
https://live.blockcypher.com/ltc/tx/2b2f0aab9d2661840a60b172dcda24f359e85b7dbd0810e7afb2d3a6c0b8e59c/

No problem with that, the fee was 0.00017 LTC and was included in the next block. The vsize of this TX = 170, which explains the 0.00017 LTC fee.

But I'm also working on my own wallet on my VPS with the Litecoin-CLI. I made a raw TX, signed it and sent it. This happened:
https://live.blockcypher.com/ltc/tx/32ceefc7f377ad53c91922dffe62e6fd19e48a46d6afb4d610c2c090646404dc/

A transaction fee of 0.1 LTC!!! And the vsize is just 192.

I went back to the litecoin.conf file and it has the paytxfee=0.001 parameter. Which means it would cost me 0.001 LTC/kB. maxtxfee wasn't turned on yet, but now it is with a value of 0.001. When I try to send now, it just prompts me with: "error":{"code":-26,"message":"256: absurdly-high-fee"}.

What am I doing wrong?

(Yes I'm testing my wallet on the mainnet, I'm stupid)

The fee of a transaction is just the difference between the input and the output value. In the second transaction you posted, the input value was 0.25 LTC and the output value was 0.15 LTC, so you paid a 0.1 LTC fee (0.25-0.15) as you say. If you choose an input which is larger than the output you want to send as well as the fee, you have to create a change output to send the rest back to your wallet as well, otherwise it will all go to the miners as fees. For example, if your input was 0.25 LTC, and you wanted to send 0.15 LTC and only pay 0.01 LTC fee, your transaction would need to have two outputs, one for 0.15 LTC, and one for 0.09 LTC back to an address you own, so that the total fee is just (0.25-(0.15+0.9) = 0.01)


Could the $25/£16 Raspberry Pi computer be used to run mining equipment? Raspberry Pi $25/£16 PC article

I saw this article today and it looks like a really interesting development in budget computing.

It's a $25 barebones computer that runs Linux, and can play games like Quake 3 Arena with no problems.

My question is would we be able to run GPUs/FPGAs with it?

I'm guessing FPGAs are feasible since there are USB ports to connect them to, but what about GPUs?

NOTE: The Raspberry Pi would only getwork and pass it to the FPGAs/GPUs. I didn't mean mining directly on the Raspberry Pi itself!

Yes and no.

As far as FPGAs are concerned, I see no reason why you should not, technically, be able to handle a getwork on one of these and pass the work units to one or more FPGAs via USB.

These units do not, however, have a PCIe slot nor do they have any connectors which, to my knowledge, are capable of connecting to an external PCIe enclosure box, so GPU mining is out of the question.

The real problem you're likely to run into is software. The Raspberry Pi uses an ARM processor and runs on a custom-compiled version of Debian. All software running on the device will have to be compiled from source (since most projects don't just release ARM-compatible executables) and even then some software simply might not work. I'm not an FPGA expert by any means so I've got no idea what kind of software is required to speak to that particular hardware, but I do at least know that software is required and you'll probably have to do some tweaking to make that hardware work.

So yes, it's technically feasible, but don't expect it to be easy (or done for you).


Invalid public key was spent! How was this possible? From previous questions this bitcoin 1FYMZEHnszCHKTBdFZ2DLrUuk3dGwYKQxh address had an invalid public key of "00" and was unspendable but the coins are now spent?? The invalid key was generated by a bug in the wallet software the owner was using and should have been "locked" due to the invalid key

see link to the owners original query
https://www.reddit.com/r/Bitcoin/comments/2t3vn0/i_cant_send_my_btc_a_triangle_apear_i_use_multibit/

also see link to a paper that lists that this is an invalid key
https://www.microsoft.com/en-us/research/wp-content/uploads/2013/11/734.pdf?from=http%3A%2F%2Fresearch.microsoft.com%2Fpubs%2F204914%2F734.pdf

see page 11

That address cannot be spent from and any such transaction that spends from it is invalid. However this does not prevent improperly written software from thinking its private key is a valid private and and performing the elliptic curve operations on it. So thus the address was created and a transaction was created that appears valid. But when validating the transaction with proper software, such software rejects it.

This transaction appears on blockchain.info likely because their software is either improperly implemented or simply not validating (or fully validating) transactions. This isn't the first time that's happened though.


Is there a way to delete a test wallet without stopping bitcoind? For my unit tests, I'd like to be able to delete and recreate a wallet without having to stop bitcoind and manually deleting the wallet directory.

When I try to delete such wallet directory without stopping bitcoind, I get an error since an handle exists on "db.log" (on Windows at least).

Is there a clean way to delete a (testnet) wallet without stopping bitcoind?

You can unload the wallet using unloadwallet and then delete the wallet file.


Bitcoin core addresses are all empty? My PC, got burned entirely in a fire at my warehouse.
Luckily, I had create a backup of my bitcoin core  wallet.dat > 2 days before ! < ,so I bought a new pc, with Windows 7 on and now I'm downloading everything from the beginning.
In the 6th day, as I had 21 weeks left, my wallet popped up the message:
Number of blocks left : Unknown Syncing headers
So I believe, that it might take a lot longer, since it might need a -reindex
or a -rescan.
So I read about the article on migrating Bitcoin core to Electrum.
when I searched for the receiving addresses that had money in them, I found only a small fraction of the total amount in blochchain.info.

My Questions are :

A) Will I need a -reindex or a -rescan FOR SURE ? and what's the difference of these 2 ?

B) Why my addresses are almost empty ? OR why can't I find the addresses which have the correct balance inside them ?

Thank you in advance.

A) While downloading entire blockchain, Bitcoin Core sets indexes and scans the transactions which belong to your wallet so no, it does it automatically. This functions exist to allow you to check the balance after importing private keys from outside manually (as default, it rescans after each private key is imported but you allowed to do a rescan after importing multiple private keys). reindex basically refreshes the table which contains transaction positions in the disk to search a transaction fastly with a given TXID. rescan scans entire blockchain to find transactions which belong to your wallet.

B) Sorry, there is no proper answer for this part. After creating backup, did you receive any amount of money into new addresses generated after the backup? Or, did you send any amount of money to anyone (new change addresses might be generated)? What was the keypool value? Its default value is 100. If you didn't change it and if you did not send or not receive any amount of bitcoin more than 100 times after backup, you must be able to have all the balance. Did you check all addresses you have in the wallet on blockchain.info? Also, are you sure your wallet has not been compromised? If you are not sure, check the transactions of your addresses in blockchain.info and try to remember your last transactions then compare them. If you see any transaction which you did not perform, then your wallet backups (or your private keys) have might be stolen.


How does a miner collects the fees? The way I understand it,  at the very top of the block the miner adds a transaction to collect the 25 bitcoins it would earn if it solves the block.

Obviously that transaction is included in the hash/nonce when the block is solved.

But what about the fees? the only way I see it done is for the miner to also create transactions for each of the fees it finds in the block.

All these "fragments" have to be traced to some source/input address.

Q: How can the miner sign a fee transaction for itself if the miner's address is not the input of the transaction?

In the same special "generation transaction" that collects the 25 newly minted bitcoins, the miner also collects the total of all the transaction fees in the block, and together can send them to an address(es) of his choosing.

No signature is required; it's a hardcoded perk to whoever manages to find a block.


P2SH secure spending. How? Maybe my question is stupid, but

imagine that I'm trying to spend inputs from p2sh.

For example, p2sh scriptPubKey looks like:

OP_SHA256 4bf5122f344554c53bde2ebb8cd2b7e3d1600ad631c385a5d7cce23c7785459a OP_EQUAL

I know, that the SHA256(0x01) = 4bf5122f...85459a (hacker do not know that, until I broadcast tx)

So I broadcast transaction with the folowing scriptsig:

OP_1 (0x51)

Why hacker can't take this unconfirmed transaction, extract scriptsig, and replace outputs to his own outputs ?

Also, what to do, if RBF (replace-by-fee) flag is set?

Of course, I'm not talking about transactions with OP_CHECKSIG

You're correct that anybody could just replace the outputs and take the funds for themselves.  This script has no authorization needed on the spender's part, so once the redeemscript is known, it's practically become an anyone-can-spend script.

Assigning an RBF enabled sequence (or not) on the transaction makes no difference (perhaps only for relay policy), since any sequence set can also be replaced by anybody.


I was scammed, told I had bought bitcoin and that it had been put in my wallet. I have never had a bitcoin wallet I am trying to recover my money through my bank. How do I prove that I have never had a wallet for this currency. If someone else created the wallet how do I identify where it is?

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

You can't.

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

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

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

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


Getting individual block by height from Bitcoin P2P network Is it possible to request an individual block from the bitcoin network, using the block height as parameter? Or would one have to start a node and wait until all blocks up to the desired height have been retrieved?

I'd like to be able to retrieve the actual, raw, serialized data, but e.g. blockchain.info, even when saying format=raw doesn't give you the raw block data.

N.B. If I understand bitcoin correctly though, I fear that if I don't build up a node by myself, starting from block 0, I can never be sure what I'm getting is true data from the bitcoin blockchain, no matter if I get it from blockchain.info (which could be compromised) or from a p2p peer, which is just one (potentially malicious) peer.

To request an individual block from a p2p peer, consider the get_data message, indicating what type of block (witness/compact/filtered).

Since you do not wish to do full block download and validation, you can first build a header chain to the most recent height, and then verify the block you are requesting is in the header chain. This would ensure that it would be expensive to falsify the block data you receive from a peer. You can also determine the block header hash corresponding to the height index you are interested in, as blocks cannot be uniquely referred to by height over the p2p network (two branches can have same height).

To build a header chain, consider the GET_HEADERS message, which also provides information (so-called block locator) about your current header branch so the peer can provide the headers for your node to catch-up to its header height.


Can malicious payer deanonymize payee in Zcash? Looking at both the Zcash original paper and the updated Zcash protocol specification, it seems that after Alice paid Bob, she can reveal to the world that she did so.

Alice can do so by revealing the randomness of the new coin commitments she generated, one of which contains Bob's PK and the amount. For example, in the image below, Alice reveals the elements highlighted in red (i.e., Alice's randomness) and purple (i.e., Bob's PK and the value), while the elements in yellow are already public.

The same attack works in the updated Zcash proposal (see Section 4.4 on page 19 in v2018-beta2.0, plus image below).

I just want to confirm that (1) I am not missing anything and this is possible and (2) it's potentially problematic. For example, if Alice paid Bob for some illicit goods or services, she can later reveal that she did so.

Thoughts would be welcome!

tl;dr Alice can reveal payments she made to Bob. She cannot reveal payments that others made to Bob, or reveal what (if anything) Bob does with the ZEC that Alice sent.

Revealing the pre-image of the note commitment only proves that Alice knows the pre-image. It does not prove that Alice sent the transaction, because the proof is replayable: once revealed, anyone can take the randomness and note data, and show it to someone else.

In order for Alice to prove to someone that she sent the transaction, she can do the following:

Write a message that contains:

The private key esk used to encrypt the note (randomness and value) to Bob.
Bob's payment address.
A challenge string chosen by the person Alice is convincing.

Sign the message using the private key joinSplitPrivKey corresponding to the joinsplitPubKey that was originally used to sign the transaction.

The signed message is proof that Alice currently has access to joinSplitPrivKey (because the challenge string is fresh). Assuming that joinSplitPrivKey is never revealed, Alice is indistinguishable from the person who created the transaction (i.e. either she or someone with her spending keys made the payment). This is what we call a payment disclosure, and is how e.g. you would prove to an exchange (or a third party dispute resolution service) that you did indeed pay them.

What you are describing is fundamentally the same issue that messaging apps have with end-to-end encryption: someone with intended access to the data can accidentally or intentionally reveal it. Removing this potential privacy leak would by definition mean that Alice cannot see some or all details about her own outgoing transactions, which is either a contradiction (in the Zcash model, Alice needs to be able to calculate a commitment from its pre-image in order to create valid transactions), or a completely unusable payment system!

Note however that even though Alice can prove that she sent a transaction to Bob, she cannot reveal anything about what Bob does with the note he received (because she does not have Bob's spending key, and thus can't calculate the nullifier that will would be revealed at spend time). Alice's ability to reveal information is limited to information she was ever able to view.


How is bitcoin infinitely divisible? I've read that bitcoins are infinitely divisible:

  Bitcoins can be divided up and trade into as small of pieces as one wants

How is this possible programmatically?  The only thing that comes to mind are floating points which are inaccurate.

Are bitcoins truly infinitely divisible or merely practically?

A link to the relevant source code would be more than welcome.

If there is a need for them, additional decimal places can be added with concensus of the network. This is why some refer to "infinite" divisibility, because we can select the level that we need as time goes on.

The current level selected in the code (by Satoshi) is 8 decimal places (1 satoshi = 0.00000001 BTC) hence the nickname for the smallest unit currently possible for bitcoin today.

As a thought exercise, if a consensus of the network (miners, but also clients and server applications for compatibility reasons) decides to update to a version of the protocol that includes 16 decimal places inspired by your post, we could end up with a new base unit (1 satoshi = 100,000,000 gracchi) as well as nanobitcoins (nBTC), picobitcoins (pBTC), and even femtobitcoins (fBTC, 10 gracchi)

I have trouble imagining the need for such a thing, unless destroying bitcoin becomes a prevalent method of use. If it is needed the potential is there and will never dilute your held bitcoins, which actually makes it a problem some would love to see the need to solve.


How to trade BCC with Blockchain app and private key There is something I do not understand.

I have handled a few bitcoin transactions using Android Blockchain app and imported private key. That worked and could buy/sell with btcdirect.eu (start transaction with btcdirect.eu and exchange bitcoin with Blockchain app)

Now after the hard fork I want to see my BCC and buy more of it, but how can I do that with my private key? If possible I want to use the Blockchain app.

In case you have your private key (or the memnomics) you can use the BIP39 browser at https://iancoleman.github.io/bip39/ to see the funds in your internal and external addresses.

More info on how to at How to sweep private extended key from mycellium into coinomi for bitcoin cash coins?


How to create different paper wallets for different currencies? I have several different currencies (on exchange) right now and would like to move them to paper wallet.

1) Do I have to have a different wallet for each currency?

2) Are the algorithms for creating (prv, pub) different for each currency, or is it possible just to create a different pair with the same algorithm (e.g just create different pairs with bitaddress.org)

Thanks a lot!

1)
It depends on the currencies you want to store. You could store Bitcoin and BitcoinCash on the same paperwallet because they use the same private and public keys. Just for a better overview I would recommend storing those on different paperwallets as well and labeling them accordingly.
You cannot store completely unrelated cryptocurrencies on the same paperwallet.
2)
The algorithms to create the private key and to create the public from a private key are/can be different for each crypocurrency out there. You would have to find tools for each one you want to store on paperwallets.


Why is the 'Estimated BTC Transacted' referring to just one of the multiple outputs? I recently started learning about bitcoins and came by this transaction. Here there are multiple outputs so if we consider one of them to be the change received by the sender then why is the 'Estimated BTC Transacted' only summing up to one of the output values? What happens to the rest of the outputs?

It's a best effort guess made by blockchain.com, has little relevance, is not particularly accurate, and should not be used for any meaningful analysis. It has no impact on the transaction, and is not part of the Bitcoin protocol.

It is somewhat accurate for very simple transactions, but breaks down for larger ones, and ones that utilize more recent anti-tracking approaches such as randomized outputs, sending change to an address of the same type as the other address being payed, etc.


which transactions does bitcoind validate? which types of transactions does bitcoind v0.10 perform checksig validation on?

blockchain transactions belonging to a wallet with known private key
blockchain transactions belonging to watch-only-wallet addresses
all transactions in the blockchain

my guesses for answers would be 1 - yes, 2 - yes, 3 - no. however i would like confirmation of this.

1, 2 and 3.

Transactions that arrive through inventory announcements on the network are validated completely by checking the form of the transaction for sanity, executing the script, checking signatures, ensuring that the outputs they are spending actually exist, and that the transaction doesn't end up making negative values anywhere. If they are accepted they are added to the nodes memory pool where they wait for inclusion in a block.

Additionally, non-consensus rules are applied to bare transactions known as IsStandard. On the production network only a small subset of transaction types are "standard", this includes P2SH (pay to script hash) and P2PKH (pay to pubkey hash, or an address), but not raw multisignature and other scripts. Transactions that do not pass are not accepted but relaying a non standard transaction is not a bannable offense.
After validation, IsMine is run to check if the nodes wallet (if it exists) has the keys which own these transactions, of it they have been added as a watching address, if they do they are marked as unconfirmed in the wallet file.

Transactions that arrive in a block are completely validated, along with the rest of the structure of the block. The proof of work is checked, the size and form of the block is checked, the merkle tree is validated to contain all the transactions it claims to and that it connects properly with the header. Every transaction is validated, same as if it had arrived from the network. If they are found to be invalid the entire block is thrown out and the peer who relayed the block is banned from connecting. If the block is valid, it is committed and written to the unspent outputs database, additional undo data is written to file if the accepted block is ever needed to be undone.

IsStandard does not apply here, any transaction that is valid is acceptable when it is included in a block.
IsMine is run to filter out any transactions relevant to the wallet or watch address (if present), and updates the wallet with confirmations if necessary.


Is it possible to autoforward bitcoins to another address? we would like to accept BTC for our token sale. In order to achieve that, we need a specific BTC address for every contributor.

The contribution flow is:
- investor sends BTC to their dedicated address
- the contribution is recorded in an offchain database
- the BTC is forwarded to a central account

as I don't know if this is even possible, some pointers would be highly appreciated.

Why do you need to forward the coins to a different address? You already control the private keys for the address that they were sent to, no need to move them to another address in your wallet. All you are doing is incurring additional transaction fees.

Instead of forwarding them to another address, just make sure that you have the private keys to all of the coins and spend them from those addresses as necessary.

If you are doing this for auditing purposes, then use an HD wallet and publish the master public key. This allows anyone to derive the addresses that you used (without needing the private keys or having access to them) to check the balance of your wallet. If you do that, just make sure that you do not reveal any of the child private keys as that will result in the master private key (and thus all of your child private keys) being revealed.


Chance of a word repeating THREE times in a BIP39 Mnemonic passphrase? And what about 2 words repeating 2 times each? So according to the other thread about BIP39 repeating words, the cahnce of a word repeating TWICE is 11.7%.

Now I was wondering, since my passphrase may or may not contain THREE repetitions :O.
And then just to finish the chance calculation wizards off, what is the chance that two words are both repeated twice?

We are talking about 24 word passphrases here.

Thanks for teaching us how to do this, or atleast understanding the math :).

The probability of 11.7% is being calculated using the birthday paradox formula.

"The paradox of birthdays is a mathematical problem put forward by Von Mises, who looks for the value N in the problem: In a group of N people there is 50% chance that at least 2 people in the group share the same birthday (day + month). The answer is N = 23, which is quite counterintuitive, hence the paradox."

So for the calculations:
-Repetition (Twice): 2 (number of people sharing the same birthday)
-Number of words: 24 (number of people in a group)
-Number of all BIP39 words: 2048 (number of days in a year)

The result is 0.119 (11.9%).
But for THREE repetitions it's getting really low: 0.00043 (0,043%).

Answering the question about two words both repeated twice, would require reworking the formula. I used an online calculator to provide the values.


8333 failed after select(): Connection refused (111) Hello I run bitcoind and i get this 8333 failed after select(): Connection refused (111).
Can you help me with this? because it was working suddenly this happened.

this happens when you have a running daemon and suddenly for whatever reason the firewall starts blocking it. IT IS A FIREWALL ISSUE.
In my case I installed additional programs on my server which changed the settings of nftables (formerly iptables). I had to open up the relevant ports again (that are required by btc-daemon).
After that you have to restart both nftables as well as btcd.
Keep checking the logs for a few minutes. And you will see it will be running just fine.


ZeroMQ support in Bitcoin Core 0.16.0 out-of-the-box? In my previous question, I'm wondering why Lightning Networks lnd cannot talk to my Bitcoin Core bitcoind backend.

The docs for lnd says it requires ZeroMQ compiled into bitcoind.  Does the binary version of Bitcoin Core bitcoind 0.16.0 contain ZeroMQ?

Yes, the official Bitcoin Core v0.16.0 binary works perfectly well with LND, no self compiling necessary.


How do exchanges set their transaction fees? I was reading on the Bitcoin wiki (https://en.bitcoin.it/wiki/Transaction_fees
) that a user can set his own fees when conducting a bitcoin transaction.  Like many, I have a Coinbase account, but I don't see anywhere in there where I can set the transaction fee.  Is this something the exchanges come up with?  How do they figure out what transaction fee to propose so that the transaction will be accepted by miners?

Coinbase does not allow you to set fees, and has been called out for their practices in this regard, as have others. The surest way to have control over what happens with your Bitcoin is to interact with the Bitcoin network directly via a full node, and to not rely on, or trust third party services. This is precisely why Bitcoin exists.


Get hex string for a public address If I want to watch a public address, I need the hex string for that address, because the importpubkey command only takes a hex input. How can I convert a  base 58 address to a hex string using the bitcoin core?

You cannot generate public key from a bitcoin address. From bitcoin address, all you can get is the hash160. Following reference, this can be done through base58 decoding, going from Step 9 -> Step 8. So you get same output as from Step 4 along with checksum at the end.

Basically you have two alternatives:

If you have the private key, generate the public key and use importpubkey
Use importaddress


I provided my XPUB and YPUB to Trezor support - should I continue to use my Trezor? I have a Trezor.  In attempting to find out why I have have not received Bitcoin Gold coins Trezor Support asked for my XPUB - I gave it to them along with the YPUB too.  Is this safe?  Should I move my coins?  Your help is greatly appreciated.

XPUB refers to an extended public key, and because it is only a public key, you have not compromised your private keys. Thus it is safe to continue using, yes. You have, on the other hand, compromised your privacy, as with that xpub Trezor support can derive all your addresses and know they are all yours. But it's likely they just want to look to see if you have any bitcoin gold balance on any of them, it's probably completely harmless


Why do LedgerJS and Electrum, using the same Nano S and derivation path, not refer to the same Wallet? I start Electrum in my cmdline like this:

./Electrum --testnet

I connect Ledger Nano S to my laptop.
In Electrum I make a new HD Wallet with Derivation path using the Nano S's private key as seed:

"m/49'/1'/0'"

In NodeJS (LedgerJS library) I write this code, using the exact same derivation path, also using the Nano S private key as seed:

const transport = await TransportNodeHid.create();
const btc = new AppBtc(transport);
const result = await btc.getWalletPublicKey("m/49'/1'/0'");
console.log(result.getWalletPublicKey())

Now, since the TransportNodeHid connects to my Ledger Nano S, I expect that the AppBtc object generates a HD Wallet with the exact same seed, and therefore the derivation path

"m/49'/1'/0'"

should give me the exact same Wallet Master Public key and receiving Bitcoin address right?

However, in Electrum:

Master Public Key: upub5EorGi4nr15AW.....
Receiving Address: 2NEYbAH7x6sXU2bS....

and in my NodeJS application, using getWalletPublicKey():

{
    publicKey:'049bd7786109d5bed56.....',
    bitcoinAddress: 'mtCKwjnNzNZr.....',
    chainCode:'c511f1afedb628fdb93299747604b...'
}

Now, I figured out that the publicKey and chainCode that the NodeJS code returns can be combined somehow to create the Master Public Key. However, the bitcoinAddress property should be the address associated with my HD wallet right? It's different from the receiving address in the Electrum app, but it should still be a receiving address.

However I already tried sending 0.0001 BTC to it with Testnet but it never arrived in my Electrum Wallet. So does this mean that this address is not associated with my Electrum Wallet? Even though I gave the exact same Derivation Path and used the exact same seed (hardware device Ledger Nano S)?

How can I "get" more receiving Address from my HD Wallet using the LedgerJS library?

I have checked LedgerJS documentation and examples, but I wouldn't go so far as to call it "documentation", because most functionality is barely explained and examples are virtually non-existent. There's a lot of guesswork involved in how exactly everything works.

https://github.com/LedgerHQ/ledgerjs/tree/master/packages/hw-app-btc#getwalletpublickey

http://ledgerhq.github.io/ledgerjs/docs

A public key can have multiple addresses. It looks like what is happening here is that Electrum is creating a P2SH-P2WPKH type address while your NodeJS code is creating a P2PKH address. These are two different address types which have different spending requirements and transaction data. However Bitcoin sent to either address type can still be spent with the same private key and the same public key was used to create both addresses.

When you sent the Bitcoin to the P2PKH address, Electrum won't show it because it is not looking for Bitcoin sent to that address. Just because you have the private key necessary to spend some Bitcoin does not necessarily mean that your wallet will be looking for outputs of that kind. A wallet cannot track all possible output scripts that it can spend (it is infinite), it can only track the ones it is expecting to see. So for Electrum, it's only tracking the P2SH-P2WPKH address and not the P2PKH address that you sent Bitcoin to.


Does BTC return fee in a failed transaction? From wiki 'The fee may be collected by the miner who includes the transaction in a block.' wiki

So I think it will return your fee , in a failed transaction.But I can't find any other article about it. Does it really return fee?

Yes, effectively.  It isn't really that it's "returned", but that the fee is never actually "collected" until the transaction is confirmed.

If your transaction isn't confirmed, then no money moves at all.  The entire amount, including the fee, remains available for your use in a future transaction, though you may have to wait a little while for it to expire from the memory pool of other nodes on the network, and depending on your wallet software, you may have to use some obscure commands to make it forget the original transaction.


Total channel count differs from explorers I have my own c-lightning node. listchannels returns 11,455 but explorers, e.g https://explore.casa/ show around 39,000. Do I need to set something to get all channel info?

$ lightning-cli listchannels | grep source | wc
  11455   22910  996585

I'm thinking "initial_routing_sync" might be relevant. But I can't find how to use it.

  upon receiving an init message with the initial_routing_sync flag set to 1:
  SHOULD send gossip messages for all known channels and nodes, as if they were just received.

https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md

Update 1

I restarted clightning 3 hours ago but still the count is 8,433. And seems the number stays at the almost same number.

What I did:

1. Stop lightningd
2. Delete /home/lightningd/.lightning/gossip_store
3. Start lightningd
4. Connect to a peer

$ lightning-cli connect 03efccf2c383d7bf340da9a3f02e2c23104a0e4fe8ac1a880c8e2dc92fbdacd9df@144.76.235.20:9735

5. Wait for 3 hours
6. Check the count

$ lightning-cli listchannels | grep source | wc
   8433   16866  733671

I thought we had that question before but the only one similar I could find was this one 1ML shows larger number of nodes comparing to other lightning network explorers which was not quite the same.

So to answer your question: listchannels depicts information your node knows from the gossip protocol. If your node is new this could take some time which is most likely the reason for your lower number.

I once had a corrupted gossip_store file in .lightning folder after upgrading a node in that case shutdown your node delete the gossip store file and restart for a new sync. Pay attention not to delete any other files in that directory as they are critical to access your funds


BTC Node for Dummies Just downloaded, and I am now running a BTC pruned node.  Is there a good primer or beginner's guide to running it?  I have more questions than I think I can ask in one post.

I hope admins is not angry that I will share the link to another forum. On the bitcointalk.org/index.php?topic=5208641.0 you can find big discussion about pruned node - full node. There you will find a lot of useful information


What is the Merkle root? The Bitcoin wiki Vocabulary article explains why the Merkle root exists:

  Every transaction has a hash associated with it. In a block, all of
  the transaction hashes in the block are themselves hashed (sometimes
  several times -- the exact process is complex), and the result is the
  Merkle root. In other words, the Merkle root is the hash of all the
  hashes of all the transactions in the block. The Merkle root is
  included in the block header. With this scheme, it is possible to
  securely verify that a transaction has been accepted by the network
  (and get the number of confirmations) by downloading just the tiny
  block headers and Merkle tree -- downloading the entire block chain is
  unnecessary. This feature is currently not used in Bitcoin, but it
  will be in the future.

How can you check if a transaction has been verified only using Merkle roots? How does that mechanism work?

The idea (as I understand it) is that the Merkle tree allows for you to verify transactions as needed and not include the body of every transaction in the block header, while still providing a way to verify the entire blockchain (and therefore proof of work) on every transaction.

To understand this, first understand the concept of a tree. Consider an 8 transaction block. Imagine each of those 8 transactions at the base of a pyramid: these are called leaves. Put four "branches" on the second tier of the pyramid and draw two lines from each of them to the leaves so that each branch has two leaves attached to it. Now join those four branches to two branches on pyramid level 3 and up to one branch (what is called the root of the tree) on the top of the pyramid. (Our tree is growing upside down in this example.)

Now we can start to understand the hashing process. Hash the hashes of the "leaves" and include that as part of the 2nd level branches that those leaves are attached to (these are called child nodes and parent nodes). Now hash the hashes of those hashes and include that as part of the third level branches. And so on. (And if you had more than 8 transactions, all you need are more levels to the pyramid.)

So now you have a root node that effectively has a hash that verifies the integrity of all of the transactions. If one transaction is added/removed or changed it will change the hash of its parent. Which will change the hash of its parent, and so on, resulting in the root node's hash (which is the Merkle root) changing as well.

So how does this help us with potentially not having to have the entire blockchain? Because we could verify the transactions as needed. If we have a transaction that claims to have been from block #234133 we can get the transactions for that block, verify the Merkle tree, and know that the transaction is valid. We can do that without necessarily knowing all of the transactions from #234132 or #234134 because we know that the blocks are tamper proof.

Even better, if we know where it is in the Merkle tree and we know the hashes of the branches we don't even need all of the transactions from #234132. (There were 868 in that block.) We start with just our transaction and its sibling (if it has one) and calculate the hash of those two and verify that it matches the expected value. From that we can ask for the sibling branch of that and calculate the hash of that and verify it. And continue with this process, up the tree. Which only takes ten verifications for 868 transactions. (That's one of the great things about trees, they can hold a lot of values with only a relatively small number of layers.)

How do we know that the source of this data isn't lying to us about the hash values? Because a hash function is one-way, there is no way that a deceptive party could guess a value that would hash with our second-to-last value to create the Merkle root. (Which we know from our verified blockchain.) This reasoning holds further down the tree: there's no way to create a fake value that would hash to our expected value. Another way to think about it, is that even a single alteration of a transaction at the base of the tree, would result in a rippling change to all the hash values of nodes in its branch all the way up to the root's hash value.

In short, the Merkle tree creates a single value that proves the integrity of all of the transactions under it. Satoshi could have just included the hash of a big list of all of the transactions in the Bitcoin header. But if he had done that that would have required you to hash the entire list of transactions in order to verify its integrity. With this way, even if there are an extremely large number of transactions the work you need to do (and the number of hashes you need to request/download) in order to verify the integrity is only log(O).

[As always, feel free to edit this. This is primarily just inference on my part from looking at the spec.]


Would more Full Nodes help scaling and transaction speed? There seems to be lots of disagreement between Core, Classic, etc on how to scale up Bitcoin.

As far as transactions per second, and transaction fees, would simply adding more Full Nodes to the network help solve several me of these growing pains?

It seems to me having more Nodes verifying transactions would both speed up the network and reduce transaction fees. Although, I don't seem much discussion anywhere about this

No, the number of full nodes is decoupled from capacity and fees.

Transaction capacity is a function of transaction size and blocksize. Blocks occur roughly every 10 minutes and have a fixed size. Transactions also have a more or less fixed size, so capacity is currently not going to change unless either transactions get smaller (e.g. Schnorr signatures, MAST) or blocks get bigger (e.g. SegWit, blocksize increase).

Fees are a function of supply and demand of blockspace. Since the number of transactions that can be confirmed is limited over time, transactions with higher fee per byte get preferred. Especially when the network is unlucky and blocks are slow for a period the transactions waiting to be confirmed may build up intermittenly, which makes the average fees in blocks peak.

Full nodes are still important: Besides allowing their owner to trustlessly use Bitcoin, they serve as information providers to thin clients. If their number would be much smaller, the full nodes would be overwhelmed by these requests.


What is the timeline for Lightning Network's availability? I have been reading a lot about this Lightning Network and what it does.
But what I still don't know is if this Lightning Network is already being used for Bitcoin or when Bitcoin will start to use it ?

Roasbeef just announced the first Lightning transaction on Bitcoin mainnet today:
https://twitter.com/lightning/status/938453165967515648

It was using a multihop payment via all three major implementations (lnd, eclaire, c-lightning).

The Lightning Integration tests are now at 75/75 working:

The three teams are now working on a beta release each. I'd expect this to be released in the next months.


Redeeming a raw transaction step by step example required I am looking, specifically, for a step by step example transaction of sending Bitcoin which uses an actual transaction (How To Redeem A Basic Txn, from a few years back, does a great job of outlining most steps of sending a raw txn but does not use a real TxID).

I have played around with both the Python pybitcointools library, the SX library and JSON output from the Bitcoin Core client (Bitcoin-QT, Bitcoin-cli, Bitcoin daemon) but have yet to find an actual step by step guide using raw transaction output (single input / single output Bitcoin txn, ie not multisig).

Hopefully the bounty will bring a step by step example transaction (with private keys for the sending address) will bring an answer showing how it's done and, specifically:

how the ScriptPubKey element fits into the raw txn
how the ScriptSig element fits into the raw txn
how the txn is signed (with DER encoding).

EDIT: I think the best resource is Ken Shirriff's Bitcoins the hard way: Using the raw Bitcoin protocol, but again, there's no single source online that answers my question without skimming past areas like scriptPubKey, signing etc.

When I activate the bounty, if you can answer this refer to this Tx as it can serve as the actual example (ie I'll provide ~$1 in BTC and private keys for 1From/1MBngSqZbMydscpzSoehjP8kznMaHAzh9y if interested)

EDIT 2: The RoyalFork Blog: Deconstructing Txns provides an unbelievably good reference for interactive Txn creation

Step-by-step description:

We start creating a new transaction which we hash and sign.

Add four-byte version field: 01000000
One-byte varint specifying the number of inputs: 01
32-byte hash of the transaction from which we want to redeem an output (reverse order): be66e10da854e7aea9338c1f91cd489768d1d6d7189f586d7a3613f2a24d5396
Four-byte field denoting the output index we want to redeem from the transaction with the above hash (counting from zero): 00000000
Now comes the scriptSig. For the purpose of signing the transaction, this is temporarily filled with the scriptPubKey of the output we want to redeem. First we write a one-byte varint which denotes the length of the scriptSig (0x19 = 25 bytes): 19
Then we write the actual scriptSig (which is the scriptPubKey of the output we want to redeem): 76 a9 14 dd6cce9f255a8cc17bda8ba0373df8e861cb866e 88 ac (look to the bottom line line on https://blockchain.info/tx/96534da2f213367a6d589f18d7d6d1689748cd911f8c33a9aee754a80de166be?show_adv=true )
Then we write a four-byte field denoting the sequence. This is currently always set to 0xffffffff: ffffffff
Next comes a one-byte varint containing the number of outputs in our new transaction. We will set this to 1 in this example: 01
We then write an 8-byte field (64 bit integer, little-endian) containing the amount we want to redeem from the specified output. I will set this to the total amount available in the output minus a fee of 0.0001 BTC (128307 - 10000): 23ce010000000000
Then we start writing our transaction's output. We start with a one-byte varint denoting the length of the output script (0x19 or 25 bytes): 19
Then the actual output script: 76 a9 14 a2fd2e039a86dbcf0e1a664729e09e8007f89510 88 ac ( this is transferring funds back to address 1FromKBPAS8MWsk1Yv1Yiu8rJbjfVioBHc )
Then we write the four-byte "lock time" field: 00000000
And at last, we write a four-byte "hash code type" (1 in our case): 01000000

OK, the result is

01000000
01
be66e10da854e7aea9338c1f91cd489768d1d6d7189f586d7a3613f2a24d5396
00000000
19 76 a9 14 dd6cce9f255a8cc17bda8ba0373df8e861cb866e 88 ac
ffffffff
01
23ce010000000000
19 76 a9 14 a2fd2e039a86dbcf0e1a664729e09e8007f89510 88 ac
00000000
01000000

Now we double-SHA256 hash this entire structure, which yields the hash 1cde0239b55717cca8003104abc2ec2673d4f6fabea0b74351940e382e88486f
Now we should create ECDSA signature...
1MBngSqZbMydscpzSoehjP8kznMaHAzh9y is a brainwallet of "mrbubbymrbubbymrbubby!", which just happens to encode an address starting in 'MB' (making linking the 2 quite easy; see @WizardOfAussie comment below for phrase origins).
Private key in WIF: 5HvofFG7K1e2aeWESm5pbCzRHtCSiZNbfLYXBvxyA57DhKHV4U3

In hex, the private key is 0ecd20654c2e2be708495853e8da35c664247040c00bd10b9b13e5e86e6a808d. There is a sign (key, digest) method in every crypto lib. It will return an array of bytes. This array will be no more than 72 bytes, and start with hex code 30. Lets imagine that the signature is 3046022100cf4d7571dd47a4d47f5cb767d54d6702530a3555726b27b6ac56117f5e7808fe0221008cbb42233bb04d7f28a715cf7c938e238afde90207e9d103dd9018e12cb7180e
 To this signature we append the one-byte hash code type: 01. The public key for 1MBngSqZbMydscpzSoehjP8kznMaHAzh9y is: 042daa93315eebbe2cb9b5c3505df4c6fb6caca8b756786098567550d4820c09db988fe9997d049d687292f815ccd6e7fb5c1b1a91137999818d17c73d0f80aef9

We construct the final scriptSig by concatenating: <One-byte script OPCODE containing the length of the DER-encoded signature plus the one-byte hash code type>|< The actual DER-encoded signature plus the one-byte hash code type>|< One-byte script OPCODE containing the length of the public key>|<The actual public key>

scriptSig will be

49 3046022100cf4d7571dd47a4d47f5cb767d54d6702530a3555726b27b6ac56117f5e7808fe0221008cbb42233bb04d7f28a715cf7c938e238afde90207e9d103dd9018e12cb7180e 01
41 042daa93315eebbe2cb9b5c3505df4c6fb6caca8b756786098567550d4820c09db988fe9997d049d687292f815ccd6e7fb5c1b1a91137999818d17c73d0f80aef9

first line is 'push signature concatenated with 01', second line is 'push pubkey'. The length of scriptSig is 140 bytes (0x8c in hex)

We then replace the one-byte, varint length-field from step 5 with the length of the data from step 16. The length is 140 bytes, or 0x8C bytes: 8c
And we replace the actual scriptSig with the data structure constructed in step 16.
We finish off by removing the four-byte hash code type we added in step 13, and we end up with the following stream of bytes, which is the final transaction:

01000000
01
be66e10da854e7aea9338c1f91cd489768d1d6d7189f586d7a3613f2a24d5396
00000000
8c
49 3046022100cf4d7571dd47a4d47f5cb767d54d6702530a3555726b27b6ac56117f5e7808fe0221008cbb42233bb04d7f28a715cf7c938e238afde90207e9d103dd9018e12cb7180e 01
41 042daa93315eebbe2cb9b5c3505df4c6fb6caca8b756786098567550d4820c09db988fe9997d049d687292f815ccd6e7fb5c1b1a91137999818d17c73d0f80aef9
ffffffff
01
23ce010000000000
19 76 a9 14 a2fd2e039a86dbcf0e1a664729e09e8007f89510 88 ac
00000000


Is it safe to keep a compromised private key in my wallet? I'm using bitcoin-qt.  Suppose that one of the private keys in my wallet is compromised somehow, and is released to an attacker or the public.  Of course, I can transfer all the coins from the compromised address to a new one (unless the attacker does it first).  However, bitcoin-qt apparently doesn't provide a way to delete or disable a private key from a wallet.   (This is understandable; it would be pretty bad to accidentally delete a private key for an address that had coins in it.)

Is it safe to leave the key in the wallet, assuming I never again intentionally transfer any coins to that address?  (I could label it DONOTUSE or something.)  Or are there situations (e.g. change) where the client might automatically transfer coins there without asking me?

If it is only one private key and you are aware not to use it anymore (and have rerouted any anticipated transactions to a new address), there is nothing harmful that the attacker can do.

Bitcoin-qt sends change from transactions to new unused addresses. Since those are the only transaction outputs that are transmitted to not-explicitly-specified addresses, it is safe to keep the private key in your wallet.

A compromising party could, however, use the private key to sign messages. These messages would appear to be authored by you to recipients that know the respective address to be under your control. Unless the compromising party had additional information about you and the counter-parties of previous transactions the compromised key was used in, this shouldn't be useful to them (nor could you stop it either).


Passing a JSON argument to bitcoind in Windows command prompt I've been trying to use sendmany on my local installation of Bitcoin-qt (version 0.7.0) from the Windows command prompt. I've seen examples but when I try them all I get is a JSON parsing error. I figure that on Windows the input needs to be escaped in a different way than on Linux.

How do I pass a JSON argument to bitcoind from the Windows command prompt?

The important part is that strings should be enclosed in triple double-quotation marks. For example:

bitcoind sendmany "" {"""1ELvnrA6PhUyDBS6iR25K1Xx4xXL6VMfJX""":0.001,"""1NX3R5Le4c1y9E316NPMze7aEmCXjpCY58""":0.001}


What are the drawbacks of bitcoin cash? I am new to crypto-currency. I bought a bit of bitcoin the other day on coinbase. Then I moved it to another crypto exchange which cost me ~ 10% of the total value of the bitcoin. IMHO, this is useless. I changed my BTC to bitcoin cash because of this. I have moved it around couple of times and the fee was only 0.001 BCH, which was really good. I read a bit about the difference between BTC and BCH and I could not find any justification for using BTC. Could someone explain to me the drawbacks of BCH? Maybe I can't find the right sources to educate myself.

Yes, the costs of using BTC are getting excessive. So much so that it is no longer practical to keep sending small amounts (< $5).

But this is a result of bitcoin being so popular and its value having risen so much in the last months. Also there's a lot of SPAM transactions going on, probably by miners in order to push everybody else to pay higher fees for their own profit.

But even then most technical users recognize that the solution taken by BCH is not the right one. Why? well because it is just a "kick the can" solution. It fixes things temporarily and it provides BCH users with a great experience (just like bitcoin had a few years ago) basically because no one is using it.

But that extra capacity doesn't come for free. If bitcoin did this, ALL nodes in the network would have their disk usage rate increased by a factor of 8, forever. The cost of that is that in the not so distant future almost nobody would be able to run a full node anymore and thus the number of nodes would decrease, leaving the network less and less decentralized. Remember that the whole value proposition of bitcoin rests on the fact that the network is decentralized enough to be resilient to attacks both from the outside as from the inside. So if we just allow the costs of running a node to increase 8 times faster, we'll probably end up with a network composed of nodes controlled by a cartel of powerful companies. This is a very dangerous scenario for bitcoin. Since it simplifies the work of governments that might want to control or censor it.

Instead of that, the bitcoin core team of developers actually just adopted another more carefully planned increase strategy that will eventually be equivalent to something close to 4x. This was already a compromise solution and one that actually opens the door to new off-chain scaling technologies.

Off-chain scaling can increase the system's capacity by orders of magnitude, not just simple 2, 4 or 8x. If you want to know more about it just google "lightning network". Beware however that it is a complex topic. Maybe that's the reason most people just dismiss it and tend to go to the simple kick-the-can solution like increasing the base block size.

Basically from my point of view Bitcoin Cash is an amateurish solution to a very complex problem. If adopted, their network will just keep on centralizing more and more (Some believe it is already very centralized). And if it actually gets a lot of traction it will inevitably face the same problem bitcoin is facing in a couple of years. The irony is that they'll be just fine if they fail to gain adoption, since they will remain much more usable than bitcoin.


File format -- rev*.dat Can anyone help me to find out the format of rev*.dat file?

There is an array with [F9BEB4D9 + 32byte number + variable raw data] for each element.

What is that 32b number? And may be how to understand what is the other variable data?

The rev*.dat files (the "undo files"), contain all UTXOs spent by the inputs of a block. It was introduced in Bitcoin Core 0.8, and contains a concatenation of records, one for each block. This mimicks the structure of the blk*.dat files which contain blocks.

Each block record consists of:

4 bytes: network magic (0xf9,0xbe,0xb4,0xd9)
4 bytes: size of the CBlockUndo record (LE32)
data_size bytes: CBlockUndo record
32 bytes: double-SHA256 of the serialized CBlockUndo record

A CBlockUndo record consists of a serialized vector of CTxUndo records, one for each transaction in the block excluding the coinbase transaction. Vector serialization first writes a CompactSize-encoded length of the number of records (the transaction count - 1, in this case), and then serialized all the records themselves sequentially.

A CTxUndo record consists of a serialized vector of CTxInUndo records, one for each input in the transaction.

A CTxInUndo record consists of:

varint: 2*height (+1 if it was a coinbase output): the height of the block that created the spent UTXO
varint: creating transaction's version [only when height > 0]
CompressedScript: spent UTXO's scriptPubKey
CompressedAmount: spent UTXO's nValue

Until Bitcoin Core 0.14.x, the height is zero for all but the last output of a given transaction being spent. In Bitcoin Core 0.15 (to be released soon), it will be present for every spend.

For more information about the detailed encodings, see the comments in the Bitcoin Core source code: CompactSize, VarInt, CompressedScript, and CompressedAmount.


How can bitcoins be used for daily currency if their value changes erratically? If Bitcoin was the worldwide money system...

Suppose that you work and save your bitcoins, to purchase something big like a house or car, but the value fluctuated like crazy, as the stock market does.

Whats to say you wont be rich today, but broke tomorrow? Today you could buy your necessities but tomorrow you would be back to zero?

How can individuals in a society live like that? You would revert back to the caveman system of bartering hard goods for goods in trading because the concept of money would be too erratic.

If Bitcoin becomes the predominant worldwide money system, the volatility due to speculative FX would greatly diminish. The problem is that it is not, and will not likely be the reserve currency any time soon (if ever).

I can not think of any counter-measure within the current design of Bitcoin, except to exchange into dollars (or gold since we are in a gold bull cycle) for storing and only use Bitcoin for a short-term holding for transactions. However, many Bitcoiners ostensibly prefer to speculate on its appreciation and hold it.

Every small cap currency has this problem, because of economy-of-scale network effects they will always be measured against the reserve currency.

This is why there was a U.S.A. Treasury official who was rumored to have quipped in reaction to some smaller country's protest, “it’s our currency, but your problem”.

So the small cap currency has no choice but to try to make itself stable relative to the reserve currency, unless it just wants to be a small cap “investment” speculation. It may be impossible to maintain stability in all scenarios. For example, the Asian Crisis of late 1990s was caused by speculative capital flows, that stampeded to Europe to invest in speculative opportunities opened up by the creation of the Euro at the turn of this century.

This is precisely why I propose an alternative design for Bitcoin.


Is an exchange a good substitute for a mixing service? Isn't an exchange such as MtGox essentially a mixing service? I might be wrong, but can somebody trace coins when they are paid to one address, possibly exchanged, and another amount is paid back from another exchange address back to you? As long as you don't pay back the coins to the same address, and amount is not exactly the same, can this even be traced through blockchain?

Well, "mixing" can be seen as different things. At it simplest, every transaction mixes up your coins a little, especially when you split or combine them. However, what makes a "mixing service" is somehow more specialised.

So, there are several differences with exchanges:

Mixing services usually have a static pile of coins, distributed over a big web of addresses. When you want to mix your coins, the mixing service can do it instantly by distributing your coins into his web transferring them to both new and existing addresses and meanwhile transfer an equal amount of coins to a new address for you by combining small parts from his web. The difference here is that you do not rely on another 3th party that also wants to mix/trade, as you do with an exchange.
Most mixing services have a fixed fee that you pay in Bitcoin. Exchanges may as well have fixed trading fees, there is another cost to consider. You will have to both make a sell order and a buy order to "mix" your coins using an exchange. Even if you make both orders instantly after each other, you will probably lose more than twice the trading fee. This is because there is always a price difference between the lowest buying price and the highest selling price. Furthermore, if you make the trades while the price is raising, it will probably cost you even more.
As Stephen Gornick already mentioned, exchanges keep logs. They usually also require you to verify your identity and this information will be bound to the logs, making the mix all but anonymous. Most mixing services do not require you to have an account at all, they just give you a sending address and ask for a receiving address to which you want your funds back.

As a final note, I want to add that with a good implemented mixing service, the user base of the mixers does not really matter. A good mixer will always have a static web that can be used for each new mix by adding your coins into it and at the same time, picking some random others to combine to an equal output. As long as this static web is big enough, the mixing will be very hard to trace.

There is one thing that could make you vulnerable for trackers. If the mixing service works instantly, the trackers could search for a new address receiving just the same amount as the amount you just spent. This is not hard to do. So, another feature that would make a good mixer, would be the option to give multiple receiving addresses and not executing mixes instantly, but taking a few minutes between funding the different addresses. Note that this can be in favor of an exchange, by which the actual mix is not logged in the block chain, so trackers need to have access to the logs of the exchange to track you.


Lightning Node High Availability/High Throughput Are there any resources/best practises on running a highly available/high throughput lightning node? If my lightning service where to take off, should I be running multiple lightning nodes or a single lightning node? Would it be possible to scale horizontally? Maybe each channel could be managed on a different machine?

So there are a couple things to consider here:

The database, it needs to be remotely available if you are going to failover your Lightning node. We talk about adding support to eclair for a remote database (postgres) in our blog post here
Safely accessing the database. If you have two nodes writing to the database at the same time, it is possible that they write conflicting versions which could result in a penalty transaction on the blockchain. This means you need some sort of locking mechanism to access the database. We have implemented this on eclair as well, you can find the blog post about it here and the actual PR on eclair here.
The final thing that needs to be considered is how to make the key material available in a highly available, yet secure way. This is still something we are exploring at Suredbits. The "dumb" thing to do is just replicate the keys across every node you have.

Now you should be able to spin up an arbitrary amount of nodes. There should be 1 master node that is actively updating the database, and n shadow nodes that are waiting for the master node to fail. For implementing this, you can use something like Amazon's ELB and health check's to determine when the current master node fails, and you should promote one of the "shadow" nodes.

You can see a demo of this here on youtube


How to import a private key in bitcoin-qt? I've a paper wallet with privatekey which is created using coinbase.com. I want to import it in bitcoin-qt but I don't see an option in bitcoin-qt UI.


What the maximum expenditure on a lighting network channel depends on I'm new in the lighting network world, and now I have a question on "How it work", so the light network, work with channel and one node for connection to a channel must spend a little of satoshi for "subscribe" to channel, I hope to understand well.

My question is what is the minimum value the satoshi for "subscribe" to the channel?

Also, with the satoshi, I finance the channel and I can spend the maximum value of the loan, right?

An example, if I have a channel X with 10000 satoshi, I can't spend the value with my node > 10000?

so the lightning network, work with channel and one node for connection to a channel must spend a little of satoshi for "subscribe" to channel

In the current implementation, the spending basically involves only one of the node opening a channel by locking some bitcoins in a multi-sig address that is controlled by both parties of the channel. However, while opening the channel the node sending the bitcoins to the multi-sig address may unconditionally send some bitcoins to other parties side of the channel. In the 1.1 implementation we will have the option where both nodes can contribute to the multi-sig.

  what is the minimum value the satoshi for "subscribe" to the channel?

There is no specified minimum value but the node needs to maintain a number of conditions to open a channel.

You will need to include the amount in funding_satoshis field that can at least cover the transaction fees on-chain to establish the channel.
Since commitment transaction is signed before the funding transaction, the to_remote or the to_local outputs of that commitment transaction should be higher than the channel_reserve_satoshi that you specified in the open_channel message.
If the other node finds the funding_satoshis to be too less, it MAY fail this channel.

However, there is currently a temporary maximum limit of 224 satoshi (0.1677 BTC) that can be used to fund a channel.

  with the satoshi, I finance the channel and I can spend the maximum value of the loan, right? An example, if I have a channel X with 10000 satoshi, I can't spend the value with my node > 10000?

Although the channel has a capacity of 10,000 satoshi, you can spend only the amount that belongs to your side. Also you cannot spend the maximum amount of the channel balance that you have. Your balance need to be at least equal to the channel_reserve_satoshi which is generally 1% of the channel balance. You can spend the rest that belongs to your side. This reserve is kept so that a node has something to lose if it were to try to broadcast an old, revoked commitment transaction.


address format is different from bitcoin core response from btcd For now, I'm generating WIF and address using golang btcutil package programmatically.

    wif, err := btcutil.NewWIF(privateKey, conf, false)
    if err != nil {
        return nil, err
    }
    strPrivateKey := wif.String()

    // Address
    address, err := child.Address(conf)

    walletKeys[i] = WalletKey{WIF: strPrivateKey, Address: address.String(), EncodedAddress: address.EncodeAddress()}

After generating wif, I import this wif using bitcoin client importprivkey

err := b.client.ImportPrivKeyRescan(privKeyWIF, label, false)

And then, I make sure this private key is added into wallet using getaddressesbyaccount "label" command.

Somehow listed address and first generated address seems different.

I'd like to know why it's different.

Thanks in advance.

Addresses are hashed and encoded pubKeyScript. There are different types of address you can derive per a single public-key (or say also private-key). Most prominent ones are P2PKH, P2SH-P2WPKH, native P2WPKH (bech32).

I expect that the address type you are deriving from BTCD is different then the one your getting from Core.

Since a Core 0.16 (until now time of writing Aug 2018), the default address derivation format is "p2sh-segwit" (P2SH-P2WPKH, starting with 3). I could imaging that BTCD still derives you P2PKH addresses (starting with 1).

Since 0.16, Core has that addresstype argument where you can pass in "legacy" or "bech32" in order to generate either traditional P2PKH addresses or new Bech32 ("bc1...") addresses


Is it possible to confirm a specific transaction with your own miner? I sent a Bitcoin transaction a few days ago and it still doesn't have any confirmations.
I actually have a ASIC miner.
Is it possible to confirm a specific transaction, in this case mine, with my miner?

Thanks

You could try to confirm it by mining a block in which you explicitly include said transaction. However, unless you have very powerful mining hardware, it is highly unlikely that you will succeed any time soon to solo-mine a block.

You could either try to double-spend the outputs you used to fund that transaction and for the second one include the correct fee, or just wait until the transaction's priority has risen sufficiently that it will be processed eventually.


Do exchange rates between countries' currencies have an influence on Bitcoin exchange rates? Are the exchange rates of each country a factor in the worth of a Bitcoin? Is the use of Bitcoin similar to traveling to another country and having a exchange rate between paper monies?

Basically, are bitcoins affected by the exchange rates of each country or the web exchange?

Bitcoin follows very closely to USD and RMB, because US and China are the biggest players in the bitcoin market now. You can see the trade charts here: http://bitcoincharts.com/charts/volumepie/

Hence US and China exchange rates will affect the worth of Bitcoin.

In regards to travelling, the merchant accepting Bitcoin will list prices in their local currency. If you pay with Bitcoin, they will use the exchange rate found on one of the exchange networks (e.g. mtgox)


A question about full nodes, lightweight nodes and merkle trees What is the purpose of full nodes storing merkle roots? Why don't they save the transactions only? The hashes could be calculated only when a lightnode asks for them and the merkle roots could be saved only be the lightnodes. Am I missing something here?

I suspect you are confusing merkle roots and merkle trees.

A merkle tree is the binary tree of hashes. The leaves are individual transactions, which are hashed, and then the hashes hashed together until only one hash remains. That remaining hash is the merkle root. A merkle branch is a particular path down the merkle tree from the merkle root to a transaction.

Full nodes store the merkle root because it is part of the block header. The block header contains the merkle root so that the block hash itself will also commit to the transactions contained within the block. While the merkle root itself isn't generally used elsewhere, as part of the block header, it frequently needs to be sent out to other nodes which are downloading blocks. It is expensive to have to recompute the merkle root every time, so instead we just keep it so that blocks can be sent out quickly.

Furthermore, by storing the complete block header, when the transactions themselves are discarded in pruning, the block headers are kept and so that the header chain is still tracked. Without the transactions, it would not be possible to verify this header chain again if the merkle root were not being stored.

Full nodes do not store the entire merkle tree or any merkle branches. These are unnecessary for normal operation. When a SPV client asks for a merkle branch, it is computed on the fly.


Was there ever reasoning presented for the size of a satoshi (i.e., the minimum amount of bitcoin that can be transacted)? If not, what are the prevailing critiques and concerns of that design choice?

Like most of these internal choices in the Bitcoin system, it's not really explained by the author and can't be easily changed even if anybody had a strong objection to it. Internally all values are 64 bit integers, and just displayed to the user as value / 1e8.

The original wxBitcoin releases displayed two decimal places of precision.


Are there any downsides to banning node crawlers? There are multiple entities and open-source software that crawl the Bitcoin P2P network to discover and monitor nodes for various purposes (statistics, surveys, academic papers etc.)
Some of those I am aware of:

btc_node_scanner
dsn.tm.kit.edu
nodes.multiven.io
bitnodes.earn.com
bitnodes.io

Banning such nodes would free my connection slots for real useful nodes that actually provide consensus sourcing.
But, is there any downside to banning such crawler nodes?

Also, what about banning btc-seeder nodes? Would that affect negatively the health of the P2P network?

I think the ideal answer could provide the effects to two cases:

banning done by one user and how they are affected
banning done by a grand/meaningful number of users and how the overall network would be affected

Thank you

It would be hard to specifically ban crawlers as a practical matter because there is no reliable way to differentiate them from other normal nodes. They can, in fact, just be normal nodes that instrumented with code to collect the desired data and report it back to an aggregation system.
So then you are left with banning normal nodes. Since all of the value of running a node comes from its connectivity to the P2P network via other nodes, this would not make sense.


Recover Old Bitcoin Wallet (Currently getting a Segfault) I have a bit of bitcoin lingering in an old bitcoin wallet (circa 2011). I just restored it from a backup but I can't seem to load it into bitcoin-qt.

If I launch the app, shut it down, the copy in my old wallet.dat file and re-open, it shows a zero balance.

If, instead, I shut it down, copy over the entirety of my old .bitcoin folder, and then re-open, I get an immediate segfault. How screwed am I?

You may find the following post relevant:

Wallet.dat (<0.4.0) format: retrieving Bitcoin, possible security concerns

This post details some of the steps you may need to perform to import the wallet into a current client, the biggest time consumer will be waiting for the full blockchain to sync with the current network.


How is bitcoin sent into my bank account? I've been trying to find a way to transfer bitcoins from my bitcoin wallet into my bank account, I've gone to a couple sites that kinda use a similar method, but I don't really understand how it works.

One of them is exkash for example, seems legit but don't I have to give them my bitcoin address before giving my bank details so that they know where the bitcoin is coming from or do they just send the amount that I enter, If so where is the money coming from.

Traditional banks don't hold bitcoin in their accounts, so you can't send bitcoin to your account.  What you can do is sell your bitcoin for fiat currency and have that fiat deposited into your bank account.  There are many companies willing to buy your bitcoin for fiat currency.

As for giving out your address for a transaction, that is not something you need to do when you are sending bitcoin to someone.  Bitcoin is a system where you push funds to someone, rather than give them the credentials to pull them from you.  Afterwards, they will be able to determine your address, but that isn't really the mechanism you use to pay someone, nor is it important to the recipient.  This is similar to if you pay someone with cash.  Afterwards they will be able to see the serial numbers on the bills, but they don't care, nor were those numbers needed by them for the transaction to occur.


How can i set fee permanently via paytxfee command I have set default paytxfee of 0.001 in bitcoin.conf file. I have updated paytxfee value via bitcoin-cli paytxfee 0.1 when I restarted bitcoin core value reset back to 0.001. is there is anyway i can set fee permanently.

You can do one thing when running bitcoin-cli paytxfee 0.1 command, you can run command to update value of paytxfee inside bitcoind.conf file.

like this:

bitcoin-cli paytxfee NEW_AMOUNT && sed -i 's/paytxfee=OLD_AMOUNT/paytxfee=NEW_AMOUNT/g' ~/.bitcoin/bitcoin.conf

This will set fee for current session also when you restart bitcoin core price will not alter.


RegTest with mainnet addresses I am trying to run a private Bitcoin network for testing.
I tried to run a RegTest network, but I need the addresses to be in the format of the ainnet.
Can I configure the RegTest to run with Mainnet addresses?

Thanks!

Solved it!

I downloaded the bitcoin core source code,
changed the regtest node address parameters to be like the mainnet in the file src/chainparams.cpp.

Then compiled it, run the node on regtest and it worked like magic!


Anyone know of an API for RSI and other indicators? I am looking for Relative Strenght Index and other market indicators API's for cryptos. I don't think TradingView provides one but maybe you know one?

I had the same problem, couldn’t seem to find a good API that supported most of the popular indicators, and at the same time covered all the exchanges. So I decided to start up a project for this. So check out https://taapi.io . We cover 200+ indicators, pattern recognitions etc… I’m a big fan of free products myself, so taapi.io is free as well.

If your indicator isn’t there, then shoot us message, and we’ll get it added!


Is there a maximum factor by which difficulty can change? I seem to recall, long ago, being told that difficulty couldn't change more than a certain amount at each retarget, but I can't seem to find what that factor is (or even confirmation that such a factor exists) no matter how hard I google. Does such a factor exist and if so what is its value?

The difficulty never changes by more than a factor of 4 (except for in a special case that only applies on testnet).

The code that enforces this is here.


How to avoid price pumps & dumps when trading with bot? Recently I recieved $500 USD in credits for trading with Coinsetter, a NYC based bitcoin exchange, so I decided to use them and coded a bitcoin trading bot for myself (never have done such thing before); The problem I'm having right now is that my bot seem to be "buying higher, selling lower" and I don't know why, you see:

If I go to the bot's logs, I get something like this:

The prices shown there are the prices at which the market order is requested, (giving an invalid price as an argument for the API request supposedly results in a failed order, so I request the live price first from coinsetter twice before I do a buy/sell operation); BUT if we go to the coinsetter transaction history we have this instead:

So everytime I do a BUY I pump up the market, and every time I do a sell I dump it, how can this be avoided? I'd prefer buying at the lower prices and selling at the higher ones.

P.S. Another question would be: What you think is the real price at which I'm buying/selling? The price I REQUEST or the price coinsetter tells me at it's history?

Thanks for your advice.

In a normal exchange, you have an order book of buys and sells. Usually, they don't cross over, that is, if the highest buy is 219, the lowest sell will be higher than that.

What you're doing is buying at market (aka market order) so any buys you do simply match the lowest sell and any sells you do simply match the highest buy. Whenever the two cross, they are simply filled by each other, so the gap will be there 99% of the time.

What you can do if you want to avoid this is to use limit orders. Generally, though, you have to wait for them to fill as you need price movement in order for that to happen.


Is it possible to increase the prune size and get bitcoind to pull previous blocks? for example, currently its:
  "size_on_disk": 32084546902,
  "pruned": true,
  "pruneheight": 650668,
  "automatic_pruning": true,
  "prune_target_size": 67108864000,

Is there a way to decrease the pruneheight? I need the prune height to be 630000.
I increased prune=64000 from prune=32000 but from what I can tell it will just store more blocks going forward?

Bitcoin Core doesn't have such a feature. The prune depth controls how many blocks are kept, and you can change that (-prune=N option on the command line or prune=N in bitcoin.conf), but once a block is pruned, it is gone. If you want to add blocks back, for now you'll need to resync from scratch.
There is no technical reason for this; it's perfectly feasible to implement a mode where desired old blocks are refetched and inserted into the blocks datadir again, but this simply isn't implemented at this point.


How do off chain transactions work? Some wallets (such as inputs.io) claim to provide off-chain transactions. Note: I have not used that wallet yet.

Say if I have a Bitcoin address A in such a wallet provider and send 1 Bitcoin to address B from the same wallet provider, what will show on the public blockchain?

Will there be 1 Bitcoin in B on the public blockchain?
If yes to 1, will that Bitcoin show as coming from A?

There will have to be a public record of a transfer into address B before any transfers can come from address B.  Internally the provider may move the funds from one address to the other "off-chain" for purposes of display but until some BTC moves into address B publicly it can't be spent from B.

Most likely when you attempt to send BTC externally from address B, that amount will either be:

1) transferred publicly from A to B and subsequently from B onward (incurring 2 transactions and twice the confirmation delay)

2) transferred to a provider address from address A and be internally deducted from address B inside the provider system and actually transferred from some other provider address

3) publicly paid directly from address A but shown as deducted from B in the provider system

Off-chain transfers are one way to add additional anonymity to Bitcoin transactions but at some point the source address has to be publicly credited with BTC for the exchange to be valid in the block chain.


What changes did segwit do to minimum transaction fee? If I understand this correctly, at the beginning, the minimum fee was 0, than it was .0001. Now, I can see that you can enter some really small amounts as fee for the transaction, however, with current congestion, I'll have to wait forever to find out if a transaction with 1 satoshi fee will be actually included into the blockchain.

Can anyone clarify.

Is it true that SegWit has significantly decreased the minimum fee that must be paid for the transaction to be included by miners in the block?

As you point out, paid fees result from two phenomena:

Full nodes on the network enforce a minimum feerate for relay, which in recent history has been 1 satoshi per byte.
Miners sort unconfirmed transactions by fee per byte, and include the highest ones first in blocks (whose size is limited to 1000000), as this maximizes their income. This results in a fee market where transactions pay according to supply and demand for space in blocks.

This means that while 1 sat/byte is the minimum to be relayed, it's not enough to actually get into a block, and as a result this minimum has become mostly irrelevant.

SegWit did not change these processes. There is still a minimum feerate of 1 satoshi per byte, and there is still a fee market.

What did change is the definition of size of a transaction. In SegWit, a significant portion of the transaction data is moved to the "witness", whose size only counts at a rate of 0.25. So for example a 200-byte non-SegWit transaction would be counted for the full 200 bytes, and 5000 of them would fit in a 1M block. If this were an equivalent SegWit transaction, maybe 120 out of those 200 bytes would be in the witness, resulting in an effective size of 80 + 120*0.25 = 110. Now 9090 such transactions fit in a block. The result of this new rule is that the optimal selection policy for miners also means looking at fee per byte, where bytes refer to this modified definition that discounts witnesses.

TL;DR: SegWit makes transactions cheaper by discounting portions of the data.


Bitcoin arbitrage, what do exchange office alows you to cash out? I am wondering, if I do BTC arbitrage, meaning I buy BTC in one exchange, send to a second exchange and sell for FIAT, does the second exchange have any problems with me doing this? Because I will be only using them to sell  my BTC, so I will be cashing out a huge amount of money every month.

What is your opinion on using exchange office just to cash out?  And what do you think, they let you cash out monthly?

Every exchange has its own rules, but generally they allow you to import bitcoin from any source and sell it. Where they tend to differ greatly is the amount that they will let you withdraw to your bank account either daily or weekly. For example, gdax/Coinbase greatly reduces the amount you can withdraw if your account is not verified, meaning, you need to upload identity documents. I believe they limit you to $1000 per day, buy/sell, and additionally limit you to $1000 per day withdraw. However, if verified, buy/sell is unlimited and withdraw is $50,000 per week.


Does Bitcoin Core validate signatures by default? There have been claims recently of Bitcoin Core not validating the signatures in a block by default. If this is true, can Bitcoin Core even claim to be a full node?

Bitcoin Core does validate all signatures after a certain point, and can be configured to validate all signatures in history if so desired.
The assumevalid feature only disables signature validation for blocks prior to a specific configured block which is updated for each version. This block is typically several (tens of) thousand blocks deep by the time the release is actually made. Any block which is an ancestor of that particular block (and that block is in the main chain) will not have the signatures checked. All blocks that come after it will have their signatures checked. This means that once your node is synced, all new blocks will have the signatures checked.
Furthermore, this assumevalid is not a checkpoint nor does it operate on block heights. If, for some reason, there was a reorg which removed the assumevalid block from the main chain, then all signatures in the blockchain would be validated. It is merely an optimization and does not affect the security of your node.

can Bitcoin core even claim to be a full node?

Yes, there is more to being a full node than validating signatures. There is more to validation than just signatures. Bitcoin Core still checks the PoW, that the outputs being spent existed, etc.


Getting address balance that not exists in my wallet When im trying to get balance of remote address I'm getting an error, this address not exists on my wallet and I want to follow her balance.

This is what I tried:

bitcoin-cli getreceivedbyaddress "1FJhBusrEHPZVTey5Q7zb3ZND86nYWrNV2" 0

And this is the error that I'm getting:

error code: -4
error message:
Address not found in wallet

I know that this address is not existing in my wallet but i do want to follow her balance.

You can use the command bitcoin-cli importaddress to watch addresses that your wallet does not control. This command will generally require a rescan of the chain, which can take some time depending on your computational resources.

Note that if you happen to know which blocks contain transactions related to the address in question, you can turn off the rescan when importing the address, and then separately run a rescanblockchain command to only search the necessary blocks. This can greatly reduce the rescan time.

Here is a dump of bitcoin-cli help importaddress, running bitcoin-core v0.17.0.1.

importaddress "address" ( "label" rescan p2sh )

Adds an address or script (in hex) that can be watched as if it were in your wallet but cannot be used to spend. Requires a new wallet backup.

Arguments:
1. "address"          (string, required) The Bitcoin address (or hex-encoded script)
2. "label"            (string, optional, default="") An optional label
3. rescan               (boolean, optional, default=true) Rescan the wallet for transactions
4. p2sh                 (boolean, optional, default=false) Add the P2SH version of the script as well

Note: This call can take over an hour to complete if rescan is true, during that time, other rpc calls
may report that the imported address exists but related transactions are still missing, leading to temporarily incorrect/bogus balances and unspent outputs until rescan completes.
If you have the full public key, you should call importpubkey instead of this.

Note: If you import a non-standard raw script in hex form, outputs sending to it will be treated
as change, and not show up in many RPCs.

Examples:

Import an address with rescan
> bitcoin-cli importaddress "myaddress"

Import using a label without rescan
> bitcoin-cli importaddress "myaddress" "testing" false

As a JSON-RPC call
> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "importaddress", "params": ["myaddress", "testing", false] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/


Generating a BCH address offline To generate offline BTC addresses, I use the bitcoin-core app from bitcoincore.org.  What is the BCH equivalent of this?

Is it the bitcoin-unlimited app?

Yes, bitcoin-unlimited lets you create BCH addresses offline.


Where can I find well-written criticism about Bitcoin? I couldn't find an article about criticism in the wiki. Is there some other place that contains well-constructed criticism for Bitcoin?

Here's the page on the wiki where weaknesses are addressed.


Why did I pay 8.7% in miner fees? Yesterday I did my first Bitcoin transaction for something physical. I bought a couple of drinks at a pub.

I was shown a QR code which I scanned with my Blockchain.info iPhone app. What caught my eye in the transaction were the miner fees of 0.5 mBTC / 5.7 mBTC = 8.7% (much larger than the 2-4% fee for credit cards).

Is it standard to pay such high miner fees for physical items to expedite confirmation? Did the QR code dictate the miner fee I had to pay, or was it the iPhone app?

It was the suggested fee that your app set, I believe you can also customize fee size on most apps, but the suggested fee is for confirming the transaction ASAP. I believe POS stuff like that doesn't really care for confirmation time so you can safely set a lower fee.


How is crypto being priced at introduction? If a crypto currency starts at value $0,0001 and it is $1 today, is it fair to state the growth has been 1,000,000%? Mathematically it is correct, but are all these coins available publicly at the introduction price?

With regular stocks, a price is set at introduction (public offering) and growth is offset against that introductory price. How does this work with crypto?

Here's the way it works in theory (and in fact how it worked for bitcoin):

0) initially there's no market, no trades, but there is a cost of producing the item. You might ask why anyone would make something that costs money but can't be sold - nerd enthusiasm

1) trade offers at specific prices are made. These were based on the cost to produce. Offers are not accepted yet. At this stage you could say the market exists.

2) the first trade offers match and execute. At this time the exchange rate is 'discovered' (at least the first guess at it anyway). Not sure if it was the first, but the most famous early price defining transaction for bitcoin was the trade of 2 family sized pizzas for 10000 bitcoins. The pizzas were priced in USD so the trade discovered the BTCUSD pair exchange rate. The 10000 was loosely based on electricity cost to produce the bitcoins.

In the current environment things work the same - people make offers and the market discovers the best price.

To the first part of your question, you can now see that the 'growth' is anywhere from undefined, thru infinity, down to some discovered value. It's pretty meaningless to apply it to early markets.

You ask if all coins are 'available at the introductory price' but the market price is dynamic and is determined by the demand and availability. Sometimes there are offers made to supply a fixed number of items at a specified exchange rate, but this is before a market is open.


Have a 0/unconfirmed transaction stuck over 12 hours This is my first time using bitcoin and I've had a transaction stuck for over 12 hours.   Any help getting confirmed would be appreciated.

https://blockchain.info/tx/0b17a765b1f4a1a7e53a47b6da287b86211ea64126192ffc26a1d6d8920eab7a

I ran bitcoind with the --zapwallettxes flag and recovered the coins.  Thankyou for the help


Bitcoin: Why can the difficulty parameter not be ignored? by the longest-chain-rule, the chain with the most blocks is considered to be the main chain in Bitcoin. I understand that an adversary needs to have more than 50% of the network's computing power in order to create its chains faster than the rest of the network. Those chains become the main chain under the longest-chain-rule.
However, that implies that the adversary sticks to the network's difficulty setting. If it didn't, it could create longer chains using much less computing power.
I wonder: Why is this setting (an adversary ignoring the difficulty and mining a long chain) not considered? Nodes that freshly join the network don't know about the difficulty and, according to the longest-chain-rule, must choose the adversary's chain.

It isn't strictly the longest chain that is chosen, it is the chain that has accumulated the most work (proof of work).
The reason miners can't fake the difficulty is that every node checks the difficulty of every new block. An attacker who faked this would never be able to spend the proceeds and would become isolated from other nodes as a known bad node.
Nodes that freshly joined do know the current difficulty. It is simple to calculate, I think you only need check a few peer nodes to find a relatively small amount of block-header data from the blockchain. That takes very little time.

The difficulty is adjusted every 2016 blocks based on the time it took to find the previous 2016 blocks.

So, (hat tip to Murch for clarifying comment) as the difficulty only changes every 2016 blocks and block headers contain a timestamp and the difficulty target, you just need the headers of a few blocks prior to the block being checked. This is a tiny fraction of the ~650,000 blocks created so far in the blockchain and so takes negligible effort compared to syncing a local copy of the full blockchain.
Even if newly joined nodes were ignorant, the vast majority of nodes are not newly joined and would result in the faked block being completely useless and irrelevant due to being independently checked and rejected by virtually all nodes.
Miners are producing a kind of hash of a set of data. The carefully chosen mathematical functions make this hash extremely expensive and time-consuming to create but extremely cheap and quick to verify.


Can I run bitcoind without downloading new blocks? I want to run bitcoind to interact with the daemon, but having bitcoin download new blocks and verify them is taking a toll on my CPU. I do not want the latest data - I just want the daemon to be running. Is there a way to prevent bitcoin from downloading new data?

Essentially, you want to run bitcoind while connected to the network to download all the blocks, then disconnect it from the network so it no longer downloads new data. There are several possible ways to do this, from least to most drastic:

Use the -proxy option to specify a proxy that does not exist.
Use a software firewall to prevent bitcoind from communicating with the network.
Run bitcoind in a virtual machine and turn off its network access.
Physically disconnect the machine from the network.


Get transaction history of address using electrum commands I am using electrum protocol to query history of a bitcoin address using blockchain.address.get_history.

All is good I am receiving the tx data for every transaction. My problem is that I unable to figure out a way to get the fee and transaction details for every tx received. ( I want to use same stratum protocol if possible )

Thanks

You can calculate the fee by taking the sum of the value of the transaction inputs and subtracting that from the sum of the value of the transaction outputs. The fee is really just the leftover amount of a transaction that is not specifically sent as an output.


Blocks are usually sent using BIP152. This transmits blocks using an 80 byte header, 6 bytes per transation, plus the coinbase transaction.  To give a concrete example block 000000000000000000117f0033fd8cff18a9fa4601da7f93e6eb3e084caab586 took 16244 bytes to transmit.

If sending to a peer that doesn't already know the transactions (or not supporting BIP152) the node sends the raw block, which is half the size of the hex.  In the case of that block the raw block is 1,125,118 bytes long.


How do I identify my IP address on bitnodes? I have supposedly successfully setup a node using the Bitcoin core, but when I go to bitnodes to remotely see if the node is communicating with the network, bitnodes says i am unreachable. Bitcoin core disagrees. How can I find my node's unique address? Using cmd to run a netstat query shows me an ipv4 address that is also unsearchable with a fluid port range (49800-49950).

Something tells me I know just barely enough about networking to be dangerous.

If you are on a NAT network (192.168.****  or 10.*******) then use port forward in your router/modem and open 8333 in your firewalls.

Not behind NAT? Check all your firewalls and add a 8333 exception when needed