Assuming that you are able to create the raw redeeming transaction yourself, it is possible to pass a signed transaction to bitcoin core's signrawtransaction (or signrawtransactionwithwallet on new releases), along with a json to describe the utxo being redeemed, to verify correctness.

In this example I'm setting up a json for redeeming a p2wsh scriptpubkey that has the very simple, single opcode redeemscript CHECKSIG, where the input's amount is one BTC.  The input's txid in this example is just FFFF...FFFF.

'[{"txid":"FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF","vout":0,"scriptPubKey":"0020EE6BB86B44339392BAE631C8F61DD8F009243C635ADAB33C0B20923A2794BF22","redeemScript":"AC","amount":1}]'

I've built the raw transaction redeeming this utxo, which is :

02000000000101FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0000000000FDFFFFFF01F0B9F505000000002321027777777777777777777777777777777777777777777777777777777777777777AC0347304402203333333333333333333333333333333333333333333333333333333333333333022055555555555555555555555555555555555555555555555555555555555555550121030EFF833692060EB20ABF63FDE930AD0F59BFDDF3FAD321AA5C85435120306FD101AC00000000

To check the validity of this spend, pass both the utxo and transaction to bitcoin core's signrawtransactionwithwallet :

$ printf '%s\n%s\n' 02000000000101FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0000000000FDFFFFFF01F0B9F505000000002321027777777777777777777777777777777777777777777777777777777777777777AC0347304402203333333333333333333333333333333333333333333333333333333333333333022055555555555555555555555555555555555555555555555555555555555555550121030EFF833692060EB20ABF63FDE930AD0F59BFDDF3FAD321AA5C85435120306FD101AC00000000 '[{"txid":"FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF","vout":0,"scriptPubKey":"0020EE6BB86B44339392BAE631C8F61DD8F009243C635ADAB33C0B20923A2794BF22","redeemScript":"AC","amount":1}]' | bitcoin-cli -stdin signrawtransactionwithwallet

{
  "hex": "02000000000101ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0000000000fdffffff01f0b9f505000000002321027777777777777777777777777777777777777777777777777777777777777777ac0347304402203333333333333333333333333333333333333333333333333333333333333333022055555555555555555555555555555555555555555555555555555555555555550121030eff833692060eb20abf63fde930ad0f59bfddf3fad321aa5c85435120306fd101ac00000000",
  "complete": true
}

To check the correctness of your script, simply replace the relevant values in the utxo and build the spending transaction.
The situation is a bit more involved when validating constraints such as relative and absolute timelocks.  To have extra assurance, you could use Regtest and Testnet to try out your scripts, and even then, if the script is very exotic (maybe using undefined op_nop codes, or other forms of non standard-ness), the transaction be easily redeemable on regtest\testnet but at the same time almost impossible to redeem on mainnet.


You can attempt to launch the client via the command line and add the -salvagewallet option this attempts to recover and dump the private keys from the wallet.


How many addresses can an Electrum Seed generate?

You don't need to worry about red addresses. Just remember roughly how many of those there were if you ever send money to one of them.

There is no practical limit of how many addresses Electrum can generate from a seed. To figure out, how much money you have in your wallet, Electrum needs to sum up the funds in your addresses sequence – of which I just said that it doesn't have a practical limit in the number of its elements. This causes a problem: When should Electrum stop checking for more money further down the address sequence? The solution is to introduce a gap limit g.

When Electrum sums up the money in the addresses, it has a counter c which is incremented every time an address has no recorded transactions and set to 0 every time it does. If c > g, Electrum stops.

By default, g is set to 20 since Electrum 2.0. Addresses beyond the gap limit are red. If money is sent to one of them but never to the g addresses before them, Electrum will not look for it.

The gap limit also determines how many unused addresses you're shown if you don't generate new ones.


Difference between createmultisig and addmultisigaddress?

createmultisig creates a P2SH multisig address for use in raw transactions.  It outputs the redeem script because you'll need that to spend any payments sent to the P2SH address.
addmultisigaddress adds a P2SH multisig address to your Bitcoin Core wallet, allowing you to track and spend payments received by that address.  It doesn't output the redeem script because Bitcoin Core stores that for you.  (You can retrieve it later with validateaddress.)


What is the function to get the object of a NXT asset in javascript?

You can get most of the nxt objects using NRS.sendRequest(""

The following code gets the asset object of whats in question.

NRS.sendRequest("getAsset", {"asset": asset}, function(response) { //do stuff with response}, false)

NRS.sendRequest("getAsset", {
  "asset": <*Your Asset ID here*>
}, function(response) {
  if (response && response.asset) {
    console.log(response);
  }, false
});

You would get the following response from chrome's console log like this:

http://prntscr.com/7zm5fh


Can a Raspberry Pi power 1 USB Asic Miner?

Yes.

I have been running my Pi (B, 512mb) with a 1.5 amp power supply with 1 usb erupter (Sapphire) for over a week with no problems. Directly connected to the Raspberry, no hub.


walletNotify on every Bitcoin Network transaction

Jeff Garzik's PyNode will, by default, connect to a Bitcoin Core running on local host a as a full node and download each transaction your node relays to it.  If you know Python, you can add extra triggers and post-processing to it.

Note, PyNode seems to be abandonware, and I think you currently need to hack it to get it to work with the latest versions of python-bitcoinlib.  It may still work with an older version of python-bitcoinlib.  You may also have better luck with PyNode2, a fork of the original PyNode.


Exactly how to add bitcoind params (e.g. "verbose") on command line?

Usually it's fairly descriptive if you know what's going on, for example it looks for a  boolean on the end of that command, so this will do as you wish.

bitcoin-cli getrawmempool true

bitcoin-cli has replaced bitcoind for RPC commands, you'll need to get used to it as the RPC client is being removed from the bitcoind binary fairly soon.


Withdrawals fees are individual per specific exchange and in many cases they don't relate to the current bitcoin feerate.
So you'd have to check your Coinbase and Binance exchange account, in the withdrawal section to see how much fees are they taking for withdrawal.


What are some of the advantages & disadvantages of the following: Colored Coins and Counterparty

The main difference between these protocols is how they associate and store data about asset ownership. Colored coins at least as implemented by Coinprism, put data in the form of a transaction output that must be retained in later transactions involving the associated standard transaction outputs (spending money). If a colored coin is handled by a wallet which is not colored-coin aware, the output containing data would not be reproduced and the colored coins involved would be lost.

Counterparty takes a different approach in that all of the ownership, issuance, order, betting and other data is stored in the blockchain with no relationship between money spending bitcoin outputs and the existence of such data. Instead, each counterparty transaction adds data to the global counterparty history. If your address has 500 FOO tokens, it will continue to have those tokens until a counterparty transaction is signed by your address that sends them somewhere else.

The model Counterparty uses, makes it possible to do things like locking the issuance of a token so no more can be created in the future.

Another fundamental difference is that colored coins use the 40-bytes available after an OP return whereas Counterparty encodes its data in the form of additional multisig addresses. Each allows spent bitcoins to be reclaimed but Counterparty can store more data in this way as long as Bitcoin's fee structure and mining community allow it.

In regards to how many xcp the developers control, that is unknown but is related directly to how many bitcoins they burned during the 30-day proof-of-burn period. At that time ~2100 bitcoins were destroyed to create 2.6 million xdp.

Colored coins would basically need to restart itself under a new model to copy what Counterparty is doing including its own solution to the initial distribution of a valuable, native XDP-like token.


Arguments against Bitcoin using adaptive blocksizes

The strongest arguments against dynamic blocksizes which can be determined by miner actions, is that they do not necessarily represent the interests of other participants such as users, node operators, or even all miners.

If miners setting the blocksize have good equipment and connections, they may want blocks so large that others are forced off the network. This could include large miners (with the best equipment and network connectivity) forcing smaller miners off the network. Alternately, (some) miners may want a small blocksize while others would prefer a larger one, but be unable to exert any real influence.

Other issues may include concerns that a specific algorithm could grow too fast, too slow, down not allow for downward scaling if usage decreases, or could be attacked.

In summary there is significant:

Difficulty in designing an adaptive blocksize formula that cannot be
"gamed"
Difficulty in creating the best model to minimize cost of
node-option (CONOP)
Difficulty in designing a system that can
efficiently scale both up and down
Time and expense to compare
alternative formulas and thoroughly testing them

Finding the optimal CONOP model that can satisfy the above concerns will be difficult and time consuming. Until then blocksize limits previously set by humans (and possibly adjusted by humans to allow for more time to study/research codified adaptive blocksize solutions) is the best option available.

CONOP was introduced in this article by Paul Sztorc:

http://www.truthcoin.info/blog/measuring-decentralization/

The concept in the context of adaptive blocksizes was also recently discussed at the Bitcoin On Chain Scaling conference by Riccardo Spagni:

https://www.youtube.com/watch?v=mM2ra-LzMQk


cannot decode block 0 to find the output address. I can decode much higher blocks. what am i missing?

Never mind I figured out my mistake. Earlier bitcoin blocks stored the public key in the signature instead of its hash.
Thank you anyway.


What makes a Bitcoin Miner chip such as an Antminer different than a usual CPU?

Bitcoin miners have ASIC (application-specific integrated circuits), special chips which can perform mining calculations and nothing else, and are very efficient for it. The specific calculations required are encoded in the hardware - the transistors are arranged in the pattern "calculate SHA-256".

In contrast, the CPU that exists in normal computers can do everything, but is not very efficient at any one task. The transistors are arranged in the pattern "execute the instructions that you are given". So you can give it any instructions you want, including "calculate SHA-256" - but it will not be as efficient as a special-purpose chip.


How much did you pay in fees? when they are too low they do take a while to confirm.

Keep in mind that you will not lose your coins. The tx will either get confirmed or around 48 hours that it hasn't been confirmed it will be invalidated (your coins returning to you).

Some wallets signal that a utxo is only spent after a transaction using it has been broadcast and confirmed. As you don't have confirmations, that's probably why it is marked as Unspent


Pass-through bank account, that transfers everything to your wallet

Bitcoin-Central is to-date the only exchange to describe the capability of an exchange account being integrated with a bank account.

It will be a EUR account.  There is no estimate on when this will be available.

Coinbase will draw funds from a bank account however they have not been able to keep up with the demand so there is no assurance that when funds are available in the bank account that a Coinbase order to draw those funds can be placed.

Dwolla is another method of drawing funds from a bank account for delivery to an exchange.  There is a several day delay between when the transfer request is placed and when the funds are made available in Dwolla for transfer to the exchange.


Upon looking at the source of a number of altcoins I have found that p2sh keys are built into all the ones I checked.

For P2SH, the first address byte will be:

  bitcoin: '05'
  litecoin: '05'
  peercoin: '75'
  dogecoin: '16'
  beavercoin: '05'
  freicoin: '05'
  protoshares: '05'
  megacoin: '05'
  primecoin: '53'
  auroracoin: '05'

The tricky bit about this is that you can't nessesarily tell what network a P2SH address belongs to like you can with normal addresses.

The reason I wanted to know is so I could collate the version numbers for my project:

http://github.com/ryanralph/altcoin-address


If newer versions of bitcoin and or bitcoin cash don't allow 0x04 uncompressed public keys, what do you do if you have an address based on one?

Uncompressed keys are only disallowed for segwit output types. Since segwit outputs are a completely new type of output that requires new addresses (and a new address type eventually), there won't be any effect on your current addresses and keys. Non-segwit transactions and outputs can still exist and will happen. These transactions will work  in the exact same way they do now; you won't be using segwit (and thus not allowed to use uncompressed keys) unless you explicitly go to use it.

Bitcoin Cash does not have segwit, so they are not invalidating uncompressed keys. The only part of BIP 143 that Bitcoin Cash is using is the sighashing algorithm.


Which method/programme can create a wallet using the least amount of space?

You may not need to have its entire blockchain on your machine, depending on your situation:

You should clarify / update your question to include why you are running bitcoind from a command-line in the first place.

If you JUST want a wallet/Bitcoin-address, there are plenty of options.

I personally use "Electrum Bitcoin Wallet" GUI and find it easy to use - again your question is unclear so this may not be your complete answer but should provide a start.


How to move in and out of wallets cheaply and fast?

There is no way currently to transfer bitcoins quickly and cheaply between wallets. You need to pay the fee necessary to get your transaction on the blockchain in the timeframe you're comfortable with.

In the near future, the Lightning Network (LN) will allow you to do this. Once you have a LN channel open, you can send to anyone (including an exchange) instantly for a very low fee. Exchanges like gdax won't be needed for crypto-to-crypto exchanges as soon as atomic swaps become available on more coins. Once that happens, you won't need a 3rd party to exchange cryptocurrencies (tho you'll still need them for dealing with fiat).

For more info on the Lightning Network, see the "So you wanna understand the lightning network" section here: https://governology.wordpress.com/2017/07/21/so-you-wanna-understand-bitcoin-part-2/


Python library for Multisignature HD wallets

Python bitcoinlib maybe? See: https://coineva.com/create-multisig-wallet-bitcoin-python.html


The balance is calculated from the UTXO set where unspent outputs belong to the address in question. Most block explorers will enable the transaction index, parse the historical and live data, and dump it into a database that runs on top of bitcoin to track additional statistics. As you can imagine this requires a lot more disk storage, but it makes things like searching faster.


BOLT #7: Can receiving node requirements in channel_update message give rise to malicious attacks?

According to my understanding the receiving node will first check the signature of related the dsha256 of the entire message before verifying the timestamp and not check the remainder of the message if the signature is invalid. So if other fields apart from signature are changed, then the signature will not be valid (as the message has changed) and the node will not process the message further.

This is the correct understanding. It is stated earlier on in the receiving rules. Although the client implementation must read at least the chain_hash and short_channel_id from the message in order to retrieve the public key associated with that channel from its storage (if it exists), in order to perform the signature check.

    if signature is not a valid signature, using node_id of the double-SHA256 of the entire message following the signature field (including unknown fields following fee_proportional_millionths):

    MUST NOT process the message further.
    SHOULD fail the connection.

The checks on the timestamp and other field are performed only if the signature is valid, and the purpose of the check is to prevent spam from a valid signer. It is assumed that more than one channel_update in the same second is a DoS attempt, and therefore, the node responsible for signing such messages ought to be blacklisted.


Is there a chart of Bitcoin merchants over time?

I went through the last 500 revisions of the wiki page, pulled the byte count into excel and graphed it. Line count would probably be a better metric but I didn't have a readily available data source for that. If someone wants to write a script that wget's each revision and counts the number of  tags that might be more accurate, but here's 500 revisions worth of data as a chart:

500 revisions goes back to Jul 8, 2011.

Also of interest, the earliest revision (Feb 10, 2011) of the Trade page has a scant 117 <li> tags while the current page has a whopping 785! I haven't taken the time to count all the revisions inbetween but that's quite a lot of growth - 668 new entries in 225 days for an average of almost 3 entries per day or about 1,084 per year! While some of these are bound to be non-merchant list items, that's still an impressive rate of growth.


How to stabilize Bitcoin's exchange rate (reduce volatility)?

The Bitcoin price is the result of a free market. There is no central authority that could by order "pump money into the system".

This currently happens anyway - but decentralized. When more people buy Bitcoins the market cap increases. With a higher market cap a single trade has a lesser effect on the price. Therefore, over time when Bitcoin attracts more users and investors, volatility will go down. There is no need for a centralized intervention.

Bitcoin can also be compared to small cap stocks or currencies of small countries. These types of assets are known for their high volatility. Large cap stocks on the contrary show a significantly smaller volatility due to the above stated reasons.

For a more in depth treatment of these arguments, read this article on Bitcoin volatility.


Multisig Who puts second signature into the script?

After "A" signs the transaction hash the hash gets updated to show his signature. "A" will send this partially signed transaction hash to "B" who will then sign that hash which will then return a third hash reflecting two valid signatures. Assuming only 2 signatures are required to spend, this third hash is what gets broadcast to the network.


My question really, could this be fraudulent BTC?

Not sure about fraudulent, but there are parties that send (near-dust) amounts of Bitcoin to existing addresses, hoping the wallet will merge the output with those sent to different addresses, as to figure out correlations for tracking.

$30 is a bit much for this, though! It could also be that someone copy/pasted a wrong address and accidentally sent to you.

  How the hell did they get my address,

Have you used it before? If so, they probably just found it in the block chain.

  and how long until I could possibly see this confirmed?

Depends on how much fee they attached. You could help it by creating a CPFP transaction spending it.

On the other hand you might not want to. If someone sent it by accident it is better for it to never confirm so that they can reclaim it at some point.


How can I measure outstanding debt? How much "stored value" is in Ripple at any given moment?

You can issue the account_lines command to a Ripple server to find out what credit lines have been extended by or to an account.

For example, you can use this websocket test page to issue websocket queries. Set the location to wss://s1.ripple.com:51233, click use secure, and then connect.

Then paste this in the Message window:
{ "command" : "account_lines", "account" : "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B" }

This pulls the credit lines that Bitstamp has. You'll see entries like this:

     {
        "account" : "rrpNnNLKrartuEqfJGpqyDwPj1AFPg9vn1",
        "balance" : "-501.64408854616",
        "currency" : "BTC",
        "limit" : "0",
        "limit_peer" : "10000",
        "quality_in" : 0,
        "quality_out" : 0
     },

This means that Bitstamp owes rrpNnNLKrartuEqfJGpqyDwPj1AFPg9vn1 501.64 BTC (Bitcoins) and that user has extended them a credit limit of 10,000 Bitcoins.


How to Track if Payment is Received with API in Coinbase

Use the callback URL, it will load it on the first confirmation.
Just have it load a URL that runs a script to notify you or record the transaction somewhere.
https://coinbase.com/api/doc/1.0/buttons/create.html

Create a payment button
This will create the code for a payment button (and modal window) that you can use to accept bitcoin on your website. You can read more about payment buttons here and try a demo.
The method signature is public function createButton($name, $price, $currency, $custom=null, $options=array()). The custom param will get passed through in callbacks to your site. The list of valid options are described here.


Can someone explain how to read blockchain.info?

A Bitcoin address starting with 3 is always P2SH (pay to script hash).
It's not P2PK (in that case you would see a public key instead of an address) nor P2PKH (you would see an address starting with 1).  It could be P2WPKH or P2WSH since these are simply implemented as special types of scripts via P2SH.  The address is only the hash of the script, not the script itself, and hash functions are one-way.  So we won't know what the script actually is, nor whether it happens to be a WPKH or WSH script, until after that transaction output is spent.
See https://bitcoincore.org/en/segwit_wallet_dev/ for more info about segwit.  In particular note the following:

Until a P2SH-P2WPKH UTXO is spent and the redeemScript is exposed, a P2SH-P2WPKH address is indistinguishable from a non-segwit P2SH address (such as a non-segwit multi-signature address)
Like any other P2SH and P2SH-P2WPKH address, P2SH-P2WSH address has prefix 3. They are indistinguishable until the UTXO is spent


How to send bitcoin programatically using API? Bitcoin Transaction. (Without Setting Node)

From C#, I would use NBitcoin to generate raw transaction and push it to some API provider. This eliminates the need of setting up full node.


How will Mt.Gox select matching orders if asking for a price that is higher than available prices

Of course it would select the cheaper ones. It's a limit order.


I'd like to connect an LKETC USB Scypt Miner to my Raspberry Pi. Help?

I think these might be rebranded ZeusMiner ASICs - LKETC doesn't appear to sell any scrypt miners below the 1MH/s range. Also, some of the reviews on that item say that they've had luck on linux with a fork of cgminer with ZeusMiner support.

There are two drivers you need. You need a driver for the USB-to-UART bridge, and a driver for the ASIC. The former is distributed with Raspbian, assuming the bridge is a Silicon Labs CP210x. (I think it is, based on the screenshots on that page.) The latter is usually distributed with your mining program of choice.

Possible fix

All instructions are intended for Debian/Ubuntu/Raspbian.

$ sudo apt-get install build-essential libtool autotools-dev autoconf git
$ git clone https://github.com/dmaxl/cgminer/ && cd cgminer
$ ./autogen.sh
$ ./configure --enable-scrypt --enable-zeus
$ make
$ ./cgminer

Troubleshooting (if that doesn't work)

When you plug it in, it should create the device /dev/ttyUSB1, and a device under /media or /mnt. You're interested in the first one.

You can get a list of devices that are plugged in with lsusb.


I'm not sure I understand your question, but: No, Bitcoin nodes do not announce their own Bitcoin addresses as part of the network protocol.

One could imagine modifying the protocol so that they did, but it would raise anonymity concerns: currently, by design, it is difficult to match an address with its owner's IP address.  If you knew at least one address that belonged to a particular node, you  might be able to look at other transactions in the block chain and deduce other addresses belonging to that node.  And ISPs usually have records that determine the identity of a user from their IP address.


How to run a full node: Am I already doing so?

Yes, congratulations you are running a full node.

Note that you're mostly running a full node so that you can fully validate everything so you can now send and receive money without trusting anyone. However you are trusting your PC itself, malware might steal your money or cause you to lose money (both would happen with non-full nodes too of course).

You might want to check how many connections you have (after bitcoind has been running for at least an hour or so) use getpeerinfo. If you only see 8 outgoing connections then other nodes can probably not reach you. If you would like to enable them to do so you might need to configure your router to do portforwarding.

For receiving bitcoins you don't even need to be online at all. For sending them you don't need to have finished downloading as long as it has downloaded far enough to know that you received any.


What's the magic key version bytes for BIP49

I'm implementing BIP49-compatible key derivation for bitcoin-s, but I'm having a hard time finding the magic version bytes to use for the extended keys.

It's prefixes are: YPUB = 0x049D7CB2 and YPRV = 0x049D7878

  Is there multiple schemes for deriving P2WPKH-nested-in-P2SH?

You are confusing the two. 77429938 that you have linked in Trezor is used to derive ypub. If you scroll down on Samourai code you will see 0x049D7CB2 for ypub which is same as 77429938 in decimal. xpub stands for extended public key and allows you to generate addresses and scan all the funds associated with them, but not spend them. ypub is exactly like an xpub, except the 'Y' denotes with certainty that this particular extended public key belongs to a wallet that is also following the BIP49 bitcoin standard. This instructs the wallet to definitely scan for P2SH(P2WPKH) addresses. There is also zpub, and that instructs the wallet to only scan for bech32 addresses that starts with bc.


asic mining with different cryptocurrencies after it is no longer profitable

An ASIC is an "Application Specific Integrated Circuit".  In the case of a Bitcoin miner, the specific application is performing the SHA256 hashing algorithm.  That is the only thing the ASIC knows how to do.

So long as the cryptocurrency you want to mine uses SHA256, you should be able to use the ASIC on that currency.


How to send Bitcoin from one addresss to another using nodejs

Learn bitcore-lib npm package:

Bitcore library provides a very simple API for creating transactions.
Let's take a very simple transactions:

var transaction = new Transaction()
    .from(utxos)          // Feed information about what unspent outputs one can use
    .to(address, amount)  // Add an output with the given amount of satoshis
    .change(address)      // Sets up a change address where the rest of the funds will go
    .sign(privkeySet)     // Signs all the inputs it can


Since Bitcoin Core 0.14.0, how does a node with default settings compute the dust limit?

The dust limit in 0.14.0+ is set by a value called the dustRelayFee. This is separate from the minRelayTxFee although it has the same default value of 1 satoshi/byte. That is what is used to calculate dust now, and the dust calculation is still the same as before. So the default dust limit in 0.14.0+ is 546 satoshis. You can configure the value you set for the dustRelayFee by using the -dustrelayfee=<n> option.

In Bitcoin Core 0.15.0, this will change slightly. The calculation changes to be that the dust limit is the amount that we would pay to spend the output at the dustRelayFee. To keep the dust limit the same as before at 546 satoshis, the dustRelayFee is increased to 3 satoshis/byte.


Accidentrally spent from unconfirmed transaction

There is nothing wrong with spending unconfirmed outputs.  Bitcoin core will happily spend its own unconfirmed outputs, though it does prefer not to if it has a choice.

Your transaction can't confirm until its parent does, but otherwise it's treated like any other transaction.

If the parent paid a low feerate and will take a while to confirm then you could be waiting a bit, unless your feerate was high enough to make up for it.

If the unconfirmed parent was created by someone else and they successfully double-spend it, then your child transaction will be invalidated. Otherwise, assuming that doesn't happen and the feerates are sensible it'll confirm fine.


How do bandwidth requirements for running a full node grow with blocksize?

The maximum bandwidth requirements for blocks previously (there is other traffic overhead including for transaction broadcasts if your node participates, the other traffic is variable depending on many factors mostly around network utilization) were ~1MB block size per ~10 minutes.

Now the max bandwidth for blocks is ~4MB block weight per ~10 minutes.

There is some information for current block size here.


What is the safest physical to store a private key only to be accessed after death?

If you are comfortable with a command line, I have used ssss-split and ssss-combine for sharding encryption keys in a n-of-m scheme.  These utilities use Shamir's Secret Sharing Scheme to safely break up secrets for later reassembly.

For example, you could create a 4-of-7 scheme, where you would hide shards in 7 different locations (personal safe, safety deposit box, trusted lawyer, etc...).  Any 4 shards could be used to re-create the original secret.  It has the property where only having 3 shards gives an attacker no more chance of cracking the secret than if they had 0 shards.

One benefit to this scheme is that up to 3 shards could be lost, and the original secret could still be recovered.  The other benefit is that up to 3 shards could be stolen, and the attacker still doesn't have enough to obtain the secret.

One important thing to note, however, is that you still need to make sure that the collection of private keys is not lost, even if it is encrypted.  BIP32 wallets are a great place to start (so you only need to shard a single key), but otherwise make sure that you have redundant copies of your encrypted wallet file.  The decryption key won't be any use if you lose the data that it decrypts.  Again, avoid that trouble by using a BIP32 wallet.


How is bitcoind "shy" when exchanging `version` packets?

First the peer who chooses to connect shares their version.
Each of the peers can only send one version message.

PushNodeVersion is used to send the version message. It is called by two functions

1) PeerLogicValidation::InitializeNode when the connection is outbound.

2) ProcessMessage when a message is received. It looks like this:

bool static ProcessMessage(...) {
    if (strCommand == NetMsgType::VERSION) {
        if (pfrom->fInbound)
            PushNodeVersion(pfrom, connman, GetAdjustedTime());
    }
}

If it was

    if (strCommand == NetMsgType::VERSION) {
        // If this if clause didn't exist: if (pfrom->fInbound)
            PushNodeVersion(pfrom, connman, GetAdjustedTime());
    }

Consider the following case:

1) Client A connects to Client B

2) Client A sends its version to Client B

3) Client B, as an answer, shares its version

Now, if that if caluse didn't exist, Client A would send the version message once again.

The comment // Be shy and don't send version until we hear is actually irrelevant.


Name of the country receiving the bitcoin currency

No. Bitcoin has no concept of countries or other societal constructions such as laws.


What prevents a miner from faking nonce hash

No correlation between any input bit or combination of bits and any output bit or combination is acceptable for any cryptographic hash. SHA256 is an accepted cryptographic hash.

Anyone can (and many do) verify a valid block by doing one hash operation, rather than the huge number it takes to find by brute-force, currently on the order of 1,000,000,000,000,000,000,000.

EDIT: I somehow computed 4 bits per byte not 8 (BIG difference), plus forgot the prevhash prefix. Corrected and also clarified some.

In addition to nonce, miners can tweak a few bits in time and use maybe 20-40 bits worth of choice in the Merkle root (by changing extranonce and/or transactions) in the time available. Plus part of prevhash is always the same (namely zeros) -- at least as long as the database 'shortcut' doesn't work, and it doesn't. Let's call it 80 160 bits total, meaning a complete database would be about 2^{240} 2^{480} entries. But we can't store that much, especially not since it must be accessed in significantly less than the normal mining time of 10 minutes. And since we can't know in advance which entries will be needed, no matter what subset of the database we store it's a "roll of the dice" for each block header whether it is in the database and thus "pre-mined".

If you use all of the roughly 2^{190} atoms in the Solar System (and move them close enough) and can store one header per atom which is many thousands of times denser than any known storage technology, your database will 'hit' (contain the desired solution) with probability one in 2^{290} which (since trials are independent) will occur for (rounding slightly) about one block every 20,000,000,000 20,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000 years, which is probably almost certainly longer than the universe will exist. (And certainly not often enough for you to make any profit from it.)

See also https://crypto.stackexchange.com/questions/1013/is-it-feasible-to-build-an-index-of-prime-factors for several discussions why a similar approach for breaking RSA is ludicrously infeasible even without the short time limit needed for Bitcoin.


My Bitcoin transaction hasn't confirmed in over 57 Hours. What can I do to speed it up?

Your transaction paid a fee of 101 satoshis per byte. With the current fee market, your transaction should be confirmed in about 17 hours. You could try using a transaction accelerator but the network is pretty jammed right now.


How to convert a keyPair to JSON and back?

Wallet Import Format can be used in a Javascript String,  which is JSON compatible.
For bitcoinjs-lib@^2.0.0:

  var prv = keyPair.toWIF()

To recover, use

  bitcoin.ECPair.fromWIF(prv)

Caution: if you store your private key in an insecure location, your funds will be insecure. fromWIF/toWIF does not provide any form
of protection.


Failing communication with Bitcoin node: Only one usage of each socket address (protocol/network address/port) is normally permitted

The problem was caused by my server making too many simultaneous requests to the same node.  The computer making the requests imply ran out of ports to use.


Coinbase (the company) is not bound to any value presented in any block explorer or even in the actual blockchain.  They decide what will be presented as your balance on their service's website, and hopefully it is always the same value that you expect to see.

Coinbase might allow funding of your balance through payment to bitcoin addresses over the bitcoin network, but in reality they will maintain a separate, much more efficient database than a blockchain to track that balance from that point on.

When you operate on those funds, you're operating on the number kept in Coinbase's database, not the one in the blockchain.  It costs money (as fees paid in bitcoin) to move funds between participants on the network, so any transactions that can be kept off chain are done within their own database (like sending between two Coinbase users).

In case you are withdrawing bitcoins from Coinbase, they will have to use an on-chain transaction (eventually), but the funding to it can come from any other payment made to them.  It doesn't have to be the same payment that you made.


If the current block mining reward is 12.5 bitcoin, then why don't outputs match?

The total output of the coinbase transaction of a block is normally the sum of the current block reward (which is newly created bitcoins) and the transaction fees from all the transactions in the block (which are not newly created coins, but are effectively being transferred from the users who made the transactions).

To put it another way, the following constraint is enforced for each block:

  Total of tx outputs <= total of tx inputs + block reward

(normally it will be exactly equal, unless the miner has screwed up)

as well as the following constraint for each non-coinbase transaction:

  Sum of outputs <= sum of inputs

You can see that the first constraint ensures that the number of "newly created" coins is no larger than the block reward (normally equal).  Then, a non-coinbase transaction can grant a transaction fee by having the sum of its outputs strictly less than the sum of its inputs.  The miner can then take the difference and add it to the coinbase transaction without violating constraint 1, thus collecting the transaction fee.


You can use the http api to perform an import. Notably, you import a wallet with the create wallet command as the import command imports addresses into a wallet.

curl -X PUT \
  http://127.0.0.1:18332/wallet/$ID \
  -H 'authorization: Basic eDppYW1zYXRvc2hp' \
  -H 'cache-control: no-cache' \
  -H 'content-type: application/json' \
  -d '{
    "masterKey":$MASTERKEY
}'

Link to docs


Mining Hardware lifespan is less than a year?

Mining really can be a zero sum game. The profitability factor though is the potential of increase in Bitcoin value. If you start mining now and begin start to mine less and less, you may only come out even. Hold those coins long enough, and you may be able to make a profit if the value of Bitcoin continues to increase.

If you throw all this money at ASIC hardware and it becomes useless in a year, it's trash. There is no use for out of date ASICS. Invest into GPUs and CPUS, in a year, you can at least sell the hardware.

Personally, I feel as though there is more potential for growth in GPU and CPU coins such as Litecoin and Primecoin/Quark. You can mine these coins and transfer to Bitcoin if that feels right for you. I started mining Litecoin in June with the assumption that I would break even around January. The value of Litecoin skyrocketed and the whole deal became very profitable. It all comes down to whether or not you believe cryptocurrencies will continue to grow in value. I believe that cryptos are just in their infancy, and things are just getting started. You might also be better off simply buying coins.


https://www.coindesk.com/information/how-do-bitcoin-transactions-work/

  She then sends them from her bitcoin wallet out to the wider bitcoin
  network. From there, bitcoin miners verify the transaction, putting it
  into a transaction block and eventually solving it.

Transactions are broadcast over the P2P network, which miners are also a part of, so they receive the transactions from their peers.

Miners are completely free to do choose which transactions to include in the blocks they mine, but generally prefer to maximize revenue by collecting fees from transactions.


When I start up my Bitcoin core, it says "loading block index".

The Bitcoin Core node software maintains several pieces of data on disk (excluding the wallet):

The actual blocks in append-only data files.
The block index (which block headers exist, how they interconnect, and where on disk they are stored)
The chain state (the set of unspent outputs with amount, txid and address) at the current best block in the index.

Because this information about what blocks are known and where they are on disk is so frequently needed, it is loaded entirely into memory.

During the "loading block index", the full block index is loaded into memory (it's pretty small, 60 MB at the time of writing), and several consistency checks are done (including verifying all difficulties and proof of work).

  Does this indexing occur on my local machine

Yes.

  or does this mean my wallet fetches the latest block info, more specifically the block height?

No, fetching information about new blocks always occurs in the background while your node is active, but during the "Loading block index" phase it is not yet active.

  What is the purpose of this block indexing?

By index you perhaps are thinking of something more fancy than it is. It's simply a table that allows you to look a block's information based on its hash.

Bitcoin Core internally has dozens of indexes for various pieces of data. This is just one that is relatively big, and stored on disk.


How to extract addresses from input in raw transaction

Addresses are associated with output scripts (scriptPubKeys). This information is not encoded in the transaction, the only information in the input is the txid and index of the output that is being redeemed. In order to do this offline you need to have the previous transaction.

The way they do it for inputs is they look up the previous output that the input is spending in their internal database and get the script from there.

In your example, this is the first input:

    {
        "addresses": [
            "38Rgbmaxitveg1S8UNbWjwV5UMoBt3PtnG"
        ],
        "age": 539082,
        "output_index": 0,
        "output_value": 18640,
        "prev_hash": "f0fa97af6ba86096d9efcfea0bef4d6d146552bdf70e25b067dce1c1520d37b4",
        "script": "2200202dc520822e73d4262000d3b456b16df1d07b0ba9d238f3063379d65840fd38e7",

        "script_type": "pay-to-script-hash",
        "sequence": 4294967294,
        "witness": [
            "",
            "304402202575f8326e510b8213d70a8213ab1a36cd2984b16673ef3579960d0089ad13de022020ec4e78129c084103909acec0319f7d326fff699de142ab354be9570d68dc1701",

            "304402202bc22860e84e0311bbc175940c2b3b5435255dc7ca3fb0d12e5f03df80237b880220536eceee1aace094825f0fd884d057e395102f4e4627188fe6dd5648cdc7a45701",

            "52210274ecb4e28e6b7be314d844bb7561b605d537106f7f5c3eaba31a8cd3dd0097c8210343ed9c58350b4013b3c9a02da2148d59e8109a90f0fa0ea77d31b8570990d46352ae"
        ]
    },

So you have to have the full tx with txid f0fa97af6ba86096d9efcfea0bef4d6d146552bdf70e25b067dce1c1520d37b4 in which case you inspect the first output (index 0) and from this output's script OP_HASH160 49e282ad0605c1cb63ff45fc34b14357859e8d08 OP_EQUAL you can derive the address 38Rgbmaxitveg1S8UNbWjwV5UMoBt3PtnG


Why do small transactions without fees ever get processed?

1) There is no motivation, asides your goodwill, or possibly wanting to support some useful Bitcoin tools, like the Bitcoin Faucet (transaction fees could eat up a lot of coins there).

2) It's a matter of how their pools and clients are set up. Some want to support the community by allowing no-fee transactions to be included in a block (as it costs them nothing), while others want to encourage people to pay fees by only including transactions with fees.

3) Technically, it might be less likely to be included if it gets really big in terms of data size (upwards to filling a block), but in most cases it won't matter (at least for now). Amount of Bitcoins sent doesn't really matter at the moment, but transactions on really small amount of coins can be discriminated against in the future should spamming them become more prevelent.

All in all, it is encouraged that you pay your dues when sending transactions, as it helps the Bitcoin project grow. If nobody was paying to get their transactions processed, the miners might soon not earn enough to get by (especially with reward halving slowly getting closer), which would result in them stopping their operations and weakening the Bitcoin network. It's not much of a threat yet, but in the future it can become important.


The source file for that method is here

BIP21 wiki

Method can be accessed like this

 String bitcoinURI = BitcoinURI.convertToBitcoinURI(String address, Coin amount, String label, String message);


What are the minimum and maximum lengths of a Mainnet Bitcoin address?

The wiki is correct! The source you linked must have assumed that the address with the smallest encoding has version_byte=00, data=20*00, checksum=94A00911
$ encodeBase58 00000000000000000000000000000000000000000094A00911
1111111111111111111114oLvT2

Which has length 27. This address is valid and has been used on the blockchain! But it is not the shortest address.
I wrote this short bash script to find the minimum length address. It found that there were a total of 266 address of length 26. For anyone who is curious, these are the 266 addresses with length 26.

The maximum length address has version_byte=00, data=20*FF, checksum=FA06820B:
$ encodeBase58 00FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFA06820B
1QLbz7JHiBTspS962RLKV8GndWFwi5j6Qr

Which has length 34. This has also been used to receive coins, as can be seen here.


Why is 'script' used in a transaction instead of the output address?

Scripts can be used to do a lot more thing than just pubkeys and signatures. There is an entire Bitcoin script language that can be used to specify things like multisigs, hashlocks, timelocks, conditionals, etc. It's pretty extensive, just hard to grasp and reason about. Such scripts do not map to addresses (before P2SH) so without having scripts in outputs, you would be locked into using only single pubkeys and signatures.


Why CBlockIndex does not store a vector of next blocks for forward iteration?

Memory usage. Adding a vector to each of the (now over 600000) CBlockIndex entries would be a significant memory usage increase (at least 48 bytes per entry, to be precise, on stdc++ 64-bit platforms).

For most operations it's also unnecessary. Instead, CChain stores a pointer to all CBlockIndex entries in the main chain, allowing O(1) access to any of those. Also, using the skiplist mechanism (see pskip) in CBlockIndex it's possible to efficiently find the height N ancestor of any given block (in O(log n) or O((log n)^2), IIRC).


What happens when "Request expires" in Electrum?

As long as you only work on the GUI, Electrum won't create private keys it doesn't generate again when you restore the wallet. On the console, you can increase the gap limit which can cause Electrum to not generate the private keys you already used to secure funds if you don't also increase the gap limit after restoring your wallet. But this doesn't mean your funds are lost, afterwards, if you keep the seed. For one thing, you can increase the gap limit in your stored wallet, for another thing, your funds will become "unlocked" after you used the restored wallet enough to make Electrum generate the private keys, again.

The "receive money" functionality of Electrum only is a built-in note program. You note for yourself that you're expecting a payment of 30 mBTC from Mark until January 18th. If he didn't pay until then, Electrum will tell you that his payment is overdue and you can get angry at him. However, Electrum has no means of sending Mark an email or something, and therefore doesn't do so. It's just notes for you. Furthermore, these nodes aren't restored when you restore your wallet via your seed as they remain on your computer and aren't sent to a cloud service.

And no, Electrum won't delete the private key corresponding to the public key corresponding to the address you noted as the receiving address, afterwards. That'd be a really bad thing. Just imagine, Mark is 10 minutes late with his payment. Then, the money he sent slightly too late would be lost forever.

You can even find this out for yourself: If you go to the tab "Addresses", you will see your wallet's addresses. The receiving address in the tab "Receive" always is the upper most unused and unmarked address, but the address is already there, before you create the receive note. And so, of course, is its corresponding public key and the private key which corresponds to that.

The only things happening when you tell Electrum that you plan to receive money, is that the note in the receive tab is generated and the address is assigned a label (which you can see in the addresses tab), which is just another local note.

You can of course hand your addresses out to people (in arbitrary order), without telling Electrum that you plan to receive money on them.


Bruteforcing a seed with 24 words of a unknown order

This depends a little bit if all words are independent. If yes the will be 24! = 620.448.401.733.239.439.360.000 permutations of the words. Assuming that you computer can check 1 billion permutations per second (which is is way too optimistic as this would assume that a signature / public key could be computed within one clock cycle which he can't) this would mean that your computer still would need 620.448.401.733.239 seconds which is 19674289 (19.6 million) years as the absolut minor / lower bound.
This estimation however does not take into account technological breakthroughs in computing hardware which could very well happen in that time frame (:


Can sidechains be used for fiat currencies?

Sidechains (at least the two-way pegged sidechains, as described in our paper), are about creating a new blockchain that uses the same currency as another blockchain.

Fiat isn't native to any blockchain, so it doesn't fit that category. You can't prove to the chain that fiat tokens are actually exchangable for real fiat. Fiat just doesn't live in the same world: it's defined by real world banks, not by a cryptographically verifiable ledger.

There are however many other ways to have fiat-representing tokens in an auditable ledger of transactions (a "blockchain"). It doesn't need pegging, or proof-of-work, or a sidechain (but isn't incompatible with them either). Still, a lot of the ledger technology itself can be reused. However, all of these solutions inherently require trusting an issuer, who promises to exchange the tokens for real fiat, forever - presumably by holding as much fiat in reserve as assets are issued.


How many paths are tried on average before a payment succeeds in Lightning?

I don't think there is a Public dataset online with an answer to your question. This would also be extremely hard to create as the results could change a lot depending on which node is doing the experiment.

I know people are probing payment channels you could do the same. Just do payments to random payment hashes and collect the data for your node. You will get the routing failures and attempted tries in that way you can easily collect those statistics yourself.


My wallet hasn't synchronized, can I make a transfer?

Yes, making a transfer works pretty fine with the Bitcoin-Qt wallet.
However, the transfer won't be submitted to the network until your local client is up to date. Up to this point, the transaction is shown in your local wallet but not in the global network.

As an alternative you could use another wallet, for instance Electrum (http://electrum.org):
Electrum is a wallet that connects to servers that are already synchronized and thus will give you immediate results as well.


I found a folder called: bitcoin-0.3.22 How do I open it?

a folder called: bitcoin-0.3.22

With that name it is probably a folder containing a download of an early version of the Bitcoin software. It may be a kind of compressed file called a ZIP file which Windows Explorer treats as a kind of folder. It may be the results of extracting the contents of a zip file.
Bitcoin version 0.3.22 was released on 5th June 2011
That folder isn't a wallet, there's no money in it.

Any remaining money would be associated with a file named wallet.dat probably in your %APPDATA%\Bitcoin\ folder.  It may have been kept in a different place back ten years ago but that's where it is normally found in current versions.


How to minimize risk when accepting zero confirmation payments?

From
http://www.cryptocoinsnews.com/news/the-mathematically-secure-way-to-accept-zero-confirmation-transactions/2014/02/13, here is what services like MyCelium and BitPay may be doing:

More specifically, with every additional second a larger percentage of active Bitcoin nodes will have heard the original transaction and everyone viewing the blockchain can be increasingly certain that the transaction will be mined in the next block and receive one confirmation, then two, and so on and so forth.
What this means is that any Bitcoin transaction can be accepted with zero confirmations with a mathematically derived confidence level some refer to as “Transaction Confidence.”  This transaction confidence measure assures us that even if a double spend were attempted the original and correct transaction is already too heavily propagated to be overtaken.

But as you aptly noted, there is no 100% risk-free way of being able to do this if you don't trust the sender.  That's why the blockchain exists in the first place.
One risk of relying on "transaction confidence" is that there's nothing in the network that prevents someone from submitting a double-spend transaction directly to the miners, without broadcasting it to the network as a whole, under the agreement that any blocks that those miners find should pick their secret one instead of the one they broadcast to the network.  This is a risk no matter how much of the network sees the public transaction, which is one of the reasons why you can't have 100% confidence in a transaction that has never made it into a block.
In particular, if you accept a 0-confirmation transaction that spends inputs from other 0-confirmation transactions, the risk is much greater, because either the transaction directly to you or any of its 0-confirmation inputs could be double-spent, to your detriment.
Frankly, even 1-confirmation transactions aren't risk-free.  Even under normal circumstances, blocks get orphaned, which could create a window for double-spending, because the winning branch may not resolve the transactions the way that the losing branch did.
If you're serious about trying to minimize the risks of accepting BTC in "real-life" (a.k.a., brick-and-mortar) situations where speed is important, I can't think of a better idea than going with a service like Coinbase (no affiliation).  Those services operate on a scale where they can afford to eat losses from double-spends, which should be rare, so that you don't have to worry about it.  Currently, they have an economic incentive to increase adoption of the currency by being very attractive to merchants who choose to do so.


Will running a pruned node make my store less secure?

No, not at all.

  I was wondering what will be the downsides to me running a pruned node?

With a pruned node you cannot:

Handle (extremely) deep reorganizations (which are in theory possible but in practice would indicate a very serious problem with Bitcoin's security assumptions).
Serve old blocks to other nodes.
Rescan for old transactions that may affect your wallet after importing an old address/key.

  I'm not too sure why I need a full copy of the blockchain.

You generally don't, apart from the cases listed above.


Why can't exchanges share their bid/ask contract pool?

There are several reasons, but one key one is simply that the assets traded are not perfectly equivalent. For example, a dollar at Bitstamp is not precisely equal to a dollar to Bitfinex. They have different banking connections, different withdrawal and deposit fees, and different risks of failing to permit a withdrawal due to insolvency, theft, regulatory pressure, or the like.

Another reason is that exchanges tend to permit fairly fast trading and having to synchronize with other exchanges would be slow and unreliable. This would be solvable if two exchanges want to perform such a thing, but rapidly become untenable if you tried to scale it. You can't reserve liquidity without freezing an order book or offers can execute out of order, angering traders.


There could also be hacks targeting the bitcoin software implementation. If a vulerability is applicable to software running on majority (>50% hashrate) of the nodes then it is a real threat.

For example lets say someone can craft a mal-formed transaction that somehow can trick >50% nodes to accept it (for example induce a buffer overflow and somehow allow attacker to gain remote access to the node system itself and make modifications) then bad things will happen.


Am I allowed to ask my employer (large IT multinational) if I can receive my salary in BTC instead of EUR according to german law?

There appears to be an obstacle in law:

  German labour law sets out certain rules when it comes to the payment of employees. An important regulation is § 107 GewO, which states a simple principle: “Wages shall be calculated and paid out in Euro”.

From Salary Payment in Tokens: German Labour Law Considerations

  Would I have to pay income tax if I do not exchange them for a year

Salary is subject to income tax. Paying a salary is not the same as making an investment.

  would I have to pay VAT for purchases made using BTC?

Yes.

  Germany will regard bitcoin as the equivalent to legal tender for tax purposes when used as a means of payment,

...

  When a buyer of goods pays with bitcoin, an article of the EU's VAT Directive will be applied to the price of bitcoin at the time of the transaction, as documented by the seller

From Germany Won't Tax You for Buying Coffee With Bitcoin

(the title may be confusing -- it is contrasting the rules in Germany with those in the US where using BTC to buy coffee means the buyer pays capital gains tax in addition to any applicable sales tax.)


Coinbase has the private key for the BTC transaction (because it should be the same as the BCH address), but it might require manual intervention on their part to recover the deposit and refund it. Unfortunately, their support is swamped with many other issues this month. If you submitted a support ticket to https://support.coinbase.com/, you might just have to wait a while before they get to it.


Bitcoin Core full node has saved a lot more space than 260gb

This is a known issue and a bug with APFS. This will be fixed in the next version of Bitcoin Core.


How to create a tx that cannot be replayed?

Yes, that method would work. It only works if the 0.1 BTC that you use as taint was mined after the fork. If it was from before the fork, then the transactions can still be replayed.


How to copy wallet.dat from v0.10.2.0 to v0.11.0.

As there was no response for this, and in case someone else has the same problem, I dumped the private keys, and then imported them to the other client.


Single-hop Payment vs Multi-hop payments

First of all at this point in time the whitepaper is pretty outdated and should only be considered as a rough conceptual guide. The Lightning Network Protocol itself is better and more accurately described / specified in the lightning rfc

That being said the situation is that even in the single-hop payment case HTLCs are being used. To set up and settle htlcs revokation keys and the revokation system currently play a vital role. The reason is as far as I know to save implementation overhead.

So if Alice wants to pay Bob in a direct channel the process is like that.

Bob creates an invoice with a payment_hash that is the hash of some pre_image
Bob somehow passes this invoice to Alice. (this can happen over any communication channel)
Alice creates an onion package (which basically just contains a 1 hop payment to Bob
Alice sets up an htlc by sending the onion via an update_add_htlc message to Bob. Alice also offers a signature for the next commitment transaction via the commitment_signed message.
Bob decrypts the onion. sees the payment is for himself and he that he can fulfill the onion.
Bob revok's his hold state by sending a revocation key to alice via the revok_and_ack message.
Bob sends signatures for Alice's new commitment transaction via the commitment_signed message.
Alice revokes her old state with the revoke_and_ack message.
the htlc is settled in a similar way as steps 4 through 7. (It starts with an update fulfill_htlc message send from Bob to Alice and then the state is updated for Alice first and then for Bob. Again recokation keys will be exchanged to get rid of the htlc output and create the state in which the payment has arrived at Bob)

A visualization of this process can be found in slides 136 through 144 of this slide deck. The process itself is described in more detail in BOLT 02

I should also note that there are other suggestions to for a payment channel protocol (for example Eltoo) which get rid of the penalty based system and the revokation keys but still use htlc's for actually transfering funds (either in multi or in single-hop payments)

Wellcome to this community I hope this technical and detailed answer is not too overwhelming. Please feel free to ask more question if necessary.


How to integrate a Bitcoin payment service in my auction site

It depends on where your head is, and what your level of skill happens to be.

You could actually run something like BitEscrow, and integrate it into your site. Or you could run a full on copy of Bitcoind, that would do the job without a payment processor. Of course, that requires thinking about things like security, which you might not want to do.

On the other hand, you have services like Coinbase and Bitpay and Coinpayments, and others, that can take some of the risk away by offering a viable third party interface, for which they, rather than you are responsible.

It also depends on the bigger question; which is, do you want to have Bitcoins or Fiat at the end of the transaction cycle? If it were me, I would want Bitcoins, because I like Bitcoins. But your needs may be different. You very well might want dollars or euros, and that's okay too.


If you are using Bitcoin version 0.7, you are on testnet 3. Updating to that version will put you in the newest testnet. Blockexplorer and Testnet Faucet use that version.


Explanation of Blockchain Payment systems

A block chain:

Block - a chunk of data

Chain - a sequence of links

So you need some data, and you need it to be inviolably linked to another block of data (repeatedly) forming a chain. In essence you take your first block of data, hash it, and append the first hash to the first data. For your second block of data, you include the first hash in the second block of data, the ph hash the whole lot to get your second hash. The second hash forms part of the data in the 3rd block. In pseudocode

Hash1=calc_hash(Data1)
Block1=Data1+Hash1
Hash2=calc_hash(Hash1+Data2)
Block2=Data2+Hash2
Hash3=calc_hash(Hash2+Data3)
Block3=Data3+Hash3

This is how the chain link between blocks is established - the hash from block N is involved in calculating the hash for block N+1. If you alter the data for block N, the hash will fail. If you calculate a new hash and try to pass it off as legit, the hash for block N+1 will fail.. and so on

It’s not new.. for many years longer than bitcoin has existed credit card terminals in certain countries have been communicating using a protocol that hashes each transaction and uses part of that hash in hashing the next transaction. It provides tamper deterrence/checking and also allows some nifty tricks such as telling the bank in a subsequent transaction whether the previous transaction was voided or not. Bitcoin might well pack many transactions into a block but it doesn’t have to- the credit cards terminals I mentioned for example, have a single transaction per hashed block


Problems loading blockchain from existing folder

As far as I am aware, you will also need the chainstate folder in order to properly run from a backup. Other files/folders are not strictly needed to restart your daemon. More information concerning specific folders can be found here: https://en.bitcoin.it/wiki/Data_directory

If all else fails start the process with -reindex and let it run - it "only" takes 24-48 hours depending on your bandwidth. Even though I know you don't want that!


How can wallets users know their private keys?

Electrum: pulldown menu "wallet", "Priv keys", --> export.

The idea to hide priv keys is linked to the security of the system. If the privkey is immedeatly "visible/accessible", the risk of unwanted access (be it malware, be it other people) is high, as the knowledge of the key allows for access to your funds. So the majority of wallets hide the priv key behind some access logic. There are passwords and seeds as most common layers, to be able to open the wallet, and then find the priv key behind a menu.

Yes, generally these wallets are save to use. On the opposite side there are so called "online wallets", offered by some providers. These wallets usually don't give you access to your priv key, and as such you have to trust these companies, that they have stored the priv key correctly (and safe) for you.


The limitation is a relay standard, but not a consensus rule. This can be modified on a per-node basis with $ bicoind -datacarriersize flag. The consensus rule that would limit this is the max block size, if I'm not mistaken. So, presumably, miners connected to the node that accepted that non-standard transaction mined that block, thus it was non-standard, but still valid.

Standards

These rules are enforced during mempool acceptance. Each node can decide to implement different rules, provided they follow consensus rules, but many just accept the Bitcoin-core defaults upon installation. In this case 80 bytes is the default setting for OP_RETURN data size.

Consensus Rules

These rules are enforced at the block validation phase. These cannot be different between nodes or it would be considered a hard fork and the chains would diverge.


Find used addresses of an HD wallet xpub (Extended private Key)

This process is in general very complicated and – missing a possible transaction – can lead to lost funds. Be careful.
With HD, you always generate publickeys. To find corresponding transaction, you need to turn them into addresses (which involves a bitcoin-script template like P2PKH).
If you just going to create standard P2PKH addresses in order to find transaction, you may miss relevant transactions.
For example: For a long time, Copay used 1of1 multisig (P2SH) for single user wallets. Restoring a such xpriv HD master with just P2PKH can result in lost funds.
Also, you need to know the used BIP32 keypath scheme of the wallet you like to restore. Some wallets are using m/0'/k, some m/k, others stick to BIP44. This makes it again more complex to "regenerate" funds.

Without a fully address-index blockchain, scanning for funds can be complicated and may take serval hours.
Probably best practice is to generate a large lookup window, where the size depends on the type of the wallet. Example: if it was a merchant wallet, there are probably serval thousand key involved. This would speak for larger lookup window.
If you want to use Core, what you can do, is generating addresses in a first lookup window.
Example:

generate pubkeys from m/0'/0 . m/0'/5000 (lookup-window of 5000 keys). Attention, this will not catch BIP44 wallet funds.
You can use a BIP32 tool for that purpose (maybe https://github.com/libbtc/libbtc#the-bitcointool-cli).

Import all these pubkeys into a new wallet (use importmulti in Core 0.14, importpubkey before 0.14 without a rescan).

Restart bitcoin-core with the -rescan option.

Decide if you want to extend the lookup-window (maybe if addresses up to 4900 are used), and start again with 1.)

TL/TR:
Someone should write a script/tool/app.


If you have some hash power, you can perform Finney attacks on testnet. With regtest, you can perform any attack requiring 51% of the hash power since on regtest you are 100% of the hash power.


nLockTime affects transaction validity only, if you make a transaction with an nLockTime in the future (by block height or unix time) it is invalid until that time has been passed. This means that if you sign a locked transaction, you can also just as easily sign a different transaction spending the same outputs that is spendable today.

This is useful if you wanted to make a contingency transaction and give it to a third party which spends the output to a charity if you aren't around to make use of it in a years time. If you are around you can spend it in an alternate way, if you aren't a third party can broadcast the locked transaction to the network once it has become valid.
The limitation is in that you can't prove that funds are actually locked in this state, there's no way of knowing that the person won't just spend around an nLockTime transaction in a different way and bypass the restriction on when they could spend the funds. Setups are possible where a user sends an output to a new key, makes a locked transaction to themselves at another address, then destroys the private key, but this is incredibly flimsy and has no real assurances that the key wasn't retained secretly.

CHECKLOCKTIMEVERIFY is a new proposed opcode that allows you to use the current real time in a transaction script, allowing some more interesting and provable use cases that involve actually locking money rather than a particular transaction. This is closer behavior to how people normally think nLockTime should operate when they first hear about it.

With CLTV, scripts that have different preconditions for spending based on the time are possible. Rather than limiting to a single presigned nLockTime transaction, a person could have every transaction in their wallet spendable by a specific charity key if 2 years pass without them being spent, or a 2-of-3 multisignature could have a contingency backdoor where an additional party can be included if the funds have not been used for an appreciable amount of time.
CLTV also allows for payment channels to be used even with transaction malleability. A mutated transaction can break nLockTime refund transactions at any point, which makes them quite risky at present. With CLTV the payment channel transactions can just timeout and be refunded to the creator without the need for any further interaction.

BIP65 is potentially dangerous to end users as there are pretty much no take backs (if you lock your money for 5 years, there's no back doors or workarounds that will get your money back before then), but that said, that's a user interface problem rather than a fundamental security one. There's little contention about soft forking this change into the Bitcoin codebase in the future.


sending an order through BTC-e API incorrect field error

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

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

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

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

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


what is referred as coin in bitcoin network?

TL;DR: When bitcoiners refer to a 'coin' they really mean a UTXO, unspent transaction output of any amount from 1/10,000,000th of a BTC to 21million BTC.

When someone sends bitcoin to another person, it gets added to the blockchain as you said. When signed by the sender's (Alice) key and verified by the miners, that transaction becomes a new UTXO.

When Bob goes to spend the 2 BTC that Alice sent him, his wallet will create a new transaction that says, in effect "take the UTXO from X address (that Alice sent him) and transfer it to the following Y address ..." That then creates a new UTXO.

In this example there is simply two bitcoin in each transaction. But what if Bob only spends 1 of the 2 Alice sent him? His transaction will then say "take the UTXO from Y address, send 1 BTC to 'Z' address (his recipient) and return 1 BTC to my wallet at the following 'change address, A The change address, A, is in Bob's wallet, so it can again be spent by him at a later date. In this example, the single UTXO (aka coin) that Alice sent Bob has become two of half the size each. Thus the absolute number of 21 million bitcoin is preserved.


You should be able to do this. You can retrieve your blockchain.info mnemonic seed phrase, and then enter it into the bitcoin core wallet to create a second instance of the same wallet.

It is worth noting that after doing so, you will still be able to access your wallet through blockchain.info. Because of this, if you are only planning on using bitcoin core from this point on, it may be smarter to just create a new wallet with bitcoin core, and then send all of your bitcoin from blockchain.info wallet to bitcoin core wallet. This will reduce the possible attack vectors for someone trying to steal your bitcoin. Remember to make good backups of your mnemonic seed phrases!


Why are hashes base16 (hex) encoded rather than base58 encoded?

Mark H's answer is correct, but I think there is a more fundamental point: addresses are directly intended for human consumption. Transaction hashes (as well as public keys, block hashes, raw scripts, raw transactions, ...) are not. They are sometimes visualized, but this is primarily for debugging purposes. And hexadecimal is a very natural choice for debugging, as it's easy to see which bytes correspond to which characters.


Will the Bitcoin network discredit a transaction if you do a simple transfer on a multi-sig after you found the collision on that address?

No, this is not a palpable concern.
Multisig is generally implemented by means of Pay to Script Hash (P2SH) addresses. Hereby, the receiver defines a script that they'll use to spend the funds, and forms an address from a hash of the script. Later, when spending, the original script is revealed and must be fulfilled. In the case of a 2-of-3 multisig, this will require two valid signatures corresponding to two of three explicitly stated public keys.
The only way a collision could be found would be if, hypothetically, a script that only requires one key happened to hash to the same address. It is generally considered infeasible to search for such pre-image collisions other than by brute force since cryptographic hash functions are one-way functions, though.


Is Bitcoin core V.0.9 not updated on PPA ppa:bitcoin/bitcoin?

The PPA is on 0.8.6, which is very recent (just missing 0.9, but I'm gonna hopefully upload that today). What you're referring to is the Ubuntu package distribution, which is very, very, very out of date (to the point of it being largely non-functional).


On the Bitcoin testnet, will transactions with higher fees get mined quicker?

Because the testnet bitcoins have no financial value, the transaction fees aren't really an incentive for miners there. But we assume that miners will run similar software to that on the mainnet and make sensible decisions regarding the fees they put in a block, so higher fees should make the transactions mined faster yes.


Bitcoin QT restore old wallet.dat - needed for Israel supreme court

Being that you have the wallet.dat file (and the password), one option that you may want to consider is using pywallet to dump the private keys and public addresses from the wallet.dat file.  See https://medium.com/crypto-blog/how-to-recover-old-crypto-wallet-private-keys-with-pywallet-bafdaeb4928e for more info.


Berkeley-db from brew which is clang compiled is GCC incompatible. Either Recompile berkeley-db4 with GCC:
HOMEBREW_CC=gcc-10 HOMEBREW_CXX=g++-10 brew reinstall --build-from-source berkeley-db4
or compile Core with clang
Discussion: https://github.com/bitcoin/bitcoin/issues/3228


What valid transactions are not broadcastable?

The following transactions are not broadcastable with the default bitcoin core configuration but could be found in new mined blocks:

Transactions whose fee is smaller than 1 sat/vB (and RBF bumps that increment less than 1 sat/B).
Transactions with size greater than 100 vkB (and smaller than ~ 1 vMB)
Transactions with outputs amounts smaller than 566 satoshis (dust limit)
Transactions that are considered non-standard (I will try to list them because this is a very broad category)
Transactions with scriptSigs larger than 1650 B (and smaller than 10kB)
Transactions with more than one OP_RETURN output or an OP_RETURN output bigger than 83 B.
Transactions with scriptPuKeys of bare n-of-m multisigs, where m > 3.
Transactions with scriptPubKeys or ScriptSigs that make the transaction malleable.


Are vanity addresses Vanitygen generated really safe to use?

The key point here is that vanitygen is not deterministic - It relies on entropy provided by the system it is running on, which is why running it multiple times with the same pattern will produce different addresses.

As long as the entropy provided by the system used to generate the address is sufficiently random, keys produced by vanity gen are as good as keys produced by any other program that would have used the same entropy.

Naturally, you should be verifying that the binary you are running matches the source code, and is using a good source of randomness, before moving any funds to those addresses.


Sending Bitcoin from LocalBitcoin to another wallet to secure my funds, does it work?

Does Bitcoin transfer from normal web to TOR Network secure in any way the bitcoin?

Transactions in Bitcoin are linkable. In other words, if you anonymously sent me Bitcoins to address 123, I could see that those bitcoins used to belong to address 456. If I also had a copy of LocalBitcoin's database, I could see that address 456 belongs to you. I would have a high degree of confidence that the Bitcoins came from you.

Tor doesn't fix that, but it's still a good idea. Tor can hide your IP address, but in the above example, I never used that anyway.


How long should synchronizing your wallet for the first time take?

There are two factors to the time to catch up with the network:

The sheer size of the blockchain
The time to verify the blocks

As Tom mentioned the blockchain is currently about 7GB in size, so no matter what it'll take some time to download it. On the other side you have to verify each block, hence each transaction in the block, which requires random access to the blockchain downloaded so far. Depending on your setup the bandwidth may not be the main issue. Random lookups on spinning disks are not the fastest thing to do, and using an SSD might actually result in a speedup of the synchronization.

So don't worry if your bandwidth is not fully utilized, it just might be that the disk is the bottleneck (especially for later block >180'000 with lots of transactions in them).


How can an online system detect coins sent to its offline (cold) wallet?

Since version 0.10.0 bitcoind has support for watch-only addresses.

Here is the text from the release notes:

  Watch-only wallet support

  The wallet can now track transactions to and from wallets for which
  you know all addresses (or scripts), even without the private keys.

  This can be used to track payments without needing the private keys
  online on a possibly vulnerable system. In addition, it can help for
  (manual) construction of multisig transactions where you are only one
  of the signers.

  One new RPC, importaddress, is added which functions similarly to
  importprivkey, but instead takes an address or script (in
  hexadecimal) as argument.  After using it, outputs credited to this
  address or script are considered to be received, and transactions
  consuming these outputs will be considered to be sent.

  The following RPCs have optional support for watch-only: getbalance,
  listreceivedbyaddress, listreceivedbyaccount, listtransactions,
  listaccounts, listsinceblock, gettransaction. See the RPC
  documentation for those methods for more information.

  Compared to using getrawtransaction, this mechanism does not require
  -txindex, scales better, integrates better with the wallet, and is
  compatible with future block chain pruning functionality. It does mean
  that all relevant addresses need to added to the wallet before the
  payment, though.

Try bitcoin-cli help importaddress (and the help texts for the other relevant commands listed above) for the details.


Json-rpc fails with "No connection could be made because the target machine actively refused it"

I was using bitcoin's port. Should have provided a port for litecoin: 9332.


How to tell whether an address is local or remote?

The validateaddress RPC will do precisely that.  Here's sample output from a testnet address with Bitcoin Core 0.10.0:

{
    "isvalid" : true,
    "address" : "mgnucj8nYqdrPFh2JfZSB1NmUThUGnmsqe",
    "ismine" : true,
    "iswatchonly" : false,
    "isscript" : false,
    "pubkey" : "03bacb84c6464a58b3e0a53cc0ba4cb3b82848cd7bed25a7724b3cc75d76c9c1ba",
    "iscompressed" : true,
    "account" : "test label"
}

If the field ismine is false, the address doesn't belong to the currently-running Bitcoin Core wallet.


Can Bitcoin help charitable organisations ensure payments go to the right people?

By itself Bitcoin doesn't provide a complete solution however it could be used in conjunction with a trusted non-governmental entity to track charitable flows.  The issue is that while Bitcoin provides public and irrefutable evidence of monetary transfers it doesn't (and shouldn't) provide information on who owns those accounts.  It would require some mechanism of registering ownership of accounts similar to how an SSL cert is used to not just encrypt traffic but to also validate ownership of the site.

Using a system of cert authorities and public key encryption one could create "public and verified" addresses.  This has potential uses beyond just Charities.  The Bitcoin network itself should always remain psuedo anonymous.  It was designed to have properties of digital cash and trying to force verified identities into the network would be a mistake.

A better solution would be building a framrwork that allows entities to volentarily have their identitiy validated.  They could then be issued a digital cert which would enable them to sign an address making it public & verified.

Many businesses would benefit by linking an anonymous Bitcoin address to their real world identity to improve the trust and confidence of customers and suppliers. Remember Bitcoin is irrevocable so this present unique challenges if it were ever to become mainstream.  If a major store (Amazon for example) decided to accept bitcoin and was hacked, the attacker could replace Amazon payment address(es) with their own. Unsuspecting customers would be paying the wrong entity and would have method of reversing those fraudulent transactions. The larger the sales volume the more tempting the target.  In the Amazon example even if the attack was detected within minutes a sizeable amount of funds could be diverted.

To protect against this thread an entity could use a "public & verified" payment address.  Wallets & browsers could implement changes to warn users that an address in unverified, similar to how browsers use SSL today to provide warnings or assurances to users.


Which sender is banned in case of nvalid transactions or blocks?

There is no way to know which node created a transaction or block, unless they publish that information themselves. Nodes should not have an identity that leaks into transaction or block data.

So banning for relaying invalid blocks or transactions always applies to the peer that gave you the information, based on their IP address. The protocol requires you to validate information before relaying, so you are in violation whenever you pass on invalid data.


How does this time-stamping system work?

But what if someone has a copy of (e.g. steals) the original file? How can I certify I was the original owner?

If you want to use the bitcoin blockchain as timestamped proof that you had the idea (document) first, then you’d need to be the first one to submit the document for a time stamp. A timestamp doesn’t prove ownership of an idea, just possession of it at that time.

  If I go to a legal entity that can make a proof of the document with my identity and date, it doesn't matter that someone steals it from me, because the document is certified with my identity. Since the blockchain is anonymous, this does not work. Can anyone explain please?

You could simply add your name to the document that is being timestamped to prove that you were the one that submitted the document at that time. Since only a document hash is stored, this wouldn’t sacrifice your privacy at all.

Alternatively, if you created the OP_RETURN transaction yourself, then you could sign a message using the private key of the bitcoin address that was used as input to the transaction. This would prove you have the private key that was used to sign the transaction that timestamped the data.


How do wallets select which balances get sent as part of a transaction?

The standard software uses some heuristics trying to minimize the transaction data size (which mostly means as few inputs as possible), with preference to older outputs which have higher priority. More information is available at What is the coin selection algorithm? and https://en.bitcoin.it/wiki/User:Gmaxwell/coin_selection.
If the sum of the inputs you use is larger than the amount of coins you wish to send, and you want to get the difference back rather than paying to the miner, you'll need a change output. Since the inputs almost never happen to sum up exactly, and you do want the change, almost all transactions have a change output; but there's no rule saying there must be one.
Every block has a special generation transaction. The miner who finds the block can freely choose the outputs for this transaction, as long as their total value is no more than the generated coins + total transaction fee.


First, don't even consider mining on nVidia GPUs. Secondly, if you're using nVidia GPU, why do you use AMD APP? You should be using nVidia CUDA instead. Next thing, Reaper is NOT mining on your GPU on the screen given, but on CPU instead - that's clearly stated in the screenshot you provided (using all devices - and only CPU is listed).

@Tom: you don't have to supply any command line options to mine with Reaper, all config can be easily done via .conf files.


Does IBB make money? Where does its earning come from?

As stated by what appears to be the founder (or a key person) in this thread in the bitcointalk forums, calling himself senbonzakura: "profit from the bank must be halal (permissible). So if the bank lends at interest, the interest then is profit for the bank, and that would mean muslims(or jews/christians) cannot buy shares in the company as the bank deals with interest, which makes it non-permissible/haram."

The motivation for running the IBB seems to be somewhat charitable, with this (edited) comment from the same person: "The problem that those 3 religions is trying to solve is human greed. Under that philosophy it does rightly condemn interest, for the reason that interest places the 'haves' infront of the 'have nots'.... From a humanitarian-philosophical perspective [the IBB] makes perfect sense, from a capitalist perspective it doesn't".

However, it is being run as a business. The IBB website says it's listed on the GLBSE, and it has asset, revenue, and dividend figures. The website doesn't go into much detail about what the bank does, but if you were to read the above linked forum thread you'd probably learn a lot more about it. Since the bank is paying out dividends, I doubt that those purchasing stock in IBB are doing it purely as a donation.

So, to summarise:

The IBB is profit based, but doesn't earn money from interest.
If you assume their revenue chart is accurate, it earns money
Their revenue stream includes (complete list so far): Shares/Dividends, Arbitrage, Gratuity
Even though IBB doesn't charge interest, they accept donations from borrowers. Depending on the culture of the customers, this could be considered to be like making optional interest payments.


How can I load a specific private key into my wallet


Solo mining on created altcoin: not able to create block

You should run instance of node in atlest two diffrent machine and both of the need to get connected via blockchain.The reason behind need of atlest two diffrent machine is consensus protocol.
To add another node,

  Run same instance of code on second machine add following line in conf
  file:

addnode=*ipOfSecondMachine*

  To check if node is conneceted

getpeerinfo

is what you need

Then go with normal  steps of minning,

ps: if you are trying to mine srypt based coins like ltc then i recommend sgminer


What happens on my computer when I mine in a pool?

Regular mining is repeatedly inserting different nonces into the block then hashing it until you find a nonce that makes a hash that is smaller than the difficulty.

Pooled mining is just like this except you don't use the full difficulty, you just have to be good enough for a much easier difficulty that the pool assigns to you. When you find a nonce that is good enough for the pool difficulty, then you tell the pool that nonce. That is a share. The pool verifies that the the nonce is good enough so the pool knows that you did the work. So the number of shares that you send tell the pool that you had to do so much work to find them.

You receive in the first place a block to mine with that you put the nonces into. You also receive a difficulty that the pool wants you to use.

You send the nonce that was good enough for the difficulty. You send this to the pool. You never interact with the network at large.

A stale share is a share that you mined on a block that isn't valid anymore. If the pool sends you a block to mine on, then someone else finds a new block, then you find a share on the old block, your share is worthless now, so it is stale.


Is JavaScript wallet generator available at bitaddress.org relatively secure?

It is good to consider the security of a system in which you are relying.

The HTML and Javascript served is not obfuscated so the code is easily verified.

While there have been no formal security audits, at least not that I'm aware of, there  are many people with strong skills in cryptography, programming, math and security that have looked at the code.

The method used to generate an address draws from other open source tools (e.g., Crypto-JS) as well as a subset of Bouncy Castle for the ECSDA ported to Javascript.  In other words, BitAddress isn't doing anything that hasn't already been implemented elsewhere, it just implements them in Javascript.


how EC Public key is generated from the private key effectively

There are a number of more efficient algorithms to compute the multiplication than just the naive method described. A simple one is double-and-add where the point is repeatedly doubled and then added with previous doublings in order to calculate the final public key. There are a number of more complicated methods which are more efficient.

You can read about these on Wikipedia.


Configure Bitcoin full node in my local LAN

It is said that deploying a Bitcoin full node would protect the privacy of my Bitcoin addresses.

Only to some extent. It is true that at least some employees of any business providing custodial wallets know a lot about the person associated with each address in their wallets. It is also true that nodes relied on by a simplified payment verification (SPV) wallet also know more than normal about the wallet holder.
However there's information in the public blockchain which is amenable to some forensic analysis that a sufficiently resourceful person or organisation can use to penetrate privacy to some extent.

If I configure a Bitcoin full node to be outbound only, would that be enough to protect me?

I doubt it has much effect on privacy regarding addresses used in transactions.

Do i still need to have a public IP address? (Since no other full node will connect in, do i still need to configure/supply a public IP address?)

No.
You might want to investigate whether your router supports UPnP and the implications of that.


Want to write my own solo cpu bitcoin miner

Tim S. pretty much covered it, but I wanted to 2 great resources which have been very helpful for myself and many others:

Ken Shirriff's blog has a few Bitcoin mining related posts which use Python code to great effectiveness; whilst Bitcoin Mining The Hard Way is probably the most useful, there's also some novel use cases where Ken tries Bitcoin mining by hand and using a 55 year old mainframe
Not specifically related to mining, but very useful in visualising related concepts is RoyalFork Blog


How long does it take to perform a single SHA256?

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

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

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

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

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

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

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

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


The relevant function in the current latest git revision:

int64_t GetBlockValue(int nHeight, int64_t nFees)
{
    int64_t nSubsidy = 50 * COIN;

    // Subsidy is cut in half every 210,000 blocks which will occur approximately every 4 years.
    nSubsidy >>= (nHeight / Params().SubsidyHalvingInterval());

    return nSubsidy + nFees;
}

Which is used later in ConnectBlock(), as follows :

 if (block.vtx[0].GetValueOut() > GetBlockValue(pindex->nHeight, nFees))
        return state.DoS(100,
                         error("ConnectBlock() : coinbase pays too much (actual=%"PRId64" vs limit=%"PRId64")",
                               block.vtx[0].GetValueOut(), GetBlockValue(pindex->nHeight, nFees)),
                         REJECT_INVALID, "coinbase too large");


The tests you mention are tests that drive the UI classes directly. They are a bit like robot tests and are a bit fiddly. If you don't run those specific tests you lose a bit of UI test coverage but no coverage of the deeper classes.

RE: the code being poorly documented: There are lots of Java doc comments, pretty much everywhere. You'll appreciate that the documentation effort has been much more on the end user side of things. MultiBit is a fairly typical MVC architecture, though of course it has accumulated a fair amount of cruft over time. Surprisingly code is almost always documented in line.


What is the difference between a electrum server type F and P

F: Full servers

P: Pruned servers

This is an old question, Electrum server are not F or P anymore.


Most Antminers have a WebSocket API that connects to the built in CGMiner software on port 4028.

You can test this in a command prompt in Windows, Mac, or Linux with (nc is a program called netcat which you may need to install):

echo -n "stats" | nc IP_OF_MINER_GOES_HERE 4028

There may also be a way to do this with CURL instead of netcat, but I have not had a chance to test it yet.

Code Examples:

  api-example.php - a php script to access the API   usAge: php
  api-example.php command  by default it sends a 'summary' request to
  the miner at 127.0.0.1:4028  If you specify a command it will send
  that request instead  You must modify the line "$socket =
  getsock('127.0.0.1', 4028);" at the  beginning of "function
  request($cmd)" to change where it looks for cgminer

  api-example.rb - a Ruby script to access the API.  usage: ruby
  api-example.rb command[:parameter] [HOST [PORT]] This script prints
  the parsed cgminer API response

  API.java/API.class  a java program to access the API (with source
  code)   usAge is: java API command address port  Any missing or blank
  parameters are replaced as if you entered:   java API summary
  127.0.0.1 4028

  api-example.c - a 'C' program to access the API (with source code)
  usAge: api-example [command [ip/host [port]]]  again, as above,
  missing or blank parameters are replaced as if you entered:
  api-example summary 127.0.0.1 4028

Java Example

C Example

PHP Example

Python Example

Ruby Example

I've built a small script for my personal miners which will not work for most environments (due to reliance on data from SlushPool), but it may be useful for some code snippets (C#): Here