How to differentiate between mining node and non mining node in bitcoin

Not really.  When a node sends out a block, it doesn't indicate whether it mined the block itself, or whether it's relaying a block received from another node.  The intention is that mining, like other aspects of Bitcoin, can be done anonymously, so the miner has plausible deniability.

If you have a large number of nodes on the network, then you could see which of them received the block first, and the peer who sent it is somewhat more likely to be the actual miner.  Some block explorers do this and report that peer's IP address, marked something like "relayed by".


How to get started with building an fpga mining device

See: Open Source FPGA miner and additional info


So having a deterministic/reproducible build system is more of a software development practice than it is a single piece of software like Gitian. There are a variety of projects that try to implement this practice which are listed below:

https://reproducible-builds.org/who/

Gitian handles the deterministic building through a virtual machine, and then the uploading and comparison of signatures through git. However, deterministic building is impossible to automate for all set of software, due to the wide range of things that can cause the compiled code to be different (for example read https://wiki.debian.org/ReproducibleBuilds/Howto or https://blog.torproject.org/blog/deterministic-builds-part-two-technical-details where they describe specific issues for reproducible builds in their particular projects). So at the end of the day, part of the reproducible build process is manually hunting down all the things that can cause the binaries to be different and fixing it.

So if you have a project like Debian with thousands of software packages and authors, part of the reproducible build system must be education and statistic tracking.

For smaller projects, what you need depends on the software libraries you are working with and what OS's you are distributing for. For example, Debian has their own reproducible build tools. You could use https://diffoscope.org/ to identify specific differences in your binaries.


Like all the Bitcoin clients, MultiBit is like a duck paddling on a lake. On the surface everything is calm but the legs underwater are kicking continuously. There is a lot of activity under the surface talking to the network, updating and saving the wallet etc.

The Send bitcoin button is greyed out when the client is either busy, or waiting for something else to complete. If you hover over the button with your mouse the tooltip normally gives you more information.

The possible reasons are:

1) If you are performing an operation that affects the structure of the wallet, various options (including Send bitcoin) are temporarily disabled. This is: add/ change/ remove password, add receiving addresses, import/ export private keys, reset blockchain.

2) MultiBit transmits the signed transactions on one bitcoind connection and listens on its other bitcoind connections to hear the transaction coming back. (It then knows the transaction is in the Bitcoin network and propagating). For this reason, it waits until it has two bitcoind connections before enabling the Send button. You should see a message on the Send window to this effect if this is happening. If you did something fancy with your network connections, for instance only opened port 8333 to a single node, you might have inadvertently prevented MultiBit from making multiple bitcoind connections and would see this.


when starting lightningd, you want to add the option:

--addr=[insert your IP address here]

so maybe when starting your lightning node, at your command line you would enter:

lightningd --alias DavideRivola --network bitcoin --log-level debug --port 9735 -ipaddr 192.168.1.1

Where 192.168.1.1 you would of course, put your own IP address.

Also, since you are probably unaware of this as well, in case you want to choose the port, use the --port=9735 option and just change the port to which you want to use. Everybody pretty much uses port 9735 though. Make sure that this port is forwarded on your internet router and is not blocked by your firewall either.

Also, if you want to choose the color that represents your LN Node on the #recksplorer site, you can use the following option --rgb 00cc00 where 00cc00 is the RGB code you would like to use. (In this case I have chosen green, because, well..look at my name :) )

Use this site to find the corresponding RGB Code for the color you want to use: http://www.color-hex.com/

use the command lightning-cli listconfigs to check what you have configured for your node to make sure everything is right after it is up and running.


What is an accepted standard for a Bitcoin system secure from loss?

The most common approach seems to be backing up your (encrypted) wallet on cloud hosting services such as Dropbox and Google Drive. To reduce the risk of theft, use a very strong password to encrypt your wallet, and do not store the password anywhere less secure than the password itself (e.g. if you use a password manager, it should also have a very strong password).

To reduce the risk of accidental loss, keep backups in multiple places. E.g. Dropbox, Google Drive, email it to your family and friends, back it up to an external hard drive; if one of these disappears, chances are still good that you can recover it from another source. You don't want the keys to be in only one physical location...e.g. having the only backup be in your house means that a house fire or theft could mean you lose your bitcoins.

Just don't forget the password! Maybe you should write it down and keep it in a safe deposit box at a bank, and/or keep paper wallets there, if it's worth the cost to you (maybe $15/year for a small box).

A rather different approach is taken by deterministic wallets like Armory and Electrum, which generate one root key or seed and then generate your private keys and addresses from that. Armory's root key works on the idea that you print out the ~256-bit root key in one or more fragments, and need the appropriate paper records to restore your wallet. Electrum's seed is a 128-bit number represented by 12 common words, which you commit to memory and/or write down. Securing these records would follow similar guidelines to a written password or paper wallets.


Prompt user for payment amount using bitcoin bip 70?


z can be calculated more easily from the raw transaction.

To get z this way, you have to simply delete all the script signatures in the raw transaction. Then place the script_pubkey of the input you are trying to evaluate where the script_sig used to be. (in the case of a multi-signature transaction you have to replace the scriptSigs for the correspondent redeem script).

This has to be done for each input, so the raw transaction will contain no script_sigs at all, and only one script_pubkey (where the script_sig was for the input being evaluated).

Then, you have to append the type of sig_hash which is almost always SIGHASH_ALL at the end of the raw transaction. The sighash field has 4 bytes of length and SIGHASH_ALL has the code value of 1, which is represented by 01000000 in hexadecimal which is 1 in little endian.

After you empty all the script_sigs, and put the script_pubkey of the input being evaluated, and also append the 01000000 at the end of the raw transaction, you can procede to calculate the double SHA256 (HASH256) of the modified raw transaction. Check out https://en.bitcoin.it/wiki/OP_CHECKSIG.

The outcome of this hash will be interpreted as a big-endian integer, and that will be your z for the particular input.

You have to repeat this for every input, so there is a different z for each input.

To evaluate your signatures (r,s), you will have to use the mathematical formula of the ECDSA which is:

A)  uG + vP = R.

B)  kG = R.

where:
C)  u=z/s; v=r/s

G is the originating point of the secp256k1. https://en.bitcoin.it/wiki/Secp256k1

P is the point of the public key on the curve.

u and v are integer scalars and, therefore, uG and vP are points on the curve.

R is just another point in the curve as a result of the addition of the other 2 points uG and vP , and will be the point that will verify the signature.

If you already have r and s (as is implied from your question), and you already calculated z, then you can calculate u and v from the formulas in C. Once you get u and v, and since you have your Public key P and G is defined by the secp256k1, then you can procede to calculate R from formula A. Just remember that this addition happens on the curve which is also on a finite field.

Once you get R, you will extract the x coordinate of this point on the curve which has to be exactly the same as r from the signature. If they match, the signature is correct.

If you want some code to get z, here is a function from an excellent book called Programming Bitcoin by Jimmy Song :

def sig_hash(self, input_index):
    s = int_to_little_endian(self.version, 4)
    s += encode_varint(len(self.tx_ins))
    for i, tx_in in enumerate(self.tx_ins):
        if i == input_index:
            s += TxIn(
                prev_tx=tx_in.prev_tx,
                prev_index=tx_in.prev_index,
                script_sig=tx_in.script_pubkey(self.testnet),
                sequence=tx_in.sequence,
            ).serialize()
        else:
            s += TxIn(
                prev_tx=tx_in.prev_tx,
                prev_index=tx_in.prev_index,
                sequence=tx_in.sequence,
            ).serialize()
    s += encode_varint(len(self.tx_outs))
    for tx_out in self.tx_outs:
        s += tx_out.serialize()
    s += int_to_little_endian(self.locktime, 4)
    s += int_to_little_endian(SIGHASH_ALL, 4)
    h256 = hash256(s)
    return int.from_bytes(h256, 'big')

However, you will have to take into account that this is just for the basic case of a P2PKH. In a P2SH transaction you will have a small variation.


Isn't it the file containing (the current running instance of) bitcoin's pid,
http://en.wikipedia.org/wiki/Process_identifier#Pidfile?


How two transactions with the same hash can cause double-spending

The scenario your tried to imagine is almost correct.

The point is that the "attacker" will generate two identical transaction coming from the same unspent outputs of his address X to "Vendor" address Y. He will generate T1 and T2 at the same time, taking funds to send from the same source but he will attach to each transaction a different fee. Of course one of the two transactions will have an higher fee.

The transaction with the higher fee (i.e. the tx which the "attacker" sends back to his owned address, as you called T2) will be the one ACCEPTED by the network. T1 will be rejected because it comes from the same unspent outputs than T2 but it has a lower fee, so after a while it gets pruned by mempool of Bitcoin network.

In conclusion, pseudo double spending, it's a matter of fees and not tx timestamps.

Hope this helped.


What is the best way to monitor non-wallet addresses for new transactions

You can use the importaddress functionality to make the Bitcoin Core wallet (bitcoind or bitcoin-qt) treat certain addresses as its own, even though it does not have the key for them.

This will make them appear in the outputs of RPCs like listtransactions, getreceivedbyaddress, listunspent and getbalance. It will also trigger notifications through -walletnotify and the recently added ZMQ mechanism.


From the Bitcoin.org Developer Documentation, a block header consists of a:

Version
Previous block header hash
merkle root
timestamp
nBits field
nonce

In that order. So as you say, the only component missing from your list is the version and the nBits field. The version is self explanatory, but the nBits field is not. What the nBits field does is encode the current target for the difficulty algorithm:

  to have at least 18 leading zeros.

Not always 18 zeroes. The number of leading zeros changes based on how quickly blocks have been found recently, in order to keep the block time at roughly 10 minutes average despite varying hashpower on the network. As more miners join, the hashrate increases, so the difficulty does too (i.e. more zeroes are required). Another way to think about the 0's, is that the output of the SHA256, as a number, must be less than some target number. That target is encoded in the nBits field. And yes, anyone can verify that the block header hashes to a number below the target, that is how other clients verify blocks are valid, because SHA256 always produces the same output from the same input - it is deterministic, a property of all useful hash functions.


New Blockchain.info wallet but where are my bitcoins? How to access them?

This method will only work if you didn't imported any addresses to your account. (Reason? "Please note that imported addresses are not backed up by the wallet recovery phrase. We strongly recommend you sweep funds from imported addresses." Source)

First go to Electrum and download the wallet from there.

Then install & open that wallet.

While opening, select "standard wallet"

Then select "I have a seed"

After that you will get a screen like this where you need to import your 12 word seed:

Then click on "options"

After that click on "BIP39 Seed"

Then the wallet will have your BTC with the same address.

Hope this helps you in some way.


Recommended way of printing a cold wallet

You can use BIP 38 encryption to encrypt your private key and then just print out your private key normally. BIP 38 will encrypt the private key using AES with a passphrase of your choice (so make sure that it is a secure one) and encode it using Base58 Check Encoding so you will get a string that is your encrypted private key. Because it is encrypted, you can print it out normally without risking the private key being revealed as the printer and any devices on the network will only see the encrypted string and not the actual private key.

The only caveat is that if you forget your passphrase, you lose the private key. One way around that would be to write your password on the printout.


Can I use the same bitcoin address to receive more than one payment?

An old address can be reused, but its usually recommended you don't do so for privacy reasons.

Even if you wallet is displaying a new address, it should still show a balance that includes any recent payments made to older addresses.

To be sure, check the receiving address on a block explorer website, and if the vendor is telling the truth, you should see the recent payment in addition to any past transactions. At that point,  try re-syncing your wallet if the payment isn't displaying properly.


how to recover a wallet from crashed bitcoin core

If you still have the wallet.dat file in the backup from your old bitcoin core, you can still access your funds. Let the new installation finish syncing, then import the wallet.dat using the "importwallet filename" command in the debug window console of bitcoin core, or "bitcoin-cli importwallet filename" from your computer's console.


How to 'buy the dip' without constantly incurring network fees?

"Buy the dip" is used by traders even for legacy markets and nothing specific for Bitcoin.

This will undoubtedly incur high network fees

For paying less in fees while moving bitcoin from/to exchange do the following:

Use P2P exchanges: Bisq and HodlHodl

Use open source bitcoin wallets with active development and support for segwit

Use RBF for all transactions. Try with low fee rate and increase later if it doesn't confirm in time.

Use websites like https://mempool.space that are helpful in managing bitcoin transactions with lots of information including CPFP details.

Use layer 2 if possible especially for small amounts: LN, Liquid. Exchanges that support LN: Bitfinex, Okex, LNMarkets etc.


bmsc only works with the BITMAIN cgminer...

I have fully tested and configured cgminer 4.9.2, the latest to work with the U3, check out my videos on vimeo and dailymotion, do a search for cgminer and antminer u3, full instructions are included.

I have bfgminer working with the U3 as well....


I've tried everything from mining bitcoin to litecoin to other altcoins....why do I have no luck?

Laptop mining worked well in 2009. It is no longer 2009.

Your integrated Intel GPU has the speed of a CPU, not a fast gaming GPU. Even in 2011 when CPU mining was dying and people mined on GPUs your GPU would be too slow.

Yes, "even" people with 100 MH/s can't mine anymore. That's because 1000x that speed (100 GH/s) is slow at this point. 1 TH/s (1 000 000 MH/s) is OK for a small mining-at-home operation.

If you go way beyond laptops with Intel graphics integrated in the CPU, to small USB sticks with ASICs, even those are useless now. Some people pay $5 or $10 for a 1 or 2 GH/s USB stick (much much faster than your laptop). Not only is this incredibly slow, but it will never break even because the price per GH/s is extremely high.

What you need is a 1 TH/s ASIC machine, or faster, and electricity at a good price. You need to get this machine at a good price per GH/s or it will not break even. Make sure you take the price of a power supply into account as well if it is not included.


Exchanging BTC (bitcoin) for LTC (litecoin)

Just use shapeshifter!

https://shapeshift.io/

No account needed, instant, and it has a fair exchange rate. I used it multiple times to exchange coins.


What percentage of bitcoins are being traded/used on a regular basis?

As of October 2012, it was determined that around 78% of all bitcoins minted (as of May 13 2012) were being hoarded "in user accounts that have never participated in outgoing transactions", meaning that all other trading and commerce was actually being transacted with a "float" of the remaining 22% (i.e. less than 1 in 4); and there is really no way of knowing how much of THAT might simply be faux-"trades" between accounts owned by the same entity.

Certainly very little of the total float (and thus even less of the total "coinage") is actually being used as a "currency" to make purchases.


Is transaction malleability an issue in Ripple?

Ripple uses substantially the same signature scheme as Bitcoin does and the server validates signatures similarly using OpenSSL. But Ripple doesn't require you to refer to previous transactions by ID to spend from them. So you can't prevent people from spending funds or jam their transaction chains.

The Ripple server will soon enforce fully canonical signatures on transactions and validations to ensure that no such attack is possible.


How a web-service like bitnode.earn can know each node's blockchain height?

Sites like bitnodes run their own lite nodes which are crawlers. These nodes connect to other nodes and only receive data from those nodes. When a node receives a new block, it will send it to the nodes it is connected to. If one of these is a bitnodes crawler, it can record that it received a block at height X from the node. In this way it can track the current height of a node.

Furthermore, nodes send their current height when they connect to another node. The crawlers, if they happen to disconnect from a node, can quickly retrieve the latest information about the node once they reconnect by simply waiting for the version message which must be sent in order for the connection to continue (it is part of the handshake at the start of every connection). The version also contains other information such as protocol version number and user agent string.

Other metrics such as up and latency come from the fact that the crawlers have open and active connections to those nodes. The fact that they have a connection means it is up. They can use the ping message to measure latency.


Is Lightning Network a risk for Bitcoin security since it reduces miner fees?

The idea that Lightning will reduce the amount of fees going to miners is very common, and we probably won't know for sure until we actually try it. However, I'll try to provide some arguments as to why I don't believe it'll result in a drop in fees for miners, let alone a drop in hashrate.

I think the idea that Lightning will drain transaction fees from the Bitcoin network is wrong. First of all Lightning will enable completely new use-cases for Bitcoin, increasing its reach and resulting in a vast increase in the transaction rate and tapping into markets that are currently simply too expensive to serve. Every single one of these transfers will result in some (small) fees for the channel operator, which she can then use to pay for the on-chain transaction for the maintenance of the channel. The fees can be much higher than a classical Bitcoin transfer since the utility the operator derived from the coins in the channel are much higher, since they have been sent back and forth an arbitrary number of times.

Think of Lightning as an aggregation layer for Bitcoin: it processes transfers that the current Bitcoin cannot process itself, accumulates fees and then releases some of those fees back to the Bitcoin layer.

Secondly, Lightning shifts the security model from a model where we broadcast a transaction and eventually it'll confirm, to a model in which the confirmation time becomes time-critical. There are transactions in Lightning, which we need to get confirmed before a timeout, otherwise we risk losing some coins, due to an old state being committed to the blockchain. This time-critical confirmation encourages channel operators to attach larger than usual fees to these settlement transactions. Fees that end up with the miners.

Finally, on-chain Bitcoin and off-Chain Lightning transactions have different tradeoffs, I don't see the world becoming Lightning only, but I do hope that Lightning is a useful tool for some use-cases. In the end Lightning is a system that is built on Bitcoin, and thus can only be as secure as Bitcoin itself.

(disclaimer: I am one of the developers working on Lightning)


Can you use non-standard characters for creating a Bitcoin Brain Wallet?

In short words: yes.

But you should know the algorithm how brainwallets are generated. Nobody guarantees that brainwallets on different services are generated with the same algorithm.


Thousands of early blocks are empty except for the required generation transaction. See block #1, for example.


That would be absolutely possible. In fact, there is a cryptocurrency out there called "Hashdollar" which is trying just that. I didn't look into it yet but if you tie the value of the Hashdollar to the US Dollar, you could use the p2p network to make "real" dollar transaction. The problem here is though, who will guarantee for the value of the Hashdollar? The value of Bitcoin is mostly made by market mechanisms but if you tie the value of a crypto currency to the dollar, you would need to have some authority to guarantee for that value and I do not see that happening.

Of course the feds could just come up with their own version of a cryptocurrency (eDollar?) and this might actually happen very soon.

Hashdollar: https://bitcointalk.org/index.php?topic=368237.20


You can build your miner with a bash command:

$ while true; do bitcoin-cli -regtest generate 1; sleep 300; done

You'l get a block every 5'. If you want a better simulation of mainnet you could use a rndom sleep


How to generate valid BTC address to withdraw coins to

Your bitcoin client is generating a P2WPKH (bech32 encoded) address, which is a newer address format which has some benefits compared to legacy formats. The address is valid, but for whatever reason, the exchange mentioned has not upgraded it's code to recognize and send to this address type yet.
The fix is easy: you just need to tell bitcoin-core to generate a legacy address. You can use the following command:
$ bitcoin-cli getnewaddress "(address_label)" "legacy"
You can substitute your own label in for the (address_label), this is just for local book-keeping purposes, it can also just be left blank if you'd like:
$ bitcoin-cli getnewaddress "" "legacy"


How does each miner know when to create a block?

A miner begins creating a new block as soon as it receives a valid block from another miner.  It then begins to construct and hash the next block on top of the block it just received.

You were correct when you thought that each miner has a separate block from the rest.  Don't look at it as if miners are all cooperating to find a hash for the same block, but rather are competing against each other to make their own block the next in the chain.  If they find a valid block, they broadcast it, and other miners give up their efforts, and instead focus their hashing power on the next block.


Is there a way to report/shutdown a Bitcoin Criminal/Bad-Actor?

Bitcoin is supposed to be permissionless and censorship resistant. That's the whole point. So, no, you can't do that.


Are trades done on exchanges added to blocks?

No.

Or are they only added once you withdraw the funds to your own wallet?

Yes.

If this is the case, how does the exchange decide on transaction fees?

Fees for trading are just a property of the exchange, transaction fees on Bitcoin transactions for withdrawals are just their choice to make. They might absorb that cost, or pass it on to the user depending on the exchange.

Now, is it possible that as a buyer one may be buying bitcoins that don't actually exist? How is this controlled?

It isn't controlled at all, you trust that the exchange actually has something to sell. There's no way of knowing if they actually do or not as a client or an outsider. They might be a complete sham, might hold only a portion of the funds they claim to, or they might be completely legitimate.


What you want is the code for Florincoin's wallet's coin selection. This is found in the CreateTransaction function. Within CreateTransaction, the wallet also calls SelectCoins and that calls SelectCoinsMinConf. The coins are actually selected with SelectCoinsMinConf but SelectCoins and CreateTransaction are all involved with coin selection.

Also, because Florincoin's wallet is based on Bitcoin Core, it does not use FIFO for coin selection. Rather it uses Bitcoin Core's special algorithm for selecting coins which is difficult to understand (it tries to solve the knapsack problem by selecting exactly the amount you want to spend, but then it does some weird things to handle fees and change).


What are the safety guidelines for using the Sign Message feature?

The signing mechanism is a way of proving that a particular message was signed by the holder of an address' private key.  A merchant could ask that you sign a message stating where you want your order shipped to, using one of the addresses your payment originated from.

You should sign a statement saying "I, Jane Doe (jane.doe@email.com) sent 1.23 BTC to Acme Corp at 12:34pm, 1st Jan 2012 in payment for product XYZ for delivery to 456 High Street, Anytown, USA".

You shouldn't sign a vague statement saying "yes, I sent that money; send the product to the address I emailed you", because anyone seeing a copy of that signed message can then pass that on to the merchant with his own postal address and get the product you paid for, in the same way as you wouldn't put your signature to a piece of paper saying "I agree to the above" where the above was left blank.  The postal address part won't be signed, but perhaps the merchant won't care.


Can a multi-sig address also be a vanity address?

Yes, that's possible.

In fact, the party that creates the address is the only one who needs to agree on the character sequence.

Suppose you have an address that can be spent with 2-of-3 multisig. This is a pay-to-script-hash address (starting with 3 instead of 1). Your script would probably look something like this:

2 <pubkey A> <pubkey B> <pubkey C> 3 OP_CHECKMULTISIG

This works, but this script's hash (with overwhelming probability) will be rather boring.

Suppose party A wants a more interesting address. She knows her private key k_A, and her public key Q_A, as well as everyone else's public key. All she has to do run the following algorithm:

while not interesting(address):
    Q = Q + G
    k = k + 1
    address = hash160('2 <Q> <pubkey B> <pubkey C> 3 OP_CHECKMULTISIG')

At which point her public key is Q, and her private key is k. G is the generator point for the secp256k1 curve. Then Alice reveals this script to Bob and Charlie, who verify that the script contains their public keys and that it hashes to the expected address.

Bob and Charlie cannot distinguish between an address generated in this special way, and Alice getting lucky on the first try in her choice of private key.

vanitygen already implements something like this for 1-of-1 signatures when you tell it to generate address starting with 3.


How long do transactions on the Liquid Network take to clear?

Does it still use a blockchain?

Yes, it is using a blockchain, however it is "federated" with a known set of participants which enforce consensus rules. It does not utilize proof-of-work mining.  The Liquid sidechain allows 2-way pegging of assets eg: L-BTC <-> BTC.

  How fast are the the transfers?

The Liquid white paper mentions 1 minute block times with the possibility to reduce this:

"Today, the implementation allows for one minute blocks. It will be possible to reduce the time to the amount required for the pre-commit and agreement threshold time of the network traversal"

However (as of October 29th, 2018) the Blockstream website has a bullet point indicating the actual settlement time is 2-minutes currently:

"React to trading opportunities faster thanks to two minute settlement times when sending between exchanges."

This should allow much faster transfers between exchanges which could potentially let users trade L-BTC upon receipt as though it were BTC.


BTC-E - Is there an official limit on frequency of requests that can be made?

At around 50 to 60 requests/second their host provider (I believe cloudlfare) starts to error.


What is the relationship between hash rate and accepted shares?

There really isn't one when you are pool mining. Most pools these days use VarDiff to achieve the same number of shares per minute by changing your workers difficulty. Now, on a low end mining rig (lets say 20 kh/s) the number of shares accepted may vary greatly as you may have some great luck with your share or it may be bad luck. So as long as you have a "sane" level of hashing power you shouldn't see (m)any trends/changes (as long as the pool+VarDiff is properly set up).

That being said, when you are first connecting to VarDiff enabled pools you will start at a diff of 1, then it will adjust over a period of time to achieve a share per minute rate that was defined by the pool op.

Source: Me, I'm a pool-op

EDIT
At one time, the number of shares you submitted directly related to your hashrate, the more accepted shares, the faster you were hashing. AsicMiner products still use the protocol originally used by pools (and bitcoind) called "getwork". Most notable of the pool servers used at that time is pushpool.

With VarDiff you don't have the ability to calculate by the number of shares submitted. So you now calculate the hashrate based on the difficulty of the share submitted. I personally have found that when the hashrate calculation based purely on the number of shares submitted is slightly weighed in with your hashrate calculation based on the difficulty of the share submitted, the user's hashrate you calculate is more accurate than you would have if you calculated the hashrate purely on the difficulty of the submitted share.


This is a common problem with electrum and nothing for you to worry about. As long as the transaction has confirmed in the blockchain it means that the coins are yours. Usually restarting electrum "fixes" this. Try restarting it a few times.


Why the leading zeros in the desired hash pattern?

The leading zeros are there to control the difficulty of the problem. More zeros mean a lower space of possible solutions and hence harder problems (more hashes to try before you find one that wins).


How are new bitcoins created without monetary inflation?

Bitcoins are created at a predetermined rate. Until this rate drops to 0 (around the year 2140), the supply of bitcoins is increasing. If this isn't offset by destroyed/lost coins and increased demand, some amount of inflation will occur. However, I'd expect the inflation rate to be low (if positive at all), and getting lower.

Once all ~21 million bitcoins are mined, no more will ever exist, so inflation will cease entirely, and only deflation can occur (again, as bitcoins are lost or intentionally destroyed). There are currently ~12.7 million bitcoins in existence, so at most, inflation will make 1 bitcoin today worth ~1.65 bitcoins in the future.


How do I get my Ravencoin wallet address on Ravencore?

Click on receive on the left vertical bar. Below the input boxes you will see "Request Payment." There you will be able to see your address.


The ECDSA digital signature scheme returns two values. To be specific, the X and Y values computed on the elliptic curve are returned.

In Bitcoin the signture is DER encoded, which is represented as a string containing the X and Y values and also some header data. But both X and Y can easily be extracted from it when reading the string from left to right.

In fact the Bitcoin protocol uses more information than only those concerning the X and Y values. For example, the size of the DER encoded signature is specified, but also a so called signature type is used to define which part of the transaction the signature was computed for.

Take a look here under the section "Signing the transaction" to see exactly how it works. In the table you will see how a computed signature is used in a scriptSig.

The details regarding the DER encoding was discussed here.


Code prevention of sending bitcoin to an address on the wrong chain btc/bch/bsv

There are three partial remedies:

bech32 addresses are invalid on BCH and BSV
CashAddr is an alternative encoding (inspired by bech32) for p2pkh and p2sh addresses that is only valid on BCH and BSV
You can check whether the recipient address is subject to address reuse: if it was previously used on another network, you should request confirmation or another address from the recipient

Unfortunately, BSV and BCH share all address formats, so you cannot distinguish which network an address was generated for between the two.

Likewise, the original p2pkh and p2sh addresses are valid on all three networks and there is no way to distinguish which network an address was intended for just from the address itself.


blockchain webgame - use api or actual blockchain to build database?

Use a third-party API if the correctness or accuracy of the data is not important. When the financial data needs to be accurate, using a third-party API is slightly more dangerous because as an intermediary they can return whatever (possibly tainted) data to your service... selectively.

Naturally, weigh this against the costs of maintaining an active bitcoind node such as upgrades, sysadmin maintenance, security, etc. There may also be an option regarding simple payment verification if you do not require the entire blockchain.


Metrics Correlated to "Health" of Bitcoin Node and Network

Due to the way the system operates it's actually a fairly difficult job deriving metrics of health.

Measuring the time since last block is very tricky as a measure of health or connectivity to the network. Block times follow a poisson distribution, you might only see two blocks in a 3 hour period and that would be completely acceptable behavior (though slightly unlikely) and not at all indicative of a problem.

In the other direction the July 2015 incident had over 50% of the global hashrate ended up mining an invalid chain for over an hour. Normally this might eventually indicate that you had been left behind on an invalid chain and action might need to be taken, where in this situation seeing a low hashrate meant that you were on the valid side of things.
Comparing your block height to other websites is pretty unreliable as well, if block explorer websites were an authority on which blocks were value then during the July 2015 event the network would have broken completely. During this event many followed the completely invalid chain and displayed this information for hours or days before being patched. Block explorer services are frequently incorrect, out of date, or simply unavailable for for phone a friend assurance of the correct chain.
The number of nodes is tangentially related to the health of the network, this measure has high latency and is extremely easily fooled by even the most basic of attackers. If you use this as a measure of health it could be pushed way up into the stratosphere by a bored criminal with a botnet, and it would be extremely hard to detect an attack like this happening over large time span. If anything the outlook right now based on this measure would be "extremely poor", with under 5500 nodes exposing listening ports on the public internet.

Statistical projects like Statoshi attempt to quantify node performance and other metrics, though many require deep knowledge of the software to make any sense of and don't give much measure of the network as a whole. Simpler projects like Shorenas network monitor give more general statistics about operation, bandwidth, and connections to the network. The aforementioned Bitnodes project has a limited reach (not all networks are crawled, the data has been inaccurate at times), but gives a general idea of the number of listening sockets available to the wider internet.

It's a lot harder of a task than one might imagine setting out, and no real clear answer.


No. They can increase scale, but that is not what they are good at or intended for.

Before giving a longer answer, let me first talk briefly about the difference between scale and scalability.

Increasing scale means increasing the throughput or number of participants to the system. It's very easy to achieve (decreasing the time between blocks, or increasing the size of blocks), but it would come at a cost of higher centralization pressure for mining and increased validation cost to the system. Whether these increased costs are acceptable is controversial, but there are certainly costs involved.

Increasing scalability means changing the system in a way such that increased scale comes with less increased costs. Known mechanisms for better scalability include better peer to peer relay protocols, faster digital signature systems, software improvements, technology on top such as payment channels or lightning to reduce on-chain transaction need, ...

Sidechains don't improve scalability. If we want the same security level with sidechains, the same amount of people and miners need to be validating them. That is at least as costly as just increasing the block size of Bitcoin itself, and sidechains come with extra compromises on top of that.

So, sidechains may increase scale, but are not better at it than larger blocks would be.

What sidechains do bring is the ability to experiment. To be able to build networks that run on different - and possibly better-scaling - technology, but without needing to first beat bitcoin's (the currency's) network effect.

Sidechains are intended to improve scalability, but only indirectly: by enabling innovation. Not because they can just offload things from Bitcoin.


Theoretical minimum # of logic operations to perform double iterated SHA256?

SHA256D, which is what Bitcoin uses, is 128 rounds, comprising
768 additions,
640 ORs
896 XORs
And a bunch of bit shifts but bit shifts are free on an ASIC.

(source)


How to generate Bitcoin private - public keys with ECDSA module?

Yes:

import ecdsa
print(ecdsa.SigningKey.generate(curve=ecdsa.SECP256k1).to_string())


Is the idea of a "honey hole" such as in gold mining, present in bitcoin mining?

No, the SHA2 hashing function is not vulnerable to any known attack that significantly reduces the difficulty of finding a block, but it is a highly random process.

Randomness is funny sometimes. Statistically it it works out to be even over a longer time period or larger population, but if you focus in on a small set of samples sometimes you see a cluster or a gap. This is why the estimated hash rate of the network on blockchain.info is woefully inaccurate on anything less than a multi-day average, and bitcoin is based on a 2 week correction period instead of a smaller number.

(which is why the unlucky miner can't expect to find 2 blocks quickly "because" he had a drought, and you should not expect a gap to "make up for" earlier luck, it's the  population that matters.)


What escrow system does the official Bitcoin bounty progam use?

Multisignature transactions can act as escrow.

A transaction could require a party and a trusted third party to complete, or it could be the trusted third party alone who signs to complete the transaction.


Is there any way to receive Bitcoin Testnet payments?

please do not use blockchain.info if you're gonna test payments.

use block.io instead, it has a full documentation for devs to try it.

you can use Testnet BTCs HERE


Installing Bitcoin Core On Raspbian with apt-get

PPAs are generally specific to ubuntu and usually can't be used with other Debian derivatives like Raspbian. Raspbian specific packages are not available in the bitcoin PPA.

Furthermore, the bitcoin/bitcoin PPA is discontinued and no longer being updated. If you still want to use a PPA to install onto Ubuntu and Ubuntu derived OSes, you can use luke-jr's PPA: https://launchpad.net/~luke-jr/+archive/ubuntu/bitcoincore


What happens when a fork/network split occurs on the Stellar network?

Assuming people chose adequate quorum slices and the system has quorum intersection (which is how the system is intended to be used), then with Stellar's new consensus protocol, at least one of the two partitions would be unable to settle transactions for the duration of the network outage.

Stellar does allow for redundancy, in that validators can have multiple slices.  For example, a slice might consist of any 5 out of 7 validators spread across countries.  In that case, if the partitioned country has only 1 or 2 validators, the rest of the world can continue to make progress.

This kind of scenario is actually unavoidable.  You have to chose at most two out of Consistency, Availability, and Partition tolerance.  This is sometimes known as "Brewer's theorem" because Eric Brewer conjectured it and Seth Gilbert and Nancy Lynch subsequently proved it.  See: http://www.cs.luc.edu/~pld/353/gilbert_lynch_brewer_proof.pdf


Can you help me tell if my new out-of-the-box ssd for a Pi4 myNode project is DOA?

You could try attaching the SSD to a different computer and run diagnostics on it. If the SSD gave out, upgrading the software would be unlikely to help.


Converting satoshis to bitcoins issue using PHP

You really should not use floating point math for precision decimal values.  It is a little-regarded truth of computer programming that when you're dealing with money you should avoid the usual IEEE floating-point math like the plague.

This is the reason why Bitcoin transactions store values as 64-bit integers.  Because storing them as floating point numbers is error-prone.

For example, in your interactive PHP shell you can do something like this to find out where your math begins to break:

php > echo 10000.00000001 * 2;
20000.00000002
php > echo 100000.00000001 * 2;
200000.00000002
php > echo 1000000.00000001 * 2;
2000000

I'm running 64-bit PHP, too.  If you are running 32-bit PHP the situation becomes pretty dire.

The take-away here is that overall precision of floating point numbers is limited.  The bigger your number, the fewer meaningful decimal places it can have.

The correct way to address this problem is to use PHP's BC Math functions.  You keep your data as strings, and BCMath will let you perform arbitrary-precision computations.  It isn't as fast as floating point math, but it isn't exactly slow either.

/** Convert Satoshis to a string that can be displayed to users.
 *  input: $value Integer or string that can be parsed as an int.
 *  output: string (eg: "1.00400000")
 */
function convertToBTCFromSatoshi($value){
    return bcdiv( intval($value), 100000000, 8 );
}

If you want to trim the zeros from the end of the output, you can use the trim() function:

rtrim($value, "0"); // trim zeros from the right-hand side


New to BTC world

Be very very careful about who you trust. Do your own independent research. Reading old questions on this website is a good start.

  what can I do with newly generated coins

People often ask this sort of question after downloading a mining game to their phone and "mining Bitcoin" on their phone. Unfortunately those are not real.

If you have real Bitcoin you already have a wallet, your wallet will show how many bitcoin you control.

Beware of watch-only addresses that let you see bitcoin amounts that you do not own and have no control over.

Beware of "testnet" bitcoins that are worthless.

Newly mined bitcoins are generally associated with a bitcoin-address that is controlled by the miner or mining pool. That address was derived from private keys which will be held in a wallet.

Mining bitcoin isn't something you can do casually.


So how would someone steal coins from my site?

You should assume your site is going to be hacked, and design with that in mind.

Blaming things on "poor coding" is a get out. There will always be bugs. You must be sure your procedures, your protocols, are faultless despite these bugs.

The majority of bitcoins should be in offline storage, and your hot wallet should be on its own dedicated server, with access through some kind of very limited API that does sanity checks and rate limiting on everything. (Access could be through a custom and very carefully written daemon i.e. not just some Apache HTTP API with associated vulnerabilities!)

Ideally, the user owns an encryption key that is used to somehow client side sign transactions (or any other action they take) which are applied to their account or the hot wallet.

Even then, a hacker could presumably hijack the serving of your pages, modify the crypto etc to steal their key. But at least if the user's key was only generated once and is only used by them occasionally, the chance for massive theft is reduced. Two factor auth may help too.

You could have daemons on other hidden servers that regularly check your site and its resources for tampering, suspending everything if necessary. Perhaps release a browser add-on which verifies your site. Your entire site could be signed, and the add-on could request a new signature to verify any changes. (And you perform this signing offline). As long as the user's browser or the add-on publishing system doesn't get compromised, you'll be alright ;)

To summarise all that:

client side encryption/authorisation of any action a user can take
this simply tunnels through the terribly insecure WWW/apache etc layer to a very limited access highly secure "hot wallet" server
some way of verifying that client side encryption is not compromised, e.g. watchdogs running on IPs unknown to attackers
(and lots of other watchdogs all over the place which halt service at the slightest cause for concern)

You'll do all this and then your hosting provider will be compromised by social engineering.

At the end of the day, all said and done, your most effective protection will be the offline cold wallet with manual (and slow and annoying) transfers of customer's funds, and regular audits to check all funds are actually there (mtgox lol).

btw, this is written by somebody with no background in security, imagine what somebody who did have such a background might write ;)

Final point: If you are thinking of running a wallet service, don't. Just don't. Give up now. It's going to end in tears, and death threats.


Why does Bitcoin use the input/output system?

Outputs neatly solve a few problems you would encounter with a balance based system.

Transactions using outputs can not be replayed cross network, multiple times, or in different situations than when they were created. In an address based system you must keep a nonce or a record of all past transactions to ensure multiple executions of one transaction does not occur. You don't have the option of re-signing a transaction with a higher miners fee, because the transactions are not atomic and can both exist in the chain at once.

Transactions using outputs can be deployed even years after they have been signed, which is incompatible with an incremented nonce.
An output based system can forget about an output once it is spent, a nonce based system must keep track of all nonces forever.

Verifying that an output exists in a block is trivial by displaying the merkle path to it, and showing the block header is part of the main chain. In an address based system this is substantially harder to prove, if not impossible given the same constraints.


Sent Bitcoin to Bitcoin Core Wallet before it finished "syncing with network"

Yes everything will be normal, the bitcoin will reach your wallet once it downloaded the block your transactions was included in :).
Just wait patiently .


BitCoin Price Index -Studies on Relation to Network Hashrate and Block Difficulty?

I know of one researcher off hand who has worked in this area, Adam Hayes. You can find his papers on the subject at:

http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2648366
http://www.economicpolicyresearch.org/econ/2015/NSSR_WP_052015.pdf

You could also look around on http://arxiv.org/. Just searching for 'bitcoin price', I found:

http://arxiv.org/pdf/1406.0268.pdf
http://arxiv.org/pdf/1405.4498.pdf


Can I specify one of my existing "receive" address as a "change" address when I create a transaction when using the Bitcoin Armory client?

Yes you can, but you have to switch to "Expert" usermode from the main window.  After you do, the "Send Bitcoins" window will have an option for customizing the change address.  You can click on the addressbook and select any address in any wallet.  Or really put in any address you want.

Just remember that you are compromising your privacy by reusing addresses.  Even when you don't reuse addresses, there's a surprisingly amount of linkage between your addresses already, just by the way they are combined for some transactions.  By reusing change addresses, you are dramatically amplifying that effect.  That why this feature is hidden under the "Expert Mode."

For instance, if you always shuffle your coins between 10 addresses, then there is no question that all 10 addresses will eventually be linked, and undeniably part of the same wallet.  Thus, every person you ever transact with, will have the capability to see your entire wallet balance at any time, as well as every transaction you ever execute.


How do SPV get their transactions after being offline?

Block fetching requests are also filtered, so the client requests every single block they missed out on seeing since the last time they were last online, sequentially. The client downloads all block headers from genesis up to the current head using getheaders, sets a filter on their peer with filterload, and then downloads filtered blocks with getdata until they are in sync with the network. filteradd may be used in deterministic wallets to extend the filter to include more keys as used ones are discovered in their scan. When they are in sync, they will only receive new inventory that matches the filter.


bitcoin exchange for other virtual (centralized) currencies

https://www.virwox.com/ is an exchange for virtual currencies, trading among other things Linden dollars.


Currencies get value from demand and supply not from governments backing them. Currencies have existed long before government's started stamping them out in their own name. The demand for a currency comes from the utility that it offers as a medium of exchange. Even pre-historic humans went out of their way to create currencies because they were useful.

Bitcoin has value because it is useful as a global, irreversible electronic medium of exchange and store of value. That is why it is in demand.


I spilled a little bit of candle wax on my Bitcoin private key and now it won't scan electronically what can I do?

You can make a manual copy of the QR code. Get out a sheet of graph paper, a #2 pencil, and start copying the grid from the QR code. Count the number of rows, and make sure your graph paper is large enough. Each square in the QR code should be either entirely filled in or entirely blank. As long as each square in the QR code is legible to you, you can make a clean version.

You don't need to get every square correct - QR codes have an error correction code.


Is there a list of coins that are bip-32 compatible?

Bip-32 allows me to dereive keys based off a root key pair, and all these keys will be on the secp256k1 curve.

This is actually not true. The BIP32 proposal simply states that (emphasis mine):

  In the rest of this text we will assume the public key cryptography used in Bitcoin, namely elliptic curve cryptography using the field and curve parameters defined by secp256k1

In reality, it can be used for any curve, as evidenced by the fact that both Monero and Zcash support BIP32 backed derivations, but use different curves.

If you wish to see a list of coins that follow the BIP32/39/44 system, you can check the coin type list maintained by Satoshi Labs at SLIP-0044


How is Bitcoin supposed to serve as currency when it is all but impossible to spend at the moment (12/2017)?

You were probably trying to pay on the blockchain itself. That's like trying to pay for lunch by moving dollars through the Federal Reserve. You should use some system designed to move small quantities of bitcoins cheaply such as Coinbase.

We don't yet have good decentralized payment systems for bitcoin, so currently bitcoin is primarily being used as a store of value. Think of bitcoin as more like gold than dollars. The Lightning Network is one proposal to provide a way to move small amounts of bitcoin at high speed with low cost.


Should signature verification by key recovery ignore compression status?

Mileage may vary with this answer. The short answer is probably no when using libbitcoin.

Rationale: Over a year ago, when I experimented with sending funds to a uncompressed address using a signed transaction, the corresponding compressed keys could not be used to spend the same funds, the opposite was also true. The balance was dependent upon the compression of a key. When receiving with funds with an uncompressed address, only use the associated uncompressed private key to spend.  Similarly, when receiving receiving with funds with a compressed address, only use the associated compressed private key to spend.


Import private key on multiple computers

Incoming payments will show up in both wallets.

If you spend any of the balance, the other wallet may show a 0 balance because the "change" will only go to the wallet you sent from. The other wallet won't know about the new "change" address.

The safest thing to do is to transfer all the funds to a new address.


How can I protect my funds in the event a quantum computer breaks the ECDLP that Bitcoin relies on?

We're deep in speculative territory here but, theoretically, if the elliptic curve algorithm were broken the entire Bitcoin system would immediately collapse.

Let's consider the case where you've successfully guarded your own funds somehow. How many public keys would still be out there vulnerable to such an attack?

Even though your "base" survived the attack, every other user out there who had UTXO on reused addresses would've been nuked and Bitcoin would have collapsed. You'd be the exceptional survivor. It'd be all over the news, dollar value would've gone to near zero, miners would stop and cut losses and so on.

So, in my view, there is no way to protect yourself individually against the eventual breakage of the elliptic curve discrete logarithm problem. Even if 90% of Bitcoin users had unspent UTXO's in safe unused addresses, the 10% that were hacked would cause immense damage to Bitcoin in a social sense.

Since Bitcoin obeys Metcalfe's law, network value being number of users squared, if enough users dropped out of the ecosystem, due to this kind of development in cryptanalysis, it'd surely deal a major blow to the community.

Not to mention another possibility: such a quantum computer could try brute forcing astronomic quantities of random numbers into private keys all day. Eventually they'd stumble on valuable wallets which could cause the community upheaval of "having broken Bitcoin" and its consequences. So having a known public key wouldn't necessarily be the only attack vector. I'm sure there are other possible attacks using quantum computing, perhaps unknown unknowns that would add immense risk to the system.

Math is the Bitcoin guardian, if it's somehow found to be vulnerable no man would be left standing in my opinion.


During Bitcoin Script execution, what is the significance of the signature verification in the stack?

How does this work

Bitcoin uses the Elliptic Curve Digital Signature Algorithm. The algorithm is described on Wikipedia (linked). Bitcoin specifically uses the secp256k1 elliptic curve.

  what is the significance of verifying two entities which belong to the same user?

There are not two entities.

The signature proves that the owner of the private key which corresponds to the public key created the signature over a given message. In the case of Bitcoin, the message is the hash of the transaction (excluding the signatures themselves because they don't exist yet). This ensures that the person spending the output is allowed to do so and ensures the integrity of the spending transaction itself.


Testnet for bitcoin - are there multiple operating?

There is no such thing as a private testnet, you can obviously create one, but then it won't be of much use to provide data regarding a private blockchain to the public.
The testing network (testnet3 presently) is the same for every user/developer.
BitEasy's block explorer for the testnet doesn't seem to be working. They don't have data even for dates a month prior to the date you asked this question.
As far as exploring the blockchain the data is concerned, you can do it yourself by accessing the block-chain on your machine after running the testnet bitcoind. The approach may be vary, but then the point being you can do it yourself if you know basic programming.


How can I simulate ProofOfStake (PoS) for a testnet (clone of Pivx)?

Ok. For some reason, I got this working when I tried it for the second time. This time, I set the Last PoW block number to 350. I mined first 5 blocks using the server. Then, I setup 4 different wallets in 4 different systems. I sent enough coins to all those 4 different wallets and make it available for staking. All these I did by the first 20 blocks. Then, I started to mine again using the server. Once the block number reached 350, I stopped mining on the server and suddenly, PoS took over and started producing blocks one by one using those 4 wallets. From this experience, I feel that just having 1 server and 2 clients are not enough to simulate PoS. We may need many more wallets connected to the network to get this working. Hope this helps some one.


How do devs decide who should have commit access? what is the process?

Many others have received/lost commit access. How exactly is this decision made? and by who?

Nowadays the decision is generally made by the developers during one of the weekly IRC meetings. This is not done by committee nor a specific group, just whoever is attending the meeting when the topic is brought up. It's usually the same people at every meeting.
Typically how adding a maintainer works is that someone brings up a topic for adding a maintainer, others nominate a person to be that, and then the group votes. Since in the past there have really only been one person nominated at a time, it's been a yes/no vote rather than a vote for a candidate. The process is largely informal as the people nominated are typically well known developers and have been around for a while.
For revoking access, the process works pretty much in reverse. Someone brings up a topic to remove access for particular users, typically because they are inactive, and the group votes on whether to do so. There have been a few exceptions to this - Gavin Andresen's commit access was revoked after concerns that his accounts had been compromised. Since he was also inactive, it was decided to leave his commit access revoked.
Developers may also choose to no longer have commit access in which case their commit access is revoked upon asking.

If the Lead Maintainer unexpectedly died (hope not), but if he did, who would decide upon the next Lead Maintainer and how?

It would pretty much be the same process as adding a new maintainer. This is also likely the same process if the lead maintainer decided to step down. Someone would volunteer or be nominated, likely one of the current maintainers, and then that person is voted on by the group at a meeting.

In general, there is a formal process for adding or removing commit access. It's generally done by the group of developers attending an IRC meeting with those developers essentially voting yes/no.


I got an error that says curl: (7) Failed to connect to localhost port 18332: Connection refused

bitcoind doesn't restart after your computer restarts. Start bitcoind after you start your computer.


Will fees be charged when importing a key to my wallet?

Since the "transaction" is not going through the bitcoin network, I can't see how a fee could be charged.


Getting a prepaid card on BitGold is pretty easy, you just have to sign up for an account, make sure you have you deposit 1 GAU (gram of gold) on it and request one by providing an id document and a proof of address.

You can use wherever they accept a MasterCard, pretty much everywhere. I personally tried it in Canada and Italy, and it worked flawlessly.

Please note that, even if you can get GAUs by depositing your BTCs, you cannot currently load them directly on the card, since you can really deposit only on the Dubai Vault, and you cannot load the card with the gold in Dubai.

This is intended, and you can ask to the customer support for more information on why is that so.

As a reference, you can check the FAQ on the website.

And this article on how to apply for a prepaid card.

Enjoy your BitGold account :)


How does the bitcoin network disallow people generating a key pair already generated?

Yes, it is possible to create an already generated and in use address. The chances of that is indeed larger then 0, but minimalistic. But really small. And if I say really small, I mean extremely small. And if I say extremely small, I mean very extremely ultra low super duper close to zero. It is definitely NOT something to be considered as a weakness, never ever (because it will cost more energy before you have 50% to hit a duplicate address then the whole sun provides in its whole life time then). source


Problems about update of protocol of bitcoin

The general approach to Bitcoin protocol updates is to maintain forward and backward compatibility with the prior consensus rule set on the network.
In fact, Bitcoin's protocol stability is considered one of its most important properties, as it ensures that people can confidently store value and rest assured that their funds will remain accessible in the future. Changes to the system that would pull the rug under prior investors would meet extreme resistance.
Obviously, every user has to decide for themselves whether the perceived social contract is stable enough to inspire confidence.


Where is the part in code related to the installation on Linux/Mac and windows?

The GUI is based on QT, the code for the GUI is in the folder src/qt.


The purpose of signatures is to 'capture' some data about the transaction - it's outputs, and so on. Signers have control over some of it, using SIGHASH flags, but some of it is enforced by the network.

Remember that anyone verifying your signatures needs to know what you're asserting in your signature, and how to reproduce the same hash for ECDSA.

When producing the signature, and verifying one, SignatureHash() is called on every input, because each input has it's own signatures.

For each input, the transaction reserialized with a CTransactionSignatureSerializer which makes the input-specific modifications to the transaction. It will null inputs/outputs given some SIGHASH flags, and also requires that the scriptPubKey of the previous transaction is included.

It seems you were enquiring partly about this. The reason for capturing this through a hash is it means the signature can't be used on other transactions. A signature is only valid for a given input, and all the requirements of its scriptPubKey.

Hence, you will find that services which verify signatures need to have the scriptPubKey of the transaction being signed for.

Edit: Actually, more specifically, what is included as the script while signing is any script starting from the last OP_CODESEPARATOR, or from the beginning of the output script. So if the script contains OP_CODESEPARATOR, only a part of the output script is signed.

One point where you appear confused is this:

  Then we clear the SigScript and put the public key and signature into the SigScript and have a signed transaction

This is not correct - the serialized form is forgotten once the hash is produced. Signatures are put into different transaction instance.

checker.CheckSig() code - Note that it calls the SignatureHash() to produce the hash, and then VerifySignature() calls pubkey.Verify(sighash, vchSig) which is the actual call to ECDSA.

So, most of what you're looking for verification-wise is at the bottom of interpreter.cpp, but also check out interpreter.h for the interfaces.


What happens if my transaction is not accepted because I did not pay fees?

If your transaction does not get accepted, you have a few options. Right now, at least for Bitcoin itself, there are still enough miners willing to include any valid transaction. So if you just keep waiting, it should eventually get confirmed.

You may also wish to stop your client and then restart it, manually forcing it to connect to a client known to accept transactions without fees. It can help to disable incoming connections to maximize the chances your transaction will go to the client that will accept transactions without fees. It can take several hours for the transaction to get out, even if you do everything right. (The client intentionally 'dribbles' out transactions to try to hide their origin. This completely fails for transactions with too-low fees, but the client still tries.)

Otherwise, you can abort the transaction attempt. Stop your client and then make sure the transaction is not in limbo by checking the list of pending transactions. If it's not there, you can stop attempting the transaction to recover the coins. Ideally, you made a backup of your wallet before you attempted to make the transaction -- reverting the wallet and restarting the Bitcoin client with the -rescan option will remove the transaction. Otherwise, you'll have to (ouch) edit your wallet file to remove the transaction.


Transactions that have outputs value more then inputs value possible?

That isn't allowed, even within a block. Here is the code that checks for that:

main.cpp: ConnectBlock

    if (!CheckInputs(tx, state, view, fScriptChecks, flags, false, nScriptCheckThreads ? &vChecks : NULL))
        return error("ConnectBlock(): CheckInputs on %s failed with %s",
            tx.GetHash().ToString(), FormatStateMessage(state));

main.cpp: CheckInputs

if (!Consensus::CheckTxInputs(tx, state, inputs, GetSpendHeight(inputs)))
    return false;

main.cpp: CheckTxInputs

for (unsigned int i = 0; i < tx.vin.size(); i++)
{
    const COutPoint &prevout = tx.vin[i].prevout;
    const CCoins *coins = inputs.AccessCoins(prevout.hash);
    // [11 lines snipped]
    nValueIn += coins->vout[prevout.n].nValue;
    // [3 lines snipped]
}

if (nValueIn < tx.GetValueOut())
    return state.DoS(100, false, REJECT_INVALID, "bad-txns-in-belowout", false,
        strprintf("value in (%s) < value out (%s)", FormatMoney(nValueIn), FormatMoney(tx.GetValueOut())));


Bitcoin CreateMultiSig in PHP always returning FALSE

I lost my guest session but I figured out the problem.

jsonRPCClient was not providing me any useful information as an output so serching Stack Exchange I was able to find somebody who changed the JSON library to output a useful error code.

    Add *'ignore_errors' => true* to the $opts array
    Change the error line that throws Request error to read throw new Exception('Request error: '.$response['error']['code'].' - '.$response['error']['message']);.

Then the output said that I was inputting a string and I should be inputting an array. So all I had to do, was put all the public keys into an array and plug it into the createmultisig function.

$pubkey_str = array();

$pubkey_str[] = "02e280809f7a7e0fabb7404d68ef89b66e9cf63ecfffd37ef2c78d06c51d2247f6";

$pubkey_str[] = "02f22be70ae35432c82e7b05846eeab1fec5b09ebe523bb98d6d6bbf1ff29d96c3";

$create_multisig = $bitcoin->createmultisig (2,$pubkey_str);
var_dump($create_multisig);

and this was the output

array(2) { ["address"]=> string(35) "2MtXTzX7pASPKr8VKmkyWKRNFt2o1oFxi9K" ["redeemScript"]=> string(142) "522102e280809f7a7e0fabb7404d68ef89b66e9cf63ecfffd37ef2c78d06c51d2247f62102f22be70ae35432c82e7b05846eeab1fec5b09ebe523bb98d6d6bbf1ff29d96c352ae"

Which is exactly what I expected. So maybe it was a stupid mistake on my behalf, but hopefully other people can benefit from it.


Strange values in Bitcon Electrum wallet file (change and receiving)

The fields you are seeing are raw ECDSA public keys.


How to work out my hardware's hashrate power

How do I work out the SHA-256 and scrypt hashrate

You can look up your hardware e.g. here (BTC) and here (LTC). But I think it's much easier and more accurate to just try mining different coins for couple hours and measure hashrate directly.

  For the Power(W) box, do I enter in my computers PSU wattage? I think it's 650w

PSU wattage is max. power it can supply, so it poses upper bound on PCs consumption.
To get accurate measurements, you can use something like Kill-a-Watt. Or you can look up TDP of individual components: CPU's, GPU's and ASIS's power consumption is usually listed in their specs, and motherboard+RAM+HDD together usually use around 50W.

  For the Power Cost ($/kWh) box, do I check my electricity bill to find out how much I am paying per kWh?

Yes.


What bitcoin exchanges are based in the USA?

I might have missed a few, but here are the main ones based in the USA:

Coinbase (not really an exchange)
GDAX (part of Coinbase)
Poloniex
Gemini

Mind you that many other exchanges based out of other countries are just as likely to accept funding via ACH.


MimbleWimble isn't fully implemented, so this answer may change as implementations mature and we gain a greater understanding of the design space.

MimbleWimble transactions may be published to the network individually or combined with other transactions before being broadcast. For example, a user may choose to publish a new transaction on its own, or to mix the transaction in an off-chain mixer that will then publish it to the network.

However, it is my understanding that once transactions hit the network, nodes forward them as-is. This means that regardless of whether the particular MimbleWimble implementation allows it, an attacker can watch and record new transactions as they are broadcast. This would allow them to reconstruct a transaction graph, albeit one without addresses or amounts, just randomly distributed elliptic curve points.


How would this normal raw transaction appear if it was a raw segwit transaction?

wow, cool question, that's not very easy. Especially as there are different Segwit tx thinkable (native P2WPKH, P2SH-P2WPKH, Native P2WSH, P2SH-P2WSH or one with Bech32 address). Then there is the point of adapting all the length parameters (for signatures and scripts). I will give it a try with a standard P2WPKH. So first I'd decode your provided tx, I get this:

VERSION
 01000000

TX_IN COUNT [var_int]: hex=03, decimal=3
 TX_IN[0] OutPoint hash 9D62373BF1838B4E4F497836DB0D8EDEFFBCAD64B1474904BCDA8DC37937C0B0
 TX_IN[0] OutPoint index hex=01000000, reversed=00000001, decimal=1
 TX_IN[0] Script Length hex=6B, decimal=107
 TX_IN[0] Script Sig
  483045022100F3C0F555CD39198CAF77F6756256801FC57BCABE4892601B9DEF52259698F40A0220230262841BFF151
EB617F7D4CDDA6BF06D6FA791230C152E47F68BCDD0E6F64A01210204B3506D8903CA601C97A4ABAB6548E91004C535A5
A45E21299A494B146859CA
 TX_IN[0] Sequence (uint32_t) FFFFFFFF

 TX_IN[1] OutPoint hash B3CA9199969BD474BA0A609A1C01C3B6C2EB97885FC1DCAD2CD1704BE5EA0E06
 TX_IN[1] OutPoint index hex=00000000, reversed=00000000, decimal=0
 TX_IN[1] Script Length hex=6B, decimal=107
 TX_IN[1] Script Sig
  4830450221009DBEB64DDD4646E1118503C87FEAA95C531B5178C6E543BE782F6ECB05E8FBE602203945570F8DC56C145617F0283FA4032E0B7895A9CF2A81C7B65665B8AC608CB00121026602A5DC59C30F485B2C457AC8E2F617E27B10A1D2AE76F3231F9B01DFF08964
 TX_IN[1] Sequence FFFFFFFF

 TX_IN[2] OutPoint hash 3E90870CB2B89307514498D010EE1A1F724EE578859B8F118902DB08A45B717F
 TX_IN[2] OutPoint index hex=01000000, reversed=00000001, decimal=1
 TX_IN[2] Script Length hex=6B, decimal=107
 TX_IN[2] Script Sig
  48304502210095E300886EC4DF78E39D6D0CF5E5E531DED8F42F00E5730C371D8951867DAD5B02203C55F9403F6C2AAC444213161A93A86661E7367D4007BE74FFB3981387CC1C790121023F0AADFEB71A4964C5087FEC8B052C8236051DAE838D4747543330C6B266CE6E
 TX_IN[2] Sequence FFFFFFFF

TX_OUT COUNT, hex=02, decimal=2
 TX_OUT[0] Value hex=D578110000000000, dec=1145045, bitcoin=0.01145045
 TX_OUT[0] PK_Script Length hex=19, dec=25
 TX_OUT[0] pk_script 76A914342AB422C9E3EF285EFE9882AE54269ED9713DD688AC
 TX_OUT[1] Value hex=20A1070000000000, dec=500000, bitcoin=0.00500000
 TX_OUT[1] PK_Script Length hex=19, dec=25
 TX_OUT[1] pk_script 76A91488D924F51033B74A895863A5FB57FD545529DF7D88AC

 LOCK_TIME 00000000

Now I make a P2WPKH tx out of it. In general, the segwit  transaction is composed this way:

  [nVersion][marker][flag][txins][txouts][witness][nLockTime]

VERSION
 01000000

SEGWIT (BIP141): this is a segwit tx, marker=00
       (BIP141): flag=01

TX_IN COUNT [var_int]: hex=03, decimal=3
  TX_IN[0] 9D62373BF1838B4E4F497836DB0D8EDEFFBCAD64B1474904BCDA8DC37937C0B0
  TX_IN[0] hex=01000000, reversed=00000001, decimal=1
  TX_IN[0] Script Length hex=00, decimal=0
  TX_IN[0] Sequence (uint32_t) FFFFFFFF

  TX_IN[1] B3CA9199969BD474BA0A609A1C01C3B6C2EB97885FC1DCAD2CD1704BE5EA0E06
  TX_IN[1] hex=00000000, reversed=00000000, decimal=0
  TX_IN[1] Script Length hex=00, decimal=0
  TX_IN[1] Sequence (uint32_t) FFFFFFFF

  TX_IN[2] 3E90870CB2B89307514498D010EE1A1F724EE578859B8F118902DB08A45B717F
  TX_IN[2] hex=01000000, reversed=00000001, decimal=1
  TX_IN[2] Script Length hex=00, decimal=0
  TX_IN[2] Sequence (uint32_t) FFFFFFFF

TX_OUT COUNT, hex=02, decimal=2
  TX_OUT[0] Value hex=D578110000000000, dec=1145045, bitcoin=0.01145045
  TX_OUT[0] PK_Script Length hex=19, dec=25
  TX_OUT[0] pk_script 76A914342AB422C9E3EF285EFE9882AE54269ED9713DD688AC
 TX_OUT[1]
  TX_OUT[1] Value hex=20A1070000000000, dec=500000, bitcoin=0.00500000
  TX_OUT[1] PK_Script Length hex=19, dec=25
  TX_OUT[1] pk_script 76A91488D924F51033B74A895863A5FB57FD545529DF7D88AC

WITNESS TXIN[0] stack elements: hex=02, decimal=2
 WITNESS[0] data length (var_int), hex=48, decimal=72, data(uchar[]):
  3045022100F3C0F555CD39198CAF77F6756256801FC57BCABE4892601B9DEF52259698F4
  0A0220230262841BFF151EB617F7D4CDDA6BF06D6FA791230C152E47F68BCDD0E6F64A01
 WITNESS[1] data length (var_int), hex=21, decimal=33, data(uchar[]):
  0204B3506D8903CA601C97A4ABAB6548E91004C535A5A45E21299A494B146859CA

WITNESS TXIN[1] stack elements: hex=02, decimal=2
 WITNESS[0] data length (var_int), hex=48, decimal=72, data(uchar[]):
  30450221009DBEB64DDD4646E1118503C87FEAA95C531B5178C6E543BE782F6ECB05E8FB
  E602203945570F8DC56C145617F0283FA4032E0B7895A9CF2A81C7B65665B8AC608CB001
 WITNESS[1] data length (var_int), hex=21, decimal=33, data(uchar[]):
  026602A5DC59C30F485B2C457AC8E2F617E27B10A1D2AE76F3231F9B01DFF08964

WITNESS TXIN[2] stack elements: hex=02, decimal=2
 WITNESS[0] data length (var_int), hex=48, decimal=72, data(uchar[]):
  304502210095E300886EC4DF78E39D6D0CF5E5E531DED8F42F00E5730C371D8951867DAD
  5B02203C55F9403F6C2AAC444213161A93A86661E7367D4007BE74FFB3981387CC1C7901
 WITNESS[1] data length (var_int), hex=21, decimal=33, data(uchar[]):
  023F0AADFEB71A4964C5087FEC8B052C8236051DAE838D4747543330C6B266CE6E

 LOCK_TIME
00000000

So I assume the segwit pattern can clearly be recognized, see that the signature length is given as "0", and at the end appears per input the witness data. More to it can be found in the corresponding BIPs, and of course in the wiki.

and the serialized hex would be this:

  01000000000103b0c03779c38ddabc044947b164adbcffde8e0ddb3678494f4e8b83f13b37629d0100000000ffffffff060eeae54b70d12caddcc15f8897ebc2b6c3011c9a600aba74d49b969991cab30000000000ffffffff7f715ba408db0289118f9b8578e54e721f1aee10d09844510793b8b20c87903e0100000000ffffffff02d5781100000000001976a914342ab422c9e3ef285efe9882ae54269ed9713dd688ac20a10700000000001976a91488d924f51033b74a895863a5fb57fd545529df7d88ac02483045022100f3c0f555cd39198caf77f6756256801fc57bcabe4892601b9def52259698f40a0220230262841bff151eb617f7d4cdda6bf06d6fa791230c152e47f68bcdd0e6f64a01210204b3506d8903ca601c97a4abab6548e91004c535a5a45e21299a494b146859ca024830450221009dbeb64ddd4646e1118503c87feaa95c531b5178c6e543be782f6ecb05e8fbe602203945570f8dc56c145617f0283fa4032e0b7895a9cf2a81c7b65665b8ac608cb00121026602a5dc59c30f485b2c457ac8e2f617e27b10a1d2ae76f3231f9b01dff089640248304502210095e300886ec4df78e39d6d0cf5e5e531ded8f42f00e5730c371d8951867dad5b02203c55f9403f6c2aac444213161a93a86661e7367d4007be74ffb3981387cc1c790121023f0aadfeb71a4964c5087fec8b052c8236051dae838d4747543330c6b266ce6e00000000


is it possible to decode block height from a blockhash?

No.  The whole point of a hash is that it's a one way function.  You can't "decode" any of the header data from the block hash.

Moreover, the block height isn't even contained in the block header.  You're supposed to calculate the block height by looking at the previous block hash in the header, which hopefully refers to a block whose height you already know; if not, get that block and recurse.  (For sufficiently recent blocks, the block height is contained in the scripts of the coinbase transaction, but that's not part of the header.)


Is it safe to keep ONLY a time-locked tx?

It should be, since all changes to the Bitcoin protocol should be agreed on by the entire community. However, there is no way to guarantee a softfork can't be abused, or even necessarily invalidate such a transaction, and there has recently been hardfork efforts by incompetent people to promote breaking compatibility, so I would advise against relying on it at this time.


Electrum 2.0: non-BIP39/32 standardisation complicates matters immensely. Why?

Thomas Voegtlin , the developer of Electrum explains the reasoning in the first 10 minutes of this interview. I think he also posted same thing to Bitcoin dev mailing list some time ago.

https://letstalkbitcoin.com/blog/post/epicenter-bitcoin-69-thomas-voegtlin-electrum-spv-wallets-and-bitcoin-aliases

His main point against BIP39 is that it doesn't include a version number, and the requirement of the word list dictionary in order to implement it.


How to set a payment in Ripple without specifying currency issuers?

Ripple won't search for paths while processing transactions. The paths must be found first, using pathfinding, and specified in the transaction. You're getting a path dry error because you're not specifying any paths, so the only path you're getting is the default path.

A simple solution is to change the issuer of the SendMax amount to be the gateway. This will implicitly insert the gateway's account node before each path, including the default path. Alternatively, specify the gateway's account node as an explicit path or use pathfinding.


How is Bitcoin's Multi Signature different from NXT's account control feature for security?

NXT's account control is based on the phasing feature. It is very different than Bitcoin multisig.
When submitting an NXT phased transaction the user, in addition to the transaction information, attaches a voting model and a block height stating that in order for this transaction to be executed another approval transaction(s) matching the voting model needs to be submitted before the block height is reached. Phased transactions are always included in the blockchain but are only executed if the voting model is matched. You can read more about it in the change log https://bitbucket.org/JeanLucPicard/nxt/downloads/changelog-full.txt

Account Control enforces that all transactions from a certain account has to be phased given a specified voting model and a number of blocks specified by the account control transaction.
In a simplistic form, account control can be used somewhat like Bitcoin multisig, the account control transaction specifies a list of accounts which need to vote for each transaction submitted by the account under control. However voting models are much more flexible and allow many other voting options.


how to split transactions based on send and receive Json rpc bitcoin

Sounds like you are looking for the listtransactions API call in combination with the category field.

First argument is for a specific account, use * to return all accounts.
2nd is how many you want to return.
3rd is if you want to skip transaction from the start.
4th argument is if you want to include watch-only addresses.

$bitcoin->listtransactions("*", 100, 0, false);

Example output (note the category field):

{
"result": [
    {
        "account": "",
        "address": "32NFcoB96ANoPnqycLH9WUd94o7bwRyq66",
        "category": "receive",
        "amount": 0.00385000,
        "label": "",
        "vout": 1,
        "confirmations": 24827,
        "blockhash": "000000000000000000250cffa73c2a08e64e53dab398ede3f38b1c30ae5c66ca",
        "blockindex": 317,
        "blocktime": 1529098309,
        "txid": "07b1d3fbc4d78d480d510264bb01bd390e81cda34dcb01e882e94adfa9355d10",
        "walletconflicts": [

        ],
        "time": 1529098115,
        "timereceived": 1529098115,
        "bip125-replaceable": "no"
    }
],
"error": null,
"id": null
}


Is there a simple python script for xpub generation from private key

Yes, I'd say the simplest way is to use python bip39 implementation of trezor, this one file should be enough with methods:
to_seed - to convert list of the words into seed and
to_hd_master_key - to generate master xpub/xpriv
It doesn't support further derivations (which require a bit more dependencies), for which I'd suggest using bip32 library.


Why is the root seed of an HD wallet undergo an additional HMAC-SHA512 hash to generate the master private key and master chain code?

It is because the root seed may not be 512 bits, it could be 128 bits or 256 bits for example as seen in the picture you linked. Thus the final SHA-512 is applied to the seed so that no matter what the seed is, 512 bits will always be generated.

The seed generation described in BIP 39 is independent of the seed -> extended private key step in BIP 32. I expect BIP 32 uses HMAC-SHA-512 instead of just SHA-512 because it makes no assumptions about how the seed was generated, and wants to ensure that the extended private key is uniquely generated for BIP 32 use rather than just using any old SHA-512 hash that could have come from elsewhere.


How does blockchain.info calculate the "Estimated Transaction Value?"

For transactions with one input it is hard to guess what is the change and what is the real payment. However because they may be have statistics so they can may be guess that for a ~4 BTC input there are 70% of probability that the change is the bigger output and the money spent the smaller one when both output addresses are new.

Now if you have a transaction with several inputs (Like ou have already explained in your question) it is much more easier to guess.
If you have :

As input
1Pi87D6NUPB5BxcuowYN4Lj3WLCSFGsuLN (0.24379822 BTC)
1PgBMDggd7GGCifDd1881vdvNe8pkn5BWk (0.08787591 BTC)

And as output
1B6tvnE3oP3mwoA4RMrYXWVup4Z73G6bDw -  0.05377413 BTC
1DswmdznL6exZzN6akJpsPUc4ZWRZo9JQc - 0.2778 BTC

In this case you can be pretty sure that the spent address is '1DswmdznL6exZzN6akJpsPUc4ZWRZo9JQc - 0.2778 BTC' and the change '1B6tvnE3oP3mwoA4RMrYXWVup4Z73G6bDw -  0.05377413 BTC'.

Because otherwise there would be only one input.


Newbie question, bitcoind installation doubte

The problem with running a network facing daemon as root, is that if in the future there is an exploit found for that daemon then potentially an attacker could execute code on your machine as root. This gives the attacker unlimited accesses to your machine. To fix this you would need to create a user/group that your daemon can run as and also assign that user/group to the files your daemon needs to access. This prevents an attacker from having free reign over your computer should he exploit that daemon.

To create a user/group for your daemon called user bitcoin you can run the following:

$ sudo useradd -U -r -s /bin/false bitcoin

-U create a group named bitcoin
-r create a system account
-s /bin/false sets the login shell to /bin/false (this way no one can potentially login with this user and get a shell

Now lets say you have chosen to store all the bitcoind related files in the /var/lib/bitcoind directory.

$ sudo mkdir /var/lib/bitcoind
$ sudo chown -R bitcoin: /var/lib/bitcoind

This will set bitcoin user and bitcoin group as the owner of all files within that directory as well as the directory itself.

When you run the bitcoind daemon you need to tell it to run as user bitcoin and to use /var/lib/bitcoind as it's data directory. Make sure your files like your wallet or blockchain data are inside /var/lib/bitcoind. Your bitcoin.conf is expected to be stored at /etc/bitcoin/bitcoin.conf in the following system script.

Now you just need to install a script that will start your daemon for you with your intended user. To do this please read the instructions (chances are you are using systemd so follow those instructions): https://github.com/bitcoin/bitcoin/blob/master/doc/init.md

I hope this helps!


Everyone that ran a node has/had the ability to record lists of other Bitcoin nodes and their IP address with a "getaddr" request (assuming they allowed incoming connections). I am not aware of a centralized online database of these records dating back more than 1 year: https://bitnodes.21.co/dashboard/?days=365
Yes: https://bitnodes.21.co/nodes/
Some early adopters used real IP addresses and others (including Satoshi) obscured their IPs with Tor, VPNs, or other means.


Are incoming connections required for mining?

Incoming connections are not required for mining. You only need some connectivity with the rest of the network. It does not matter how that connectivity is established.

You would need to use the getblocktemplate based mining interface, with dedicated mining software, as Bitcoin Core no longer has any built-in miner support since v0.13.


Are the indexes generated by txindex=1 persisted to disk?

The transaction index is persistent, and bitcoind will pick up where it left off if it is shut down and restarted.

Note that you must start it again with the -txindex option set, or any new transactions it processes will not be indexed. However, with recent versions of bitcoin, it will still maintain the partial index if you forget to set the option, and only reindex blocks for which it wasn't set if you set it again, which is considerably faster than having the entire index deleted and recreated if you forget the option once.


How do I connect my `bcoin` wallet to `bitcoind`?

To run two full nodes on the same machine, they'll need to be bound to different ports. Luckily, bitcoind and bcoin run regtest on different ports already by default (18444 and 48444 respectively). Just note this wouldn't be the case for testnet or main net.

Launch bitcoind

$ bitcoind -daemon -regtest

Launch bcoin in SPV mode

$ bcoin --spv --daemon --network=regtest

Connect bcoin to bitcoind:

$ bcoin-cli --network=regtest rpc addnode 127.0.0.1:18444 add

Get a wallet address from bcoin:

$ bwallet-cli --network=regtest account get default
{
  ...
  "receiveAddress": "n4C5ikvkn5HUNjqAPrPB1udnZPjm9p6xGY",
  ...
}

Generate a block with bitcoind, sending coinbase subsidy to the wallet address:

$ bitcoin-cli -regtest generatetoaddress 1 n4C5ikvkn5HUNjqAPrPB1udnZPjm9p6xGY

Check bcoin wallet balance:

$ bwallet-cli --network=regtest balance
{
  "account": -1,
  "tx": 1,
  "coin": 1,
  "unconfirmed": 5000000000,
  "confirmed": 5000000000
}


Setup cgminer on Ubuntu 12.04 (im getting libudev.so.1 not found error)

Yes, NVidia Graphics card utilization versus naked CPU does help, quite a bit.

Breath. Take a step back.  Make sure you're running as an administrator. Try bashing

  sudo apt-get install libudev1

Use this wiki http://www.distrogeeks.com/install-cgminer-latest-ubuntu/

Don't get discouraged! It's tough but we've all gotta learn sometime, no better way to do it but to Do It.


What can 1 master public key in a multisig reveal?

From a security perspective related to spending bitcoins, since only the master public keys have been compromised, there is no way that the attackers can derive the child public keys as they do not have access to the chain code. However, if the chain code is also revealed, there is no way to derive child private keys and hence the attacker cannot spend the funds. So if you are trying to create transactions with 1-of-3 or 2-of-3 multi-sig, the attacker still does not have access to the signatures (since he does not have the private keys)

However, if you are going to create a P2SH address of all the 3 public keys involved, there is no way anyone can recreate this address even if they know the 2 of the 3 public keys.


What is "Emergent Consensus" as a Mining Pool Support proposal?

Emergent consensus

Emergent consensus is a protocol upgrade proposal championed by the Bitcoin Unlimited developers. The idea is for each node to broadcast its acceptable block size and to thusly establish a feedback mechanism by which the miners can determine the size of blocks to create. In parallel, rules governing block size would be largely lifted under the assumption that a free market would discover the correct block size. The proposal is marketed as a permanent solution to the block size debate and as a means to put the block size limit into the hands of the users.

However, this proposal has collected a fair share of criticism, such as:

It's expected that it'll end up putting the block size limit into the hands of the miners instead of the users, as the out-of-band feedback mechanism is in no way binding to the miners.
Larger miners might be able to abuse the mechanism to put smaller miners at a disadvantage, resulting in further incentives for hashrate to consolidate.
Incentives for larger blocks overwhelm reasons to restrain block size growth, e.g. costs of larger blocks mostly burden node operators, while miners mostly benefit.
Specific implementation issues with the mechanism of establishing bigger block sizes in the network.
The necessity of a hard fork to activate the proposal.

For a more comprehensive overview, I'd recommend that you read the excellent three part series by Aaron van Wirdum that explores the proposal in detail:

A Closer Look at Bitcoin Unlimited’s Configurable Block Size Proposal
How Bitcoin Unlimited Users May End Up on Different Blockchains
Why Bitcoin Unlimited’s “Emergent Consensus” Is a Gamble

BIP100

Is a block size voting mechanism proposed by Jeff Garzik in 2015. It would establish a dynamic block size per vote of the miners. Each block would cast a vote for a maximum blocksize, and from the votes of the past 12,000 blocks the current limit would be derived by discarding the lowest 20% of the votes and picking the remaining minimum.

The proposal puts block size under control of the miners and requires a hard fork to activate.

Aaron van Wirdum covered it here: A Closer Look at BIP100: The Block Size Proposal Bitcoin Miners are Rallying Behind

Extension block

Another proposal to improve capacity which suggests appending additional blockspace similarly to how segwit adds the space for the witness programs. Unupgraded nodes only see the stripped version of the block (just like in segwit). However, while segwit keeps all the transaction "instructions" in the stripped block and only partitions the one-time-use witness program, the extension block actually allows complete transactions in the added space. Unlike segwit, the extension block therefore establishes a second UTXO set only visible to upgraded nodes. While the proposal could be rolled out as a "softfork" due to the stripped blocks being backwards compatible, the partioning of the UTXO set would basically force everyone to upgrade immediately to the new version in order to be able to track all economic activity on the network. (Whereas with segwit even old nodes see all transactions, even though the nodes don't understand some restrictions that apply to the segwit formatted transactions.)


Is there a recommended maximum number of transactions any one address should ever receive?

You can use it as many times as you like. There is no upper limit.

The reason that people advocate using new addresses is that it increases anonymity. For example, people who know your address can easily look up how much has been sent to it in total. See these questions for some more info on anonymity:

How anonymous are Bitcoin transactions?
How can one remain relatively anonymous while using Bitcoin?


Please explain network propagation with unconfirmed transactions (blockchain.info)

Network propagation is the number of nodes (computers running a bitcoin client) that have heard about your transaction.

Confirmations is how many blocks have included your transaction and how many blocks have linked onto that block.  1 confirmation means your transaction was included in a block, 2 confirmations means that another block linked onto that first one, and so on.

Until a transaction has been included in a block, it isn't considered to have really happened, regardless of how many nodes have heard about it.

Propagation needs to happen before a confirmation can occur, as a mining node needs to be aware of the transaction to include it in a block.

As of this moment, both of your transactions you linked are now showing as having 1 confirmation after being included in block 228337.

As for why it took so long to get a confirmation (468 minutes for the first one), no real idea.  Might be something regarding some miners dislike for satshoidice.  For example, the Eligius pool is configured to exclude any Satoshidice transactions from their blocks, as they view them as spam.


Who issues the transaction of reward when a miner solves the block?

The miner itself includes a special transaction in the block called generation transaction. Every block only has a single generation transaction.

This generation transaction transfers the block subsidy plus the fees of the block to an address controlled by the miner.

For intance, if you look at block 434868, there is a single generation transaction that transfers 12.96 to address 17ggdTQzKFwrKP1zgqb5Kjuw6CpGKaE6Jrw.


Multibit: Using the same passphrase for both my wallet and exported private keys

How (un)safe is this?

It is probably OK. Even though, in general case, you would want a different password for any different use, in your case the things you protecting are nearly the same. The wallet will hold all the "keys", and the keys along form your wallet.

Suppose you have a selection of deposit boxes in a bank. Now imagine that there are no guards in the bank and anyone can pop in and open any deposit box. Now, expand this idea, instead of a single bank you have as many deposit boxes as there are probably atoms in the universe.

A key is a pointer to one of those boxes. No passwords, no locks, just the location.

Because the wallet and keys are kind of the same stuff you can use the same passwords. But really, in a world where tools like KeyPass, can generate strong random noise, there is no excuse not to use them, and not to have two different passwords.

  If an attacker retrieves these files, can the attacker take a cryptographic shortcut because both files use the same password?

An attacker would need to get access to either of the wallet or the keys to get your money. Given access to any, means he will be able to transfer the funds elsewhere. The good news, he will need to know your password. There are no successful attacks known, that can decrypt the data without the password.