Every transaction has a hash associated with it. In a block, all of the transaction hashes in the block are themselves hashed (sometimes several times — the exact process is complex), and the result is the Merkle root.

In other words, the Merkle root is the hash of all the hashes of all the transactions in the block. The Merkle root is a part of the block header. With this scheme, it is possible to securely verify that a transaction has been accepted by the network (and get the number of confirmations) by downloading just the small block headers and Merkle tree – downloading the entire block chain is unnecessary. This feature is currently not used in Bitcoin, but it will be in the future.

UPDATE: This feature is currently used by lightweight bitcoin clients

  "Is some data is changed, the hash will not be the same so, it is
  possible to notice that some data is changed."

Yes if some data is changed then the Merkle root hash will be different.


What .dat files are safe to be accessed while the Bitcoin client is running?

None of them are safe to access while bitcoind is running.  The only one that is critical to backup is wallet.dat, and the backupwallet rpc command will do that safely while bitcoind is running.


How is Coinbase any different than Mt Gox?

You're right that in this regard, Coinbase and Mt.Gox are similar: they control the private keys, and incompetence or malice on their part could result in the loss of your coins. One difference is that Coinbase doesn't keep a balance of USD (or other fiat) in your account, only bitcoins. The other major difference is that Coinbase has not (AFAIK) shown any signs of incompetence or malice jeopardizing your bitcoins stored there (these signs, I hear, were around for a long time before Mt.Gox finally died).

Cold storage is a good thing when done correctly: it improves security and doesn't prevent instant bitcoin withdrawals (except in exceptional circumstances).

Still, personally, I will (long-term) store my bitcoins in a local client or my own cold storage, not an exchange or online wallet. There's still a real (maybe even higher!) chance of loss this way, but it'd be due to my incompetence, not someone else's.


Why can we have small fractions of a Bitcoin?

Bitcoin amounts in the protocol and software are expressed as an integer number of "satoshis". 1 BTC is defined as 10^8 satoshis. So a block reward that is internally represented as 5*10^9 satoshis is displayed in the GUI as 50 BTC.

Splitting bitcoins to even smaller fractions will require a change in the protocol and software, and may be done when their value becomes much larger.


Where can I find a graph of the current size of mining pools?

The http://bitcoinwatch.com/ site gives a pie-chart of the hasrate distribution by mining pool.


Tracking a specific Bitcoin to make it represent something else, which could then be traded without trust

As you say following the outputs of a transaction could be used as you describe, there are more people that like that kind of use cases and that's why ColoredCoins was created or Zerocoin which try to make it completely anonymous.

Indeed so many people is trying to add metadata to coins that in 0.9 version of the client there is a new output type that can include 80 bytes of data with no other use (you can read more about it here https://bitcoinfoundation.org/blog/?p=290)


How to run a private bitcoin network with low difficulty?

Use regtest

Chain selection options:

  -regtest
       Enter regression test mode, which uses a special chain in which blocks
       can be solved instantly. This is intended for regression testing
       tools and app development.

  -testnet
       Use the test chain

Using this mode, you can manually mine blocks by issuing the following command, where nBlocks is the number of blocks to mine. You will need atleast 101 blocks before your first mining reward becomes available.

bitcoin-cli generate nBlock


Please take a look at my server print out to see if all looks well or if the repeating errors mean something is wrong

The message

potential stale tip detected, will retry extra outbound peers

is associated with at least two situations:

A firewall is blocking port 8333 and your node cannot communicate with peers.
Problems with genesis block (delete blocks and chainstate directories and restart).


How to get the pool name from coinbase transaction?

Although is may be possible to associate addresses that appear in coinbase transactions with mining pools, this relationship can be quickly broken - because they can easily change this address - and that's not how tipically mining pools are identified.

Mining pools/miners that want to identify themselves do so in the scriptsig of the coinbase. In your example, the scriptSig is:

03404a092cfabe6d6d5995dc2134639c494208abda86747b0f77fe5b92e9456a85974f452f51a3da0910000000f09f909f00144d696e6564206279206365616d6b7978696c6f6f000000000000000000000000000000000000000000000005001f450000.

If you decode this hexadecimal number to ascii, you get:
@J ,ú¾mmYÜ!4cIB«Út{wþ[éEjOE/Q£Ú    ðMined by ceamkyxilooE

You can see that it contains the string Mined by ceamkyxiloo, which is what identifies F2pool. Most of the decoded text is unintelligible because this field (expect the first ~4 bytes) are used to create entropy during mining - what is called "extra nonce".

Most block explorers keep a mapping of these signatures to miners/mining pools. Here is an (outdated) mapping.


How does the wallet identify which UTXOs belong to a public address while creating a new transaction?

A Transaction output has a field for amount and a locking script but no direct field for public address for which the output is meant.

This is not quite correct and seems to be the source of the confusion.  A "locking script" contains the essential part of an address surrounded by the additional commands necessary to lock (or encumber) the bitcoins in that output to the address.  Let's look at an example; first we get an address:

$ bitcoin-cli getnewaddress
397yNmAFc1w6AK1gqkKNxJPb44jnvznm2b

Then let's ask the wallet what it knows about this address:

$ bitcoin-cli validateaddress 397yNmAFc1w6AK1gqkKNxJPb44jnvznm2b
{
  "isvalid": true,
  "address": "397yNmAFc1w6AK1gqkKNxJPb44jnvznm2b",
  "scriptPubKey": "a91451812710fc166bf61033afc0d2a8d7cda7a0fd8c87",
  "isscript": true,
  "iswitness": false
}

Note the scriptPubKey---that's what you're calling the "locking script."  Let's see what that script says:

$ bitcoin-cli decodescript a91451812710fc166bf61033afc0d2a8d7cda7a0fd8c87
{
  "asm": "OP_HASH160 51812710fc166bf61033afc0d2a8d7cda7a0fd8c OP_EQUAL",
  "reqSigs": 1,
  "type": "scripthash",
  "addresses": [
    "397yNmAFc1w6AK1gqkKNxJPb44jnvznm2b"
  ]
}

The asm field is the interpreted form of the locking script; OP_HASH160 and OP_EQUAL are two parts of the P2SH-style encumbrance for addresses starting with a 3.  The value in the middle 5181...fd8c is the hex form of the essential component of the address (other parts of the address are a version byte and a checksum; these aren't necessary to put in the locking script).

So, in short, the address 397yNmAFc1w6AK1gqkKNxJPb44jnvznm2b is a representation of the same thing as the scriptPubKey a91451812710fc166bf61033afc0d2a8d7cda7a0fd8c87.  The scriptPubKey is the data that actually gets placed in the output to indicate that a certain set of bitcoins are controlled by the owner of the corresponding address.

  How does it find this subset of UTXOs which is locked to the public address?

A wallet that's part of a full node simply scans every transaction the full node receives to see if any of their outputs pays one of that wallet's scriptPubKeys (addresses).  If it does, the wallet saves that UTXO in its own database until it's time to spend it.

Lightweight wallets typically ask full nodes or servers to help them find the outputs.  Sometimes this entails scanning blocks basically the same way the full node wallet does with some extra steps (see BIP37), sometimes the server builds a giant database of every address every seen and performs lookup queries on it (see Electrum servers), and sometimes the full node builds a very compact index and sends that to the lightweight client so the client can request blocks that might contain its transactions (see BIP158).

Notably, wallets need to know which UTXO paid you in order to show you your balance, so wallets don't look up UTXOs when spending, they look them up when receiving.


Does any documentations with mathematical description of Bitcoin exist?

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

etc.


how to differentiate bitcoin-cli command when have testnet & mainnet both running

You can pass the -rpcport flag to bitcoin-cli to specify which node to connect to when running multiple on the same machine.


estimatesmartfee expects the number of blocks you want the tx confirmed in as the parameter, not the amount of BTC you are sending.

Try estimatesmartfee 5 to get an estimate for confirmation in the next 5 blocks, for instance.


The first step is to identify the specific type of coin and what company created it.

See Coindesk - 10 physical bitcoins - If your coin looks like any of those, you can find out whether it has any value and how to use it.

There are many variations:

Many physical bitcoins are novelty items and have no value.
A few may have some intrinsic value from the materials they are made of (gold, silver etc). I imagine most do not.
Some physical coins have an associated bitcoin value which can be redeemed if the company that issued the coins is still in business and honest. For example, Titan bitcoin say:

  If you ever want to spend or transfer a 2FA coin’s bitcoin value, simply peel back the coin’s security hologram and enter the redemption code on our website, along with your registration info.

Some physical bitcoins have a private key concealed inside them or under a tamper-evident sticker. You can probably type that into a bitcoin wallet to import the key. An example is the discontinued
series-1 Casascius Coin

  How they work: The "private key" is on a card embedded inside the coin and is protected by a tamper-evident hologram.  The hologram leaves behind a honeycomb pattern if it is peeled. If the hologram is intact, the bitcoin is good. If you have purchased a 2-factor item, the private key is encrypted and will need to be decrypted using your original preselected passphrase before you can redeem the funds.

  The 8-character code you see on the outside of the coin is the first eight characters of the Bitcoin address assigned specifically to that coin.  You can verify the coin's balance on Block Explorer.  There is a mathematical relationship between the Bitcoin address and the private key inside the coin. The digital bitcoin is actually located on the public "block chain" stored on the internet, but it is completely inaccessible to anyone unless the private key from the coin is loaded into a Bitcoin wallet.

My emphasis - I'd guess this may be the coin you have.

Note that the issuer may have records of those private keys. If the issuer went out of business or the records fell into the hands of others, it is possible that someone else will have subsequently removed any bitcoin value associated with the private key.

Useful references

Bitcoin Magazine - Physical bitcoins


Does bitcoin qt need to synch before I can spend my change?

Does bitcoin qt need to synch with the network before it will notice the change has been received

It won't know about the change transaction until it has processed the block containing that transaction. Your change transaction is in a recent block, your bitcoin software is still catching up earlier blocks and hasn't retrieved that recent block yet.

  allow the big transfer to go ahead ...  It is still rebuilding the blockchain

This seems like a misunderstanding on your part. If the block containing the "transfer" has 6 confirmations, it has already "gone ahead". It is absolutely irrelevant whether your wallet ever catches up or not. In this scenario wallets only ever do two things

send your transaction out to a few Bitcoin nodes it knows about hoping they will pass it on and that eventually a miner will notice it and include it in a newly mined block.
keep listening for newly published blocks and reading them to see if they contain any mention of any of the set of addresses the wallet thinks you are interested in (ones it generated for you).

Wallets do not "allow the transfer to go ahead". As far as the rest of the world is concerned, once your wallet sent out the candidate transaction, your wallet's role in the process ended.

Wallets generally try to dissuade you from using money associated with  transaction outputs the wallet has either not yet seen in a mined block or for which it has not seen at least 6 subsequent blocks built on the block containing the transaction.

Footnote:

For simplicity, and to avoid causing confusion, I have omitted possibilities like RBF, double-spending attempts, etc. I am assuming the normal simple process used in most ordinary regular boring plain transactions.


What is the difference between key aggregation and signature aggregation?

As Pieter Wuille states here key aggregation is completed at address creation time not at signing time or post signing time.

Of course, key aggregation has an impact on the signing algorithm, and that's probably one of the main reasons why it's useful to do it before CISA: the work needed to support MuSig signing in wallet will take a while, but it's pretty similar to CISA signing.
Why is key aggregation better? Because it means the original keys never end up on chain. With signature aggregation you still have on-chain keys, but with 1 signature....Key aggregation means the consensus rules can be completely oblivious of even the concept of aggregation.
Downside: key aggregation cannot be used cross input, as you can't predict which UTXOs will be spent together.

Meanwhile signature aggregation is completed at signing time or post signing time, not at address creation time. To implement it it would possibly need a specific opcode that observes multiple keys.

Signature aggregation implies a verification algorithm that receives a list of (message,pubkey) pairs and a signature.

You could see key aggregation as a special case of signature aggregation as the aggregated signature is also a valid "single key" signature for the aggregated key. But conceptually there is a huge difference in how they would be implemented.

Why is it important to be careful to use the correct term in its correct setting?

The proposed Taproot soft fork does not enable signature aggregation at all (cross input or otherwise), it facilitates key aggregation schemes e.g. MuSig. As Pieter says, the consensus rules of Taproot and Schnorr don't have any awareness of aggregation. Hence if you say Taproot enables signature aggregation this is incorrect and will confuse. In addition, when moving onto the discussion of what soft fork(s) could potentially follow Taproot, enabling signature aggregation will be a candidate feature that is seriously considered as the block space savings could be significant. (Note witness data is already discounted post SegWit). Key aggregation allows you to aggregate keys within one input but cross input signature aggregation could potentially allow you to aggregate signatures across inputs.
Aggregating signatures not only across inputs but across transactions could potentially mean only one signature goes onchain for the entire block. However, this is not possible with discrete logarithm based cryptography (see Pieter's comment below). It needs non-interactive aggregation as you can't require transaction authors to cooperate. This aggregation needs to be done by miners.


How does nix-bitcoin provide greater security for installing Bitcoin nodes?

nixbitcoindev explains here that the additional security provided by nix-bitcoin is due to minimalism, code reproducibility, compartmentalization and defense in depth.
nix-bitcoin uses NixOS which is a purely functional operating system which means that it builds the entire operating system from the source code of every application of the Linux kernel resulting in the same system every single time it is deployed.
With a general Linux distribution it is not possible to de-install all the packages you don't need as it would eventually result in a broken system. NixOS has a kind of formula where it goes through and calculates what you need and only builds that. This minimalism significantly reduces the attack surface.
Everything is reproducible with NixOS, not only Bitcoin related software such as Bitcoin Core, c-lightning, lnd etc but the entire stack including the Linux kernel. As a result you know you have exactly the same system that everybody else has. That’s a really strong defense against  the developers inserting malicious code or code upstream getting compromised. Once the developers have verified the software, within the hash it’s going to be the same software that everybody is using.
Every service runs in its own little box under its own user. It can only see its own directory and with network namespaces it can't even scope out your entire network. It can only scope out its own network and its Linux namespace and the ones it is allowed to see. Outside processes outside of that network namespace also can't look inside. That offers a great deal of security because now programs like Spark wallet that connect to your c-lightning, they’ll never see JoinMarket, they’ll never see Electrum, they’ll never see bitcoind. They are maximally compartmentalized.
Defense in depth means putting up multiple walls or multiple lines of defense. nix-bitcoin isolates by users and isolates on the network level with systemd.


Not from Btc-e though you can probably get them from bitcoin charts or start keeping your own and then just query that (thats what I did.) Btc-e's API sucks, but heres a project that makes several API calls not in their official documentation.


How can I accelerate confirmations in ledger nano s?

There are a few services that can accelerate Bitcoin transactions. According to the Bitcoin wiki, PushTx seems to be reliable.


Is my wallet effected by the Meltdown and Spectre vulnerabtilies?

If you use a modern computer (i.e. one that has a processor that came out in at least the past 10 years), you are effected by the Meltdown and Spectre vulnerabilities. In fact, even if you use an older computer, you may still be effected as it is theorized that Intel CPUs dating back to 1995 may still be vulnerable. However CPUs that old were not tested. Meltdown primarily effects Intel CPUs while Spectre affects a wide range of CPUs, including Intel, AMD (including Ryzen), and ARM (used in smartphones) processors.

Meltdown

All wallet software are effected by the Meltdown vulnerability. Meltdown allows a malicious software to read any bit of memory that it knows the location of. It is capable of dumping the entire contents of the physical RAM in your computer. This means that any wallet which is currently running and has private keys loaded into memory is at risk of having the private keys stolen. Wallet encryption does not help here as the private keys will need to be unencrypted in memory in order for you to be able to sign transactions. Thus any malware exploiting Meltdown will be able to read those private keys.

Mitigations

Meltdown requires that code exploiting the vulnerability be run on your machine, so the usual explanations of due dilligence and avoiding malware apply. However it may be possible for the attack to be performed through malicious JavaScript that is loaded from a webpage. Thus, as usual, you should avoid visiting suspicious websites and disabling JavaScript entirely would not be a bad idea.

Furthermore, there are operating system upgrades that can mitigate Meltdown and make exploiting the attack almost useless. There are also browser changes planned that will make it much more difficult for JavaScript code to retrieve data from your computer's memory. You should expect to see these patches coming out soon for your browsers and operating systems if they are not already available.

Lastly, Meltdown appears to only effect Intel CPUs, so if you have an AMD CPU, you shouldn't be effected by this vulnerability

Spectre

Spectre is more limited in scope than Meltdown is and targets specific processes. It also requires that specific knowledge of the software that is being attacked which does make the attack much harder to pull off. Spectre effects every piece of software which receives an input from somewhere, so all wallet software will be vulnerable.

Furthermore, the Spectre example attacks have been focused primarily on Virtual Machines and browsers. It allows for malicious applications to break out of the sandboxing that VMs and browsers provide. This is particularly bad for web wallets as malicious JavaScript executed in your browser can result in your private keys (which are held in the browser's memory) to be leaked to the attacker.

Mitigations

Spectre effects a wide range of CPUs and it has no known software patches.  It effects all modern Intel, AMD, and some ARM CPUs. This means that both computers and smartphones are vulnerable. Some variants may be mitigated but other variants may still be exploitable. As usual, you should avoid visiting suspicious websites and downloading suspicious files to your computer. The usual due diligence applies.

Since JavaScript can exploit Spectre, patches will become available from browser vendors to reduce the effectiveness of using JavaScript to exploit Spectre. There will also be other operating system and other software updates which will reduce the effectiveness of Spectre. Unfortunately it cannot go away entirely unless hardware is upgraded. As usual, you should ensure that all of your software is up to date in order to avoid the exploitation of these vulnerabilities.

Patching the vulnerabilities

Unfortunately there are no known ways to patch the vulnerabilities entirely through software. The current proposals are stop-gap measures which only reduce their effectiveness but also at the cost of performance. Because these vulnerabilities are based in the CPU hardware, the only way that they can be patched is through new hardware that is not vulnerable. It is not known whether a microcode update (aka the CPU firmware) will fix the vulnerabilities or not.

Keeping your coins safe

The only way to ensure that you are not effected by these vulnerabilities is to use hardware that is effected by the vulnerabilities or use hardware where even if they are effected, the data cannot leave the device. There are really only two options for this: use a hardware wallet, or use an offline computer solely for your wallet.

Hardware wallets

Hardware wallets do not have these vulnerabilities because they use processors that are not vulnerable. The processors do not feature Out-of-Order-Execution which is what both Meltdown and Spectre exploit in order to read data. Furthermore, even if they were vulnerable, software that runs on the hardware wallet must either be flashed as new firmware or be manually installed by the user. This makes it much more difficult (basically impossible to do without the user noticing) to get malicious software onto the device that could exploit these vulnerabilities. But as said earlier, they are not vulnerable so such software would be useless.

Hardware wallets also do not transmit any secret information (i.e. private keys) to the computer so the private keys are never exposed and thus cannot be stolen.

Offline cold storage devices

Offline cold storage devices that are not hardware wallets typically consist of older, low powered general purpose computers. Such computers are likely to be vulnerable to Meltdown and Spectre. But because they are offline, it is much more difficult for a piece of malware to both get onto the machine and get data off of it.

Although it is harder to infect and exfiltrate data from offline devices, sophisticated malware does exist and can do so. They do so by hiding on the USB drives that are typically used in such setups. By hiding on a USB drive, the malware can go from an infected online computer to the offline computer, infect the offline computer, and transmit data from the infected offline computer to the infected online computer via the USB drive. This would allow an attacker to steal private information (which may be read by exploiting Meltdown or Spectre) from an offline cold storage device.

The only secure way to send data between an offline device and an online device would be something which allows you to inspect the data before it reaches the online machine. Unfortunately this is rather difficult to do.

Conclusion

Meltdown and Spectre are two vulnerabilities that are based in the hardware and are difficult to fix through software patches. They have the potential to leak private keys and other secret information from a computer to an attacker whilst leaving little to no trace of it ever happening. The vulnerabilities effect all software wallets (including web wallets) which run on a computer or smartphone. The only way to secure your coins is to have the private keys stored on a device which cannot leak the private keys without the user noticed. It is thus my recommendation that you use a hardware wallet.


What should I do if my friend runs a Bitcoin business but doesn't understand how it works?

He should listen to his engineer. I think that's just about it.


if your channel's are initially as you described (just depicted here again with better readability using total cpacity of the channel in brackets in the middle of the channel and the respective local balance on the side of the peer)
You -(200) --------[400] -------- (200) - Alice
You -(200) --------[200] ---------- (0) - Bob

And you create a circular rebalance of 100 sats the result schould (in an ideal world ignoring routing fees) look as follows:
You -(300) --------[400] -------- (100) - Alice
You -(100) --------[200] -------- (100) - Bob

Thus your total local balance should have stayed the same as the total capacity of the channels should not have changed. Of course you pay the routing fees for such an operation so in reality the result might look a little bit more like
You -(298) --------[400] -------- (102) - Alice
You -(100) --------[200] -------- (100) - Bob

This means that you had sent out 100 set to Bot Bob and others have probably decreased the amount to forwards a little bit so that you will only receive for example 98 on your channel with alice.
The situation that you discribe in which you magically have 500 sats instead of 400 can / should not happened with a rebalancing operations. Are you sure that:

noone sent you 100 sats on the channel with Alice at the same time
You did not earn 100 sats of routing fees on that channel with alice at the same time?

Thus I would kindly ask you to reproduce the operation..


Transaction from bitcoin core is different from the explorer

The problem is with getrawtransaction command in bitcoin core. It doesn't recognize the SegWit input which is why it decode/deserialize the transaction incorrectly (wrong input txid and negative amount in output).
https://bitcointalk.org/index.php?topic=5014781.0


How was the overflow bug of 2010 detected? Should UINT64_MAX value transactions be considered suspicious?

Your first question is kind of a pointless retrospective question. Sure, now that we know that overflow can be a problem in this way, we should consider transactions that attempt to overflow to be suspicious.

The bug was detected by inspection of the blockchain. The bad transactions stood out. Had it not been detected by inspection, sooner or later it would have been detected by the presence of too many Bitcoins circulating.

There are no issues any more. Each individual output is now checked in a way that ensures that their sum cannot exceed the input to the transaction. Overflow is, so far as we know, no longer possible.

Your question seems to be asking if there's some "magic bullet" that can solve similar future problems that are presently unknown. The thing is, if there was, we wouldn't know it because we don't know what the future problems are likely to be. Sure, in retrospect, there are many things that could have been differently that would have made this particular exploit impossile.


Is it safe to store all my coins on Coinbase?

I would recommend diversifying your btc holdings as much as possible. What if something happens to your wallet? That wouldn't necessary be better than coinbase. You could keep some in a personal wallet, some on several exchanges. Ideally by diversifying your capital, you can some what mitigate commonality of the risk. This prevents the possibility of a single devastating loss.

That said consider some alternative, if there is a single fault, but the probability is very low, that may be a good choice.

Consider https, which typically relies on one main root of trust who's security has been well verified, compared to some of googles authyoath crap (which places trust on a diverse sequence of relatively completely insecure mechanism) which have been hacked whilst https remains secure.

P.s. Google, stick to search engines.


Recovering a wallet from a lost device onto newly bought device

If you are using a wallet, based upon hierarchical deterministic (HD) standards (e.g. BIPs: 32/39/44/49), be sure you have already saved your BIP 39 seed words (typically 12, 18 or 24 words from a list of 2048 words that must be in saved in a specific order and spelled correctly) and any associated passphrase(s) in one or more secure locations. The passphrases are of your choosing and and can include special characters.

The BIP 39 seed words are needed to reconfigure your replacement software or hardware.  A BIP 39 passphrase provides and additional level of security if someone gains unauthorized visual access to your seed words. However, don't store your BIP 39 seed words and BIP 39 passphrases in the same location.

Not of aware of any software-based HD wallet GUIs that are supporting BIP 39 passphrases, seems to be mostly a feature the hardware vendors are supporting.

If you did not take these precautions in advance before your device was lost/stolen/broken, you are SOL.


What is a simple explanation for how the number of bitcoins in circulation is determined?

You could explain the coin limit like this:

When Bitcoin started, its creator set a rule - "No more than 21 million Bitcoins will ever be created, and they will be given out gradually for creating blocks" (Add further explanation of block reward or proof-of-work here if needed). Everyone who joined Bitcoin knew about this rule, and they were all for it. As everyone can see all the money created by solving the blocks, everyone can check if someone tried to go against the rule and cheat. If cheating is detected, nobody will accept the solution, instead looking for one that follows the rule. Because everyone is checking everything, nobody can cheat and create more Bitcoins than is allowed.


As a solo miner how can I prioritize my own unconfirmed transactions?

If you are the pool itself, or are solo mining you can use the prioritisetransaction command to add weight to your own transaction, if you are a client of a pool you do not have any control over what you are mining.


Is a multisignature transaction propagated through the Network before it accumulates enough signatures?

Mike Hearn talks in his speech about the future of bitcoin and mentions subchannels when doing micro payments, is this what you are looking after?

When i try this in Testnet
getreceivedbyaddress does show the amount sent to the multisig address, but listunspent does not. So even if listaddressgroupings include the multisig address, you still need to know the txid to be able to spend that prev_output.

if i try to send a tx with only 1 signature, this is what i get in the log:

ThreadRPCServer method=sendrawtransaction
ERROR: CScriptCheck() : 4378d77e5d VerifySignature failed
ERROR: CTxMemPool::accept() : ConnectInputs failed 4378d77e5d

and with 2 signatures (Complete):

ThreadRPCServer method=sendrawtransaction
AddToWallet 470a194f21  new
keypool reserve 9
keypool keep 9
CTxMemPool::accept() : accepted 470a194f21 (poolsz 5)
AddToWallet 470a194f21
received getdata for: tx 470a194f21

txid is also returned 470a194f21 by the client.

My answer is:

No, the mempool will not work as a subchannel (right now, if it ever was indended)


What were the previous Binance coin burns as stated in the white paper before 2018 April?

Found this on their website. They plan to burn 100 million coins every quarter by burning 20% of their profits in BNB. Currently have have burned 2 million so far.

Q1: https://support.binance.com/hc/en-us/articles/115002205552-Binance-1st-Quarter-BNB-Burn-Event

Q2: https://support.binance.com/hc/en-us/articles/360000012892-Binance-Coin-Burn-in-2018-Winter


How do I set up my machine to process transactions and earn the transaction fees?

The only way to collect money from transaction fees is to solve blocks; they are one and the same thing. The reward for being the first to successfully mine a block is:

the coinbase reward (currently 25 BTC), and
any transaction fees for the transactions included in the block

There is no way to separate these two.


Im guessing your on ubuntu because of your username ;)
Step 1 add the bitcoin ppa

sudo apt-add-repository ppa:bitcoin/bitcoin

Step 2 install bitcoind

sudo apt install bitcoind

Step 3 set bitcoind up

Make a config file with the following contents in /home/$USER/.bitcoin/bitcoin.conf
https://github.com/bitcoin/bitcoin/blob/master/contrib/debian/examples/bitcoin.conf
Replace some parts like rpc password etc

Step 4 add walletnotify

Walletnotify will run a shell command everytime something changes in your wallet.
I like this repo.
https://github.com/damonp/walletnotify

I hope this  helps!  :)


How do I get wallet balance using xPub address with blockain.info api?

See this link:

Multi Address
https://blockchain.info/multiaddr?active=$address|$address
Multiple addresses divided by |
Address can be base58 or xpub
Optional limit parameter to show n transactions e.g. &n=50 (Default: 50, Max: 100)
Optional offset parameter to skip the first n transactions e.g. &offset=100 (Page 2 for limit 50)


I requested a transfer on July 22 and still haven't received it yet. There was a bounty offered for people to prove that they've received a wire in USD from Mt.Gox from the moment in which they announced they had resumed withdrawals. Only one user claimed it and he requested his wire on July 3 (which was July 4 on Japan time which is Mt.Gox's time zone). Unfortunately, it seems he's the only person to have gotten paid so far or the others aren't sharing any info.

Thread here:

https://bitcointalk.org/index.php?topic=251895.160


What is the best language to use for making API orders?

Go - easy concurrency, productive and effcient


Bitcoin: Why can the difficulty parameter not be ignored?

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

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

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


Transaction fees for smaller transactions

The default fee is in place to decrease the chance the creation of dust outputs (miniscule amounts of bitcoin). Dust outputs cost more to spend than they are worth themselves and they still need to be stored in the disk space of anyone that stores the complete blockchain - thus are frowned upon.

To read a discussion on that matter with some of the Core Developers you might want to review The minimum transfer fee is not trivial anymore.

Currently, there are some mining pools that accept transactions even without transaction fees. The default transaction fee in bitcoin-qt has been lowered before when the value of bitcoin increased sufficiently to make the recommended transaction fee too high. This happened for example in May 2013, when the default fee was reduced to 0.0001 BTC from 0.0005 BTC.

It is therefore expected that the default transaction fee will be kept at a respectively low level should the value of bitcoin increase dramatically. In any case, anyone can choose to ignore it by changing the settings of their bitcoin-qt.


From LND Bitcoin Wallet to Bitcoin Wallet

Yes. You always have two accounts on LND (ZAP interfaces over rpc with your self hosted lnd node). One account is your lightning wallet where channel management is done, and the other is your on chain wallet. Depending on where your balance is there are different processes for moving the balance to your on chain wallet (which is what I assume you want).

Moving balance from lightning channels - You need to close the channels on the ZAP wallet which will broadcast the closing transaction to the bitcoin network. Depending on how long the HTLC is, the balance would take some time for it to become spendable.
Moving on chain balance - You can simply transfer on chain funds to your other wallet just like any other on chain transaction.


You cannot choose the TXID of your transaction, really. It is calculated by SHA256d hashing the serialized transaction bytes. If you did happen to get miraculously lucky enough to get a transaction with the same hash as a different transaction, then it would be refused by the network for attempting to overwrite a transaction.

There used to be a bug in bitcoin that coinbase transactions could have the same TXID sometimes. This was fixed by BIP34.


How does PoW solved in miner.cpp gets transferred to main.cpp in source code?

If you read a few lines after the BlockFound signal, you'll see:

CValidationState state;
if (!ProcessNewBlock(state, chainparams, NULL, pblock, true, NULL))
    return error("BitcoinMiner: ProcessNewBlock, block not accepted");

https://github.com/bitcoin/bitcoin/blob/v0.12.0rc2/src/miner.cpp#L373-L375

This is where the processing actually starts. ProcessNewBlock is defined in main.cpp.


What OpenCL video cards (or FPGAs) are best for multiplication?

The simple answer is to compare the results of 2 sites for an answer.  Both are coin mining hardware comparison pages, one for script, the other is for sha256.  Unfortunately, there is little information for the older Nvidia cards on the scrypt mining.

SHA-256: https://en.bitcoin.it/wiki/Mining_hardware_comparison
Scrypt: http://litecoin.info/Mining_Hardware_Comparison

they also include a few other CPUs and Arm processors as well as FPGAs.  With FPGA multiplication and parallel addition, the more core segments, the more likely it can do it and do it fast with out having to buffer a sum then use the sum as input back in to the equation.  Spartan 6 FPGAs are a good example of fast units, and depending which one, possibly able to do multiplication as a low level logic function rather than use a math processor due to the logic cells available.

As far as GPU features go, the newer, faster and the more shader cores ( or equivalent ) the better at math the card will be.


Instant confirmations with pre-published, locked, transactions

This is a solved problem, see https://bitcointalk.org/index.php?topic=25786.0 and this.

It has also been recently implemented in BitcoinJ, and called "Micropayment channels".


#include <openssl/bn.h>

[...]

BN_mod_inverse ( a, b, c, ctx );


What is the incentive to broadcast the whole blockchain? What is the incentive to broadcast unprocessed transactions?

Note that not all full nodes are miners, and that there are significantly more non-mining full nodes than there are miners (as in the vast majority of full nodes are non-miners).

  Is there a direct incentive to broadcasting the whole blockchain though (i.e. operating a full node)?

The incentive for operating an archival node that can serve the blockchain to other peers is that doing so helps maintain the network and thus gives value to the Bitcoin that you are mining.

  Likewise, is there a direct incentive to broadcast all transactions to other nodes immediately?

Yes. If run a full node which is not broadcasting transactions, then when you decide to make a transaction, it becomes immediately obvious to your peers as to where that transaction originated from. The incentive is to preserve your privacy.

Even with a delayed broadcast, you would still be risking privacy as your peers would like hear the transactions first from other peers, so as soon as they see you broadcast a transaction that they hadn't seen from elsewhere, it would be reasonable for them to assume the transaction came from you.


The "two years behind" is not telling you how long the synchronization will take but what time you are caught up with. Bitcoin processes history much faster than real time.  If you are at two years behind you are most of the way done.  If you click the "behind" text it should give you an estimated time left counter.

Syncing speed depends on your hardware. The first time takes anywhere from a day (on reasonably fast hardware) to a few days (on slower hardware).  After that it doesn't take long on restart.


How can I request payment to a set of addresses?

It appears that the Payment Protocol is, indeed, what I want, and it is relatively widely supported according to this comparison page: https://bitpay.com/docs/wallets


Specification of Transaction Inputs - Bitcoin vs Ripple

Advantages of UTXO/blockchain approach:

You don't have to pay to addresses that refer to accounts. Transactions can pay to unique rules or conditions that can exist only as the rule to claim a particular transaction output.
Transactions are more independent in execution, not contending for access to the same account structures.
All you need to know about a transaction is that it succeeded. There's no "additional information" such as the previous balance and the new balance.

Advantages of account/ledger approach:

Accounts exist as primary structures and so can have properties, both persistent/configured and dynamic/reported.
Transactions are more independent in formation, not contending for access to the same transaction outputs.
There is no UTXO database to maintain and synchronize and attacks on the UTXO set do not work. (Though there are other ways you can defend against attacks of this type.) More sophisticated transactions can be supported without creating the risk of disagreement on the UTXO set.

Bitcoin's design naturally fits the UTXO approach. Transaction results are simple, and there's no need for account parameters.

That approach would not have worked in Ripple for a variety of reasons:

Because Ripple supports arbitrary assets, many of which can be worthless, there has to be a way for recipients to indicate which assets they'll accept as payment. This means something has to have that as a property, which requires an account.
Something has to issue those assets, which requires accounts to act as issuers.
Cross-currency payments can produce complex results, trying to map those deterministically onto UTXO operations is not a natural fit. Adjusting an account's balance is simpler than choosing UTXO's to consume and create at transaction processing time. Ripple's transactions could not have, for example, specified which UTXOs they'd consume because that isn't known at transaction formation time. (How do you know know who will offer the best rate when your transaction executes? If everyone competes with transactions hardcoded for the juiciest liquidity, the majority of transactions will fail.)
The more complex network state requires a more complex structure to ensure the network agrees on that state. Bitcoin's structure has no way to protect against UTXO divergence, which would be catastrophic, other than keeping transactions simple enough that a mistake of this type is unlikely. Ripple's more complex transactions need a powerful defense against divergence or small bugs in the code could cause catastrophic results.
Because Ripple transactions have more complex outputs, they tend to be larger. Ripple's approach makes it easier to discard transaction history because all you really need is the current status of all accounts and other persistent structures.

You can pretty much meet any requirements with either approach. There are ways to work around each of these issues without changing the approach. But it's often easier to start with the design that most naturally fits your requirements, rather than shaving and jamming to get a round peg into a square hole.


A script exists on GitHub by the name of coinsweep.


Bitcoin unconfirmed transactions - what is the best solution to fast it up?

The simplest thing you can try is to rebroadcast the transaction and see if you get lucky. Here is one of the sites that offers this service http://www.speedupmybitcointransaction.com/

Failing that you can ask a mining pool for some help. For example ViaBTC offer a service described here https://www.cryptocompare.com/coins/guides/how-to-accelerate-your-bitcoin-transaction/

And failing that you can create a Child Pays For Parent (CPFP) transaction to increase the fee paid https://bitzuma.com/posts/how-to-clear-a-stuck-bitcoin-transaction/


Where do wallets such as Exodus store the blockchain?

Exodus does not have a copy of the blockchain locally, instead it relies on a central server for fetching blockchain data.


Generating addresses on the fly or pre-generate and store public key?

To answer this question accurately, we'd really need to know more about how these new addresses will be used in your service.

If these newly-generated addresses are to be "deposit only", that is, as long as you're not needing to send coins from these addresses, then the most secure option by far is to generate the addresses offline and keep the private keys offline.  This is pretty obvious: cold wallets are almost always more secure than hot wallets.

Unfortunately, most services will need to access the private keys of newly-generated addresses for some reason, if only to send any Bitcoins received to another wallet.  In this case, the next best option is to maintain as low a balance as possible in these addresses.  That is, as soon as they receive any coins, forward the balance as soon as possible to an address that is stored in a secure, offline wallet.


Is possible to send transactions with blockstream satellite?

No, communication is unidirectional, you can only receive the data which is broadcast by the system. The satellites being used are TV relays, the uplink essentially being amplified and re-broadcast without any knowledge of the content.Transaction broadcast needs to happen by terrestrial services like a cellphone network, dialup modem, or just the regular internet.


python bitcoin public key to address code error

You get the error because the hexstring you provided is 127 characters long. You need to pad with zeroes.

Even if you pad with zeroes 05bd8834885082d9e9775f2084610bea79d2bd7acde2fc28b4dba85b0902ac786ef3a1fa082da527a3a51bcd71104b4e6ef91b62b2e93bcfdbc4ac7c35e9fddb is not a valid public key. It must start with 04.

The coordinates y1, y2 of your public key also do not lie on the Curve. I do not know where you got your key from but it is invalid.

The Public Key corresponding to Private Key 0x5bd8834885082d9e9775f2084610bea79d2bd7acde2fc28b4dba85b0902ac786 is 04b302d50e6afaea3eb3194fced5b12ba45aa170d2d717d5a598511a96187a7a90e8c84b1f57a822bda9ecf111374c9e92fe0d1fb5a192a45790f437828d17f009 and the P2PKH address is 14pFAXD2uQpdpToL5LS4oh1bsSGXnVpA2r


Bitcoin private key and address generator in golang

btcd does no support this functionality by design, however you can use btcwallet which is written in golang and support what you want

https://github.com/btcsuite/btcwallet

here is a similar question https://github.com/btcsuite/btcd/issues/1308


Is it possible to link multiple bitcoin addresses under one private key?

It is possible to derive different addresses from a single private key, namely one address from the private key's compressed public key, and one from the private key's uncompressed public key.

If you sent bitcoins to each of these two addresses, they would exist as separate UTXOs, even though the same private key could sign to spend the funds in either address.

  This would make signing raw transactions easier.

I'm not sure what is meant by 'easier' here, but in general, it is advised that users do not handle keys themselves, rather let the software take care of this.

Perhaps also worth mentioning: BIP 32 HD wallets allow many keypairs/addresses to be generated from a single seed/extended key. However each address generated in the HD wallet can only be spent by signing with the private key associated with that address. A parent extended private key cannot sign for child address transactions (it is instead used to derive the child private keys, which can then be used to sign transactions).


Where is the string that generates the hash with 18-20 zeroes?

If I undestend the your question,

This is an example of the proof-of-work algorithm.

The nonce is a component of the block, the strucure of the block contain the value, inside the blockchain.com you can find the value inside the propiety "nonce"

I hope I answered your question


Attack the network by temporarily adding hash power?

Yes it is possible. You already answered your own question:

"This could dramatically increase the time it takes for transactions to be confirmed, as well as makes it not profitable for other miners. Granted this would only last until the difficulty is readjusted, but perhaps it could be enough to shake public confidence in the network."

There are other attack vectors (such as certain Sybil attacks, Finney attacks, 51% attacks or attacks on blockchain immutability such as the ETH hardfork proposal in response to the recent attack on the DAO) that could have a far greater impact on public confidence than a temporary difficulty adjustment.

If the attacker could generate enough hash rate to engage in a double spending attack, that would also have a much larger impact than changing the difficulty as you describe.


Is a cloud mining subscription worth it?

Keep in mind, at current prices it would take a very long time to get your initial investment back with cloud mining. There have been many reports of cloud mining to be a ponzi pyramid scheme as they have the advantage of "time" on their side. They are basically paying you back what you paid them slowly.

However, if the price of BTC does rise significantly you can make a profit doing cloud mining. You are better off using the $150 to buy $150 worth of btc and holding that vs mining it via the cloud. You would instantly get the BTC to USD value vs waiting.

My advice if you want to get into mining as a "hobby" just get a usb miner you can find on ebay. Or just mine with your computer and join a pool with one of the other profitable coins found here: http://www.coinwarz.com -- bitcoin mining is a losing battle for the soloist.


Wallet management now that accounts are deprecated?

If you are using more than one wallet, the wallet is selected by sending the RPC requests to <host:port>/wallet/<wallet_name>.


Is it any open source Bitcoin exchange available

Justcoin uses snow which is open sorce. I don't know if you are asking about Justcoin or Snow, either way, any of those two should be the answer to your question.


Wallet advice for users without technical knowledge

When you register to LocalBitcoins you get a free web bitcoin wallet. You can access this with a web browser and protect it with secure paper codes log in.

Also the site allows you to buy bitcoins with cash, so you get two birds with one stone.


If two parties submit a conflicting transaction between each other, how does the network decide which one is correct?

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

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

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


If you have two chains of same length and you add your block to one chain while n/w selects the other

That block and the transactions in that block will not be accepted as confirmed by the network.

Few things can happen with these transactions though:

some or all of these transactions are possibly included in the other chain
the transactions that are not included in other chain are returned to the pool of unconfirmed transactions, waiting to be included in some future block
if conflicting transaction is included in other chain than the transaction will be considered invalid (as a double spend) and will be removed from the pool and will not be included in the future


Anyone could teach me more detail about version prefix

The address prefix determines how a wallet will interperet the address. Let's look at an example.

Generate a P2PKH address

Take a public key, e.g. 023cba1f4d12d1ce0bced725373769b2262c6daa97be6a0588cfec8ce1a5f0bd09
Apply HASH160: 3a38d44d6a0c8d0bb84e0232cc632b7e48c72e0e
Prepend the version prefix for P2PKH (0x00): 003a38d44d6a0c8d0bb84e0232cc632b7e48c72e0e
Base58Check encode it: 16JrGhLx5bcBSA34kew9V6Mufa4aXhFe9X

See How to Generate a Bitcoin Address — Step by Step for command line steps.

Prefixes

Bitcoin has 2 main address prefixes (mainnet):

P2PKH (Pay to Public Key Hash): 1
e.g.: 17VZNX1SN5NtKa8UQFxwQbFeFc3iqRYhem

P2SH (Pay to Script Hash): 3
e.g.: 3EktnHQD7RiAE6uzMj2ZifT9YgRrkSgzQX

Addresses are just representations of the information necessary (scriptPubKey) to create a transaction output, which is part of the transaction and which is validated and stored on the network. It is only used by wallet application software, addresses are not stored on the Blockchain in this format.

The wallet will determine, based on the address prefix, when it is decoded, how to construct this scriptPubkey. For P2PKH this would be in this form:

OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

Where you will notice, the only info it needs is the pubKeyHash which is contained in the decoded address (step 2 above). However, the format for a P2SH scriptPubkey is OP_HASH160 <scriptHash> OP_EQUAL. If you used the wrong prefix, the wallet would create the wrong script and a tx will most likely burn those coins because no one will be able to guess keys/scripts that will successfully satisfy the scriptPubkey.


Detection of double spend in Bitcoin for aged transactions

The Unspent Transaction Output (UTXO) set only includes valid transaction outputs that have not been spent yet.  Once a TXO is used, it is removed from the UTXO set. So, to check if an output exists and is spendable, you see whether it is in the UTXO set.
This actually makes discovering a double-spend attempt of "aged transactions" much easier than finding double-spend attempts in unconfirmed transactions.
A majority attack is not only theoretical, unless you deem someone acquiring 51% of the hashing power a theoretical possibility. But it's really expensive and would probably disintegrate Bitcoin value, so one could argue that it is unlikely to happen.
It puts the risk of reversal below 0.1% with an attacker that has 10% of the hashing power. Why is 6 the number of confirms that is considered secure?


When mining, all my shares are rejected. Why am I not getting any accepted shares?

My guess is that you did not launch cgminer with the --scrypt option.  This is required to mine Litecoin, Dogecoin or any other scrypt coin. When mining scrypt coins that card should deliver ~100 Kh/s in your screen shot it shows Mh/s which would indicate that you are using SHA256 which is for Bitcoin.


Reason for Mininig a block without transaction

Generally, if you'd like to know why a miner mined an empty block, you would have to ask them. They could do so for any reason, really.

For a more specific example of a technical example of why a miner may mine an empty block:

As a miner, you'll want to include transactions that pay fees in your blocks, in order to maximize your profits when a valid block is found.

But also, you need to ensure you are always working on valid blocks, because any time spent mining on what may be an invalid block is likely just a waste of your resources.

With this in mind, consider what happens when you hear about a new block on the network. You can validate the header of the block quite quickly, and begin mining on it, in order to not waste resources mining at the height of (chaintip - 1). The catch is that downloading and validating every transaction in the block takes a tiny bit of time, and until that validation is finished, you will not have a clear picture of which transactions are included, and not. So until you have finished validating the new block, the safest play is to begin mining an empty block on the new chaintip. Otherwise if you include an already-confirmed transaction, your block will be invalid! Once your node has a clear picture of which transactions were included in the new block, you can resume mining on a full block, in order to maximize profits.

In reality, the time between hearing about a new block, and updating your mempool accordingly is quite small, but nonetheless on occasion a block is found during this time.

I do not know if that is what happened with this block, but it serves as an example of a technical reason why an empty block may be published to the network.


Which crypto currencies can merge mine with Bitcoin?

Being able to merge mine with another cryptocurrency recquire that both chain use the same hashing algorithm, sha256 in our case, so in theory all those crypto could do it https://en.bitcoinwiki.org/wiki/List_of_SHA-256_crypto_currencies

The most famous currently merge mining being Dogecoin with its parent blockchain Litecoin both using the same algorithm

You can read more here: https://medium.com/altcoin-magazine/merged-mining-how-dual-mining-of-cryptocurrencies-works-98323ea57529


How often do I need to backup my Copay wallet? Is a new backup after every transaction necessary?

As long as you did not import any additional private keys manually, you do not need to make a new backup every time. Those 12 words can be used to restore all addresses in your account, past, present, and future.

If you imported any additional keys manually, you will need to make a backup every time you import a key, since they are not linked to the 12 words.


How does a miner get selected in Proof Of Stake?

The minting algorithm for staking is different for various coins; for example, it is different in BlackCoin from Cardano.

There are several approaches to staking, but most of them are susceptible to "grinding attacks" and almost none of them are proven secure against every attack (only argued secure intuitively by showing that certain specific attacks do not work).

To give a concrete answer to your question, I will describe a specific case of a proof-of-stake protocol which is proven secure: the Ouroboros Praos protocol.

In the Praos protocol, you can imagine each satoshi corresponds to a public/private key pair. The Praos protocol for staking works as follows: If you are an honest staker, you look at the current date and time and round it to the nearest second (the time unit you round it to is configurable in general and corresponds to the synchronous "slots" of the protocol). Say, for example, that you get d = "2018-07-01 00:19:24". You take that date and time as input, and you sign it with your private key corresponding to your satoshi, obtaining a signature s. You then compare that signature against the difficulty target T to see if s <= T, similar to how bitcoin compares block hashes against the difficulty. If it is, then you have been "elected leader" and you are allowed to generate a block. You first generate the block contents x which consist of the transactions in your mempool as well as a pointer to the previous block. You then sign x using your public key, and produce another signature s'. You then broadcast to the network your signature s illustrating that you have been elected; the current date and time d for election confirmation; the confirmed transactions x which also include the reference to the previous block; and your signature over the block contents s'. The tuple (s, d, x, s') is the block.

Now, other validators can check that you are the rightfully elected leader. They check that s is a signature for d, that s' is a signature for x, that x contains valid transactions and points to the tip of a previous blockchain (with an older timestamp and non-conflicting transactions). Finally they must verify that you meet the target: s must be below T.

This is quite a simple protocol, but, perhaps surprisingly, it can be proven secure. This is what makes it elegant. It's also quite similar to how bitcoin generates blocks. If you are intrigued about why this protocol is secure, I encourage you to read the paper.

A few details:

It is possible for bad actors to generate multiple block contents for the same datetime that they have been elected leader. This doesn't cause a problem because honest parties will only generate blocks committing to one older block, thereby breaking ties.
It's possible that two honest parties generate a block at the same time. This is not a problem and can also happen in bitcoin. Such ties will be resolved, as long as the protocol parameters are tweaked to not allow blocks to occur very often among slots (the exact parameters are specified in the paper)
I said above that s is a "signature" on the current time d, but a technical point is that it's not a signature but actually what we call a VRF - Verifiable Random Function. This is like a signature, except it has the assurance that the output behaves like a random output (such as a perfect hash behaving like a "random oracle").


WARNING: abnormally high number of blocks generated

Luke-Jr commented on this error here: https://www.reddit.com/r/Bitcoin/comments/3ydwg2/warning_abnormally_high_number_of_blocks/#oo

  What this means:

  48 blocks were found within the last 4 hours. The average is
  "supposed" to be 1 block every 10 minutes, or 24 blocks over a 4 hour
  window. Normally, however, blocks are found at random intervals, and
  quite often faster than every 10 minutes due to miners continually
  upgrading or expanding their hardware. In this case, the average has
  reached as low as 5 minutes per block, which triggers the warning.

  If the network hashrate was not increasing, this event should occur
  only once every 50 years. To happen on average, persistently, the
  network would need to double its hashrate within 1 week, and even then
  the warning would only last part of that 1 week. So this is a pretty
  strange thing to happen when Bitcoin is only 6 years old - but not
  impossible either.

  Update: During the 4 hours after this posting, block average seems to have been normal, so I am thinking it is probably just an anomaly.
  (Of course, I can't prove there isn't a new miner that has just gone
  dark or mining a forked chain either, so continue to monitor and make
  your own decisions as to risk.)

  Why is this a warning?

  It's possible that a new mining chip has just been put online that can
  hash much faster than the rest of the network, and that miner is now
  near-doubling the network hashrate or worse. They could have over 51%,
  and might be performing an attack we can't know about yet. So you may
  wish to wait for more blocks than usual before considering high-value
  transactions confirmed, but unless this short block average continues
  on for another few hours, this risk seems unlikely IMO.

  Has the blockchain forked?

  No, this warning does not indicate that.

  Will the warning go away on its own?

  Bitcoin Core will continue re-issuing the warning every day until the
  condition (>=2x more blocks) ceases. When it stops issuing the
  warning, however, the message will remain in the status bar (or RPC
  "errors") until the node is restarted.

Edit: Note that although the gist of the explanation above seems to be correct, the exact number of "once every 50 years" seems to be incorrect (bug in bitcoind code) and is probably more like once every 4 years. Details are in the replies to the above Reddit post.


As far as I know, you heard wrong.  I don't think Bitcoin Core supports sending coins when the wallet is not synchronized.  It needs an up-to-date copy of all the transactions on the network, so that it can be sure of spending coins that have not already been spent.  (Such a transaction would be rejected by the network, but it would lead to confusion on your end, and could also result in other nodes on the network refusing to relay your other legitimate transactions.)

You can either wait to synchronize (note that you are downloading about 60 GB of data) or see Cannot access my bitcoins because my wallet is still synchronising. What can I do to spend them immediately?


How do I retrieve my backed up wallet to Bitcoin Core?

Restoring a wallet on a fresh machine:

Start Bitcoin-Core (daemon or Qt), shut it down after it has started up (you only do that to create the necessary data directory)
Replace wallet.dat with your backed-up wallet.dat (see https://en.bitcoin.it/wiki/Data_directory if you can't find the data dir)
Startup Bitcoin-Core, wait until your node is in sync (can take a couple of hours/days)

If you have created the wallet with Bitcoin-Core >= 0.14 (HD Wallet).

2a. Startup Bitcoin-Core (Qt/core), call getnewaddress 100-10000 times (depending on how many addresses you have created)
(This hopefully will go away in Core 0.15)


Which server(s) determine the difficulty and issue coins

Being a decentralised consensus, with all nodes aware of all the rules and all acting in lock step, there needs to be no centralised controller for anything. Every participant using Bitcoin is responsible for coming to their own conclusion about the state of the network, making sure every piece of data is correctly formed and executed according to the consensus rules they are aware of. Should everything be working correctly, the state they come to will match that of their peers without ever having to consult an authority.


What is the best way to facilitate bitcoin transfers between users of mobile and web applications?

If the service controls the private keys (i.e. they are holding Bitcoin for their users), then they can maintain an internal database with each users balance and just update that database. The Bitcoin is only sent when users wish to transact with people who are not using that service.

If the private keys are held by the user, then the most efficient thing to do would be to have the users transact directly with each other. This reduces transaction fees.


Is there a JSON-RPC method for retrieving all transactions for a given address?

This would be nice but, no, there isn't a way to do this.  The simplest way to accumulate this information is to call listtransactions or listunspent for a list of transactions in your account.

After receiving the list, filter for the needed information.  It is worth mentioning the listunspent RPC call.  This can cut down on a lot of returned data if you are only interested in the incoming transactions that make up your current balance.


How To Lower The Disk Space Needed For Full Blockchain?

No, there isn't any straightforward way to reduce the disk space requirement.  The block chain is the size that it is.

There are various ways proposed for bitcoind to use less disk space (see diskspace), but as far as I know, none of them have yet been added to the standard distribution.


Generating Bitcoin address from private key in browser console

If JavaScript is your language of choice you might be interested in bcoin - the bitcoin full node implementation and modular library written in JS. It's designed for use in nodejs environments but can be compiled for the browser as well.

This guide in particular walks you through the process: https://bcoin.io/guides/webapp.html

Please note that web browsers are insecure environments for cryptography and especially cryptocurrency, this guide is based around public keys and testnet addresses to avoid any real risk. If you try to manage private keys in a browser's JS environment you need to be extremely careful (use an offline computer if possible, no "chrome extensions" etc)


Is it true that colored coins or digital assets (counterparty / ethereum / nxt assets / etc.) have an issue of paying fees?

I noticed that even if I created an account for my customers, they have no way of sending that token back to me when they wish to redeem it as these platforms require their transaction fees be paid in their native currency.

That's kind of true for Counterparty. The transaction fees are paid only in Bitcoin (which is a native currency of Counterparty), but not in Counterparty (XCP) which is the other native currency.
If holders want to redeem their token(s) for a good or service, they only need to pay a small transaction fee (that goes to bitcoin miners) which is expected.

I wouldn't say other systems that do require their own currency for this are flawed, it's how they decided to do things, as karask noted. Counterparty's approach emphasizes the use of BTC while XCP have been only where necessary (at least that's been the case so far).


Calculate block hash is different in regtest?

The nonce needs to be 8 hex digits but printf %x only generates the minimum digits needed for the value, which for 0 is only 1 digit. (The same is true of other numeric conversions %d %i %u %o also.) You need to use %08x to force an 8-hexit value:
ver=$(printf 20000000 | tac -rs ..)
prev=$(printf 4776b1ccad27e2de9ccbdc5bf4ad4d972a89e27a020db1f7b59abb857d77f3be | tac -rs .. )
mkl=$(printf 23b4600b467f18ef0ec18bd73a9b921077486cf67c44c912de114888db184bf9 | tac -rs .. )
time=$(printf %x 1599147354 | tac -rs .. )
#should be %08x if any timestamp can be before mid-1978
bits=$(printf 207fffff | tac -rs .. )
nonce=$(printf %08x 0 | tac -rs .. )
printf $ver$prev$mkl$time$bits$nonce | xxd -r -p | openssl sha256 -binary |
 openssl sha256 | awk '{print $2}' | tac -rs..

-->
4221d8b10b0a7eb5e050337c76819abf71113f17e266e88cb12df4bf5ce24b55

Other changes:

most of your items didn't even have a newline, and for those that did it is discarded by the tac -rs.., and so none of them need |tr -d '\n' -- although for consistency I removed the \n in some printf formats, and changed the echo (which adds newline by default) to printf (which doesn't). (And even if the/some/any items did contain newline, if you doublequote the final printf "$ver...$nonce" so they get treated as data and not wordsplits, the xxd -r -p will discard them as if they weren't there at all.)

I used the newer syntax $( ) for process substitution instead of the older backticks (which I can't show in Stack markdown!) because in many cases it has advantages, although not here specifically, and I like to be consistent. (There are dozens of Qs about this on other Stacks.)

I used openssl instead of sha256sum because I have it on my systems and it's a little easier.

This wasn't a problem on mainnet and testnet, at least for most blocks, because they have difficulty high enough that the nonce value will be at least 29 bits most of the time.


Would it be theoretically possible to make a Cryptocurrency in a scripting language like PHP, Python, or Ruby?

Yes, it is possible. A cryptocurrency is essentially a set of rules and network protocols that nodes can use to talk to one another to implement those rules. The reference implementation Bitcoin-Qt is implemented in C++, but there are other implementations (eg. Java).

The tricky part about implementing a client for an existing cryptocurrency in another programming language is that you must be careful to implement the rules in exactly the same way as all other implementations. If there are any changes (even such as fixing bugs present in the original) then the blockchain may fork and your client would need a patch to continue participating.

If you're creating a new cryptocurrency from scratch, of course you don't need to be concerned with replicating bugs in an existing client. However, you run the risk of introducing a whole new set of bugs.


Extremely slow syncing speed while starting bitcoin-qt on HDD

When you say smarter, you mean by not storing chainstate on a disposable drive? Unless ImDisk stores to HDD on shutdown.

Try this answer.


Verifying a bitcoin Signature and what is the transaction data that is signed?

What you described only works for transactions with one input and one output.

In general, what you do is you take the transaction that you want to verify, remove the scriptSigs from all of the inputs, and for the particular input you want, you place in the scriptSig the scriptPubKey (prepended by its length) of the output that input spends. If the output that was spent is P2SH, then you put the redeemScript instead of the scriptPubKey. Then you put the sighash type at the end of the modified transaction.

Once you have that message, you need to hash it with SHA256. Most cryptographic libraries take a message and hash it once. However in Bitcoin, the message is actually hashed twice. So to verify a signature in Bitcoin with a general purpose cryptography library, you need to hash the message first, and then allow the library to hash it again when it verifies.

Lastly, the message is different for inputs that spend Segwit outputs. This message is defined in BIP 143.


Pending BTC transaction for more than 30 hours

You should take a look at this: Why is my transaction not getting confirmed and what can I do about it?

It would seem you did not attach enough of the fee. How many sat/byte does your transaction show?


Why is BIP32 not simply PublicKey multiplication?

The purpose of BIP32 is to provide a standard for hierarchical deterministic (HD) key derivation. BIP32 allows users to back up the initial secret of their wallet, and then reconstitute all derived addresses from this initial backup in the future.
The mechanism you describe is essentially an application of an Elliptic Curve Diffie-Hellman (ECDH) to establish a shared secret. It relies on foreign input and therefore (as described) does not fulfill this backup function—each new address requires the sender's secret to be retained for the address to be recoverable in the future.
A similar approach is in use for  Monero's Stealth Addresses. AFAIU, Monero solved the backup concern by using OP_RETURN outputs on the Monero blockchain to establish the shared secret. This ensures that the recipient key is sufficient to rediscover the shared secrets when resyncing the blockchain. This comes with some trade-offs: finding all recipient keys is much slower (since the blockchain has to be parsed) instead of something that can be done with local data even on offline devices and each address creation adds more data to the blockchain.


I used an old wallet address. Is my coin lost?

If the address a wallet shows changes, that's OK. When you look at a wallet's receiving address at different times, unless it's a poorly designed wallet, it'll show different addresses. To increase anonymity, addresses shouldn't be reused, and therefore your wallet has multiple addresses. Don't worry, they'll come sooner or later (but make sure to be using the same Electrum wallet file).


Easy steps :
1.  Start up Electrum where your Bitcoin is.
2.  Save the Wallet Private Key somewhere safe.
3.  Move your Bitcoin to your Trezor or Ledger (you really should have a hardware cold wallet).
4.  Now install ElectronCash from electroncash.org (it's fine on same PC)
5.  Start up ElectronCash & login with SAME password as your Electrum.
6.  You'll see the Bitcoin Cash sitting there.
7.  Transfer Bitcoin Cash into Ledger or Trezor (using the Beta Trezor Wallet here : https://beta-wallet.trezor.io/)
8.  You're all set.

Cheers!


Where can i download latest stable bitcoin-core src files?

As you can see here the latest version is now the more stable version. As the most recent changes are for bug fixes, etc.

  This is a new minor version release, including various bugfixes and
  performance improvements, as well as updated translations.

If you download a previous version this version may contain those fixed bugs.


Is there a way to identify exchanges in the blockchain?

To expand a bit on the above answer, blockchain.info provides information about several APis and exchanges here:
https://blockchain.info/api/3rd_party_apis


The sole and only reason to buy there, is because you already have fiat stuck there and you want to get it out ASAP.

About selling, if you are optimist you can say that some people value that the risk of Mt.Gox defaulting plus the time they have to wait without their money is less than the price difference with the other exchanges.

If you are pessimist, you could say instead that they are simply stupid and do random things without really thinking about it.

Still, since there's no reason at all to send fiat there to buy BTC, yes, I agree it makes no sense for Mt.Gox to be still in business.


What are conflicting transactions? Does it mean BTC lost permanently?

Conflicting transactions are simply two or more transactions that spent the same UTXO in its inputs (i.e. doublespending).

The only remedy is to not treat a transaction as successful until it has a number of confirmation that satisfies you.

It is impossible to recover from a successful doublespend attack should the conflicting transaction be included in the blockchain.


Could it be that the outputs depicted in listfunds do not have yet enough confirmations? Maybe you got them after you closed a channel and c-lightning did not allow you to use them right away. Could you check again?


What are some compelling reasons to use Electrum?

Why Electrum?

Instant on: Your client does not download the blockchain, it uses a remote server.
Forgiving: Your wallet can be recovered from a secret seed.
Safe: Private keys are never sent to the server. Information sent by the server is verified using SPV
No downtimes: Several public servers are available, you can switch instantly.
Ubiquitous: You can use the same wallet on different computers, it will auto-synchronize.
Open: You can export your private keys into other Bitcoin clients.
Tested and audited: Electrum is open source and was first released in November 2011.

http://electrum.org/tutorials.html#why-electrum


Where can one find the best explanation of the blockchain?

Since nobody answered and I continued my research I'll post something I found online that helped me understand the blockchain.

http://blockchaindemo.io - This website visually simulates a simple blockchain to explain how it works. Pretty well made in my opinion based on comparison with other explanations I found online.

Otherwise here is the white paper from Bitcoin's creator, Satoshi Nakamoto, even if outdated, it can help understand some of the original concepts:
https://bitcoin.org/bitcoin.pdf


How to derive segwit addresses from an extended public key?

Zpub's would be needed for native segwit addresses. And current bitcoinj master branch does not support Zpub, it support xpub and xpub's would always derive to
legacy addresses. Give a try to Segwit branch that may helps. Also take a look at this


Cgminer not working on windows with Nvidia graphics card

If you using a Nvidia card you should use cudaMiner since you will get better hash rates for it. https://bitcointalk.org/index.php?topic=167229.0


Bitcoind daemon get received notifications by public address

Instead of polling many addresses every 30 minutes, you probably want to import your addresses into bitcoind, using bitcoin-cli importaddress and then have bitcoind notify you automatically when a new transaction comes in, using the walletnotify option.

See for example: How do I use walletnotify?

There are a lot of details to get right: transactions might never confirm, the transaction ID might change. When bitcoind loses connection to the network, you want your script to be able to handle that. etc.


Streaming API for confirmed transactions?

You can't really "stream" them. Transactions get confirmed once included in a block. So for 10 minutes you would have nothing and then all of a sudden there would be a 1,000+ transactions with a confirmation. If that's what you're looking for you can just use something like https://blockchain.info/block-index/$block_index?format=json and replace $block_index with the latest block. The json will respond with all transaction id's in an array that were included under "tx":

https://blockchain.info/api/blockchain_api

EDIT:
Blockchain.info has all the info you need.
First get the current block height which you can get from https://blockchain.info/stats?format=json

$bcinfo = json_decode(file_get_contents("https://blockchain.info/stats?format=json"), true);
$latestblock = $bcinfo["n_blocks_total"];

Then plug the current block into https://blockchain.info/block-height/$latestblock?format=json

$getblock = json_decode(file_get_contents("https://blockchain.info/block-height/".$latestblock."?format=json"), true);

Then just count the amount for each array and run a for loop to grab each input(from address) and each output(receiver) along with the time.

Here's one I did quickly in PHP: http://phpfiddle.org/lite/code/k16m-r8fh

<?php
$bcinfo = json_decode(file_get_contents("https://blockchain.info/stats?format=json"), true);
$latestblock = $bcinfo["n_blocks_total"];
$getblock = json_decode(file_get_contents("https://blockchain.info/block-height/".$latestblock."?format=json"), true);
$counttxs = count($getblock["blocks"][0]["tx"]);
for($i=0;$i<$counttxs;$i++){
    //tx time
    $timetx = $getblock["blocks"][0]["tx"][$i]["time"];
    $date = date('Y-m-d, H:i:s', $timetx);
    echo $date."
";
    //count inputs
    $countinputs = count($getblock["blocks"][0]["tx"][$i]["inputs"]);
    for($ii=0;$ii<$countinputs;$ii++){
        //get input address
        $addr = $getblock["blocks"][0]["tx"][$i]["inputs"][$ii]["prev_out"]["addr"];
        echo $addr ? "INPUT: ".$addr."
" : "";
    }
    //count outputs
    $countouts = count($getblock["blocks"][0]["tx"][$i]["out"]);
    for($iii=0;$iii<$countouts;$iii++){
        //get output address
        $outaddr = $getblock["blocks"][0]["tx"][$i]["out"][$iii]["addr"];
        echo $outaddr ? "OUTPUT: ".$outaddr."
" : "";
    }
    echo "

";
}

?>


How to resolve Bitcoin Daemon Warning of last 100 blocks have unexpected version message?

There is no need to resolve anything - some miners create arbitrary versions to attempt to speed up the mining process, as it gives them an additional field in the block block header to alter without having to recalculate the merkle root and other fields.

This is harmless, provided they aren't producing invalid blocks for version 2, in which case the block would be rejected


Is there a connections limit on bitcoind?

By default, bitcoin-core allows up to 125 connections to different peers, 8 of which are outbound. You can therefore, have at most 117 inbound connections.

I think there is no need to handhold bitcoind to control the connection management.

You could try to limit the maximum connections with -maxconnections=<num> to reduce the amount of internet traffic produce by your node.


What is the absolute smallest size of the data (bytes) that a blockchain transaction could possibly be?

Depends on the number of inputs, the types of scripts the inputs are redeeming, the number of outputs, and the type of scripts that the ouputs are paying to.
The absolute minimum for a transaction that might appear on chain is 60 bytes :

02000000
01
  0000000000000000000000000000000000000000000000000000000000000000
  00000000
  00
  fdffffff
01
  0100000000000000
  00
00000000

But this just an academic example.  The input is redeeming a utxo where the script does not require any signatures, and the output scriptpubkey is empty.
You're more likely to find a 191 byte transaction such as :

02000000
00
01
01
  0000000000000000000000000000000000000000000000000000000000000000
  00000000
  00
  fdffffff
01
  0100000000000000
  16
    00 14 ffffffffffffffffffffffffffffffffffffffff
02
  21
    020000000000000000000000000000000000000000000000000000000000000001
  47
    3044022077777777777777777777777777777777777777777777777777777777777777770220555555555555555555555555555555555555555555555555555555555555555501
00000000

Which both redeems a and also pays to a p2wpkh segwit program.
Note that this one doesn't have a change output in it, which most transactions carry.  A second p2wpkh output will be another 32 bytes for a total of 223 bytes.  Still less than your upper bound of 256 bytes.


Is there a standard procedure for refunding Bitcoin transactions?

As of right now, there is not a standard way to return other than to ask the returnee for an address to which the returner can send. You could ask for them to verify the address by signing some text with its private key, however, users of web wallets are at a disadvantage because not all wallets provide this functionality.

It is too onerous to ask for a return address at the time of sale, because a conscientious user would have to create a new address for each sale's return address. Managing these would grow difficult over time.

Issuing store credit with the option to cash it out via a variety of methods is probably worth consideration, as it prioritizes consumer choice. If I'm ordering from a company from which I order frequently (e.g. Amazon) or I know that I'm going to reorder later, I'll take the store credit and save the management time. Otherwise, I'll cash out the bitcoin and find another vendor who can meet my needs.

Update 21 Feb 2014: Bitpay announced today that Bitpay is now supporting BIP70-73 payment protocol, which includes refund addresses.


Okay, I found this information about Copay, one of the few multisig mobile wallets:

Depending on the key derivationStrategy, addresses are derived using BIP44 or BIP45. Wallets created in Copay v1.2 and forward always use BIP44, all previous wallets use BIP45. Also note that since Copay version v1.2, non-multisig wallets use address types Pay-to-PublicKeyHash (P2PKH) while multisig wallets still use Pay-to-ScriptHash (P2SH) (key addressType at the backup):

[...]

BIP45 note: All addresses generated at BWS with BIP45 use the 'shared cosigner index' (2147483647) so Copay address indexes look like: m/45'/2147483647/0/x for main addresses and m/45'/2147483647/1/y for change addresses.
Since version 1.5, Copay uses the root m/48' for hardware multisignature wallets. This was coordinated with Ledger and Trezor teams. While the derivation path format is still similar to BIP44, the root was in order to indicate that these wallets are not discoverable by scanning addresses for funds. Address generation for multisignature wallets requires the other copayers extended public keys.


Can long time taken for confirmations become blocker for bitcoin adopotion?

To answer the question today, It really depends on the confidence level of Bitcoin's image in the business' eyes.  To answer the question for the future, it's very possible that "things" built on top of the Bitcoin network will help solve this problem.  Not necessary reduce the time it takes to get confirmations but instead to minimize the risk of NOT waiting for 6 confirmations.  If you think about it with credit cards, businesses today completely ignore the risk with credit card charge backs and simply ship items as soon as the buyer has paid even though the buyer can issue a charge back days after the purchase.


Consequences to reducing `checkblocks` in console on a node?

checkblocks and checklevel are simply for local sanity. It's just making sure when your node is coming up that things aren't completely crazy, it won't catch malicious alteration or set any flags anywhere. If the checks fail the node won't start up at all and will show nasty error messages. Turning them down in all probability won't have any impact on you, the only downside is that if your node state is left inconsistent the sanity check might not catch it.


ECDSA transaction signing on a smartcard?

Yes, there is Smart Card Wallet project, though there seems to be no clear indication on what stage the project currently is.

There is also hardware wallet by Slush. It's not smart card based, but works pretty much the same way. Also still in development.


BitcoinCore 0.13 HD wallet chain structure

It uses m/0'/0'/i' with i incrementing over time.

The dumpwallet RPC command will produce a text file with all private keys in it, including the BIP32 seed.


is my xPub published when I make a payment? (wallet privacy)

No, the xpub is not published anywhere. Only individual public keys are published and those are permanently stored in the blockchain. There is also no way for someone to figure out the xpub and any related keys given just those public keys.


“Sentinel” is just an interface to an API owned by Samourai Wallet. It therefor leaks the fact that you own the outputs you’re watching are probably offline storage (and links them together into one wallet) when you watched them, and your connection details like your IP address and probable physical location.


How is the target in Bitcoin set? Who does this?

The target is calculated by each node in the network independently.

Bitcoin is a decentralized system, so there is no authority that will set the target. The network is its own authority.

On this network, each participant (node) follows certain rules. These rules are the same for everyone, and govern how the network behaves. They include things such as the block size limit (block weight, in recent times), no double spends allowed (each output may only be spent once), difficulty adjustments to stay as close to a 10 minute block interval as possible (this is the target), and various other rules.

Every 2016 blocks (roughly 2 weeks), each node will look at the last 2016 blocks and calculate the average time spent mining a block. If this value is greater than ten minutes, the difficulty is reduced. If it is faster than ten minutes, the difficulty is increased. This readjustment allows the network to self regulate the mining target.

Since each node follows the same consensus rules, and all blocks are the same for all nodes, they will all arrive at the same difficulty value independently.

If a node were to miscalculate the target (or lie about it), and then produce a block based on their incorrect value, it may be rejected by the rest of the network for failing to meet the target requirements, and all the work invested into mining that block will be lost.


Do extra hop channels in a BOLT#11 invoice need to exist on chain?

What you propose is (theoretically) totally possible but as far as I understand (for a good reason: the short_channel_id would loose its semantics) not implemented.

The problem is as far as I understand that even the construction of private channels are currently implemented with a 2-2 multisig wallet. You could patch your lightning node though so that your private channels could operate on a different payment channel mechanism (or without an actual channel as an what you call it abstract channel)

Let us assume you have such an abstract channel after patching your lightning node:
The sender who creates the payment would use the channels from the invoice to create the onion. In the onion the sender has to use the short_channel_ids that are given from the gossip protocol and from the invoice.

As far as I remember the code the node creating the invoice relies on the fact that the information from the gossip protocol and the invoice is correct and constructs the onion. In particular the existence of a private channel cannot be checked against the gossip store anyway. Also the nodes routing the payment don't know later hops anyway and don't care.

So only your nodes that run private channels who are actually forwarding the payment have to see if they know the channel (and they should if they mess around with the protocol. The channel does not even have to be backed on the blockchain in such a case)

However theoretically the sender could - when creating the onion - check if there is at least an output on the blockchain that is referenced by the short channel id and that the output is at least a 2-2 multisig wallet. However that would only be a a hint that this output belongs to a funding transaction of an actual payment channel. In general payment channels cannot be detected for certain from the blockchain data.

BTW: When I was tinkering about similar ideas I came up with the name virtual payment channels instead of your proposed name abstract payment channels. Meanwhile I believe the best way to construct virtual payment channel is by fetching the htlc of the first node in your private network. This can for example be done with a c-lightning plugin (which does not exist in an open source way) and can be used to scale a farm of lightning nodes for an HA service. ]

I recommend waiting until rendezvous routing from BOLT1.1 is implemented. With Rendezvous routing it will be very easy to construct private channels. You can create an onion with a rendez vous point outside of your private network and as soon as the onion enters your network the first node can catch the htlc and talk with the real recipient over any communication protocol to release the preimage.


How do I send Bitcoin from my cold wallet to a new one?

Funds from a cold wallet need to either be imported or swept (for cybersecurity reasons sweeping is always preferred over importing) into most any hot or warm wallet to then sent to another cold wallet address synthesized from private keys that are usually in either the Wallet Import Format (WIF) or in BIP 38 standard format (is AES encrypted and starts with the letters 6P). Wallet imports or sweeps usually take WIF or BIP 38 input formats that have associated input error checking versus raw hexadecimal that a prone to human input errors like Ethereum.

Electrum is not technically a cold wallet unless the Electrum BIP 39 seed words have never been loaded into an Electrum warm wallet.  An Electrum wallet is warm only if it uses a hardware wallet such as a Trezor, Ledger or Keepkey token generators that have been loaded with BIP 39 seed words. Otherwise, the Electrum wallet is a hot wallet.

Cold wallets need the private keys and associated public addresses generated on a trusted offline computer. Cold wallets can use self contained JavaScript programs, or a standalone binary executable such as Bitcoin-Explorer (bx) running on air gapped computers that can also leverage brainwallets provided the brainwallets input text have sufficient entropy.

To answer your side question, you should be using a HD hardware token generator with Electrum to have warm wallet functionality, or you need to use multiple cold wallets probably using a trusted JavaScript key generator program, not a single cold wallet.


ANXBTC.com / MTGOX v2 API "Authentication"

Michael,

To generate the Rest-Sign header, use the following code (example in PHP):

Rest-Sign function

 function hmac_512($msg, $secret)
        {
        $secret = base64_decode($secret);
        $result = hash_hmac('sha512', $msg, $secret, true);
        return base64_encode($result);
        }

Rest-Sign inputs
$post_data should be an array with a nonce and any relevant API post data, and $api_path should be the portion of the API after https://anxbtc.com/api/2/ that you are calling.

       $post_data_encoded = http_build_query($post_data);
       $msg = $api_path . "\0" . $post_data_encoded;
       $rest_sign = $this->hmac_512($msg, $api_secret);

Regarding your second question, you can run this API from your personal computer or a server.

Hope this helps,

Evan


Litecoinj transaction sent to unknown address

I looked into this by converting the addresses from base 58 to hex. What I got was this:
MD1AYTZnTtGKQToj2LTD7qLsSzrqcdXr9J -> 0x3237fb62589f848d3808f0b9bfe9762edabe150b93f409d315
LaPJ9TfBr6E2MSRa4t1MMhFPQAue4osUn8 -> 0x3037fb62589f848d3808f0b9bfe9762edabe150b93bab51bf3

Notice that the positions from byte 1 to byte 20 are the same: 37fb...0b93.

This is unfortunately bad news and means that the software you are using is bad.

The address that starts with M or 3 in Litecoin are pay-to-script-hash addresses (P2SH) and the software should have created P2SH outputs but it has for some reason instead created pay-to-public-key-hash outputs (P2PKH) as you can see here:

{
          "value": 15149,
          "script": "76a914a64e3a77893db78edfb3ba4abfa2106f84ba80eb88ac",
          "addresses": [
            "LaPJ9TfBr6E2MSRa4t1MMhFPQAue4osUn8"
          ],
          "script_type": "pay-to-pubkey-hash"
        },

The funds you have sent are unfortunately lost and you should stop using this software immediately since it only seems to support P2PKH addresses and not P2SH addresses.

If it is any comfort, you are not the first one to make this mistake.