Are there any risks to giving someone your wallet address?

As long as you make sure you give them a new Bitcoin address (not one you're used in the past) there are no risks in just giving them an address.
If you give them an address you're used before, they may be able to see some of your old payment history.
A scammer could try to convince you they've paid you when in reality they haven't. To avoid that, give them the new address, check for the payment on your own wallet or a trusted blockchain explorer, and don't click links they give you to "prove" they've sent the money or believe that they've sent you money until you see the coins on your own wallet or blockchain explorer yourself.


The base58 private key format includes an SHA256-based checksum.  See this answer for details (disregard the part of the question where the private key itself is the SHA256 hash of some other data).


What will happen when nLockTime is used along with Counterparty transactions

Disclosure: I work for Coinprism.

Counterparty uses the Blockchain for timestamping only. It doesn't use it as a ledger since it builds it's own "parallel" ledger.

As a result most advanced functionality of the Bitcoin ledger can't work on Counterparty:

nLockTime
SPV
Payment Channels and lightning networks (very important for scalability)
Unconfirmed transaction chaining (important for mobile payments and fast transaction processing)

If you want to be able to use all bitcoin features out of the box, you need to look at colored coins.


It's like two people holding on to the same $20 bill and each of them saying, "see, I have 20 dollars!".

Bitcoins can be spent/accessed by anyone that has the private key to unlock them. If two computers have the same private key stored, then they can both access the bitcoins. If one wallet spends the bitcoins, the other wallet will show them as spent as well, just like one person spending the $20 bill means it is gone for the other person.


Is it OK not to sort transactions at all?

As long as all selected transactions are valid, you may select any transactions you want.

You should check that there are no double spends among the selected transactions and that you keep any transactions which build on each other in the correct order, i.e. if TX B spends an output of TX A, TX B has to be listed after TX A in the block if you select both.

Sorting them by fee rate (i.e. fee paid per data size or satoshi per byte) will greedily maximize the transaction fees that you collect per block, to optimize block usage while maximizing fee, you'd have to perhaps use a knapsack solver.

Priority was turned off by default in Bitcoin Core 0.12.0, I actually asked a few months ago whether any miners still select by priority.


How do you set up Pushpool/Litecoin for windows?

It can be done. There are windows equivalents for all of the programs you need to install.

Cron. Normally, I'd tell you to use the task scheduler, but it looks like the program you linked needs to run stuff every 5 - 8 minutes. This tool seems to do  what you need. You'll need Perl too.
PHP. Note that you need to use the command C:\PHP5\php.exe -f  instead of php.
MySQL.
Apache2.


Why do we inverse the hash of the blockheader?

Why do we not accept a hash that ends with all those zeros? Is it because it's easier for a program to calculate if hash < expected_hash?

Counting the number of leading or trailing zeroes does not give a lot of granularity. If represented as a hex number, then there are only 64 possible target values if you are counting just the number of zeroes. If in binary, that is 256 possible values. Furthermore, counting the number of zeroes means that you can only change the difficulty by some power of 2 (in binary, the difficulty has to be doubled or halved). There are thus not many values for the target and this loss of granularity is bad.

Conversely, comparing the value means that there are (in theory) 2^256 possible values for the difficulty. This is much more granular, and these values are integers. Instead of having to change the difficulty by multiplying, the difficulty can be changed with addition and subtraction. By having more values, the difficulty will be less likely to be too hard or too easy.

  But in this case, I don't understand why do we do not simply accept a hash sha256(sha256(header).digest()).digest().encode('hex') that is lower than the expected hash? The probability to get that should be as high as the inversed one.

It is actually just like you said. The reversing of the hash is only for how the bytes are actually represented. They are stored as bytes and interpreted as a little endian 256 bit integer. The comparison is still an integer comparison and the data representation is irrelevant (they could just as easily be stored and represented as big endian integers). But when they are displayed, they are displayed as big endian values in hexadecimal because humans are accustomed to big endian. The reason for little endian is likely because the x86 architecture uses little endian for storing integers.


With HD wallets you get a new address for each payment request so there is no need to paste a previous address


The fee is the sum of unspent value in a Transaction.

Aka the value NOT SENT by your outputs.

  fee = in - out

For an example,  if we assume the input aa94ab02c182214f090e99a0d57021caffd0f195a81c24602b1028b130b63e31, 0 has an unspent value of 15000...

var txb = new bitcoin.TransactionBuilder()
txb.addInput('aa94ab02c182214f090e99a0d57021caffd0f195a81c24602b1028b130b63e31', 0)
txb.addOutput('1Gokm82v6DmtwKEB8AiVhm82hyFSsEvBDK', 15000)

When we send 15000 to 1Gokm82v6DmtwKEB8AiVhm82hyFSsEvBDK, the fee is the value of the inputs minus the value of outputs.

  in:15000 - out:15000 = fee:0

For a fee to be non-zero, in > out is required.


No sign of my private keys in Electrum wallet ... where do I find them?

You ask a lot of things, so I'll explain how Electrum works for you and hope it is what you need.

Electrum uses a seed (twelve words length password). Your private keys are derived from this seed every time you make a transaction.

The only thing you need to spend the coins received in your Electrum addresses is that seed. You can export the private key for one of the addresses in your wallet, but you should not do it. Keep your Electrum private keys PRIVATE.

You can also import a private key from another wallet, e.g Blockchain.info to be able to spend the coins in that address. It will be added to your wallet as a imported address, imported addresses behave kinda different to Electrum seed addresses. So keep a copy of the imported private key, just in case.

You will always be able to restore all your Electrum addresses using your seed, but not the imported keys, as they are not on your seed.


Can someone explain me ECDSA (creating public from private key) with 8-bit numbers?

It's my opinion that mechanical explanations of ECC are almost completely worthless to people, and mostly just generate false understanding.  Exactly how two points get added to each other isn't an important thing to understand in order to understand ECC any more than understanding van der waals forces is important to someone trying to oil paint. So my advice is to find explanations that talk about the abstract algebra of ECC rather than the mechanics of group operations. :)

But some people just love the mechanics.  So if you must, find a tutorial that uses secp256k1 (the 'bitcoin' curve) and replace the field size P  with 79 (so you would be doing arithmetic mod 79 instead of 115...663), and N with 67 (instead of 115...337).  'a' stays 0, 'b' stays 7. For G you might choose {60, 10}.

The resulting curve should have all the same algebraic properties as secp256k1 (except for being discrete log insecure due to being so small). To check your math, G * 29 = {37, 10}. Meaning that the pubkey for private key 29 is the point at {37, 10} with the above parameters.


Payment channels with dynamic signatures

It's possible for Alice and Bob to agree among themselves to pay Carol and any number of other recipients (subject to limits on transaction size).  However, it's not possible for Carol and other additional recipients to receive those payments with the same trustless security available to Alice and Bob through the payment channel construct.

Alice and Bob open a channel by committing funds to a multisig address that requires signatures from both of them in order to spend.  For Alice, this guarantees that her consent is required for any transaction spending the funds to be valid.  Bob receives the same guarantee that his consent is required.

The innovation of bi-directional payment channels (including, but not exclusively, those used by Lightning Network) is that each payment in the channel can be revoked by the recipients, allowing a subsequent payment to take its place.

The encumbrance (redeem script) that protects a revocable payment is larger than a normal Bitcoin encumbrance, so the most desirable end to a payment channel is a mutual close where the last revocable payment is revoked and converted into a non-revocable payment that looks like a normal Bitcoin 2-of-2 multisig spend.

The only known way for revocable payments to work is for each party to have a complete list of every payment ever made and (if it has been revoked) what data is necessary to revoke it.  This is what prevents Carol from having full payment channel security.

Alice and Bob can both mutually consent to paying Carol and they can tell Carol about this payment.  If the transaction containing that payment gets broadcast, Carol gets her money.  But because the multisig address to which the funds were initially deposited only requires Alice's and Bob's mutually consent to create other payments, they can create other payments in secret from Carol.

If one of the secret payments created between Alice and Bob gets broadcast, Carol doesn't have the data necessary to prove on the block chain that it was made fraudulently.  Alice and Bob can thus, by mutual consent, steal Carol's funds.

A more conceptual way of looking at it is to envision the block chain as a trust anchor for payment channels.  You need to have some degree of control over that anchor in order for you to be able to trust the resultant channel.  Alice and Bob have that because their consent is required to use the anchor; Carol does not have any control over the anchor and so cannot trust it.


private key to wif - need help converting to base58encode (step 6 to step 7)

Version byte 0 is for addresses, for an uncompressed private key you want 128.

https://en.bitcoin.it/wiki/Base58Check_encoding#Version_bytes


Why is 6 the number of confirms that is considered secure?

I believe this is addressed in page 8 of Satoshi's Bitcoin paper when showing the probability of an attacker catching up.

The wiki states:

  "Only 6 blocks or 1 hour is enough to make reversal computationally impractical."

The key word is "impractical".

The important sentence in Satoshi's paper is:

  "Assuming the honest blocks took the average expected time per block, the attacker's potential progress will be a Poisson distribution".

So, it is not that someone couldn't create the worlds first and own a $50 million ASIC farm, so as to have the ability to overtake the blockchain from a fork six blocks prior but that doing so would be a.) a massive undertaking, b.) obvious to all and c.) terrifically unprofitable to the attacker.


Is this a usable systemd startup script for bitcoind?

I haven't tested this particular systemd service file, but from my experience in Ubuntu, you need to create the directory structure beforehand and the user running bitcoind would need write permissions to /var/lib/bitcoind/. Otherwise the service will end with errors and will not run.

If you start bitcoind as user bitcoin, the daemon by default will look for and use /home/bitcoin/.bitcoin, which will inherently have write access. For simplicity, I suggest you point to the .conf created in this directory. I also suggest placing the pid file in this location.

I am not aware of any security vulnerabilities of using the user's home directory for -datadir and -pid, as those locations need to be write accessible to user bitcoin wherever you put them anyway; I'd actually like to see a discussion on this topic. Using the settings suggested in that systemd service file would mean you'd have to give user bitcoin write access inside a directory that is normally modifiable by root only.

Consequently, I suggest a slightly modified systemd service file:

[Unit]
Description=Bitcoin's distributed currency daemon
After=network.target

[Service]
User=bitcoin
Group=bitcoin

Type=forking
ExecStart=/usr/bin/bitcoind -daemon -pid=/home/bitcoin/.bitcoin/bitcoind.pid \
-conf=/home/bitcoin/.bitcoin/bitcoin.conf -datadir=/home/bitcoin/.bitcoin -disablewallet
PIDFile=/home/bitcoin/.bitcoin/bitcoind.pid

Restart=always
PrivateTmp=true
TimeoutStopSec=60s
TimeoutStartSec=2s
StartLimitInterval=120s
StartLimitBurst=5

[Install]
WantedBy=multi-user.target

Note that if you place PIDFile= before ExecStart= you will get a warning in the log, but the service will run anyway.

There is this current template https://github.com/bitcoin/bitcoin/blob/master/contrib/init/bitcoind.service,
maybe you can take some security improvements from there as well. This template uses RuntimeDirectory=bitcoind to create /run/bitcoind owned by bitcoin (and places the pid file in there). It places bitcoin.conf probably in a read only environment, and ommits -datadir, which will in this case default to /home/bitcoin/.bitcoin.


ZMQ Raw TX doesn't include all transactions

There is a limit of how many messages can be in the ZMQ:

http://api.zeromq.org/2-1:zmq-setsockopt

  The ZMQ_HWM option shall set the high water mark for the specified socket. The high water mark is a hard limit on the maximum number of outstanding messages ØMQ shall queue in memory for any single peer that the specified socket is communicating with.

So you might need to specify the option -zmqpubrawtxhwm to something that is larger than the default of 1000.


How to overcome the 21M limit of Bitcoins as adoption increases?

A single Bitcoin is currently divisible up to 8 decimal places (giving you 21*10^14 units of money, or about 2.1 quadrillion units), nothing stops it from being divided further with small protocol change. In order to change the limit of Bitcoins created, one needs to change the protocol and force most of the Bitcoin network to adopt the change, which can be quite hard to do. This hard limit of the amount of Bitcoins is one of the features of the system, not a flaw - it is meant to fight against inflation. If for some reason you want a cryptocurrency without a limit (hint from Lohoris: you don't), try browsing for alternatives.

All in all, there will be enough Bitcoins to go around for everyone for a long while.


The version you are using is the latest version

It supports OpenCL GPUs.

Which includes Intel HD Graphics 4000.

There is no information of Bfgminer discontinuing GPU support anytime soon.


Current blockchain.info wallets use the BIP39 wordlist, which you can find for various languages at https://github.com/bitcoin/bips/blob/master/bip-0039/bip-0039-wordlists.md/

Previous versions have used non-standard implementations with a variety of different wordlists for example v2 and v3.


Is it possible to watch the chain to count the number of Lightning channels?

They can only be detected when force closed and there are still pending htlcs otherwise they look like a spend from a 2-2 multisig wallet. I've been told some people try to do chain analysis and machine learning to predict private channels. I highly doubt that this is reasonably possible.

Although there is one thing to consider. If a node has public and private channels the funds get mixed. Implementations currently do not do separate bookkeeping of those outputs which is a privacy issue and an attack vector for what you want. However if a new ln node is set up and it only has private channels it will be hard to detect those on chain (unless the Chanel partners later reuses / mixes the outputs with some fire public channels.


Performance and modularity of Bitcore vs Toshi

Both are implementations of the Bitcoin protocol, however they are customized to make it easier to develop with. They are able to do this by storing all transaction and blockchain data in a database for quick queries, and along with this comes large disk space requirements (200-300GB).

Bitcore (I have used)
- NodeJS
- 200+GB required for storage as it holds all transaction data.
- Bitcore also has a library-only version (not a node), and a public API.
- Add-ons available (Block explorer API, UI & and Wallet Service)

Toshi (I have not used)
- Ruby
- 300+GB required for storage as it holds all transaction data.
- Toshi has a public API. As far as I can tell it does not have a library-only version like bitcore.
- A block explorer API and UI available. No wallet service, that has to go through coinbase which requires an application, credit check, etc.

As for your question about performance I can't really say since I haven't used Toshi, but Toshi's Github hasn't been worked on in over a year with only 200 commits. Bitcore is constantly being worked on with over 1,600 commits some as recent as 6 days ago.

Also I'd say outside usage would be a good guide as to which one performs better. I'm not aware of any well-known service using Toshi.

Localbitcoins uses Bitcore for their explorer.  https://www.localbitcoinschain.com/
Counterparty uses Bitcore http://counterparty.io/news/counterparty-uses-bitcores-insight/
SatoshiLabs(TREZOR) uses Bitcore http://themerkle.com/satoshilabs-unveils-mytrezor-beta-and-switches-to-bitcore/


Duplicate ANY transaction from Bitcoin to Bitcoin Cash.. is it possible?

No, transaction will not be approved. There are differences in transaction format. Transactions are not valid between 2 forks.


How does a wallet use unconfirmed outputs as inputs after unconfirmed transactions?

Is the wallet using unconfirmed outputs as inputs here?

Yes.

  If so, how is it doing this

Except for coinbase transactions, transactions are independent of blocks. A transaction spending an unconfirmed input looks exactly the same as a transaction spending a confirmed input.

It's safe for Bitcoin-Qt to spend unconfirmed change because it knows that the input is valid and will be confirmed at some point (though probably slowly). It would not be safe for Bitcoin-Qt to spend unconfirmed inputs that it did not itself create because they might never confirm, resulting in permanently tied-up funds. (Very old versions of Bitcoin made this mistake, but it was corrected after widespread issues.)

  how can I do it using raw transactions?

You can create the transaction with createrawtransaction normally, but you'll need to give signrawtransaction some extra info about the unconfirmed transaction in its second parameter.


Why does bitstamp have two addresses for Ripple?

They use hot and cold wallets for security reasons. The address you trust can create an infinite number of IOUs and so its key must be carefully secured. The address they transferred to you from must be able to perform transactions easily and quickly and so cannot be fully secured.


Serialized transaction bigger than the actual transaction object? CVE-2013-4627

Yes. The attack was adding junk to the end of otherwise valid transactions to cause the junk to get relayed around. (as an aside, if we hadn't fixed that, segwit would have been easier to deploy...)


What's the easiest way for a third party to malleate a transaction?

The easiest way to malleate a transaction is to just change the signature from Low-S to High-S and vice versa.


I’ll pay whomever can help me Bitcoin Cash from blockchain wallet to Coinbase wallet with Bitcoin address

Talk to Coinbase Support center they will surely help you because it's impossible to transfer your credit without there help


Minimum number of transcation in blocks one must include?

A block is required to have one or more transactions. The first transaction must be the coinbase. (This is the transaction that claims the reward.)

Removing transactions from your block will not save you mining time. (Note that it may make your block propagate faster, and it may be impossible to tell if a transaction is valid when SPV mining.)


Bruteforce bitcoin address - I know the words + public address but not the order

Doing this requires three things:

Permutations of the seed words
The address you're trying to locate
The derivation path for that address.

In this specific case, the address is the one this puzzle on reddit leads to, so we will assume the derivation path is m/49'/0'/0'/0/0

This is a simple nodejs script using bitcoinjs-lib to read seeds from a file, validate them, and then try the first address against the one you are searching for. You can parallelize it by splitting the input file into pieces and running it once per file.

Do note that 12 words means roughly half a billion combinations. While this is doable with today's computing power, it is still going to take you a very long time. Some quick tests show it would take about 4 days on my laptop, although you may be able to speed it up by using a faster language, or parallelization.

var bip39 = require('bip39');
var bitcoin = require('bitcoinjs-lib')

var lineReader = require('readline').createInterface({
  input: require('fs').createReadStream('addresses.txt')
});
var ctr = 1;
lineReader.on('line', function (line) {
    if (ctr%100 == 0) {
        console.log("Processing #" + ctr);
    }
    if (bip39.validateMnemonic(line)) {
        var roothex = bip39.mnemonicToSeedHex(line);
        var rootnode = bitcoin.HDNode.fromSeedHex(roothex);
        var basechild = rootnode.deriveHardened(49)
                .deriveHardened(0)
                .deriveHardened(0)
                .derive(0);
        for (var i = 0; i < 3; i++) {
            var child = basechild.derive(i);
            var keyhash = bitcoin.crypto.hash160(child.getPublicKeyBuffer())
            var scriptSig = bitcoin.script.witnessPubKeyHash.output.encode(keyhash)
            var addressBytes = bitcoin.crypto.hash160(scriptSig)
            var outputScript = bitcoin.script.scriptHash.output.encode(addressBytes)
            var address = bitcoin.address.fromOutputScript(outputScript)
            if (address == "3CcxyPhyvyc3S9UuPfu42GNZLvVVV11Uk8") {
                console.log("Found seed! " + line)
            }
        }
    }
    ctr++;
});

You will need to install nodejs, and bitcoinjs-lib for this.


Your settings look correct for the versions you would have been using, I do not know about bitseed.conf however.

For a more up to date guide for setting up Bitcoin Core to run over Tor, you can try this question. Bitcoin Core now supports automatically configuring an ephemeral Tor service, for example.


Unable to sweep account using WIF, Green wallet says "No UTXO found"

That WIF private key does not correspond to that address. Not even if you convert the key to its uncompressed format.

That hex private key does not correspond to either the address or the WIF private key.


What is the smallest sensible transaction?

I personally think that the most smallest and sensible transaction is at least 0.0001

HOWEVER NOTE: If you want a confirmation in 10 or 20 minutes, you will need to post a minimum transfer fee of 0.0001

So technically If you want to transfer 0.0001 to a account you will need at least 0.0002

If you want to transfer a bigger amount, the transaction fee will not need to be changed
e.g. If you want to transfer X amount to a account you will need at least X amount + 0.0001

I have tried to transfer 0.00005593 with no transaction fee, and there is still no confirmations: https://blockchain.info/tx/15ee5484920eed92457643a1709629d8ff579b15fc805b0060a9cf0efdcbb8ed

Transfer More faster = Pay a Higher transfer fee

Just to note: transfer fee same as Miners Fee same as transaction fee


Will I double my money after a bitcoin hard fork?

No, it doesn't mean free money.

When a cryptocurrency forks into 2 separate cryptocurrencies, then the market sets the value for each.

Much of the value of Bitcoin is based on several things, such as the existing base of businesses that accept it, the efficacy and reliability of the developers maintaining it, and the familiarity by people that use it.

After a fork, that value becomes reduced, as many users or businesses pick one or the other to use.

New value may be created by new functionality added by the changes that caused the fork, or overall value (ie the sum of both forks) may become reduced due to a loss of trust in the system.

A more reasonable expectation is probably that the overall value, between both forks, is roughly the same as before the fork, but becomes split between two.

However, given the speculative nature of a sizeable proportion of the market, any small change may trigger large market movements, so it's anyone's guess as to what will actually happen.

After the fork, if you sell your BTC, then yes you will still have your B2X to sell (assuming that the wallet service you're using gives you access to it, or that you run your own wallet).


Is there some client like Bitcoin core, but which highly compresses the blockchain?

The Bitcoin blockchain is mostly comprised of signatures (mostly non-compressible) and hashes (non-compressible), there's some space to be gained by eliminating redundancies due to people re-using addresses but it doesn't seem to be worth the implementation cost. Using gzip -9 and zpaq -method 5 on the block files for example saves only about 20% of the total size, using a compression system with knowledge of the Bitcoin block format would do a slightly better job, but that's the sort of ballpark you would expect to see.

128M  blk00318.dat
101M  blk00318.dat.gz (30 seconds)
95M   blk00318.dat.zpaq (5 minutes)

Even a 25% or 30% reduction in the size of the chain wouldn't allow for many more people to be able to run full storage nodes, the current growth rate (2GB per month for 400KB average blocks) would make it uneconomical again in a couple of months.

If you want to run a fully validating node to have a secure wallet or view of basic block chain data in small space, Bitcoin Core 0.11.0 does have a prune mode which can run with as little as 1.5GB of consumption- but it won't be contributing to the network at when this option is set, and your wallet use will be slightly more constrained than normal. Beyond that there's little in the way of other full storage nodes with more compact disk footprints, at least for now, pruned nodes should be made significantly more useful to the network in the future.


How much is a mining pool share worth on average?

If the global network difficulty is D and the difficulty of shares in the pool is d, then the probability that a share will lead to a valid block is d/D. The reward in this case is B, so the average reward per share is B*(d/D). If the operator's average fee is f (so for example f=0.01 means 1% fee), the average reward miners get per share submitted is (1-f) * B * (d/D).


Help with bitcoin gold explorer: using explorer after fork

After more googling I found this one: https://bitinfocharts.com/bitcoin%20gold/
It displays the correct BTG balances for my addresses at least


Converting address formats is not feasible without knowing the public or private key(s) used to generate them.

Without reviewing the source code of btcrecover, I can't advise whether you should use it or not. But if you do trust it and decide to use it, consider first generating a new seed and address to immediately send your bitcoin to.

Consider any seed you may recover with btcrecover compromised and no longer secure.


How OP_EQUALVERIFY works in a standard transaction?

The script in the output is created first. Its form is typically:

OP_DUP, OP_HASH160, pubKeyHash, OP_EQUALVERIFY, OP_CHECKSIG

pubKeyHash is the hash contained in the address being sent to. So it is the hash of the public key of the receiver.

When this receiver wants to spend this output, he must construct an input to claim it, and provide the actual public key that corresponded to his hash, and signature using it:

signature, pubKey

Twice, the same public key data is used. Once by the sender, stating the hash of the public key of the receiver, and when the receiver becomes a sender himself, he provides his full public key.


How long can my lightning node be safely offline?

that depends on the locktime that is configured for your channels. taken from c lightning (c.f.: https://github.com/ElementsProject/lightning/blob/97118c558e84e0b3a12a8cbe60528ad5cfcb2fd6/doc/lightningd-config.5.txt )

  watchtime-blocks='BLOCKS'::
      How long we need to spot an outdated close attempt: on opening a channel
      we tell our peer that this is how long they'll have to wait if they perform
      a unilateral close.

  max-locktime-blocks='BLOCKS'::
      The longest our funds can be delayed (ie. the longest watchtime-blocks
      our peer can ask for, and also the longest HTLC timeout we will accept).
      If our peer asks for longer, we'll refuse to create a channel, and if an
      HTLC asks for longer, we'll refuse it.

I believe the standard setting should be 144 blocks which statistically should be 24 hours. of course you should consider a safety window to be able to get your breach remedy tx mined in case of a unilateral close.


What are the security implications of not hosting your own Electrum server?

A dishonest server could lie to you about how many bitcoins you have.


Is there a way to only sync up to a certain block?

bitcoind supports the argument -stopatheight, which takes the number of blocks to download before halting.


Is the generated Public Key from Private Key Unique in Bitcoin?

The base58 number 16w4zZWjWnhfEasJcSbfDQeHJRk1LytPHF5ir1ZS9mtUD5adsdH is a base58Check encoding of the (compressed) public key:

030d4018f164d58e41e0c5fb99eb5ec26b4f21fc8ad0db726d51a7cce60c75df0a

which corresponds toKwY7eRvXXFd7HPX4Zuv8STZMLsVSe2X22HkU24Av84W1Cb7Rd5Yh, and whose address is 16reZXagkyToongduimD25SEerXwP3MQ4n. Note that your private key is actually a bit more than a private key. It is a 38 bytes number which is a base58Check encoding of a number which contains 34 bytes (rather than just 32 for a secret key). There is an additional version byte 0x80 at the beginning which indicates that the private key is to be used for the main bitcoin network (rather than a testing network). There is an additional 0x01 suffix byte at the end (just before the 4 checksum bytes) which indicate that the public key associated with this private key is to be generated in compressed form (33 bytes) rather than uncompressed form (65 bytes). So while it is true that your WIF representation of your secret key leads to a unique address (one corresponding to a compressed key on the main network), the actual 32 bytes secret, can potentially lead to 4 addresses (depending on compression status of the public key and type of network).


Why can't I use Electrum seed to recover my wallet on Trezor and Blockchain.info?

Electrum uses a custom mnemonic format so yes Electrum wallets cannot be restored in any other wallet using the seed mnemonic. Instead I suggest installing and running electron cash to get access to your BCH straight away. It's a fork of electrum for bitcoin cash and by default it imports all your electrum wallets automatically. The official site is https://electroncash.org/


How to know what kind of Multisignature address?

You cannot know, to which type an address of "3QJ...inyC" belongs, unless you created it yourself, or had the underlying data. Such a "type 3" address can be a hash of any data :-)

Ok, to be more precise for multisig: the address is probably created out of a redeem script (e.g. for a 2-of-3 multisig: <2><3>). This redeem script is hashed, and as a hash is a one way function (as per today's knowledge), you cannot reverse it.

You might have the chance to see which msig addresses / pubkeys and number of required sigs are included, when the spending transaction has been mined. Then you see all details of the redeemscript in the sigscript.

The way it works is described here: https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki. Much more details can be find in chapter 5 of Andreas' book "Mastering Bitcon, 2nd edition".


The probability that 1 node is connected to another node will be 1 in 8, so if there were 10 million nodes, we can divide it in 8 block of nodes, every node will have access to one of the blocks.

The transaction takes less than 1 second to transfer from one node to the other, let suppose it takes 1 second, to make it easier.

On first second 8 nodes will be notified
On second 2, 8*8 = 64 nodes will be notified
On second 3, 8*8*8 = 512 nodes
Continuing this way, 8 seconds after the block is issued, a total amount of 16 million nodes can be notified of that transaction

So there is no problem with 10 minutes block, the problem arises when the block is for low times, like on some chains with 1 minute per block or less.


Does it make sense to "collect" smaller transactions balances into a single account during low activity?

In satoshi client, the "accounts" therein are only a convenience for labeling of receiving addresses. They don't matter for sending at all.

If you receive bitcoins, the balance is not added as in bank, but the amount is saved as "unspent output". Client only shows all these outputs together as one available balance. It doesn't matter whether one address has n unspent outputs, or these are on more addresses. When you send bitcoin, the fee is based on number of these outputs used and it is higher if they are very recent. So trying to consolidate them won't help much, only that you pay the fee sooner. And it isn't done "while you sleep", it's done by simply sending your whole balance minus fees to yourself.

In other clients, the fee algorithm can be completely different.


What happens if the block's generated are exactly 10 minutes?

Exactly nothing. The difficulty would remain the same.


Where is the bitcoind executable on Windows 10?

It's at C:\Program Files\Bitcoin\daemon.

NOTE: On the download page, make sure to choose the installer, not the zip file.

The first one:


If there are three addressess A, B and C and someone sends a transaction tx1 from A -> B and another one tx2 from B -> C that spends the exact same coins (tx2 input is tx1 output) then tx2 cannot be confirmed until tx1 is confirmed.
Yes someone could trick you to accept an unconfirmed transaction as final and then send the same coins elsewhere (with a higher fee). That’s why you should not consider transactions final unless they are confirmed with at least a few confirmations (6 used to berecommended)


Transaction not complete for two days now

1N9V3yNuBEbgS3g87qibrnTGARj9SrKFst did receive bitcoins. If they ask you to send again, don't, it might be a scam.

You can give them the transaction ids:

170e84bcc871f4cca8d352035c4bbe9e1a44bf2f66c8e9e4ff69547ea1256639
d1b5b5fddfde0aa492f8ef8a58f6740222ceed42d2ee369082ea4e95f7233415

even though they don't need them. You can just tell them "on block explorers it the transactions are shown as confirmed." with a kind "Can you confirm that the output address 1N9V3yNuBEbgS3g87qibrnTGARj9SrKFst shown on the block explorer was the one you had given to me?"


Would backing up my private key be enough?

That's exactly how private key works. All you need to have is a private key to access your wallet. And this is the reason it is not a good idea to fire your private key to mars, if someone get there before you, they will steal all your coins.


How much privacy does Lightning actually have?

Bob only knows the channel R3--Bob and his other channels.
in particular due to the onion routing Bob has no way of knowing who send the payment or say anything about the channels of the sender (as Bob does not know the sender)
Routing only know their incoming and outgoing channel. So the only thing that R2 would know is that there was and HTLC offered by R1 and that it is supposed to be forwarded to R3.
With respect to your question of how does Bob know about Alices channel. As said Bob doesn't but you could invert the question. If alice wants to pay Bob, how does she know about the R3 - Bob channel? There are two possibilities. Either Bob specified a Routing hint in the invoice or she does so (with other channels on the path) with a probing trial and error approach. This is well described in https://arxiv.org/abs/2103.08576 where this was also used to probe for the balance values of channels. In that sense the information on Lightning Network is not strictly private.
However probing takes time and might be inacurate as there are counter measures to probing channel balances. (In comparison if you see something on chain it is pretty clear that this is the reality)


Extract output address from raw script in bitcoin protocol

It won't work, because there is no address for that script.

Addresses are templates to construct outputs from. Generally, you should not go the other way, as addresses may be misinterpreted as a place to send coins to, without the receiver asking for it or aware of it.

Furthermore, there are only a few common script types (P2PKH, P2SH, P2WPKH, P2WSH) that has associated addresses. Others, like your example, don't.


Is there an active list of BIPs currently open for voting?

This question is based on a misconception. Miners do not vote on proposals. Consensus changes to Bitcoin are made by the entire ecosystem transitioning to new rules that they choose, by running node software that enforces these rules.
Miners are a part of that ecosystem, and their enforcing of new rules is part of what makes them safe. But if miners refuse to adopt a rule change that the rest of the ecosystem demands, they have no choice. If a rule is implemented and enforced by the network's full nodes, then miners who produce blocks that do not follow those rules will simply be ignored.
Everything works better however, if miners and the rest of the ecosystem do not diverge on what rules they're demanding and enforcing. For that purpose, several past backward-compatible consensus changes ("softforks"), have used a mechanism where miners can signal that they're ready to enforce a particular rule, and once a certain threshold is reached, all of them (including non-miners) start enforcing those rules in lockstep.
So in reality, such a signalling mechanism is for coordination, not for voting. Proposals may go through even without miners' consent, but it's better for everyone if things are synchronized.
Previous softforks that have employed such a coordination mechanism are:

BIP34 Height in coinbase (2012)
BIP65 OP_CHECKLOCKTIMEVERIFY (2014)
BIP66 Strict DER signatures (2015)
BIP68/112/113 OP_CHECKSEQUENCEVERIFY and associated relative locktime semantics (2016)
BIP141/BIP143/144 Segregated witness (2016)
BIP147 Dealing with dummy stack element malleability (packaged together with BIP141/BIP143/BIP144) (2016)
BIP91 Reduced threshold Segwit MASF (2017)

The specific rules used by each of these differ (see my answer here for details). Some used a simple threshold of 750 or 950 blocks over the past 1000; some used BIP9.
Earlier softforks (BIP16, BIP30) were coordinated at the human layer. BIP16 did use signalling in blocks as well, but only to inform changes made to the software. The actual activation was time based (as soon as enough support was signalled, node software was modified to start enforcing new rules after a certain date). As BIP16 did have a competing proposal (BIP17), it was easy to misinterpret support for one or the other as a vote. Perhaps that is where the misconception originates.
Right now (as of July 2020), there are no unactivated consensus changes implemented in node software, so there is nothing to signal for, though there are discussions about the activation mechanism to use for BIP340/341/341 (Taproot).
Disclaimer: I am a (co-)author of some of the BIP documents listed in this answer (BIP30, BIP66, BIP141/143/144, BIP340/341/342).


No new UpdateTip. Just "Pre-allocating up to position ..."

If you're seeing pre-alloc messages but no UpdateTip messages, it means that you're receiving blocks from peers, but not the next block you need.
Bitcoin Core tries to spread downloading of blocks among multiple peers. However, once a block has been requested, it won't get requested again as long as that request is still outstanding with the peer it's already requested from - until that peer goes offline, or the request times out (at which point the peer is disconnected too).
However, validation requires consecutive blocks, eventually. If we've processed all blocks until number N, we need block number N+1 to continue. It's possible that the request for block N+1 was sent to a non-responsive peer, while other blocks (N+2, N+3, ...) are requested from other peers who are responding. Validation won't proceed until N+1 is received. There are some heuristics to detect such straggling peers and disconnect them (you'd see "Peer X is stalling block download" messages when this happens, I believe), but it's not perfect.


How to sign rawtransaction with private key

With java? Sign it with the program that created the raw transaction, bitcoin-cli.
With signrawtransactionwithwallet.
Or with signrawtransactionwithkey (0.17.0 RPC)
signrawtransactionwithkey "hexstring" ["privatekey1",...] ( [{"txid":"id","vout":n,"scriptPubKey":"hex","redeemScript":"hex","amount":value},...]
take txid,vout,scriptPubKey from an online explorer, live.blockcypher.com
redeemScript should be blank.
"raw transaction" "["priv key"]" "[{"txid":"the taxid","vout":the vout integer,"scriptPubKey":"from the explorer","redeemScript":"","amount":the amount}]"
after sign, if want to call sendrawtransaction, if the tx id is not synced will be "Missing Inputs"(in dogecoin-1.10.0 executed) ; or if wallet is offline or if started with -noconnect, then broadcast the transaction online like here https://live.blockcypher.com/btc/pushtx/
More info to deal with a -noconnect and no synced data situation: How to send bitcoin from an offline Bitcoin Core that doesn't have a synced balance?


How Do I Calculate the profit of the value of my bitcoin?

The simplest way to calculate would be:

averagecost = ((BTC[t0] x USD[t0]) + (BTC[t1] x USD[t1]) + (so on))/total_BTC

where t0,t1 and so on are different time when you bought.

The above gives you the average cost for all your BTC

Now to know the profit, use the below formula:

profitloss = (current_BTC_price - averagecost) x total_BTC

If profitloss is negative, then you have a loss.

If profitloss is positive, then you have a profit.


How can I recover the private key for my bitcoin address?

Private keys cannot be recovered. If you lose or forget the private key, the bitcoins become unspendable.


Why does this transaction give me an error?

The transaction wasn't going through because of the newly implemented "dust transaction" policy that makes it so that no output of a transaction may total less than 54.3 micro-bitcoins. One of my outputs was below this threshold. So I fixed that, but then the output to the "change" address was pulled below 54.3 uBTC and it still failed. I haven't found a way to ensure electrum doesn't try to deposit less than 54.3 uBTC into the change address, so for now I'm sticking with a single, large input to avoid small amounts of change.


Can I see all transactions not included in a block yet?

The upcoming release of the Bitcoin.org client, version 0.7, includes:

getrawmempool


Transactions are stored in the block chain, so you never lose them.  However, if you lose the private key associated with an unspent output, then you can never spend it.  So it is important to always back up your private keys (the public key and bitcoin address can be derived from just the private key).  When you import a private key into a new wallet, the wallet will scan the block chain looking for transactions that match the associated bitcoin address.  These transactions will then appear in your wallet without any further action on your part.

Some wallets use discrete private keys, which means you must backup the wallet each time a new private key is generated.  For example, Bitcoin-Qt keeps a pool of 100 new private keys, so you only need to backup the wallet after every 100 send requests (since change is returned to a new private key).

Deterministic wallets only need to be backed up once since they generate new keys using a stored seed.  If you need to restore the wallet, the private keys can be regenerated from this seed.  Electrum is an example of a deterministic wallet.


How does change work in a bitcoin transaction?

First, let's clarify the difference between accounts and addresses.

"Accounts" are used for the convenience of people to track their funds. This is primarily used to track the source of funds. Since this is just for your tracking, you can move Bitcoins from one account to another just by moving a number from one column to another. No transactions are needed. (This is like when you know you owe your son $25 for allowance, and you have $200 budgeted for groceries.)

"Addresses" are used to receive Bitcoins in transactions. The coins are sent to an address. The client associates each address with an account and adds received funds to that account. This is simply done for convenience to allow people to track indirectly which address funds were sent to. But you can have any number of addresses associated with the same account.

Change comes from the way Bitcoins are spent. To spend a certain number of Bitcoins, you must pull in Bitcoins from transaction outputs to accounts you control. Note that in the spending part, it doesn't matter what address this is or what account that address is associated with. When you spend Bitcoins from a particular account, that just means you debit that account for the amount you send. It doesn't mean the funds come from addresses associated with that account. Remember, the association between addresses and accounts is for receiving only, not sending. (Like when you spend money on groceries, it's not like you have specific bills for groceries. You just have an amount budgeted.)

So when you pull in transaction outputs, you form a pile of Bitcoins big enough for the number you are trying to send. Usually, it won't be exact since you must claim an entire output. So the excess forms the 'change'.

Since there is no address associated with sending Bitcoins, there is no particular address the change should be sent to. So, to preserve anonymity, the client creates a new one just to receive the change from this transaction. Since this address isn't really associated with an account and shouldn't be used to receive any more Bitcoins (because that would senselessly tell people the same recipient got the coins as got this change) the client does not display it.

Because the client manages coins in a particular way, it doesn't make sense to try to view coins it is managing with any kind of explorer. It's specifically trying to obscure the fact that all the coins are related. Those kinds of services are intended to monitor recieved funds, not managed funds.


bitcoin core 0.13.1: Inconsistent getbalance result from RPC

I think I've hit a bitcoin-core bug that may happen in weird circumstances (such as when trying to send a transaction which the node refuses to send, by returning a "rejected" error code). After I restarted the server, the transaction showed up in the bitcoin network, and the getbalance RPC calls started to be consistent again.


Is anyone developing a DNS-like system for Bitcoin addresses?

The NXT Cryto has a built in alias system:

http://www.nxtcrypto.org/


Mistakenly sent BCH to BTC bitfinex wallet - can I get my BCH back?

They will be recoverable, but only by the exchange the money was sent to.


Get wallet address when creating wallet with blockchain API

I've not used this myself, but it does look like the behaviour you're seeing is different to the official documentation and the  documentation on GitHub. You are getting the xpub of an HD Wallet in the response, instead of a standalone address. Which version did you install, and what does the documentation that come with it say? Are you passing any parameters to create that you didn't list in the question?


Is blockchain.info storing paper wallet (offline) private keys?

My Wallet's warning for watch-only addresses ("You will not be able to send bitcoins from this address without later providing the private key") can be a bit confusing.

It's possible to specify an address and watch it. And it's possible to import a private key to be able to use the associated address as if it was generated with the My Wallet client.

But these two features are really unrelated. You don't "send out of a watch-only address", rather you import a private key thus making it no longer a watch-only address.

So the question is really whether My Wallet's "Import Private key" feature is safe. I don't have the official answer, but I see no reason why it shouldn't follow the same policy as other keys - the private key is encrypted in your browser (and as needed, decrypted and used to sign) and never leaves your computer in plaintext. If that's true, it is safe as the server never sees your plaintext key.


No. The address in the format you're used to seeing it isn't encoded like that in the transaction.
When you send a Bitcoin transaction to someone, your wallet will verify that their address is formatted correctly by validating its checksum, then it decodes the public key hash or script hash that is encoded in the address, and this hash is what is included in the transaction output. The purpose of the address checksum is just to prevent typos; it is not included in the transaction itself.


How do I lookup Blockchain sizes for crypto-currencies like Litecoin and Dogecoin?

Bitinfocharts.com lists stats for the main cryptos including the block chain size. You will find "Blockchain size" near the bottom.


Withrdawing bitcoin from web-based exchange wallet to local wallet. My wallet passphrase is requested- is this necessary?

NEVER share your seed pass phrase/mnemonic. Anyone that has it can steal your bitcoins, and there is NO reason a web-wallet would need it in order to transfer your funds.

If the web-wallet is requesting a password in order to withdraw funds, it is most likely the password to log in to your web wallet account, or a secondary password you set up to spend funds from your web wallet account.


Why is the field 'hash' necessary in a bitcoin transaction?

Note that Bitcoin transactions don't actually contain the txid or hash within them. This is only part of the decoding output from Bitcoin Core.

The hash is there because of segwit. Segwit specifies that witness data for a segwit input (i.e. signatures, scripts) are not part of the txid. Those are in a separate area in the transaction. You can see this information decoded in the txinwitness field. So the hash is over the entire transaction, including this witness data, but the txid is not. Since transactions that do not have any segwit inputs do not have witness fields for their inputs, the txid and hash are the same.


How can I spend my paper wallet directly?

Unless you plan on doing ECC math and hashing algorithms by hand (it would take you about a day just to do a single round of SHA256) and publishing the raw binary transaction via raw network protocol, you're going to need some software.

I would recommend getting Mycelium, which has a paper wallet import feature. You can then spend it where you like using the wallet.


How to generate bitcoin addresses on the command line or with python?

Bitcoin Core's bitcoon-cli provides command-line functionality for manipulating a wallet, including creating addresses.  Running a full bitcoin-core node also means you can connect programmatically via Python to it using json-rpc to create addresses.


Does bitcoin-qt support mining in a pool?

No. Also the hashing implementation in the client is very, very limited. It is not optimized for different architectures AFAIK and does not support any other calculation medium other than regular CPU. That means no GPU, FPGA or ASIC mining. And CPU are extremely slow in comparison with these (see for example Why a GPU mines faster than a CPU).

For this reason the standard Bitcoin GUI client (bitcoin-qt) does not support mining anymore.


Where can I find the transaction volume?

I am assuming you are asking for trading volume across exchanges.

Brave New Coin (BLX) provides a good API to get volume weighed average across major exchanges: https://bravenewcoin.com/data-and-charts/indices/blx

You can also see their chart with volume on Trading View (look for BLX ticker): https://www.tradingview.com/chart/?symbol=BNC:BLX


Is possible to destroy the Bitcoin for just $500K? (51% attack)

TL/DR: No.

The long form of the answer:

Online mining is that grey area where you don't invest until you're 100% sure. The aforementioned website is likely to scam you if they are providing such a service in the first place.

To address the question, how much will it take to launch a 51% attack;

Firstly you can check the current compute power (hash rate) and it's $ equivalent.

attack-cost gives you the exact cost for a 51% attack at any given point of time.

If you compare the calculated hashrate against one of the more popular ASICs on the market, the figure stands at about 2.2 billion. However, this assumes that suddenly half of the network right now goes rogue and decides to attack it. If not, you would need more than 2.2 billion dollars since the hashrate needed has to be 51% of the total hashrate (after the attack starts).

Its rather resource consuming and it isn't that big of a problem since none of the government really cares that much to spend their budget on attacking a cryptocurrency. You probably wouldn't profit all that much when you attack; doubt exchanges credits more than 2 billion dollars worth of Bitcoin automatically without raising a red flag.

Also, If you don't have 51% of the whole network (ie. more hashrate than the others), you don't have a 100% chance of executing an attack. The honest/longest chain still has a chance of overtaking you and you have to acknowledge their blocks. The probability of success decreases with the number of blocks.

Assuming the attacker decides to do 51% attack by purchase lots of ASIC/GPU, but it's not a really accurate number because:

There's no way you could get thousands (maybe millions in the coming future) of ASIC/GPU units easily
Even if they could, it's obvious that the price of ASIC/GPU will be more expensive due to high demand and low supply (this is already the case with graphics cards, poor gamers!)
Unless you have a connection, it's highly unlikely you could use lots of electricity and big mining location without ringing any alarms

Now, what if the attacker wants to hire a pool instead of investing in purchasing the equipment. In the current state where almost all mining power is concentrated within less than ten pools, that's enough to 'buy' a pool admin(s).

Why would even mining pools agree to "rent" their hashpower? If they actually did that, they would quickly lose their users. I don't really think if there would be many farms interested in this form of attack. Long-term earning is much wiser than trying to cheat and sell as much as possible. The rest of the network would quickly realize that the 51% attack was performed. Just look what is going on with Verge which is/was being attacked. The 51% attack is the reason why there are people who think that banning ASICs and mining only with GPUs is a good way to prevent it from happening.


You've already made a post on reddit, made a thread on bitcointalk and added it to the wiki, but if you want to advertise it (as in paid advertising) then you can try the following sites:

coinurl.com - banner and text advertising, fairly cheap

bitads.net - you choose which sites you want to advertise on. can be quite cheap too

a-ads.net - no account system, just create a campaign and deposit. again, fairly cheap.

Bitcoin advertising are generally much cheaper than traditional advertising. If you accept Inputs.io, you can also get a free ad slot on Inputs' wallet page, and an instant payment button sounds perfect for selling digital files :)


You can calculate the change yourself. The coinbase API (not a recommendation, just an example) has and endpoint for 24-hour stats (https://api.pro.coinbase.com/products/BTC-USD/stats)

{
open: "7674.24000000",
high: "7810.99000000",
low: "7490.00000000",
volume: "14477.94427039",
last: "7694.56000000",
volume_30day: "479763.13996598"
}

Last price minus the open price equals the 24 hour gain. Divide the gain by the open to get the decimal percentage.


How were miners supposed to signal support for BIP148?

BIP148 was not a soft fork deployment on its own, so it did not have a BIP9 version bits signal associated with it.

The actual softfork deployment was SegWit itself, defined in BIP141 and signalled by bit 1 in the version field.

Any block signaling soft fork readiness with BIP9 must have the top three bits set to 001:

https://github.com/bitcoin/bitcoin/blob/a79bca2f1fb25f433d6e100a31a3acfde2656ce1/src/versionbits.h#L14

/** What bits to set in version for versionbits blocks */
static const int32_t VERSIONBITS_TOP_BITS = 0x20000000UL;

Readiness for SegWit was signaled by bit 1 or 1 << 1 in 32-bit hexadecimal: 0x00000002

Therefore all blocks signaling SegWit during the BIP9 STARTED phase had the version 0x20000002

In Bitcoin the block version number is serialized as little-endian, meaning on the wire and on disk the first few bytes of a SegWit signaling block look like this:

bitcoin-cli getblock 000000000000000000f288b3ff879d0ef11d3197f88dcdc1e29c3933b9c0e5af 0

0200002038493522351788...

Note the expected version bits in the first four bytes, little-endian.

To address your question specifically about the version in binary, all SegWit-signaling blocks would have a version field like this (shown here as big-endian to match your example)

00100000 00000000 00000000 00000010

Miners do crazy things and some miners during this time signaled extra bits for various other reasons, but the two bits shown here must be set to signal SegWit.

On to the question of BIP148: It had no extra signals except for ASCII strings encoded in the coinbase scriptSig. In block 469345 the coinbase scriptSig is:

03612907236808005fe905fcc10000bf33092f736c7573682f4249503134382f

Which, decoded to ASCII:

a)#_i|A?3       /slush/BIP148/

BIP148 nodes also included a similar string in their user-agents. Otherwise they provided no signal to the network that they would reject non-SegWit-signaling blocks after the flag date. They required no network majority to enforce their rules.


Bitcoin core does not produce a wallet at all

Bitcoin core automatically generates your first bitcoin address for you but you can create as many new ones as you want.

This is outdated. An address is no longer created for you by default.

You can create an address from within the Receive tab by clicking the "Create new receiving address" button.

  Here is what I see:

You are looking at the Sending Addresses window which is for addresses that you want to send to. It is not for your own receiving addresses; that would be the Receiving Addresses window. In recent versions of Bitcoin Core, the functionality to create a new address in the Receiving Addresses window has been removed.


There are, but I can't remember where I read about them. Sorry.
There has popped up Litecoin wallets with malware/trojans in them... Therefor there is always a warning/saying that tells you to download the wallet ONLY FROM the official site. (for instance http://litecoin.org)


Is there an API that exchanges USD to Bitcoin?

This looks like a service that does what you're asking for, if I'm understanding your ask and this page correctly: https://developers.coinbase.com/docs/wallet/guides/send-receive

This would require you to already have USD on deposit in your Coinbase account.  The page says they are working on a feature to automatically withdraw USD from a linked bank account (I wouldn't hold my breath for this).

Since you explicitly asked about doing this via an API, I looked into this aspect a little bit, too:
https://developers.coinbase.com/api/v2#transactions

In the example json on the right, I'm seeing that it has separate "amount" and "native amount" sections specifying BTC and USD respectively, and there's an "instant_exchange" field.  This leads me to believe it can do exactly what you're asking for, provided you have USD on deposit and instantly available:

Hold USD, not BTC
Create a new transaction to send BTC, via API
USD is converted to BTC "just-in-time" at time of transaction

I didn't look into converting a USD amount to BTC based on the current price via Coinbase's API, but of course their API will provide for that (via a previous request).

blockchain.info also offers a free API to do this, although I'm sure the precise exchange rate on Coinbase will vary slightly from what blockchain.info reports: https://blockchain.info/tobtc?currency=USD&value=500

Hope that helps.. although I imagine you've probably answered this yourself since posting this question.


Bitcoin was sent to my wallet 7 days ago but it has not reflect in the wallet

Your transaction is indeed confirmed on the network. This means that either your wallet failed to pick it up, or it paid a different address than you think.

Check whether the address that the transaction credits indeed belongs to your wallet. Verify that the address is not a "watch-only" address.
Check if your wallet is out of sync. Many wallets have a way to "rescan" or "resync" the blockchain. You can probably find instructions by searching for " out of sync".


funding and spending a "no-multisig/no segwit" P2SH tx

Now I understand, why there was no answer - it gets really long :-)

So I answer it by myself. I am with bitcoin core (getinfo) version 150100, on OpenBSD (ksh) and OSX (bash v3):

I solved it on testnet, and got the tx to go through. Some information from @nick here:
Does OP_HASH160 consume the top stack element?

I was wondering, if this holds true:

  For this to work, the <OP_HASH160> opcode would have to know, that the
  pubkey and the <OP_CHECKSIG> would need to be hashed together

Obviously it does. Here is the whole cycle... First I try to have a look at the stack with input and output scripts (as per link above):

sigscript:     <sig> <redeem script>
pubkey script: OP_HASH160 <RedeemScriptHash> OP_EQUAL

Based on the link above and looking at the stack, it would run through these steps:

  Input SigScript (push data on stack)  STACK:
  Execute pubkey script  a. this would first push first OPCODE of pubkey script on stack and execute  STACK:
  OP_HASH160

  b. this command consumes top stack element, and replaces with hash
  STACK:

  c. the next elements of the pubkey script is pushed to stack  STACK:
     OP_EQUAL
  OP_Equal verifies top two stack elements, if untrue --> invalid
  If true, script ends with "true" on top of stack  STACK:
  verify if script is P2SH (... ok, it is P2SH ...)
  clean the stack, and run sigscript again  STACK:
  pop top stack element, and run it as script  a. the top element of the redeem script is OP_CHECKSIG   STACK:   OP_CHECKSIG

  b. CHECKSIG would verify pubkey and sig, and return true ...

To see if this is correct, assemble a funding tx on testnet/regtest. When using coinbase tx (mined block), need >100 confirmations! Start with creation of a redeemscript and address for this tx:

NEWADDRESS=$( bitcoin-cli -regtest getnewaddress )
echo $NEWADDRESS
PUBKEY=$( bitcoin-cli -regtest validateaddress $NEWADDRESS | awk -F '\"' '/pubkey/ { print $4 }' )
REDEEMSCRIPT=$( printf "21%sac" $PUBKEY )
# creating the hash of the REDEEMSCRIPT
printf $( echo $REDEEMSCRIPT | sed 's/[[:xdigit:]]\{2\}/\\x&/g' ) > tmp_fn.hex
openssl dgst -sha256 -binary <tmp_fn.hex >tmp_sha256.hex
REDEEMSCRIPTHASH=$( openssl dgst -ripemd160 <tmp_sha256.hex | cut -d " " -f2 )
# convert redeemscripthash to bitcoin address (testnet!), with "C4" Prefix
PRFX_REDEEMSCRIPT=$( printf "c4%s" $REDEEMSCRIPTHASH )
# double sha256 the hex value
printf $( echo $PRFX_REDEEMSCRIPT | sed 's/[[:xdigit:]]\{2\}/\\x&/g' ) > tmp_fn.hex
openssl dgst -sha256 -binary <tmp_fn.hex >tmp_sha256.hex
openssl dgst -sha256 <tmp_sha256.hex | cut -d " " -f2 >tmp_dsha256.txt
# checksum and append
result=$( cat tmp_dsha256.txt | cut -b 1-8 )
result=$( printf "%s%s" $PRFX_REDEEMSCRIPT $result | tr "[:lower:]" "[:upper:]" )
# and base58
base58str="123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz"
REDEEMSCRIPTADDR=$( dc -e "16i $result [3A ~r d0<x]dsxx +f" | while read -r n; do
    j=$(( n + 1 ))
    echo $base58str | cut -b $j
  done | tr -d '\n' )
bitcoin-cli -regtest importaddress "$REDEEMSCRIPTADDR" p2sh
bitcoin-cli -regtest importaddress "$REDEEMSCRIPTADDR" rescan
bitcoin-cli -regtest validateaddress "$REDEEMSCRIPTADDR"
bitcoin-cli -regtest listunspent

The redeemscript's address would start with a "2" on testnet. Now create the funding tx. Search for an UTXO, that we can use, and note down tx and vout.

UTXO_TXID=d260e120647360dcfc8606e242c6389acece3ee585d5e0d76a26b87b08b322e0
UTXO_VOUT=0
VALUE=49.9997
RAW_TX=$( bitcoin-cli -regtest createrawtransaction '''[{"txid":"'$UTXO_TXID'","vout":'$UTXO_VOUT'}]''' '''{"'$REDEEMSCRIPTADDR'":'$VALUE'}''' )
bitcoin-cli -regtest decoderawtransaction $RAW_TX
SIGNED_TX=$( bitcoin-cli -regtest signrawtransaction $RAW_TX | awk -F '\"' '{ print $4 }' )
bitcoin-cli -regtest decoderawtransaction $SIGNED_TX
UTXO_TXID=$( bitcoin-cli -regtest sendrawtransaction $SIGNED_TX )
bitcoin-cli -regtest getrawmempool
bitcoin-cli -regtest generate 1

# verify new address has funds:
bitcoin-cli -regtest validateaddress "$REDEEMSCRIPTADDR"
bitcoin-cli -regtest getreceivedbyaddress "$REDEEMSCRIPTADDR"

At this point, the funding transaction is sent. Now the spending tx, we need a new address to receive the funds from the P2SH address:

RCVADDRESS=$( bitcoin-cli -regtest getnewaddress )
echo $RCVADDRESS

# verify that tx from $REDEEMSCRIPTADDR has funds
RAW_TX=$( bitcoin-cli -regtest getrawtransaction $UTXO_TXID )
bitcoin-cli -regtest decoderawtransaction $RAW_TX
# to send funds from $REDEEMSCRIPTADDR to a new address, need the privkey:
NEWADDRESS_PRIVKEY=$( bitcoin-cli -regtest dumpprivkey $NEWADDRESS )

create the raw tx, sign it, and send it (maybe the amount needs to be updated):

UTXO_VOUT=0
UTXO_OUTPUT_SCRIPT=$( bitcoin-cli -regtest validateaddress "$REDEEMSCRIPTADDR" | awk -F '\"' '/scriptPubKey/ { print $4 }' )
VALUE=7.7699
RAW_TX=$( bitcoin-cli -regtest createrawtransaction '''[{"txid":"'$UTXO_TXID'","vout":'$UTXO_VOUT'}]''' '''{"'$RCVADDRESS'":'$VALUE'}''' )
bitcoin-cli -regtest decoderawtransaction $RAW_TX
SIGNED_TX=$( bitcoin-cli -regtest signrawtransaction $RAW_TX '''[{"txid": "'$UTXO_TXID'","vout": '$UTXO_VOUT',"scriptPubKey": "'$UTXO_OUTPUT_SCRIPT'","redeemScript": "'$REDEEMSCRIPT'"}]''' '''["'$NEWADDRESS_PRIVKEY'"]''' | awk -F '\"' '{ print $4 }' )
UTXO_TXID=$( bitcoin-cli -regtest sendrawtransaction $SIGNED_TX )
bitcoin-cli -regtest getrawmempool
bitcoin-cli -regtest generate 1

At this point I could see, that my newly generated RCVADDRESS contained the value (bitcoin-cli -regtest listunspent | grep -A5 -B5 $RCVADDRESS):

... "amount": 7.76990000

I had one smaller observation, which is not yet fully clear to me: the scriptsig was changed in the final tx. It had the signature, and behind should follow the redeemscript. This redeemscript was "extended" in this way:

  23210355ef94c6e097752f303d685e4011b9dba8c1cd1382f8fa68bf2de0d523f18fffac

The 23 at the beginning would be the length indicator for the following pubkey, but this would include "ac"... Not sure, why bitcoin core extends it this way.

Now that I got it to work with simple P2SH, I can try SegWit-P2SH :-)


You can run Coinomi through the Google Chrome browser. You install the ARC Welder extension...
https://chrome.google.com/webstore/detail/arc-welder/emfinbmielocnlhgmfkkmkngdoccbadn

...which lets you run Android apps without an Android device. Download the required .apk (the wallet app) from https://coinomi.com/downloads .

Edit: I discovered this on this reddit thread:
https://www.reddit.com/r/BitcoinAirdrops/comments/7hc0qu/best_way_to_claim_bcash_from_old_core_walletdat/

which also has some possibly helpful tips.


With Ripple, how can I move my wallet to/from Payward?

I'm seeking for an authoritative answer for myself, but it seems the answer to the first question is:

  On account creation (and whenever you login) you can set the "Fetch
  wallet from" option to one of "Payward", "Payward and Local Browser"
  or "Local Browser".

source


Why did InstaWallet shut down, and what does this mean for Bitcoin?

Apparently someone got access to their database (another link)

The Instawallet service is suspended indefinitely until we are able to
develop an alternative architecture.
Our database was fraudulently
accessed1, due to the very nature of Instawallet it is impossible to
reopen the service as-is.
In the next few days we are going to open
the claim process for Instawallet balance holders to claim the funds
they had stored before the service interruption.

This probably means that one should be more careful when using online Bitcoin services. Most of these do not hire security consultants (or don't hire enough), as Bitcoin is still a fledgling market and they probably don't have enough resources to ensure foolproof security. I would probably trust Mt. Gox's security (not completely, just to a reasonable degree) as it is a rather big company, but smaller ones like Instawallet are always in danger of being hacked.
If you own a bitcoin service, hire a security consultant. The nature of Bitcoin makes it hard to pursue a hacker via the legal system, so if something is compromised, there's not much going back. So don't let it be compromised in the first place.
1. Sounds suspiciously like SQL injection


Diffrent transactions in different block sync problem

Once A solves the block containing T1 and the new block reaches B, B will cease to mine for (T1,T3). When B receives A's block, it will be validated. As part of this validation process, B will check each transaction in the block, and notice that T1 has been mined in that block.

B will then construct a new mining template, including T3, and possibly other transactions that were recently broadcasted, or previously didn't make the cut due to space constraints. Mining will then commence on this new template for B.


Isn't it safer to only encrypt the wallet, then back it up, and NOT save the seed?

Backing up the encrypted wallet file and saving the password elsewhere is basically equivalent to encrypting the seed itself and saving the encrypted seed in a different location to the encryption key. But indeed, that would require both parts to be used so would be more secure than just backing up an unencrypted seed itself


How do you install Bitcoin Daemon using Yum package manager?

This page has instruction on how to install Bitcoin using yum:

http://linux.ringingliberty.com/bitcoin/


You need to have a channel. Otherwise there won't be any node announce messages with the gossip protocol. Lightning network explorers can't see you without a node announcement message.

The fact that you need a channel to announce your node is a measure to fight SPAM in the gossip protocol. It is described in BOLT 07. Even if you have a channel it takes some time until your node announcement has propagated through the lightning network and being processed by 1ml. So bring some patience


Technically, yes.
Realistically, no.

As long as your private key is random, you should be fine.

Still concerned? Maybe you want to consider multisig, as it would require M of N keys to collide, making the already practically impossible, even more impossible.


What is the simplest command I could use to test that my wallet unlocking process works properly?

You can sign a message using the signmessage command. Note that this only works if you are using legacy addresses (Bitcoin Core currently defaults to p2sh-segwit addresses which cannot be used to sign a message). You an get a legacy address using:

bitcoin-cli getnewaddres "" legacy

If the wallet is locked, you won't be able to sign a message.


Determine which transaction spent a Transaction Output

Bitcoind does not track this information as it is not necessary for normal validation, so no, this is not easily possible.


Trezor issue - "The bitcore server does not reply. Cannot connect to wallet"

Try the other servers.

This means Trezor's blockchain explorers (for example, this one: https://btc-bitcore3.trezor.io) are under maintenance, or restarting, or can't be connected (DNS/ISP problems)...

If your Trezor can't connect to Trezor's servers, then it won't be able to make transaction (as it'll be unable to find older transactions, unspent outputs). Try the other servers. If it still doesn't work, contact Trezor support.


It isnt clear what exactly you're asking, but wiki is pretty clear on the structure of the response to a getaddr message.

https://en.bitcoin.it/wiki/Protocol_specification#getaddr

The response to receiving this message is to transmit one or more addr messages with one
or more peers from a database of known active peers.

So the payload of the response will be a bunch of addrs:

https://en.bitcoin.it/wiki/Protocol_specification#addr

Provide information on known nodes of the network. Non-advertised nodes should be forgotten
after typically 3 hours

Payload:
Field Size  Description     Data type               Comments
1+          count           var_int                 Number of address entries (max: 1000)
30x?        addr_list       (uint32_t + net_addr)[] Address of other nodes on the network.
                                                    version < 209 will only read the first
                                                    one. The uint32_t is a timestamp (see
                                                    note below).
Note: Starting version 31402, addresses are prefixed with a timestamp. If no timestamp is
present, the addresses should not be relayed to other peers, unless it is indeed confirmed
they are up.

And it even provides sample data:

Payload:
01                                              - 1 address in this message
Address:
E2 15 10 4D                                     - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)
01 00 00 00 00 00 00 00                         - 1 (NODE_NETWORK service - see version message)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)
20 8D                                           - port 8333


Are price movements of Bitcoin and altcoins inversely coupled?

The idea that bitcoin rising leads to altcoins falling is an unproven hypothesis, it is something that traders have noticed, but due to the various flaws in human observation, we cannot say for certain it is true.

That said, there are several factors that could lead to this effect in the short term - but these are all speculative.

Traders are attracted to liquidity. Bitcoin has the most liquid leveraged markets of any crypto currency, or at least historically that has been the case.  While the relative swings of bitcoin are smaller than for altcoins, the use of leverage allows traders to create large profits off of those swings in highly liquid, leveraged environments. When bitcoin is climbing rapidly, traders might be incentivized to reduce altcoin positions in order to increase their available bitcoin capital for leveraged trading.
Arbitrage against US dollar. Many altcoins are traded against the US dollar as well as against bitcoin. Let's say ETH is $50 USD, and .05 BTC/unit, and bitcoin is $1000. Bitcoin suddenly spikes to $2000 - the standing order books for the BTC/ETH pair will still show a price of .05, but that .05 is now worth $100. An arbitrage trader can buy ETH on the USD market and sell it on the BTC market for a near-instant profit - this drives down the BTC value and drives up the USD value until equilibrium is reached.
Bandwagon effect. The idea has become axiomatic so when bitcoin spikes, traders may be psychologically primed to sell altcoins in response.

Note: in many situations these factors are overwhelmed by other market forces, and it is not entirely uncommon for altcoins to outpace bitcoin during sustained price increases - this is demonstrably the case for most of the early 2017 bull market.


How is a TxID assigned to a Transaction?

It's a hash of key transaction information -- inputs, outputs, scripts, signatures.

  Are 2 identical Txs that: double spend, have identical k PRNG-signed (so not a RNG!) sigs, identical inputs/outputs (a lot of assumptions here) given identical hashes?

This question is ill-formed. Unless there's some difference between them, they're not 2 transactions, they're one transaction. It's like talking about "two identical integers" -- that would just be one integer.


computational effort needed to mine a block given the number of leading zeros in the resulting hash?

The difficulty does not specify a certain amount of computational effort that needs to be expended. In other words, the difficulty is not set to '1000 effort', and miners slowly progress from 0 to 1000, with the first one to expend 1000 effort winning the next block.

Instead, you need to think of it like a lottery. You can expend effort to make a guess, and if your guess is correct, you win the next block! The higher the difficulty, the lower the odds of any one guess generating a valid block.


Non-standard transaction scripts broadcasting

Standard output scripts are defined by IsStandard() (which calls Solver() to perform the actual script matching). The standard output scripts are as follows:

P2PKH
P2PK
P2SH
P2WPKH
P2WSH
A script beginning with an OP_RETURN and only pushes at most 80 bytes data to the stack
Bare multisig up to a 3-of-3 multisig

Any other script will be non-standard and the entire transaction will be rejected as being non-standard.

Instead of trying to include a non-standard output script, you can instead use P2SH or P2WSH. Your output script will become the redeem script or witness script which can be anything. P2SH and P2WSH allow you to do exactly the same things as if the script were in an output script.
If you still insist on wanting your non-standard script to be in the output, then for your transaction to be broadcast and mined, you will need to find a miner and give them your transaction through some other means. Non-standard transactions will not be relayed and most nodes will not accept them. You will need to give your transaction to a miner who is accepting non-standard transactions, and it is highly likely that you need to do this out of band, i.e. over some form of communication that is not the P2P network.


A good phrase for this is "If you need to ask, you shouldn't." because there is just so much that can go wrong and not to mention wallet services are vast and abundant. But if you really want to: http://coinpunk.org/


What if I receive bitcoins when my device is powered off?

Solution

This works fine.

The bitcoins will appear next time I start my wallet application. (Read tuxcanfly answer)

Bitcoins are not actually received by the software (wallet) on my computer, they are appended to a public ledger that is shared between all the devices on the Bitcoin network. (Read SPRBRN comment)

If someone sent bitcoins when my wallet client program is not running and I launch it later, it will download all blocks and catch up with any transactions it did not already know about, and the bitcoins will eventually appear as if they were just received in real time.

My wallet is only needed when I wish to spend bitcoins!

Helpful resources

https://bitcoin.org/en/faq#what-if-i-receive-a-bitcoin-when-my-computer-is-powered-off
https://www.weusecoins.com/en/questions/#what-if-i-receive-a-bitcoin-when-my-computer-is-powered-off


Do bitcoin clients automatically add more fee than specified?

Yes, an additional fee is added for each 1000 bytes in the transaction.  You can get a rough estimate of the transaction size using this formula:

148*IN + 34*OUT + 10

where IN is the number of inputs and OUT is the number of outputs.  The result can vary by IN bytes since a leading zero is prefixed to keys where the first byte is 0x80-0xFF.  This assumes the transaction is using compressed public keys (bitcoin addresses).

So, for the minimal fee, you need to keep the transaction size under 1000 bytes.  Assuming two outputs (the recipient and change), you can have up to 6 inputs without incurring an additional fee.


What should a stratum server do with "mining.submit"?

Read the documentation please: https://en.bitcoin.it/wiki/Stratum_mining_protocol#mining.submit

A quote from it:

  mining.submit

  mining.submit("username", "job id", "ExtraNonce2", "nTime", "nOnce")

  Miners submit shares using the method "mining.submit". Client submissions contain:

  Worker Name.
  Job ID.
  ExtraNonce2.
  nTime.
  nOnce.

  Server response is result: true for accepted, false for rejected (or you may get an error with more details).

You write:

  What next do I need to do with this data?

You could check the poolserver for example code: https://github.com/GOSTSec/poolserver/blob/master/src/server/poolserver/Stratum/Client.h#L82


When will the public key of an address used in the network?

The 1111111111111111111114oLvT2 hasn't been spent yet whereas 1HBheYzvX7NDtcwVrMS7gxReNRVezYS7w2 has.

To spend, the public key is part of the INPUT's ScriptSig:

http://en.bitcoin.it/wiki/Transactions#Explanation

So until there is a spend transaction, the public key isn't known to the network, just the Bitcoin address.

Related: Why is it impossible to derive public key from address?


Work is being done on cleaning up the database by getting rid of obsolete data, although full nodes would probably always want to keep everything.

Also note that non-full nodes, like a wallet app on your phone, don't need the full 19GB at all and are really quick already.

Also keep in mind that disk size and network speed keep growing as well, so we still have quite some time to go before this would really become a problem.


Bitcoin confirmed but have not received anything

You probably have to wait for your node to sync i.e. download 200+GB of the blockchain. I suggest making a thread on https://reddit.com/r/bitcoinbeginners and posting a link here so we can help you further. Stack exchange is not suitable for a back and forth diagnoses session.


Could BTC be changed so that it limited the amount of computation power a given miner used?

No, it does not seem possible to impose limitations as proposed on miners without severely impacting key properties of Bitcoin. The proposed change would at least require registering miners and instituting some sort of oversight mechanism to evaluate their participation. The likely outcome would be some mix of reduced utility and evasion of the oversight at the cost of increased complexity and centralization. Either way, the Bitcoin network can only be upgraded by convincing the vast majority of participants to run software enforcing the updated rules—and a proposal with such mixed trade-offs sounds like a tough sell.
While it is possible to form a ratio from Bitcoin's energy consumption and on-chain transaction count, that number is not as meaningful as one might think at first glance. The payment mechanism is a necessary function of the Bitcoin system, but Bitcoin's predominant use has been emerging to be as a long term store of value. Bitcoin's mining expenditures now secure savings worth about $1T.
I'd like to explain a bit further why comparisons with other payment systems are often inapt.
Bitcoin is not book money like PayPal or banking balances. An on-chain Bitcoin transaction is an irreversible transfer of a bearer instrument directly from sender to receiver that finalizes in minutes. Consider being able to directly hand someone cash or a bar of gold on another continent without any intermediaries. A system like that is useful, e.g. to gain access to banking-like services, to facilitate international payments, or to hedge against the rampant inflation of their national currency.
Leveraging Bitcoin's digital nature, the Bitcoin network is used as a base layer to build additional systems on top, much like the internet is built on top of TCP/IP. Even today, most Bitcoin payments are not recorded on-chain but happen on second layer systems like the Lightning Network or in the form of book money between users of custodial services—akin to transactions on Fedwire vs payments on PayPal or the VISA network.
I suppose our argument is that the uses and benefits of the Bitcoin network justify its energy consumption even when taking into account its environmental impact.


Is the difficulty target always truncated for practical purposes?

When mining, is the truncated target used (the one you get from bits), as opposed to the more accurate target you get by dividing the maxtarget by the difficulty?

Yes. The bits value actually stored in headers is what matters, as this allows validation of standalone headers without context. Due to headers-first sync this is no longer strictly needed, but there is no reason to change the rules now.

  Therefore, for all practical purposes, you should truncate the target you get when you divide the maxtarget by the difficulty?

Yes.

There is at most a 0.0015% difference between the two, though (1 in 2**16).


Why does only the earliest transaction matter for double spending?

"Doublespend" refers to an attempt of spending the same funds twice. In Bitcoin specifically this occurs when a user publishes two transactions that are in conflict due to attempting to use the same unspent transaction output as input. Obviously, only one of the two transactions can be valid.

Before Bitcoin was published, the solution to the doublespending problem was to designate a central actor that decided which of the two transactions would take precedence. The central actor would do this by announcing which of the two it had seen first.

The "first-seen" behavior was at first explicitly encoded in node behavior: nodes would not accept a conflicting transaction into their mempool (the temporary storage of unconfirmed transactions). However, this lead to the incorrect assumption that zero confirmation transactions could be reliable whereas actually the doublespending problem is solved by miners collecting transactions into blocks for confirmation. The blocks may only contain one of the two conflicting transactions, as otherwise the block is invalid. Thus, the blockchain specifies the precedence of transactions by converging on a common journal of the transactions without a central actor.

In the past months, we've seen the "first-seen" paradigm get softened significantly as doublespends (of unconfirmed transactions) have become more or less trivial due to the high demand for blockspace. As it is becoming common for users to update transactions with a higher fee (i.e. a doublespend), the "first seen" paradigm is falling out of use and being replaced by the defacto mechanism of "first-included". Assuming rational miner behavior selecting the most profitable transactions first, we will converge on a full replace-by-fee system eventually.

In other words, when the whitepaper describes the requirement for the Bitcoin system to create a convergent history with "first-seen", it describes a simplified situation that didn't account for the network dynamics of competition for blockspace. From today's perspective this should be understood as "first-confirmed".


Mining requires doing work (i.e. using electricity to power machines that perform the proof of work) to produce blocks and earn coins. Staking generally requires those that are staking to lock up their coins for some period of time (i.e. can't spend the coins) for a staker to have a chance of being selected to produce a block and collect the block reward.


Transaction pinning happens when:

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

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

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

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


How do I create the coinbase from the genesis block?

The nBits don't exactly get swapped. The notation on the wiki is in big-endian notation, which is basically the notation you'd use when displaying it, similar how the number twelve is written 12 and not 21 (different number order) but can be stored as 21 by a computer.

Your modern computer uses little-endian, which means that if you write something like :

int myInt = 0x1d00ffff;

It will actually store that in the RAM as 0xff 0xff 0x00 0x1d

Because of that, when you take the pointer of that int, and convert it to a unsigned char*, you get the little-endian order of it. Which happens to be what the reference client does :

(const unsigned char*)pszTimestamp

So, to put myInt in a char[], all you have to do is copy it there:

char tx[4];
int myInt = 0x1d00ffff;
memcpy(tx, &myInt, 4);
// tx now contains 0xff 0xff 0x00 0x1d

The only things that bitcoin actually swaps are network port numbers, which are stored in the memory as big endian numbers. Anything else doesn't really get swapped by bitcoin, it just stores them in the CPU's native endianness.


Why is wif prefix 0x80 more than pubKeyHash prefix

0x80 is the version number for private keys. It allows a decoder to know what to do with the data it received and to check that you have entered the correct thing. Like many magic numbers in Bitcoin, it was arbitrarily chosen by Satoshi Pieter Wuille.


How to correctly sign a transaction? Error: 64: scriptsig-not-pushonly

You are building an incorrect scriptSig.

Notice that, if you check the scriptSig of every input from the transaction you provided, it looks like:

76a914321d6a0077ddadfcce3d68d302d866ce81405eba88ac

Which has the following structure:

OP_DUP OP_HASH160 <20-byte-hash> OP_EQUALVERIFY OP_CHECKSIG

However, this is not what is expected to be found in a scriptSig, but what will be expected in the scriptPubKey field.

What you have to do is provide the correct script in the scriptSig field of each input of the transaction, that would correspond to the signature of the transaction if you are creating a P2PKH transaction, or the script that matches with the script-hash from the UTXO you are spending, in case you are building a P2SH transaction.


Can Bitcoin-Qt be configured to trim the blockchain?

Since Bitcoin-Core 0.11.0 you can prune (trim) the blockchain in Bitcoin-Qt.
But not from the UI.
You need to add prune=550 to your bitcoin.conf file and restart Bitcoin-Qt.

Explanation:
-prune=<target in MiB> will tell bitcoin-core to remove blocks which are older than oldest block that can be kept with a chainsize (sum of block-sizes) of <target> (min. 550MiB as example above shows). A minimum of 550MiB ensures to keep at least 288 blocks (~2 days).
(simple explanation not including undo-data)

Restriction:
-prune does disable all wallet functions in version 0.11 (will work with a wallet in version 0.12).


Can a Qubit Miner ASIC device be created and what would its impact be on the mining community?

The best thing I can imagine is running Grover's algorithm, which speeds up what would be an exhaustive search for a single solution among N input values to take only about the square root of N actual evaluations. Only very special problems, like factoring numbers, have better known quantum algorithms.

If you imagine connecting a hypothetical quantum computer to a mining pool, the impact would be low: The quantum computer can only be run on the share of work it gets, which means finding if any of 2^32 nonce values yield a proof of work. An ASIC miner could probably do that in less than a second using (internally and highly parallelized) something like 2^32 operations, each of which includes several 32-bit additions. The quantum computer could get away with doing about 2^16 equivalent quantum operations, which, after serializing the bit operations of the additions, likely means many thousand times 2^16 consecutive qubit operations. And it will require on the order of a thousand qubits, at least. Sounds to me like in this scheme a quantum computer might, at best, be equivalent to a hundred ASICs or so.

But it might just get interesting if we move more of the mining algorithm onto our hypothetical quantum computer. If the extra nonce can be incorporated into the Grover algorithm, a larger search can be performed, with a correspondingly larger speed-up. Unfortunately, a much larger quantum computer running a much more complicated program would be needed. Or let us say fortunately for whoever might otherwise worry about mining competition!


Proof of work: average number of tries to create a block

As MeshCollider's comment mentions, it is simply the difference between the total number of bits against the target bits.

As to why it is this way is just a function of probability. If you have a range of 1-100, and your target is <= 20, there are 20 numbers that satisfy your requirement. Thus, 20 * 1/100, or 20 tries out of 100 should result in a valid  number against your target.

It works the same way, although on a much larger scale here. Your target and attempt are both 256 bits numbers, which means they range from 0 to 2^256-1. If your target is 2^179, it means that 256-179, or 2^67 tries will, on average, produce a valid number against the target.


I think you may be missing that when a node in the Merkle tree doesn't have a hashing partner it is concatenated with itself before hashing. To calculate the Merkle root of a transaction tree with a single transaction txid0, you would need to hash:
Merkle root = sha256d(txid0 + txid0)

I'm not sure about the endianess conversions.


Are Bitcoin and Ethereum really de-centralized? Or is federated a better term?

Yes Bitcoin and Ethereum are still decentralized. What happened is it got to risky to mine solo so miners banded together to have a better chance of getting blocks. I suppose you could say that Bitcoin or Ethereum could be federated but the fact that these pools are competing against each other destroys that idea.
 Federated means (with reference to a number of states or organizations) form or be formed into a single centralized unit, within which each state or organization keeps some internal autonomy.* According to the definition of federated I would rather say that each mining pool is a federation of miners in itself. But with all these different federations involved it is still decentralized system because not one of these federations control more than 50% of the hashrate.

*Definition from Google Dictionary


Does Bitcoin-QT use more CPU when its idle than during synchronization?

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


My local client not showing correct output for listunspent

Apparently this command only works for addresses in my wallet, and moreover, there is apparently no way for the reference client to do this query for addresses not in the wallet (doh :-/)


BTC graph of Price vs graph of Market Cap inverted today -- is this normal?

EDIT: perhaps what I am seeing is due to different graph scales for the two values?

Yes, these two values are plotted on the same graph, but against different axis. Which line is higher/lower on the graph relative to the other is of no real interest.
Looking at the site in question, I can currently see that the y-axis on the left lists the 'Market cap', while the y-axis on the right lists the 'bitcoin price'. By adjusting the scale on either axis, the relative position of each plotted line will change.


getbalance and listaddressgroupings inconsistent

You are using getbalance incorrectly. You have specified an account name of the address that you want the balance for. However this is not how getbalance works. Bitcoin does not use accounts and addresses are not accounts. An account here means an account in Bitcoin Core's internal accounts system which has since been removed.

So your command getbalance mmUToPM2vBb2F1ZNcR86J12GxqAbUJtFCr is asking for the balance of the account named mmUToPM2vBb2F1ZNcR86J12GxqAbUJtFCr, but no such account exists. The account that has the address mmUToPM2vBb2F1ZNcR86J12GxqAbUJtFCr is named From Electrum Wallet. Thus the command you should be using is

getbalance "From Electrum Wallet"


Path notation for extended public key of hardened child?

Is there any standard notation for the xpub calculated from a hardened child private key?

I have chosen to use the below notation. Others may use it if they find it useful.

[m/44'/0'/0']

Is the public key derived from the hardened child private key.

[m/44'/0'/0']/0/0

Is a child public key derived from the master private key m. However, [m/44'/0'/0'] may be stored as a separate public key, essentially as a checkpoint in the HD tree.

This notation has some useful characteristics:

Easy to parse.
Shows exactly where the private->public derivation was done. So, while [m/44'/0'/0']/0/0 and [m/44'/0'/0'/0]/0 my produce the same xpub, the calculations done to derive that xpub were quite different.
Inside of brackets, hardened notation may be used, but outside of brackets only non-hardened notation is permitted.