Assuming the transaction was really made and confirmed (try looking up the transaction id on a site like http://blockchain.info), and the destination address isn't one of yours, then it appears your coins have been stolen.  Unfortunately, there isn't anything you can do about it, from a technical point of view; one of the features of Bitcoin is that transactions cannot be reversed for any reason.  Of course, you can report the theft to the police, but it is probably not likely they will be able to catch the thief or recover your coins.

In order to steal the coins, the thief would have needed access to the private keys stored in your wallet.dat file.  From the information you gave, I can only speculate as to how this might have been done.  Some possibilities:

You have a virus or some other malicious software on your computer.  This software could have sent your encrypted wallet.dat to the thief, and also captured your keystrokes at some time  when you typed the passphrase to decrypt it.  Then the thief would be able to decrypt it as well.
The thief obtained your encrypted wallet.dat (via malicious software on your computer, or getting access to your backup, etc), and your passphrase was not very complex, so they were able to guess it with a brute-force attack (trying a very large number of possible passphrases until they found yours).
The thief is someone with physical access to your computer, and may have seen you type your passphrase.  They could then steal your coins simply by sitting at your computer, entering your passphrase, and sending your coins to their own address.


When does a blockchain fork resolution happen?

Each node will usually resolve and reorganize their local chain as soon as they are made aware of a chain with more work.
If two blocks are mined at block height N, there is a fork. As soon as a single block at height N+1 is mined and broadcasted, any nodes that receive it will keep the block N that the new block builds upon, and orphan the other block as there is now one chain with more work.
This is what makes block withholding attacks possible, as an attack could broadcast several blocks at once, which suddenly present a new, longer, valid chain.


How do Open Source Blockchain companies Stay Competitive?

They can do this because the crypto market can support multiple companies

However, it does not happen many times anyway, due to the following reasons:

Just "forking" is not as easy as it sounds; you also need:
Infrastructure & dev-ops
Support
A legal entity
There might be a lack of skilled people, which get hired by the companies instead of starting their own projects
Response time: why would I use a fork, if the project it was forked from is the original one, with faster bugfixes?

In addition, some companies only open-source a limited portion of their code that does not let you run it, which is pointless, the way I see it.


When to worry about 1-confirmation payments

The thing to consider is, "what does the attacker have to give up in order to attack me?"  If the cost of that thing is less than the reward from a successful attack, then attacking is rational from a purely economic standpoint.  (Obviously, attacking someone comes with a non-economic moral cost.)

A miner who controls more than half of the network hash rate, and expects to maintain that control indefinitely, will lose nothing by attacking you.  This is the so-called 51-percent attack.

A miner who controls less than half of the hash rate will likely lose a chance at a certain amount of income, but how much depends on how close they get to half of the network hash rate.  I created the following image a few months ago to illustrate this:

If you look at the BlockChain.info mining pools chart, you see there are several which can make affordable attacks against both once-confirmed and six-confirmed transactions.  I suspect all that prevents them from doing so is their reputation in the community.

The others factor are:

How much can the attacker get from you in a single attack?  For example, can they order multiple 50 BTC items at the same time?
How easily can the attacker profit from an attack against you?  For example, how much can they resell those 50 BTC items for?  Most attackers aren't going to want 20 digital copies of Plan 9 From Outer Space, but they'd love 20 times 50 BTC worth of another crypto currency.

Unfortunately, this factors don't apply just to you: they apply to everyone the attacker can attack at the same time.  For example, if they can make 10 BTC by ripping you off and 190 BTC by ripping other people off, then an attack which costs less than 200 BTC is economically worth it.  This means you can't fully analyze your risk by looking just at your items.

Waiting for more confirmations will always increase your security substantially, and I expect there are few things is this world worth 50 BTC that people can't wait an hour or two for them to arrive.  (But hey, maybe I'm just not rich enough to be spending $20,000 USD on a regular basis.)

If this is all very depressing, I'm sorry.  Long term, the goal of the community will be to decrease miner centralization.  If no miner or mining pool controls more than about 1% of the network hash rate, attacks against once-confirmed transactions become both expensive and unpredictable, and attacks against six-confirmed transactions become practically impossible.

Footnote: Math

In the image above, the average cost of a successful attack here is

r * h * b / p(h,b) - r * (b-1)

Where r is the block reward (25 BTC), h is the percentage of network
hash rate, b is the number of blocks to create (confirmations plus
one), and p() is Satoshi's probability calculator from bitcoin.pdf page
7. r * h * b is the average value of work used per attempt; p(h,b) is
the probability of success per attempt; r * (b-1) is the block reward
the attacker would've received if they mined honestly.

For reference, the time (average number of blocks elapsed) an attack takes is simply

1 / p(h,b)


Why can't I spend my bitcoins when they have been fully confirmed?

I don't use MultiBit, but just checked its source code to see what the message you quoted means.

It turns out that the message is shown when the amount you're asking to send plus fees is less than the "available balance", which is defined as:

  Balance that can be safely used to create new spends. This is all confirmed unspent outputs minus the ones spent by pending transactions, but not including the outputs of those pending transactions.

The source code also says:

  Consider a real-world example: you buy a snack costing $5 but you only have a $10 bill. At the start you have $10 viewed from every possible angle. After you order the snack you hand over your $10 bill. From the perspective of your wallet you have zero dollars (AVAILABLE). But you know in a few seconds the shopkeeper will give you back $5 change so most people in practice would say they have $5 (ESTIMATED).

So my guess would be that your balance includes some unconfirmed change from your previous transaction(s), and that simply waiting for that change to confirm will solve your problem.

In other words MultiBit doesn't allow you to spend the $5 change until you have it back from the shopkeeper.  Note that the Satoshi client does allow you to spend unconfirmed change outputs.


While creating new crypto using fork need to generate smart contract?

Cryptocurrency(a new blockchain) is deployed by distributing/convincing people to use your node software. The genesis block can be considered a type of smart contract. Clever marketing has hijacked the "smart contracts" buzzword to mean hosting your code on a network that works exactly like AWS but with worse performance and higher price.
This is not an ethereum forum and nor are ethereum contracts really "smart". They rather dumbly execute the stored logic in a centralised manner. The beauty of a true smart contract is that it can be written in any language and it auto-deploys itself because it arose from a use-case. Eg, multisig


why is transaction history from genesis to date necessary to store on the blockchain to prevent double spending?

why is there a need to track transactions? Why cant we just track the balance in every account?

Well, for a start, the Bitcoin protocol has no concept of accounts or balances.
To change Bitcoin to work on the basis of balances would throw up some interesting problems

how does a node calculate the balance in the first place?
how do we relate transactions to balances?
how are accounts created, managed and authenticated in a global trustless peer to peer system?

Any cryptocurrency that addresses these is clearly so vastly different to Bitcoin that it couldn't reasonably be named Bitcoin.

A bitcoin node doesn't need to store the whole transaction history. This is why there are pruning nodes. However a pruning node needs to have processed all transactions so that it can discard transactions whose outputs have all been subsequently spent. In your hypothetical account-based cryptocurrency a node would also have to process all transactions to calculate the correct balance. The main alternative is to trust some other nodes run by other people and hope that they are honest.

Double spending also poses some interesting problems for an account based peer-to-peer cryptocurrency. A global network of nodes can't guarantee that all nodes see the same blocks or transactions in the same order. There has to be a deterministic method of reconciling differences that are guaranteed to converge on a common outcome.
If one node receives first a transaction that reduces some other person's account (e.g. A gives 4 of their 5 BTC to B) and a different node first receives a conflicting transaction (e.g. A gives 3 of their 5 BTC to C) , the first node presumably rejects the A-C transaction (insufficient balance) while the second node rejects the A-B transaction for the same reason.

Storing a list of all transactions with unspent outputs may seem like a chore. But having each node storing and continuously updating at least one account balance for each of 7 billion people might also be a challenge.

There will be cryptocurrencies that address these issues but those are not Bitcoin. So it isn't really sensible to ask whether Bitcoin could do this. If it did it wouldn't be Bitcoin.


So, this smart contract, with its setup today, would it be possible to make it use the RSK network instead of Ethereum?

Yes. https://developers.rsk.co/tutorials/ethereum-devs/port-ethereum-dapps/
RSK Bridge can also be helpful for users to swap tokens: https://developers.rsk.co/tools/tokenbridge/

If yes, what could be the pros/cons (eg. cheaper/faster transactions) and whether it would make sense to do the transition?

There are lot of differences. You can read this medium post which explains few technical differences and development of Rootstock: https://medium.com/iovlabs-innovation-stories/similarities-and-differences-between-rsk-and-ethereum-e480655eff37
Scaling is the biggest advantage in using a Bitcoin Sidechain for such experiments.
Rootstock resources: https://github.com/john-light/RSK


Are BTC Private Keys evenly distributed in 256bit space?

The random number generators that generate private keys should follow a uniform distribution as this is the distribution that maximizes entropy.

As the private keys that are used are not known we can't measure if the keys in use have been statistically speaking distributed uniformly.


The rate (of exchange) is just the price for your order.

According to their documentation, when you create a buy or sell order, you need to specify the market, the quantity, and the rate. The market specifies the currency pair. For example the market BTC-XRP specifies BTC as the "quote currency" and XRP as the "base currency". The quantity specifies how much of the base currency you want to exchange. The rate specifies the quote price at which you want to exchange.


I Found old wallet but there is new mined transactions but unconfirmed

Those are orphaned blocks, it means while you were mining that block someone else mined it faster than you, thus you do not get the credit for those mined blocks.


Are time, timereceived and blocktime in UTC?

All timestamps are in UNIX format, that is: the number of seconds since januari 1st 1970, 0:00 UTC.


I think this works great if you want to confirm a shipping address in order to make sure the person who paid is aware of where the shipment goes (if you want to accept the fact that everyone in the network can see your shipping address).

You can embed an shipping address into the blockchain using OP_RETURN or something similar, but a much simpler way is to sign your shipping address using your bitcoin address, and send that via a private channel.

  But does that work for a notary use case, for example? How can you know, using Bitcoin message signing, that the company "AMCE Ltd." is actually behind the address "XYZ"? Is this only possible if you actually call AMCE Ltd. or email them for them to sign a message for you? What if you can not trust the communication channel (e.g. message gets intercepted by a potential attacker).

You need some sort of trusted communication channel to send an address. If you do not have one, most methods of starting one (like SSL) involve some kind of trusted third party.

But that's not unique to Bitcoin, of course. There's a huge problem with fake, nonexistant businesses on Google Maps. In order to create a naming system that resists tampering and fraud, you must have 1) some system to detect and remove fakes, and that system must work consistently and 2) some way of punishing people who create fakes.

  Why would you need a distributed ledger anyways if you already trust the middleman?

One reason is that there are different kinds of trust in play. For example, I trust Comodo to verify SSL certificates before signing them, but I don't trust them to hold any of my personal data. I trust my bank to route payments to the correct recipient, but I don't trust them to not charge me an inactivity fee.


What are the differences between Bitcoin and Libra?

This question might be considered too broad and too opinion based according to the rules of this forum. However, tackling it from a technical standpoint based on facts rather than opinions might be on-topic and I will try my best to deep dive on that. Let's try to hit the five most important aspects that people might be interested in: security, decentralization, scalability, governance and privacy.

Security

The most important security consideration that needs to be given to a digital currency is preventing double spend (spending the same coin more than once), fraudulent transactions (spending what is not yours) or creating money out of thin air. Bitcoin prevents all three of this by storing its transactions in a blockchain that are almost immutable after
certain blocks due to the proof of work (PoW) algorithm. Supply is capped, coins can only be generated by the mining process, transactions are governed by cryptography and coins can only be spent by providing a valid signature. The PoW is also an important security consideration for preventing double spending that is sometimes overlooked by many. It signifies the inherent cost involved to modify blocks and also means that the malicious party amasses more mining power than rest of the network combined. After a certain number of blocks the transactions becomes extremely difficult to alter which means the they are immutable.

Libra operates on LibraBFT consensus, a class of the classical Byzantine Fault Tolerance (BFT) model. A model that operates on BFT can be trusted as long as there are at least 2/3rd honest nodes operating the network. So 33% of the nodes can come together and launch a malicious attack. They also need not spend money in terms of hash power like PoW in order to do that. So collusion could be an easier possibility with BFT models.

Decentralization

Bitcoin is one of the largest distributed network on this planet. Entire data is public to all the participants of the network and there are no gatekeepers or requirements to become part of the Bitcoin network. Every full node operating the bitcoin software validates all transactions in its entirety from the genesis block. When miners mine a block, every full node ensures that the block is generated according to the consensus protocol and rejects blocks which do not meet them. This ensures full decentralization, and ensures that power is not concentrated in the hands of the miners as claimed by many ignorant people. Try reading about the block scaling debate of 2017 and you will understand how the community played a major role in governing the network.

In Libra's current implementation, 'trusted' validator nodes are core to the security model. The Libra blockchain will be open to the public to read, but closed for writes.
This means that hard power is centralized around these few entities and the protocol itself depends on these entities to validate the protocol. This means the protocol depends on whatever they decide it is. These entities can freeze your coins, take your coins, issue new coins, or really whatever they want - the sky is the limit. Libra claims that in the future it might move to a permissionless model, but it is highly doubtful that such a scheme can succeed.

Scalability

Bitcoin was designed for transactions to be as secure as possible and that comes at a cost of sacrificing scalability for security and decentralization. However, the current Lightning Network implementation solves this issue and ensure that bitcoins can be transferred almost as fast as you can create and transmit them without sacrificing on the underlying security mechanisms.

Libra being 'permissioned' inherently has higher scalability. It is no different than doing a paypal transaction or spending via your credit card.

Governance

Trustlessness is the most important characteristics of Bitcoin. Bitcoin governance  emerges from users through the software they run on their computers. Nobody calls the shots. The entire Bitcoin code is public and you can go and verify the entire program yourself. The governance components also involve the decentralization and the security considerations that have been mentioned above. Also, Bitcoin developers have no special powers to make users switch to a new network. Even if the Bitcoin Core developers were to release a new version of the software to create such a new network, users of the older software implementations could simply ignore the update and continue using the existing protocol as they please. That is the power of decentralization.

Libra being a stable coin, one needs to ensure that for every coin that issued, balances of fiat currency is maintained. So there involves trust in the organization to keep the balance in fiat currency, trust in the fiat currency itself and the instruments (or banks) in which this balance is actually kept. Also, given the centralization involved in Libra, the sky is the limit in terms of what the 'trusted' validators think the protocol should be. Most of these validators are Fortune 500 companies, and they are not there for charity. Their main goal/incentive lies in improving shareholder value and one might now be incorrect to think they can potentially go to any extent to achieve that based on historical precedence.

Privacy

Bitcoin provides pseudo-anonymity. Although, many exchanges ask for KYC while buying bitcoins, the protocol itself does not need any verification. Even after buying from an exchange, you can do a CoinJoin transaction to hide your identity. Preventing address re-use and keeping keys under one's control will then ensure your privacy is protected.

At least from what I have read, the resellers of Libra will have to collect identifying data from users under current FATF recommendation if the amounts being transferred exceed $1,000. This data has to be managed and transmitted out of band from the blockchain. A lot of internet companies have come under flack recently for in-apt data sharing practices. If one were to draw a parallel, this data can be overwhelmingly be used for many other business enhancing practices as well.


Has there been any cases of bitcoin being stolen without getting access to the owners private key?

Yes, for example, a company named Bitcoins Reserve lost 100 BTC when an attacker hijacked the CEO's email address and sent instructions to the CTO requesting a client withdrawal while instead providing their own Bitcoin address.

This and other incidents are described here: https://bitcoinmagazine.com/articles/cautionary-tales-bitcoin-security-1422491521/


Why GPU (cgminer) scrypt mining generates so many false-positive nonces?

It's likely your intensity is too high. Usually higher intensity or other settings may look good with higher hashing power, but in truth results in a lot of false positives.

Playing around with the settings till you get the sweet spot is the best practice.


Where can I download BTC historical ticker data?

You can get complete and up-to-date price history here:

http://api.bitcoincharts.com/v1/csv/mtgoxUSD.csv

You can also get subsets of the data.
For details see: http://bitcoincharts.com/about/markets-api/


How do we "exchange coins on one blockchain for those on the other"?

There are two ways to avoid transaction replay (besides something being built into the fork to begin with). You can taint your coins or double spend.

Tainting your coins requires you to get access to coins created after the fork on at least one of the chains. If you create a transaction which includes an input from a coinbase transaction created on the BIP 148 chain, then that transaction is invalid on the non-BIP 148 chain. And vice versa. Then any transaction which spends from this tainting transaction will only be valid on one chain.

The other way is to perform a double spend. Let's assume that the BIP 148 chain has less hashrate (and thus slower blocks). You make a transaction which signals for RBF which is likely to confirm in the next block on the non-BIP 148 chain. Since the non-BIP 148 chain produces blocks more quickly, your transaction will likely confirm on the non-BIP 148 chain before it does on the BIP 148 chain. Once you have a confirmation on the non-BIP 148 chain, create a double spend which pays a higher fee (to take advantage of RBF) and sends the coins to a different address. This transaction will then confirm on the BIP 148 chain since it is invalid on the non-BIP 148 chain and has replaced the original. Your coins are now separate and won't be at risk for transaction replay.


How do I use the blockchain file bootstrap.dat?

When you run bitcoin-qt or bitcoind in command line, pass that argument. This way, the client indexes transactions from a file, not from the internet.

bitcoin-qt -loadblock=/path/to/bootstrap.dat

Source: http://eu2.bitcoincharts.com/blockchain/
 Version 0.7 or later will also import this file by passing the command line argument "-loadblock=/path/to/bootstrap.dat" to bitcoin-qt or bitcoind.


*** System error while flushing: Database corrupted

This could most likely be attributed to faulty RAM or storage device. You will have to sync again. If corrupted again, consider testing/replacing your components.


Unexplained fee in electrum to localbitcoins transaction

This transaction had more than 50 inputs resulting in a bigger virtual size so had to pay more fees.
Tx: https://btc.bitaps.com/dea92494d9f5e22bfc5834963a161e906735cd04cefbd3b82ec390fceff1626a/38Q5TNhLdbZzKfnHVmdFgLXxaoTMipJgjp
Virtual size: 4003
Fee rate used: 60 sat/vByte
Total fees: 240180 sats or 0.0024 BTC
BTCUSD right now: 24000
Fees in USD: 57

How to avoid this in future?

Consolidate UTXOs when there are very less transactions in mempool and use fee rate 1-5 sat/vByte
You can also manually select inputs used for a transaction in Electrum Wallet.
If you had done the consolidation of UTXOs when mempool had less transactions and used fee rate 5 sat/vByte:
Fee for consolidation transaction: 0.0002 BTC (5 USD)
Fee for spending UTXO after consolidation assuming it had 1 input and 2 outputs with virtual size 150 (60 sat/vByte): 0.0001 BTC (2.5 USD)
You can read this answer to know more about UTXO consolidation: https://bitcoin.stackexchange.com/a/100440/


Is it possible to create a transaction with 2txin and 2txout?

You can definitely do that. Generally speaking you can have any combination of n inputs and k outputs, both n and k being integers.

I'm assuming you want to know how to implement the signing process. The process to sign such a transaction is rather involved. You basically set the signatures on all inputs to an empty string and then iterate through the inputs, copying the transaction with empty signatures, inserting the script of the corresponding output in the signature's place and signing the resulting temporary transaction.

For the exact details see this very extensive explanation blog post.

If on the other hand you're using the Bitcon Core JSON RPC then it's a simple matter of calling signrawtransaction (API) and passing in a raw, i.e., unsigned transaction. Be careful though as there are no checks when signing this way and the resulting transaction does exactly what you told it to, e.g., it might claim 10 bitcoins and allocate only 1 on the outputs, leaving 9 bitcoins floating for transaction fees and you'll lose them.


How to select minimum difficulty when mining with Slush Pool

From the research I have done to understand the minimum difficulty it boils down to a balance between server/client bandwidth limitations and time to put at risk.

The pool which you connect to distributes work for miners to solve. The more difficult each "package" of work sent to you, the longer you will take to find a solution and reply back to the pool with this solution, named share.

As explained in this Post you will on average be rewarded the same solving problems of 10k difficulty at 10 seconds per share, as solving problems of 1k difficulty at 1 second per share.

On the Antminer s9 Miner Status Tab the stats I believe, it may not be correct, I have deciphered are the following:

Summary:

Elapsed - Time passed since online
Utility - Number of Accepted shares per minute
WU (Worker Utility) - Total Difficulty Submitted (Accepted + Rejected) per minute

Pools:

Accepted - Number of Shares Accepted by the pool
DiffA# - Total difficulty of accepted shares
DiffR# - Total difficulty of rejected shares
Rejected - Number of submited Shares rejected by pool

either good hashes of bad work or bad hashes of good work

Discarded - Discarded Work that has not been worked on. According to a developer of cgminer, meaningless.
Stale - Number Shares that were sent after a block was already solved.
LSDiff - Last Accepted Share Difficulty
LSTime - Time since Last Accepted Share

You can now check to see which difficulty the pool has automatically assigned to you in the Miner Status Page.

So back to the initial question / response of the "optimum" difficulty is a balance of how many packages back and forth the network connection between the server and client is comfortable with handling and time to put at risk.

If the difficulty is very low, the network and server will be flooded with shares of solutions you have found and may reject some as it can not handle so many packets per second.

So some work you have done in solving problems has gone to waste as these solutions have been rejected.
you are spending some time waiting for recieving new work from the server and also spending time sending the solutions to the server that could have been used for finding solutions.

If the difficulty is very high, you may be working on solving a problem which no longer needs solving and so you will get no credit for the work. As far as I understand, these submited shares would be marked as Stale or Perhaps Rejected.

Currently a new bitcoin block is found every 10 minutes or so, sometimes under a minute sometimes more than 15 minutes. So, if you set the difficulty to a value which allows you to generate 1 share per minute --> Utility = 1.0 then when blocks get found under 1 minute, you have lost that minute because the pool will generate new work with the latest new block to mine and the work you were working on that you couldn't complete in time would be useless. But if the next block were found in 1 minute and 2 seconds, you would have only lost 2 seconds theoretically cause you would have probably managed to submit a share.

So, ultimately you don't want to overload the pool but you want to make sure that you risk as few shares as possible.

Your Risk would be approximately = "1 / ( Average Accepted Shares per minute * Average Minutes per Block )"

From my experience hashing at 13.5 TH/s at a difficulty of 13.3K will produce approximately 1 share every 4.5 seconds or so --> Utility = 13.5 --> "WU = 13.5*13312 = 179712" , Risk of approx 0.74%

To optimize your difficulty you should look to maximize the WU : Worker Utility Value. Theoretical Max WU you can achieve is approximately 1 per 71.6 MH/s, so a 13.5 TH/s machine can not achieve a better than a WU of 197706.

I currently have a system configured at 10k Difficulty with a Utility of 18.0 obtaining a Worker Utility of 190k, mining at KanoPool. I have aimed for 18 shares per minute as that is what is recommended by the pool.

Just though I may contribute my research on the subject incase it helps :)

Disclaimer: This response are just compiled bits from forum replies, github code and other bits here and there I have found and my own understanding of how it apparently works. This is not necessarily 100% correct information.

Some of sources:
- CGMiner Github Repo
- BFGMiner Github Repository
- BFGminer Forum talk


Coinbase wallet address listed as spent without spending

You don't have a Coinbase wallet address, you have a Coinbase deposit address that's used to deposit bitcoins into your wallet. Coinbase sweeps funds from deposit addresses into their secure holding accounts.


How would a hard fork for a new key-pair/address generation algorithm be implemented practically?

You'd have both the old and new address types valid. You can't drop support for the old address types because there's no guarantee all coin users are going to convert their coins right away.
The updated wallet software, merchant services, etc will all only provide addresses in the new format though, so eventually the use of the old addresses will slowly drop off, just like how with the adoption of segwit, legacy address use dropped off (although not completely phased out).


Why are redeeming inputs themselves scripts?

Don't think of them as separate scripts, but rather as 2 parts of the same script.  The software executes both scripts using the same stack, so it's like they were concatenated and run as one.  The advantage is that it's the same code that executes each script.

However, you are correct in suspecting there is no reason to have anything other than serialized values for scriptSig, at least with most scripts.  With a stack based language such as Bitcoin's script, there are no variables or memory allocation.  The only way the results from an earlier part of the script can affect the rest of the script is to push values to the stack to be used as inputs of other operations.  This means it is pointless to perform any operation in scriptSig other than pushing values to the stack.  As such, transaction inputs that use operations in their scripts are considered non-standard.

The exception to this rule is the multisig script type, which needs to push an extra value onto the stack due to an unfortunate off-by-one error in OP_CHECKMULTISIG.  Even so, the OP_0 or OP_FALSE that is used in a multisig scriptSig only pushes values to the stack.  That is all a scriptSig should ever do.


Do all transactions require a siganture to be broadcasted

No. Bitcoin does not require that valid transaction must have signature verification.


1- how do miners in a network learn that there is a new transction added in one block?

When a node recognizes a new block, it sends it to all the other nodes directly connected to it. It is very important for miners to build on top of the newest blocks they possibly can and to get their own blocks to as many other miners as quickly as they can (or they lose money) so miners, at least, go to extraordinary lengths to make this fast and efficient.

For new transactions not yet in blocks, more or less the same thing happens. Nodes in the bitcoin network distribute the transactions.

  is there some party responsible for notifications or something?

Anyone who wants notifications is responsible for making sure that they get them. Since pretty much everyone in the network does, this is not difficult. Nodes just share new transactions and new blocks.

  after getting this information, must a miner re-copy the whole blockchain to his local computer?

No. They just need to adjust their current state slightly.

  2- As I understand, mining is done on blocks in bitcoin. So if someone add a transaction to a valid block, does this mean that the block has to be re-mined?

If you modify a block, it's a different block entirely and not the block that was mined. If you try to produce a block by any process other than mining, you will simply fail to produce a valid block.

  3- finally who decide to create a new block?

Pretty much every miner is trying as hard as they can to create a new valid block all the time because they want the block reward that they will get if they are successful.

  is there some conditions on the size of the block or is it unconditional unlimited process?

There is a block size limit. If a miner produces a block that others will not consider valid, his block will just be ignored by the network and he will lose money. So miners must create blocks that comply with all the rules that other node operators enforce.


What hash rate should I expect using a BiFury with USB2.0 rather than USB3.0?

I found that some USB2 hubs with enough amps (3-4) can take 3 BiFury each easily reaching 5.2-5.6 GH/s. I have 5 running off two 5V 3A hubs daisy chained off of a RaspberryPi with minepeon, works well. You 100% need a couple of fans to keep these cool, I am using arctic breeze, works fine. Errors are at about 4% and temps range from 38 to 50°.

So, the conclusion is… USB2 will work well with BiFury just make sure you have a good amount of amps to supply the thirsty 0.9A they need each! I think they are a good miner for people to get started without spending to much.


Is the date here true for live bitcoin and altcoin prices?

I don't think the prices are live and up to date.

Check this one out and compare them
http://bitcoincharts.com/markets/currency/USD.html

That's real time incl. BTCchina and other non-USD markets.

Well, if you need multi-coins prices, the USD price should be averaged somehow and you probably use the right tool to track them all.


How do hardware wallets communicate with the outside world?

A hardware wallet only has responsibility for handling private keys. This includes generating addresses (when receiving), and signing transactions (when sending). It needs some sort of communication with the outside world to do this. There's multiple hardware wallets on the market, and they don't all operate the same way. However, the principles are the same.

1) How is the transaction broadcast? After the transaction is signed, the hardware wallet can export this in raw format. Anyone connected to the Bitcoin P2P network can then broadcast this raw transaction. One way of doing this is through bitcoin-cli sendrawtransaction. Another one is through a web wallet interface. This is typically provided by hardware wallet manufacturers.

2) How does a hardware wallet query the blockchain? It doesn't. It has to have an external source of information about this. This could either be a full node like bitcoind, or a lightweight SPV wallet like Electrum.

Common for both of these are that the hardware wallet needs to communicate with something externally. Trezor and Ledger does this by USB connected to your phone or computer (some Ledger models also have bluetooth), Coldcard uses micro SD cards.


How much hashpower would I require to surely mine one block per day?

Divide this number by the number of seconds in a day (86400) to get the required number of hashes per second to solve one block per day on average. You might get more than one block on some days and no blocks on others. It's random.

Currently, you'd need about 931 TH/s, which is a ridiculous amount of mining power.


Mining your transaction to push it to the blockchain?

You can pay to mining pools to mine your stuck transactions.

Expensive but i don't know any other mining pools who provides this feature.

https://pushtx.btc.com/

Try to push your stuck transactions before you pay, maybe that could help you if your transactions have more than 120/sat per byte.

  https://insight.bitpay.com/tx/send

  https://blockchain.info/pushtx

  https://blockexplorer.com/tx/send

  https://btc.com/tools/tx/publish

  https://coinb.in/#broadcast

  https://chain.localbitcoins.com/tx/send

  http://webbtc.com/relay_tx

  https://www.smartbit.com.au/txs/pushtx

  https://live.blockcypher.com/btc/pushtx/

  https://www.f2pool.com/pushtx (Needs referral code from pool operator.)

  https://pool.viabtc.com/tools/BTC/broadcast/

  https://chainquery.com/bitcoin-api/sendrawtransaction

Some websites asks for hex format transaction ID, You could convert it like that:

https://blockchain.info/tx/TransactionID Here?format=hex


How does a miner choose which transactions go into the next block?

A miner can choose whichever (valid) transactions they’d like to include in a block, for any reason they’d like.

  I understand transactions with higher fees are given priority.

Generally, yes, we would assume a rational miner would maximize the amount of fees they can possibly obtain. But this is not mandatory.


Is there a limit on number of transactions included in a block?

Short answer: Yes, there's a limit but it depends on transaction size, not count.

Basic summary of blocks

Miners are incentivized to put as many transactions into a block as they can with fees. The more transactions, the more fees the miner collects, and that can mean an extra coin on top of block rewards. A block gets bigger as more transactions are added, this is the problem and the reason why fees need to be a certain amount.

Block size limit explained

But the more transactions a block has the larger it gets in size and larger blocks can fail to propagate, creating an orphan block. Orphan blocks cause a lot of pain to the network, the miner loses 25 BTC (current block reward) and certain confirmed transactions become unconfirmed. To prevent this from happening often, the Bitcoin protocol has a block size limit to enable speedy propagation and reduce anomalies. Each block has a size limit of 1,000,000 bytes. This can change based on community consensus and probably will some time in the future due to technological progress causing the internet to be faster and more robust. A valid block is below 1 million bytes in size, otherwise it just won't be accepted by most miners.

Which transaction make it in

Most miners choose transactions as profitably as possible. They go for largest fees and smallest transaction sizes. Since they can't claim all transactions they go for efficiency. You can have a transaction a little less than the size of a block be included and processed if it had a fee beating the collective fees of the next hundred most profitable small transactions that would normally be included in a block. This system is called priority, it's all about maximizing profit for the miner.

Resulting amount of transactions

The transaction count in a block can range be reasonably anywhere. There have been blocks with no transactions other than the block reward. I say reasonably because the max depends on the smallest possible transaction size (41 bytes + 9 bytes) divided by block size. The average seems to be around 350 transactions per block.


The specific reason that AMD cards are more efficient for Bitcoin mining is twofold and the answer to this question depends on both reasons:

AMD GPUs tend to have lower-end ALUs but make up for this by packing more ALUs onto the card overall. For most hash algorithms this is preferable.
AMD GPUs uses ALUs which can perform the 32-bit integer right rotate operation in a single instruction - Nvidia's ALUs take three processor cycles to perform the same operation. SHA256 uses this operation heavily, therefore Bitcoin mining uses this operation heavily.

Combining the two reasons above results in an overall 3x-5x faster generation of SHA256 checksums. However the two effects are not equal: Effect 1 leads to approximately 2x-3x Nvidia's performance all on its own, with Effect 2 accounting for about 1.7x performance advantage. Even if you were to choose a hashing algorithm that made less use of the BIT_ALIGN_INT instruction AMD cards would still be 2x-3x faster for hashing algorithms in general. This is because such algorithms are explicitly designed to be simple binary operations which AMD's simple ALUs can handle just as well as Nvidia's more complex ALUs.

In order to choose an algorithm which would perform better on Nvidia cards than AMD cards, you would not only have to eliminate scenarios such as #2 above where a specific instruction happens to be better implemented on one card than the other, you would also have to choose an algorithm with math complex enough that Nvidia's higher-end ALUs get the chance to individually shine. To my knowledge no such algorithm exists.

To back up my statements, here is some example data from oclHashcat's web site. The table below compares actual performance measurements from similarly priced AMD and Nvidia cards for the MD5, SHA1, MD4, NTLM and SHA256 algorithms, among others.

Keep in mind that in comparing PC1/2 and PC3/4 that the Nvidia cards actually have higher clock speeds in both cases and still perform worse. In no case did Nvidia's performance approach the performance of a similarly priced AMD card, and to my knowledge no currently implemented algorithm performs sufficiently complex mathematics to make use of the more advanced ALUs on Nvidia's cards.

In short, Nvidia cards are like a small room with several fairly intelligent people, each capable of complex mathematics while AMD's cards are like a sweatshop. Hash algorithms are the computing equivalent of mass-producing name-brand tennis shoes and so the AMD "sweatshop" card will always outperform.


Is there some way to merge two wallets or to import/export addresses?

Pywallet is a python script that (among a number of other things) can export and import key pairs. It's not as complicated to use as it might sound, some python stuff has to be installed but that's almost automatic and once it is done the tasks can be performed using a web interface. From the linked forum post (updated 8/23/11):

  Currently you can:

  Dump your wallet, see your pubkeys, privkeys, their labels, etc
  Dump your transactions to a json file
  Import a key/address into your wallet, with a label, or as a
  reserve key
  Import a transaction into your wallet
  Import transactions from a json file
  Delete addresses from your wallet
  Delete transactions from your wallet
  Get info about a privkey, i.e. see address, base58 privkey,
  hexprivkey, pubkey and hash160, using the network you want
  Sign and verify string, files, and binary string
  Read a device to find deleted keys (CLI only)
  Print the balance of a bitcoin address, read from blockexplorer


Can't find Multibit wallet file after closing wallet

On a Mac the wallets are stored by default in the user data area:

/Users/"user name"/Library/Application Data/MultiBit

The default wallet file name is "multibit.wallet".


How can I define the change address of a transaction using createrawtransaction?

In Bitcoin, change is a normal output which sends the remaining money to one of your addresses. When creating a transaction with createrawtransaction, you have to add change output manually (just like any other output), otherwise that money would go to the miners.


In bitcoinj, why is MemoryBlockStore not used by default?

If you don't persist the headers in some way then you'd have to reload them each time you launched. Loading the headers from scratch isn't a free operation. Its not just a matter of downloading 626k. It may be a small amount of data in the end but each header still needs to be verified (targets calculated and checked, etc). Not only that, but there are less obvious privacy implications of requesting the block chain from the network each time.

SPVBlockStore still uses memory mapped IO so its not like you take a performance hit, it just makes subsequent launches of the software faster.


Understanding speed vs. fees on various wallets, esp. Instawallet and original client

A wallet provider might make it seem like the transaction is instant, but it will have to be included into a newly mined block (happens about every 10 minutes), for it to actually "go through". If you only pay a low transaction fee, it might take some time until a miner decides to include your transaction.

After that, it's up to the receiver of the transaction to decide how many blocks to wait until he books it as confirmed on his side.

The default client waits for six of these so-called confirmations to show the transaction with a checkmark.


Why is the USD spread of the order book on GDAX kept very low most of the time?

GDAX offers 0% fee to maker (traders who's trades are being matched by a seller or buyer). That incentives traders to try to match bid and ask as close as possible thus reducing spreads.


What is the absolute minimum amount of information required to have access to a bitcoin balance and or a wallet file?

Nmat answer is correct the absolute minimum you would need to rebuild a wallet is the private key of the address.

An alternative is a deterministic wallet.

What is a deterministic wallet?

A deterministic wallet can use cryptographic algorithms to create (and recreate) and wallet containing multiple public/private keys from a single passphrase.

A deterministic wallet has the advantage of being able to create an infinite number of addresses from a single passphrase.

A deterministic wallet has the disadvantage that if the passphrase is retained but the software & algorithm is lost then the addresses can never be recreated and all value lost.

That risk could be partially mitigated by keeping multiple copies of the wallet generation software both online and offline.  As a final backup the algorithm (and optionally  the passphrase) could be etched or cut into a thin sheet of aluminum (8.5" x 11" to simplify storage) using a laser cutter.  This would provide a time resistant disaster recovery method.  Using a sheet with dimensions of standard documents would allow it to be easily stored in a safe or safety deposit box.  This task is simplified because many cryptographic algorithms can be expressed using diagrams which reduces the amount of space necessary to express the algorithm.

For example SHA-256 (and SHA-512) can be partially expressed by this diagram:

To completely express the algorithm you also need to record each variable, the number of rounds, and the meaning of the symbol operators.


How important is the fee for speed of confirmation?

It seems like there is some policy against free transactions in official client.

There are some anti-spam protections, which my toy transactions exactly meet (low transactions, recently accepted coins, etc)

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

https://en.bitcoin.it/wiki/Free_transaction_relay_policy


What is the best way to buy bitcoin for long term investment to sell for cash later?

Exchanges work by letting you both buy and sell bitcoin (see How can I withdraw dollars from Mt Gox?). That's who is doing both the buying and selling in most cases: people like you who got their starting bitcoins by buying them.

When you're looking long-term, you should consider the stability and reputation of where you store your bitcoins. MtGox and Coinbase are two options for exchanges you could use, but as the above-linked question states, getting USD out of MtGox isn't straightforward at the moment, while getting it out of Coinbase is (but nobody really knows what the legal status of these exchanges and Bitcoin will be in 5 years). To eliminate the possibility of someone else losing your bitcoins (or you losing access to your account), instead of keeping the bitcoins in the exchange, you could transfer them to a wallet of your own (especially if you decide to buy a more significant amount of bitcoins).

Then the onus is entirely on you: print the private key and keep it somewhere secure (a bank's secure deposit box would be perfect, but too expensive to just store $100 worth of bitcoin), or encrypt it and remember (or write down, and secure the paper) the password while putting the encrypted file on various drives and cloud storages, or whatever else you decide to do. Of course, this means that you might accidentally lose access to your bitcoins if you aren't careful.

You can decide which risk you're more willing to take. I think I'd do the following: Buy it on Coinbase and transfer it to an offline wallet. Secure that as mentioned above, then when you're ready to sell, transfer it back into Coinbase (or whatever exists then) and to your bank account.


Why is my withdrawal from the 50BTC pool not visible in the blockchain yet?

50btc was hacked some time ago and the hacker completely messed up all account balances. If you actually have mined over 200 BTC there, I suggest you contact the administrators. But I assume you're just one of the people who woke up one day and saw that your 0.001 mining profit had been replaced with a completely arbitrary number of coins, in which case no, "your" Bitcoins were not lost since they never existed in the first place.


Compiling a statically linked binary for bitcoin core v0.12.0

Apply these two commits in order to update fontconfig.
https://github.com/bitcoin/bitcoin/commit/86d410d91b2188405a56bba5f1a1f74694be886a#diff-7cec5704a9b80e0db0bdc569395a7e8f2584356138b37b6a70ff30ba38224516
https://github.com/bitcoin/bitcoin/commit/3498a8d018fa02de17e1f9c4cda49f4c7edb3c6c#diff-7cec5704a9b80e0db0bdc569395a7e8f2584356138b37b6a70ff30ba38224516


Can the bitcoin lightning network support more than 8 decimal places?

Lightning uses millisatoshis as the unit of account for all transactions and routing fees, but the sub-satoshi balances are not reflected on the bitcoin blockchain in the event of channel closure.

When a channel is closed, any sub-satoshi amount held by each party is dropped from the commitment/closing transaction and goes towards payment of the on-chain transaction fee which miners collect.

Amounts below a satoshi, or rather, below dust_limit_satoshis, are made cooperatively between the parties of a channel and are not enforcible on-chain, but if many of such transactions are made, they add up to whole satoshi amounts which will be enforcible in later commitments.


How can I convert a bitcoin private key (hex) into a Bitcoin public key?

I'm voting to close since this is very similar to the other question, but what you want to be doing is scalar multiplication of the private key to the generator point using Elliptical Curve Cryptography. The curve parameters, including the generator point is defined in SECP256K1. The resulting x and y coordinates are encoded via SEC uncompressed format to get the public key.


Are there any bitcoin node that are running the original Satoshi codebase?

If you mean truly unmodified, the answer is almost certainly no.

Version v0.2.9, released on May 26 2010, introduced checksums in the protocol. During a transition phase until Feb 20 2012, checksums were only used after a version negotiation, making sure both parties understand checksum. After Feb 20 2012, all new initial connections would start using checksums everywhere. This transition period was designed by Satoshi, and took effect on the planned date without any issues.

However, it means that no Bitcoin software from before May 2010 is currently compatible with the existing protocol. It is however possible to write protocol adaptors, or make small patches to old code to make it function. With such changes, version 0.1.0 should accept the current blockchain.


Mining on Nvidia(i know it's bad, but it's a start)

Here is a comparison chart.  Your card is not even on there. So I assume its going to be about 5khs if you lucky.

I would suggest you sell that card even for five bucks and invest in AMD card with loads of cuda cores. Its obvious you don't want to spend lots of money but for 50 bucks you can find a decent card on eBay or something. That will give you allot more kh/s.

The problem with GFX mining is that electricity is really expensive. If you dont have to pay for it or you are within a green area (Hydro plants, Solar Power) and its "dirt" cheap then it is still worth it.

Good luck with your experiment.

FYI - I would suggest looking into ASIC Erupter for ultra low power BITCOIN miners.

Or you sell everything and stack the pennies up order one of these 5GHs "Jalapeno" miners  from Butterfly LABS. They can be "jail borken" and even go to 9ghs if you add extra fans.

I am in no way affiliated with any of these companies. I just use their stuff and I know it works and brings me money in. No BS!


How to update balance of imported address in electrum

You could try with other server, maybe the one you were using was lagging in the moment you imported the address.

To switch servers just go to the green ball at the bottom-right Network and select other server.


The blocks, chains, and all that excessive data can be tossed. All you need is your wallet.dat which contains your private key.

I like to think of it this way... The bitcoin network is like a massive bank full of billions, trillions, and so on of vaults. You can put coins into any vault without needing a key to that vault. You can only take coins out of a vault IF you have a key to that vault (your wallet). Your coins are never stored on your actually computer. Only the KEY to the vault is stored on your computer. That key is used to access your coins. Downloading the blockchain is simply a way of letting your bitcoin client know how many coins you have, who you sent coins to, and who sent coins to you. Its like a virtual copy of those billions of vaults, which mostly all you don't have access to. Only that vault whose key you possess. Good luck!


Why does this code keeping giving me this error? I am just trying to understand the raw bitcoin protocol

In python, you don't need to prefix a call to a function in the same module with the module's name. You can call it like print privateCeiToWif(private_Cei)


If someone wanted to pretend to be Satoshi by posting a fake signature to defraud people how could they?

Unfortunately, given the public's limited of understanding of cryptography this is apparently an easy fraud to pull off.

The key trick is that non-technical people are prone to believe things that just sound jargony enough and that technical people tend to think they know a lot more than they actually do-- and so they're easily sent off into the weeds.

In cryptosystems the details are more important than you could possibly imagine.  So all you have to do is make a forgery that works for a slightly modified cryptosystem and then lots of people who THINK they understand how ECDSA works will rush out to claim the result holds.

Most modifications that you can think of are sufficient to make the scheme insecure.

So, for example, a couple years ago Craig Wright claimed to 'prove he was Satoshi'  by simply copying some pre-existing signatures out of the blockchain and posting somewhat obfuscated instructions on verifying them. It was figured out pretty quickly, but still managed to fool a lot of people-- they were too caught up in the mumbojumbo to think of the obvious.  The "modification" in this case was that the message the scammer was claiming to sign just has no relationship to the message that was actually signed.

More recently it appears that someone attempted something similar again, but this time with 'signatures' that weren't from the blockchain... resulting in 'verification' from the developers of some BCH clients to an engineer at RedHat. But it turns out that, again, that the attempt was fake and people's partial but incomplete understanding of crypto burned them.

As Bitcoin developer Pieter Wuille notes "ECDSA signatures where the message isn't a hash and chosen by the "signer" are insecure."-- this time the scammer just published 'hash', r, s tuples.  The hash part of ECDSA is integral to the algorithm. If the verifier doesn't run the hash themselves, the security properties of ECDSA don't hold and an existential forgery becomes trivial.

[This same vulnerability was baked into the original OP_DSV opcode in BCH-- it originally didn't hash the incoming data but left that up to the user-- but I reported it and they appear to have fixed it before deploying it.]

If the verifier doesn't perform the hash himself but just accepts a value given by the signer, he becomes susceptible to the following: Given public key P, pick random nonzero values a and b. Compute R=aG+bP. Now (R.x, R.x/b) is a valid signature under key P for "message-hash" (R.x*a/b).

This doesn't compromise the security of real ECDSA because you cannot find a message that hashes to a chosen (R.x*a/b) value.

People should be wary of obfuscated or overly technical 'proofs', -- things that look "like" a secure system but for some reason have people verifying it working with raw numbers or code. Well designed cryptographic software put in a lot of effort to avoid users being fooled by stunts like this. This stuff is tricky and anyone could be confused into accepting a false proof if they were convinced to effectively implement a bespoke cryptosystem themselves. A cryptosystem is not secure simply because you, personally, don't see how to break it.

Here an an example Sage script to produce forgeries that will fool someone that accepts an ECDSA 'signature' without hashing the message themselves. It works with any EC key, including one that the forger hasn't seen a signature from before.

F = FiniteField (0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F)
C = EllipticCurve ([F (0), F (7)])
G = C.lift_x(0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798)
N = FiniteField (C.order())
P = P=-C.lift_x(0x11db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5c) # block 9 coinbase payout key.
def forge(c, a=-1):  # Create a forged 'ECDSA'  (hashless) signature
  # set a to something other than -1 to be less obvious
  a = N(a)
  R = c*G + int(a)*P
  s = N(int(R.xy()[0]))/a
  m = N(c)*N(int(R.xy()[0]))/a
  print 'hash1 = %d'%m
  print 'r1 = %d'%(int(R.xy()[0]))
  print 's1 = %d'%s
for c in range(1,10):
  forge(c)

This code produces fake forgeries of the sort that was used to trick people recently.

hash1 = 25292222169426362969760742810503101183086560848420849767135309758511048414376
r1 = 61518691557461623794232686914770715342344584505217074682876722883231084339701
s1 = 54273397679854571629338298093917192510492979773857829699728440258287077154636


Can a low fee unconfirmed transaction prevent confirmations of following transactions?

Yes, if the second transaction spends the output of the first one, then #2 cannot be confirmed until after #1 is confirmed.  (Though they can be confirmed in a single block, as long as #1 appears before #2 in that block, in which case the confirmations are effectively simultaneous.)

Most miners will consider transactions on a "child pays for parent" basis, so that a low fee for #1 could be compensated by a high fee in #2.  The two transactions would be considered as a single "lump" with their combined fee, and a miner would confirm them if the combined lump pays a higher fee than the next most lucrative transaction (or lump) that could fill that space.


BIP0016 pay-to-scripthash transaction detection

The document you linked to provides all the information you need.

Specifically, for an output to be recognized as pay-to-scripthash, its scriptPubKey must match the format

OP_HASH160 [20-byte-hash-value] OP_EQUAL

The scriptSig of the redeeming input is validated using different rules:

  Validation fails if there are any operations other than "push data" operations in the scriptSig.
  Normal validation is done: an initial stack is created from the signatures and {serialized script}, and the hash of the script is computed and validation fails immediately if it does not match the hash in the outpoint.
  {serialized script} is popped off the initial stack, and the transaction is validated again using the popped stack and the deserialized script as the scriptPubKey.

Older clients would accept such inputs, but they would not validate the included script. Therefore, the addition of these rules is a soft fork.


One cannot distinguish between saved and lost coins, because it is only possible to prove ownership of a private key, but impossible to prove that a private key is lost. I.e. nobody can tell the difference between whether I just haven't moved my coins for five years or I lost the key.

Coins cannot be counterfeited.

Coins can only be spend by having access to the private key. Rediscovering a private key, though, is extremely unlikely and due to the amount of computation required most likely not profitable.


Is it viable to CPU/GPU mine popular cryptocurrencies given that they have dramatically spiked in value recently?

Taking Bitcoin as an example, a typical CPU is about 10,000 times less efficient than an ASIC (compare the Mhash/J numbers here vs here), so the cost to mine is roughly 10,000 times higher than the reward.  In the last few months, the price of Bitcoin has maybe doubled or tripled from $5,000 to $15,000, which is nowhere close to enough.  Check back when the price hits $150,000,000.  Assuming the difficulty doesn't go up by then, which it will.


How is the network hash rate calculated?

The hashrate can be calculated from the expected rate of finding a block (144 a day), the actual rate of finding a block and the current difficulty.

So let's calculate the average hash_rate for a single day:

expected_blocks = 144
difficulty = 11187257.461361 # this is on May 22nd 2013
blocks_found = 155 # Also May 22nd 2013
hash_rate = (blocks_found/expected_blocks*difficulty * 2**32 / 600)

The reason we use a day to average out the hash_rate is that taken block by block the variance would be really high and we would not get anything meaningful.

According to WolframAlpha this gives us an averagge hash_rate for the 22nd May 2013 of 86.19 THashes/s. Numbers of course may vary depending on how you chose your interval, which appears to be the reason numbers don't match with the ones on Blockchain.info


How do I get my BTC back into my exchange without losing my BCC?

Just send your BTC where you want to send to. As replay protection is implemented, your BCC will stay at your paper wallet, and you'll be able to spend your BCC.


strange weird address in transaction after send bitcoin bitcoin-qt

When you send money to another address, the client selects one or more unspent outputs to get a sufficient amount to cover the amount you are sending.  Any excess is returned to your wallet using a change address.

In your case, it looks like you had an unspent output of 2 BTC.  Since a transaction completely consumes its inputs,  the transaction needs to send 1 BTC to your specified address and 1 BTC back to your wallet to account for the 2 BTC that were consumed.

Changes addresses are typically not displayed by the client.  If you are running Bitcoin-Qt, you can check all of the addresses in your wallet by entering the command

  listaddressgroupings

in the debug console.


How to import data from Blockchain.info to Excel

Blockchain.info has a list of API endpoints to make it easy to collect data.

blockchain.info/api

Depending on which data set you want, you can typically add ?format=csv to the end of the query to get results in csv format, or ?format=json if you'd prefer JSON. Once you have the data in a .csv file, you can simply open the file in Excel, which has native support for .csv files.


In getrawtransaction, what is the vout integer in the vin list?

The input of every transaction refers to an output of a prior transaction.

An input can't be defined by only the transaction hash.  A transaction consists of 1 or more outputs if you only specify the transaction hash there is no way to know which output is being spent.**

Since these types of questions often come from a larger misunderstanding of how the network "really works" I am going to start with some "plain english" rules on transactions (tx):

1. A tx consists of one or more inputs and one or more outputs.
2. All tx inputs refer to an unspent output of a prior transaction.
3. The full value of an input is always spent; a tx can not spend part of the value.
4. Likewise all outputs are either spent or unspent, they can't be partially spent.
5. A tx "spends" the outputs which are referenced in the input portion of the tx.
6. A tx creates new spendable "unspent outputs" listed in the output portion of the tx.

Now that we got that out of the way, to define a tx input you need to refer to the hash of a prior transaction AND the output index.  The tx hash identifies the transaction, but the transaction may have more than one output so the index is used to identify which output is being "spent" here.

This may seem confusing because you will hear statements such as "I have 20 BTC stored at address 1XYZ..." or "My wallet had 100 BTC", but this is really an abstraction.  The client is merely showing you the sum of all the unspent outputs for an address or the entire wallet.

The Bitcoin network works on the concept of inputs and outputs

The Bitcoin network doesn't consider the "value" an address when validating txs.  When validating a tx, outputs are considered as independent entities.  Spending one output for a particular address has no effect on the other outputs (if any) for that address.  A transaction is valid (among other things)if all the inputs refer to valid unspent outputs of prior transactions (can't spend coins twice), the sum of the outputs is less than or equal to the sum of the inputs (can't counterfeit new coins), and the inputs are signed by the correct private key (only the "owner" of the private key can spend the coins).

Examples

To avoid a lot of excess detail we will look at a simplified version of the transactions used in the Bitcoin network.

Say an previous transaction exists (tx hash 1234567890).  In this transaction you have an input which referenced an unspent output of a previous transaction worth 100 BTC.  You send 50 BTC to one address, 10 BTC to another address, and the change (40 BTC) is sent to a new address in your wallet.  Remember we can't spend part of an unspent output so the change is necessary because we are spending a 100 BTC input but only need to "send" 60 BTC.

The simplified pseudo-transaction may look something like this.

In[0] <lets ignore the input for now but it does have a value of 100 BTC>
Out[0] Bitcoin address=1ABC... Value=50 BTC
Out[1] Bitcoin address=1DEF... Value=10 BTC
Out[2] Bitcoin address=1XYZ... Value=40 BTC

The tx has 1 input, 3 outputs, all in/out indexes are zero based, and the value of the outputs is equal to the value of the input.  If the output(s) are less than the input(s) then the difference is the fee paid to the miner.  If the outputs are more than the input(s) then the tx is invalid.

Now since the "change" address is 1XYZ is another address in our wallet we can use it in a new transactions. We will pay a merchant 1 BTC and give the miner a fee of 0.01 for fast inclusion in a block.  The change will be sent to yet another new address in the wallet (1ZZZ....). The resulting transaction may look like this:

In[0]  Tx hash=1234567890 OutputIndex=2
Out[0] Bitcoin Address=1HIJ... Value=1 BTC
Out[1] Bitcoin Address=1ZZZ... Value=38.99 BTC

The input refers to the 3rd (0 base array) output of the tx above.  Looking up the output index 2 of tx 123456789 we can see the value is 40.00 BTC.  The sum of the outputs are 39.99 meaning 0.01 BTC will be collected by the miner of the block.

Real txs deviate from the simplified version shown above

Note this isn't really important unless you want to dive deeper into the workings of the protocol.  The output of Bitcoin transactions are actually scripts instead of static addresses and values shown above.  Functionally for most outputs they work the same, although to save space the hash of the public key not the address is used in the output. All blocks have a required tx called the coinbase which has no input because the output is the block subsidy and the fees paid to miners.  All values in the Bitcoin network are integers in Satoshis (1E-8 BTC) so technically all the numbers in this post would be multiplied by 1E8.


Sensitive information stored in contracts

Data in the blockchain is public and everyone can see it.

It is "secure" in the sense that it is computationally very difficult to modify the data later, without making it obvious that you have done so.  It is also unlikely to be deleted, since a large number of computers store the entire blockchain.

The hashing provides a certificate that a large amount of computation was done using this particular data.  Someone who wants to claim that they have the authentic data would have to do even more computation.  But the hashing does not encrypt the data in any way; the data itself remains perfectly readable (in fact, this is essential to being able to verify it).

So such data is "secure" against tampering or loss, but not against being read.


Yes. With Zerocoin. It completely and properly and mathematically anonymizes the source, it seems. http://zerocoin.org


Customer pays in EUR and I receive bitcoin anonymously

No. I don't think there are any good services that will allow customers to pay with fiat and have you receive Bitcoin even if you were okay with completing KYC, but regardless, no legitimate fiat payment processor will allow you to stay anonymous.


How to get time of input and output of a given a transaction?

Transactions do not have an individual timestamp. The closest you can do is get the timestamp from the block that it was included in (but note Pieter's warning about accuracy).

API Example

Using blockchain.info, for example you can do:

https://blockchain.info/rawtx/$tx_hash

For $tx_hash = b6f6991d03df0e2e04dafffcd6bc418aac66049e2cd74b80f14ac86db1e3f0da this would return:

{
    "hash":"b6f6991d03df0e2e04dafffcd6bc418aac66049e2cd74b80f14ac86db1e3f0da",
    "ver":1,
    "vin_sz":1,
    "vout_sz":2,
    "lock_time":"Unavailable",
    "size":258,
    "relayed_by":"64.179.201.80",
    "block_height: 12200,
    "tx_index":"12563028",
    "inputs":[

            {
                "prev_out":{
                    "hash":"a3e2bcc9a5f776112497a32b05f4b9e5b2405ed9",
                    "value":"100000000",
                    "tx_index":"12554260",
                    "n":"2"
                },
                "script":"76a914641ad5051edd97029a003fe9efb29359fcee409d88ac"
            }

        ],
    "out":[

                {
                    "value":"98000000",
                    "hash":"29d6a3540acfa0a950bef2bfdc75cd51c24390fd",
                    "script":"76a914641ad5051edd97029a003fe9efb29359fcee409d88ac"
                },

                {
                    "value":"2000000",
                    "hash":"17b5038a413f5c5ee288caa64cfab35a0c01914e",
                    "script":"76a914641ad5051edd97029a003fe9efb29359fcee409d88ac"
                }

        ]
}

From there you can query the block height of the inputs the same way as above using the inputs[i].prev_out.hash field. Then, to get the timestamp for a block, just query the raw block by height. E.g. for the output timestamps, you would use block_height: 12200 for the example above:

https://blockchain.info/block-height/12200?format=json

The timestamp would be returned in blocks[0].time

Note: Transactions technically can have an individual timestamp. When they do, it is the locktime property, see Bitcoin Wiki - Transaction. However, the locktime is most likely not going to be the time that it was created, rather, the time it is available for spending:

  if non-zero and sequence numbers are < 0xFFFFFFFF: block height or
  timestamp when transaction is final


How do I find out which wallet fits which client?

Bitcoin Core is the only software that uses a file called wallet.dat, as far as I know.


I want my money i used the recommended fees for my 3 transfers but we going on 36 hours and no confirmation

No one is responsible if your account gets hacked , your funds stolen or your transaction is stuck. Your problem is caused as currently the network has a backlog of 200,000 unconfirmed transactions.


Longer fake block chain with "valid" transactions

Bitcoin clients always accept the longest valid chain. On one hand, clients check the received blocks for validity, on the other hand length is defined by another metric than many assume. The length of the blockchain is the sum of the difficulty of all its blocks, not the number of blocks. So, in order to create a fake chain, the attacker would have to actually create a valid chain at the same difficulty. This is either possible for very short chains (double spend attack) or requires a major share of the network's power (51% attack).


You can also try Electrum a very user friendly wallet, alternatively to get you started off you could simply set up a web wallet somewhere like blockchain.info.

I suggest having a look over the bitcoin.org page here:

Choosing Your First Wallet


Why is the block size so big, taking into account a relatively small number of transactions?

Why the size of the block 656143 is so big (Size: 2,337,727 bytes), taking into account a relatively small number of transactions (Number of Transactions: 84)?

It contains a number of transactions which are substantially larger than average (it is spending a very large number of outputs, legacy P2SH multisig scripts), so an assumption based on the average size of transactions does not hold.

However, the size of the block 656143 is ~2.3Mb; therefore, a "more realistic maximum" is not that realistic :)

The quote refers to the assumed average size, not including obvious outliers like this.


Monitor all transactions on bitcoin network - API

This can be done with some degree of effort using the Bitcoin API.

v0.7 even has support for this for addresses that are not in your own wallet:

http://en.bitcoin.it/wiki/Raw_Transactions

There are other tools that you can use to build this capability as well.

libBitcoin
Armory (see Extras)
Bitcoin ABE


Can Bitcoin Diamond be claimed on Segwit addresses?

Bitcoin Diamond does support segwit, so it is possible to claim it. However, it may not be possible to (safely) do it directly from the trezor.

There is apparently an Electrum for Bitcoin Diamond, which claims to support hardware wallets. However, I have never used it, and would be hesitant to trust it to not send the coins to its own address (maybe even from other chains).

If you really do want to claim it, I would suggest:

Move all coins from the trezor, for all chains, to a temp. wallet
Reset the trezor to get a new seed
Send all coins back
Use the old seed to derive your keys using a BIP39 tool, such as https://iancoleman.io/bip39/
Import the required keys into the core client for Bitcoin Diamond, and sweep them.


When changing transaction data in a block change the hash of previous block?

When a new block is received by a node, it is validated. This validation includes verifying the validity of each individual transaction, constructing the merkle tree and the merkle root, verifying the merkle root against the block header, verifying the PoW in the block header, and finally verifying the hash itself.

After this validation is completed, the block is saved into the node's local chain database.

If you were to go and modify the stored data, it would have little effect - no other nodes will see your modified data, and all you will achieve is a broken local state if you run a reindex or reindex-chainstate.


If you're creating a version 2 transaction with the disable flag not set, then by definition the whole nSequence value will be less than 0xFFFFFFFE (because it will be at most 0x7FFFFFFF).

This implies that a transaction with an active relative locktime will always be replacable according to BIP125.

This is intentional. Nonreplacable transactions attempt to make use of the existing network policy rules to favor the first broadcasted version of a transaction. A transaction that will only become valid at a future point in time cannot make use of that, as it can't be broadcast until it becomes valid.


Setting up Bitcoin Miner in a data center

Yes. I definitely wouldn't take the chance. Minimum is a possibility of a DoS attack. I'm not familiar with the Antminer firmware and how that's setup, but you could possibly get hacked in your WebUI. Then they could point your miner at their pool.
Yes, a firewall with VPN capabilities and a switch are your typical data center networking setups. You don't really need to set it up that way. You could use a simple home router and turn the WiFi off. Then attach your Antminers to the router. If the router has VPN capabilities, then use that. Otherwise you can setup a computer in the data center to with TeamViewer or LogMeIn. Then you can remotely access your devices through that.


Who got the bitcoins when nobody was mining it in the very begin?

In the beginning, the Standard Client mined blocks by default. The difficulty was low enough that a single computer could reasonably create blocks just with its CPU. The Standard Client stopped CPU mining by default when GPU mining became prevalent.

Early blocks were most likely mined by Satoshi and other first adopters. One can see that the Genesis Block was created on January 3rd, while the next block was mined on January 9th, showing that most likely the blocks would not be mined unless there was someone on the network - Satoshi was probably running a node from the start, second person joined the network a week later.

Bitcoins are only generated when a block is mined. If a block is not mined, no new coins are generated. The system does not generate new coins every 10 minutes, but every block, which is designed to be mineable on average in 10 minutes.

If blocks would stop being generated for some time, creation of new coins will be halted until a new block appears. Worst case scenario if a lot of computing power drops from the network, the system will be slowed down until the Difficulty is readjusted. This happens every 2 weeks worth of blocks.

On TestNet, if a block is not generated in 15 minutes, Difficulty is dropped to 1 automatically to make it a more efficient testing environment. MainNet does not do this.


How to generate legacy receiving address in Bitcoin core 0.19.x.x

From within the GUI, no, and this is intentional. There is no reason to use P2PKH addresses anymore. If you need backwards compatibility, then that's what the P2SH checkbox is for.

But if you really must have P2PKH addresses, you can configure Bitcoin Core to only use them by adding addresstype=legacy to your bitcoin.conf file. If you want your change to also be P2PKH, you will need to set changetype=legacy as well.


Is there some way to take advantage of the fact that I own 10 BTC without spending them or giving up control of them?

Bitcoin Core > File > Sign message, then you can sign your nickname. Be careful, this signs for you address, not your coins, and anyone who can use a blockchain explorer can see to whom you send if you ever spend your coins.


try this:

bitcoin-cli -rpcuser=user -rpcpassword=pass -rpcport=8332 getinfo

also make sure bitcoind is running, you can do that by
ps -aux | grep bitcoind


Litecoin, by intentional design, uses a hashing algorithm that can't be made as efficient as Bitcoin's can. Computing a Litecoin block hash requires about 1,000 times more computations that a Bitcoin block hash.


After downloading the entire Bitcoiin blockchain from a torrent, what are my next steps to link it to Bitcoin Core 0.17.1?

You should not use a torrent to download the blockchain.  There is no general purpose to using a torrent, as using it makes synchronization slower because validation (which is the slow part) cannot proceed concurrently with download.  Because there is no purpose to using a torrent, I wouldn't trust that any particular torrent wasn't made maliciously and didn't contain things that might be used to exploit your computer.


My BTC is taking way too long to transfer

Is the transaction showing on blockchain.info as unconfirmed, or not there at all?

If it's unconfirmed, just wait as it may be that the transaction included no or a minimal transaction fee which means it will take a while to be included in a block.


Depending on the language you are using, there are several libraries you can use to sign a pre-made raw transaction.

I use Python, so one that I found quite intuitive and easy to use is the old vButerin's Bitcoin tools. The code is no longer supported, but it could be helpful.

Moreover, I've personally developed some tools to help people understand how Bitcoin transactions are created, what are their parts in the transaction serialization and how can they be created from scratch. There are publicly available on GitHub also. The library is intended to teach, so maybe you could use the comments to understand how to do what you asked.


dumpprivkey in bitcoin core returns private key in WIF
importprivkey adds a private key (as returned by dumpprivkey) to your wallet.
Private key to WIF: https://bitcoin.stackexchange.com/a/99101/


It is notoriously hard to establish a digital currency derived from Bitcoin that focuses on a specific niche. This has for example been attempted with country specific currencies (e.g. Auroracoin in Iceland,  MazaCoin for the Lakota nation and SpainCoin in Spain, see national altcoins), and industry specific coins (e.g. MaryJanecoin, Titcoin, and PotCoin).

The main issue is that Bitcoin and other more popular altcoins have a much better utility due to broader acceptance, and the newly created coins often immediately get sold for those after an initial hype.

Specifically regarding Banking, banks actually have very different needs than what Bitcoin provides: Their environment is more one of cooperation with known particpants, where a central database would be more of a communication and audit tool rather than one to achieve consensus. This has both allowed Ripple to successfully pursue banking clients with their IOU based network, and has led to a score of banks founding the R3CEV, whose product naturally diverged significantly from Bitcoin's blockchain.

I could see how the banking industry would attempt to resist the adoption of an open blockchain by favoring such a permissioned blockchain. The latter are naturally much more efficient as the decentralization comes at the cost of inefficiency. Unless an open blockchain overwhelms other forms of money, I would expect both to survive.


Bitcoin blockchain search algorithm and consistency policy

The blockchain is either a tree structure (with each block just referencing its parent), or a single path through this tree (a singly linked list).

Internally in software (at least in the reference implementation), indexes exist of course to find blocks (by height, and by hash).

Technically however, there is no indexing of transactions at all. They're not necessary for validation. Instead, a database is maintained with just the outputs of transactions that have not been spent yet (which is indexed by transaction hash and nothing more). Every block that is validated updates this database: its new outputs are added, the outputs consumed by it are removed. This database is tiny, compared to the blockchain (400MB vs 16GB as of march 2014).

In fact, earlier blocks themselves are not used during validation at all. We only need them for serving them to other nodes that are starting up - otherwise they would have no way to know the current state in a zero-trust manner.

This last point is important for Bitcoin's security model: full nodes never trust data they have not validated themselves. This is why we can't just copy the database of unspent outputs from someone and forgetting about the blocks before that point.

Regarding separation of data across nodes: such mechanisms typically have very bad DoS properties, where knocking out a few network nodes can mean that some data becomes inaccessible.

For just blocks, it is certainly possible to not have every node store and serve every block ever (and this will likely be implemented somewhere in the future). Again, all they are needed for is bootstrapping a new node.

The database of unspent outputs can also be sharded, namely by only retaining outputs of transactions within a certain range of hashes. However, this still requires each node to validate each block, and the result is technucally not a full node. You would need a set of nodes, that together validate the full range of hashes, to be sure blocks are fully valid.


The default size of the keypool was raised from 100 keys to 2x 1000 keys.

This was done in order to reduce the cases where recovery of a backup needs to decrypt the wallet to generate further keys.


NOTE: This applies only to LEGACY ADDRESSES that start with a "1". Addresses starting with "3" have 0x0014 appended to the beginning and are Base58Check encoded, while addresses starting with "bc1q" have 0x0014 appended to the beginning but are encoded with Bech32 Encoding.
You will get Hex/binary after decoding from Base58Check. There should be 20 bytes after decoding the Address to get the public key's hash. If whatever process or function you're using to Base58Check decode doesn't remove the version byte and checksum, you will have 25 bytes instead: The first byte will be 0x00 (the version), and the last 4 bytes (the chscksum) will be the first 4 bytes of the double SHA256 hash of the other 21 bytes.
What you'd be converting to a large integer is the HASH160 of the Public Key; aka, the result of taking the public key in compressed format (33 bytes) and running it through SHA256 then running that hash through RIPEMD-160.
More information about legacy addresses can be found here. Additionally, I've written a breakdown on how addresses are created here.


Can I install a wallet on Windows Server 2008?

You can install "Bitcoin-Core" (including Bitcoin-Qt) on a window server 2008. It requires initial syncing and verification of around 40GB of data. So it might take 1-2 days until you can use it.

Other option would be to install a SPV client like "Electrum" (Python based) or "Multibit HD" (Java / bitcoinj based). They can be used immediately but they won't give you the same level of privacy.


Writing an article on Bitcoin for my school paper

(NOTE: This answer is meant to be understood at a high school level)

Bitcoin is the first and currently most popular cryptocurrency created by the mysterious Satoshi Nakamoto.

It was designed to allow users to securely and anonymously transmit wealth to each other in a way where no single entity has control.

It is secure because it uses the nearly the same technology that has been used for decades to transmit information securely across the web.  It does this somewhat anonymously because nothing about a user is recorded.  It is "decentralized" (no one person or group of persons) has control because every transaction is verified by "hashing" it in a very difficult and original way yet can be hashed by anyone.  The transactions are hashed into something called the "blockchain" which is essentially a collection of rule-abiding transactions so that a record of all transactions alllll the way back to the very first transaction is available for all to see.

Yes, but what exactly is it?

It's basically a program that everyone uses, originally created by Satoshi Nakamoto.  If someone tries to use a different program or change the original code beyond certain parameters, called the "protocol", all other programs will reject anything that the different program will try to do.

Security

Transactions are secure because a user gets a private key/public key pair generated by a program.  They have to be generated in such a way so that for every private key there is almost certainly only one public key, so a user can choose a random private key, and an acceptable program will generate a corresponding public key.

Once a user has this pair, they can "sign" a transaction with the private key that the user keeps only to oneself, but anyone can view the true data when using the corresponding public key.

The "private key" is more like a "private lock".  A user can create a transaction and lock it with the "private lock" that only the user has while anyone can unlock it with the public key.

The public key is actually the address that all users use to receive coins.  So, if I want to send you money, you give me your public key while keeping your private key to yourself, and I sign a transaction that says "give X bitcoins to okarin's public key" and append my public key to the transaction so everyone can use it to decrypt my message which could only have been sent from me (or someone who stole my private key) because I used my private key to encrypt the transaction.

Anonymity

As long as no one knows who owns a public key, that user is anonymous.  Bitcoin records no other information.

No one controls it

This is mostly true.  Remember, this is all based upon a single program, and someone actually does control the source code to that program.  Whenever it's changed, most people adopt the change, but if they don't, one legitimate transaction record can turn into two: one for the people using the old code and one for the people using the new code.

Aside from that, the program itself is decentralized yet unified because after a transaction is sent out, it is verified by someone else on the network.

This has to be done because if, going back to the example above where I've sent you money, only some people see our transaction but others don't, I could send the exact same money that I sent you a second time to someone else who doesn't know about our transaction.

To prevent that problem, all transactions are included into a single record, the blockchain.  And the longest rule-abiding blockchain is recognized to be the legitimate one.

A single person or group of persons is prevented from having control over the blockchain because a "block" of transactions are hashed.  This requires a computer to do a calculation that costs resources such as a computer strong enough to do this quickly.  Since there are many people trying to do this because they get paid in new bitcoins to do so, it's really hard for a single person or group of persons to do all of the hashing themselves.

Not only are the new transactions hashed, but all of the old ones are too.  This turns into a very large transaction record constantly reverified and rehashed, called the blockchain.  Transactions are verified in batches called "blocks".

Where do bitcoins come from

Remember, they essentially come from the program, but new ones are rewarded to those verifying transactions as payment for doing a good job.  If someone tries to cheat, no one will give them new bitcoins.

New bitcoins are created according to the rules in the protocol.  And since the protocol says that everyone should award the first to verify transactions properly, users who use the right program do.

If a user uses the right program, this is all done more or less automatically, so a user can simply get coins from someone and send them to someone without having to worry about all of this complexity.

Good luck on your article and feel free to plagiarize this (but only you, okarin)!

If there's anything you still don't understand, send me a comment, and I'll try to help.

If you want the technical outline of what bitcoin is, you can read the original Satoshi Nakamoto paper.

Yes, I know there are a ton of ifs ands or buts, powerusers, but I was trying to outline the basics.  Feel free to edit this as necessary into layman's terms.


Bitcoin Core `getaddressesbyaccount` method not found (-32601)

The account API has been deprecated for a while, and was completely removed in Bitcoin Core 0.18.0.

You should be using the new mutliwallet API, or handling account based labelling externally.


As Luca mentioned it is really difficult to measure, but there is a way to map Bitcoin addresses to IP address under certain conditions.
Refer this paper

Title : An Analysis of Anonymity in Bitcoin using P2P Network Traffic.

Authors : Philip Koshy, Diana Koshy, and Patrick McDaniel.

Note: It analyses relay pattern of transactions. It cannot analyse transactions that are already confirmed in blocks.

Some companies publicly disclose their data and it might be possible to come up with a ballpark estimate.  Blockchain.info shares the number of wallets used in their My Wallet service.


When did the main Bitcoin client become known as Bitcoin Core? When/Why/How did this happen?

The renaming was merged in December 2013 with prior discussion on this GitHub issue. The general motivation was to distinguish between one particular implementation of the Bitcoin protocol (many refer to Bitcoin Core as the "reference implementation") versus other implementations (libbitcoin, btcd, bcoin, bitcoin-s etc) that either existed at the time or came later.
At the time most of the well known altcoins (Litecoin, Dogecoin etc) didn't hard fork the Bitcoin blockchain. They started their blockchain from a different genesis block to Bitcoin. The well known hard forks came later in 2017 with BCH, BSV etc.


Bitcoin and Bitcoin Cash blockchain split

Ensure you have your private key of the address the BTC was sent to backed up. As long as you have the private key, you will be able to spend those UTXOs on the fork and BTC itself.


Lightning Node High Availability/High Throughput

So there are a couple things to consider here:

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

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

You can see a demo of this here on youtube


Is there any central management of public and private key pairs in blockchain?

No, there isn't.  Bitcoin has no central management of anything at all.

Public keys are pseudonymous and in general it may not be possible to identify the user to whom a public key belongs.  A private key is kept by the user who generated it, and typically is never revealed to anybody else.


Ramifications of illegal content in transaction messages?

Would it be possible to make using Bitcoin illegal by posting child porn or similar highly illegal content in the message of a transaction?

Bitcoin, as a decentralised provision network of sorts, may have the same protections as given to ISPs and content providers. So unless the government is gunning for Bitcoin anyway - I'd say no, Bitcoin can not be rendered illegal this way.

  There are methods for having 'thin clients' that don't download the entire transaction history - would these be immune to an attack like this?

Obviously if you don't download the illegal content nor upload any intent to download specifically that type of content - you should be safe with a thin-client. But it limits the security of Bitcoin network considerably if only thin-clients were possible.

  How difficult would it be to track the sender of such material?

Not very difficult. Bitcoin is not an inherently anonymous protocol. If the communication between nodes is not encrypted with ephemeral TLS sessions, a mix service wouldn't provide any meaningful anonymity either.


From the Bitcoin wiki:

  An exchange that enables leveraged speculation in its
  contract-for-difference (CFD) market against the Bitcoin to USD
  (BTC/USD) exchange rate.

  The service charges no trading fees but instead earns from the trading
  spread -- similar to how forex trading functions.

This was a powerful (and risky) service to provide to traders as leveraging allowed them to invest in more bitcoins than what they owned, and the contract-for-difference market allowed traders to take a position (gamble?) on exchange rate movements.

There appeared to be a strong appetite for such a service, because it grew in popularity very quickly - it was first mentioned on bitcointalk.org in Sep 2011 and by March 2012 was large enough to be holding BTC43,000 (when it was first hacked).


Why do we often see 2 blocks mined within a few seconds of each other?

is something else going on?

Maybe.

AFAIK Mining nodes don't synchronize time. Timestamps in blocks are not accurate. You cannot tell the elapsed time between two blocks by looking at timestamps in those blocks.


The following exchanges allow you to buy Litecoins directly:

Harborly
Crypto-Trade
BTC-E
UpBit
OKCoin (Chinese)
Kraken
Or you could find a local trader


What is the max length of a public note when attaching it to a bitcoin transaction using blockchain.info?

Googling this, my first hit was the blockchain.info website FAQ. Under the point "How do I make a public note?" they show the following picture:

I'm gonna go out on a limb here, but I think it means that you can put "Anything you like up to 255 characters." into a public note.