How does bitcoin core save raw transaction data?

I understand that the default setting in bitcoin core is that non-wallet transaction data is not stored on your harddrive in the blockchain data

Actually the default is that it is stored, in the blk.dat files. There is another database for unspent outputs, in the chainstate folder. Your wallet will also index transactions for which you have imported the keys to either spend, or just watch.

  Is transaction specific data (ie: bitcoin address, time, inputs/outpus, etc...) stored in any of my raw data (eg: blk.dat file)?

Yes. Except that addresses are not stored, as addresses are an external format for specific types of scriptPubkeys, and timestamps are only in blocks, not transactions.

  How does my node verify/validate the past blocks without knowing the transactions from that block? I'm assuming other nodes don't store the transaction data so how is it that my node obtains the transactions to do a full validation of the particular block?

It does know the transactions from that block because it downloads the blocks from other nodes. The blocks contain the transactions.

  If the transactions are not stored on my computer, how do I have a full copy of the blockchain? I thought this was one of the points of running a node - you have a full backup of the entire blockchain. How could I reproduce the entire blockchain (if needed) without having the transaction data within each block?

They are, see above

  If transaction are not stored, what exactly is stored in the block data and how is that useful? Is there a way to decode or use a mechanism to obtain the transaction information from the raw block data files?

They are, see above. You can get the information with RPC commands using the cli such as:

$ bitcoin-cli getblock
$ bitcoin-cli getrawtransaction <tx-id>

  If transaction data is not stored in the block data of your computer (ie: txindex=0), how can you reproduce all the transactions if needed without having to download anything or connect to intenet to get it from other nodes if say you were the last node with a copy of the blockchain (eg: in case of an emergency if say, theoretically, all blockchains were somehow deleted and mine was the only one left)?

txindex=0 does not mean that the transaction data is not stored, it only means that it is not indexed. This means you can only get raw transactions by txid using the getrawtransaction command for transactions in the mempool, see getrawtransactions

  Do I need to enable txindex=1 to have raw transaction data stored on my node? Or is it stored and accessible if needed without this enabled?

Only to index the transactions, see above


How to correctly create and import a SegWit paper wallet

The steps you described is for a single private key, not a BIP32 wallet. If you are looking to back-up your HD seed (master key) in bitcoin-core you should use the dumpwallet command.
https://bitcoincore.org/en/doc/0.18.0/rpc/wallet/dumpwallet/


Should Electrum users give out their master public key?

Users should be strongly discouraged from doing this because it makes them targets for robbery and extortion. Knowing a user's Electrum Master Public Key is equivalent to knowing all of their addresses and being able to look on the blockchain to see if they're worth robbing.


In the future, if I pay a coffee with a very low fee, will it ever be paid?

No, ofc not.

In future, if the fees are insignificant, there will be a lot of transactions and miners will get the proper rewards for their work by all those small fees together.

New blocks are coming with new transactions every 10 minutes. Any transaction with fee superior to 1sat/byte will eventually gets confirmed.


How easy would it be to reverse this string to the original privkey if you knew my recipe? (1. remove first char, 2. split key anywhere and flip)

Absolutely trivial. An attacker only needs to try a few dozen combinations.

You should assume an attacker can try billions of combinations per second, at least.


how to explain to a child WHAT is BTC made of which is received as reward for mining a block?

The 'coin' is an unspent transaction output (UTXO). It's a long number which specifies a location and some code to allow the UTXO to be accessed by a further transaction which supplies the right key. So ...

it's not a coin really
you never get sent the 'coin'. It remains on the blockchain.
you specified the utxo location before the block was mined, back when you put it in the block you mined. At that time you also created the right key to access the utxo value later.
if you have trouble with the idea that a number can have value, I suggest you consider what value your bank password has.
the value is on the blockchain, visible to all. You have control of it with the right key in your wallet.


How could LN mitigate NAT transversal problem?

first of all if your lightning node sits behind a NAT it can still connect to other lightning nodes and also open channels with them. once you have channels you don't need a public IP address but your node id is enough. your channel partner and nat will solve the rest.

The problem is that your node behind a NAT does not have a public IP address. therefor you need to configure port forwarding in your NAT.

edit:
Also you can run your lightning node behind a toronion to have a static address.


Can unupgraded nodes that accept zero confirmation be fooled after SegWit?

If it is a transaction that pays B, that means that B chose that address. If B doesn't support SegWit, it won't ask for a SegWit output, so this cannot happen.

In practice, SegWit wallets will likely use P2SH initially; the SegWit output will be embedded in a pay-to-scripthash, and the address a SegWit wallets gives to sender will be the P2SH hash of the SegWit output script. However, in our scenario, B doesn't know anything about all that, and will just give out a normal old-style pay-to-pubkey-hash address, and A will pay to that.

More information about failure scenarios around softforks that introduce new transaction types: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012014.html


bitcoind json-rpc interface specification

Send HTTP POST requests to the Bitcoin Core RPC server and you will get responses in JSON.


Redeeming OP_SHA256 hash OP_EQUAL (Testnet) Tx

So, it's looks fine, right?

No. It does not look fine. You have to put your 'secret' into scriptSig. And your scriptPubkey should be redeem to one of your addresses (for example to msimoNvz23QXyiRofLtGSCsVdkdsNJn4SU). You should not try to sign this transaction - redeeming it does not require ecdsa signature

something like this:
(sorry, I did it "by hands", so it may be incorrect)

01000000
01
13a8a4171e5394b98ad10115a24c6b12cd33265b75cb77db724081e681c9526b
00000000

86    // length of script
4c84  // push 0x84 following bytes
6164666c61647366687569666f38727938666834753465743465357473673431356574343538733433657467343173333565346733353431723335673134337367353473333835673431733533356531673433357334673b2e3a3b2c5b40736e726c74676e6a736c656e6a72676b6c736e6c6569676e696c736e6b6c676e736c6e676c6b
ffffffff

01                 // one output
204e000000000000   // value in hex
19                 // length
76 A9 14 85ddbd9c2f9733dc3860b9e1ffcdc0da2633004b 88 AC // redeem to msimoNvz23QXyiRofLtGSCsVdkdsNJn4SU

00000000


Why was the target block time chosen to be 10 minutes?

10 minute blocks is simply a compromise.

Shorter block time:

PRO - Faster 1 confirmation time (to protect from 0-confirm double spend)
PRO - Less payout variance for miners (less reliance on large pools)
CON - Requires increased bandwidth (inter node communication)
CON - More forks, longer forks, and longer re-org time
CON - A greater portion of the raw hashpower is wasted, resulting in lower effective security.

With a longer block interval target of longer than 10 minutes, the pros and cons would be reversed.

The major benefit of a shorter block time is the reduced 1 confirm time.  While a quicker block's 1 confirm transaction has less strength than a longer block's 1 confirm transaction it is still better than any block's 0 confirm transaction.

The speed of 1st confirm may seem to be a huge benefit but in reality for most low value and time sensitive transactions such as the buying a cup of coffee, paying for a taxi, or using a vending machine, the risk of double spends is very low. Keep in mind that accepting credit cards is not without risk however merchants have long accepted they will face some losses however if those losses are minimal then it can just be seen as a cost of doing business.  So many merchants could simply accept 0-confirm transactions without exposing themselves to more risk than they do from credit card fraud.

The other factor that diminishes the real world potential of shorter target block intervals is that for many merchants, even  "faster" confirmation times still isn't fast enough. For a Point of Sale transaction, an average confirmation time of 2 minutes is still significantly longer than what most merchants would consider to be workable. The average credit card transaction takes about 20 seconds (including delays by customer).  The entire industry has spent significant resources to shave even a few seconds off.  Changes like enabling customer to swipe card, swiping before all items have been rung up, and not requiring signatures on low value are all about shaving a couple seconds off an already quick process and the cost of those changes is considered acceptable in order to slightly improve the efficiency of a checkout.

The other factor is that reducing the target interval only reduces the average confirmation time but half of them will be longer and the tail can be very long. Due to the random nature of blocks solutions about 15% of blocks will take longer than 2x the target, 3% longer than 3x the target and >7.5 minutes and about 0.5% will take longer than 4x the target.  That uncertainty makes it difficult for a time sensitive business to as a matter of policy wait for confirmations.  Having most transactions confirm in 30 seconds but some take minutes is going to lead to customer frustration at the point of sale.

If the BTC economy grows large enough we could see expanded use of "green addresses" to fill the need for instant acceptance without confirmations.  Such services could be provided by major corporations, and backed by insurance against fraud (for a small per transaction fee).  This would be a more viable 0-confirm solution than a simple reduction of the block interval.

That being said the 10 minute target was probably overly conservative and there are some advantages to a shorter block time.


How does a node decide whether a block is valid?

Blocks cannot be modified because the next block contains a hash of the previous block's header. Any change to a block would result in a change to the header, and thus, change its hash, requiring all blocks which succeed it to also be modified because their hashes would no longer be valid. It isn't possible to rebuild all of the blocks because it requires work to compute valid hashes (they must have nBits leading zeroes in their merkle root).

Blocks are correct only if they are in the longest known chain with the most accumulated proof-of-work. Meaning any chain with less work than the longest known chain is invalid.

If a node sees a valid block X but then later, receives a new block Y, where YHeight > XHeight, and the chain of blocks up to #YHeight does not contain the block X, then X is discarded. Only the blocks in the longest chain are treated as valid blocks.

This is also true in a tie. If two blocks are mined by different miners at the same time, each participant assumes that the first block they received is the valid one, and they continue the Proof-of-Work process from this valid block. The next miner to create a valid block ends the tie by creating the longer chain, and any miner who was working on a block other than the one referred to in the new block's header will discard the work they have done so far on the shorter chain, and continue working on the longer chain.


Which BIP describes the structure and algorithm for creating a wallet file?

There is a list of BIPs at https://github.com/bitcoin/bips

I don't see anything that specifies a wallet format.

To be honest I'd be surprised to see one. This is something that each implementation ought to determine for itself, Some wallets might use an embedded SQL DBMS, some a Berkely DB format, some a JSON store of some sort and so on. Similarly, the contents may depend on what unique features and facilities the wallet offers. Wallets might be multicurrency or even multiuser, they might have settings for GUI skins that need to be saved as part of a wallet backup, they might have IDs for associated exchange or other services.


How to download blk.dat files from a specific block number?

I see two broad solutions:
Use an API that allows you to get blocks by block height
BlockChain.info allows you to query for blocks at a certain height. Example:
https://blockchain.info/block-height/100?format=json

returns
{ "blocks" : [
{
    "hash":"000000007bc154e0fa7ea32218a72fe2c1bb9f86cf8c9ebf9a715ed27fdb229a",
    "ver":1,
(snipped)

(Remember to filter out blocks that aren't on the main chain, by looking at the "main_chain" attribute.)
You can take that hash, and look up the block:
https://blockchain.info/rawblock/000000007bc154e0fa7ea32218a72fe2c1bb9f86cf8c9ebf9a715ed27fdb229a

returns
{
    "hash":"000000007bc154e0fa7ea32218a72fe2c1bb9f86cf8c9ebf9a715ed27fdb229a",
    "ver":1,
    "prev_block":"00000000cd9b12643e6854cb25939b39cd7a1ad0af31a9bd8b2efe67854b1995",
    "mrkl_root":"2d05f0c9c3e1c226e63b5fac240137687544cf631cd616fd34fd188fc9020866",
    "time":1231660825,
(snipped)

(This is in a JSON format custom to BlockChain - I haven't found any API providers that will return the raw block. Kinda annoying.)
Write a client that gets the blocks from the network
This downloads the headers of the Bitcoin blockchain (much smaller than the whole blockchain). Then, it goes through the block headers and downloads the ones you want.
WalletAppKit kit = new WalletAppKit(MainNetParams.get(), new java.io.File("."), "test");
// Download headers
kit.startAndWait();
BlockChain chain = kit.chain();
BlockStore bs = chain.getBlockStore();
Peer peer = kit.peerGroup().getDownloadPeer();
// Get last block
StoredBlock current = bs.getChainHead();
// Loop until you reach the genesis block
while(current.getHeight() > 1) {
    // Fully download blocks between 100 and 200
    if(100 <= current.getHeight() && current.getHeight() <= 200) {
        Block b = peer.getBlock(current.getHeader().getHash()).get();
        System.out.println(b);
    }
    current = current.getPrev(bs);
}

This example uses BitcoinJ, but other SPV Bitcoin libraries can do this too.
(Thanks to Diego Basch for the code.)


What are the ways to secure bitcoin daemon on linux?

Ideally, you should not be storing the wallet receiving the mining payouts on the same server that hosts your pool software.

In general, when dealing with security, you want to minimize the attack surface. Any additional software you run increases the attack surface, since any vulnerabilities in non-daemon software might allow someone to exfiltrate the wallet or to pass commands to the wallet.

Once you have the wallet on a separate, isolated server, you should follow common best practices such as not having a public RPC interface, IP whitelisting for incoming connections, change all default passwords, disable password and root ssh login, have a strong password on the wallet itself.


There is no link between a BitPay business account and a BitPay wallet. If you gave an individual a receiving address belonging to your wallet, then you should see the bitcoin arrive directly to your wallet.

If you were trying to have those funds routed through your business account, you should send your client a bill using the Email Bill tool or add a payment button on your website.  They can generate an invoice from the bill or payment button and when they pay the invoice, the funds are deposited to your BitPay business ledger and then settled through the settlement process.

If you need more information, please contact BitPay via the support form at https://help.bitpay.com/requestHelp.  There is also a lot of information about setting up your business to accept bitcoin as a payment option at the following link: https://bitpay.com/docs.


What is the path used for the HD wallet in Bitcoin Core 0.13?

0.13 (current most recent release) supports HD wallets (if you create a new wallet with 0.13 it will use HD by default, <0.13 wallets will keep the non HDness).

You can disable the HD feature in >=0.13 with -usehd=0 (or usehd=0 in bitcoin.conf).

It does use only hardened private key derivation.

The keypath-scheme is m/0'/0'/k'.

BIP44 is not supported right now. It makes little sense (weak security) to use public key derivation (BIP44 does) together with a possibility to export private keys.


How much disk space do I need to run Bitcoin Core with txindex on?

Currently 48GB. Its hard to say how much the chain will grow in the future, but the 1MB block size limit caps the growth of the chain itself to 50GB per year. Building services that rely on a fully indexed block chain is probably quite inadvisable, you should aim to construct systems that don't require it.


Security of online Electrum wallet after deleting wallet file

Are there any risks that my bitcoin will be stolen if the computer is hacked?

Yes.

Uninstalling software or deleting files will not remove actual data in disk blocks that have been deallocated. Mundane file recovery software may be able to recover those contents.

Any computer connected to the Internet may have already been compromised by a hacker without the user being aware. Any access to a wallet in the past makes unsafe all future deposits to addresses controlled by the original seed-phrase.

Remember, wallets don't contain money. They contain a secret number that controls the spending of amounts of money that are kept track of in a public transaction journal that every wallet has a copy of (or indirect access to a copy of).

after deleting the wallet file, I've also used some disk utility to truly wipe it from my hard drive.

Overwiting all unallocated space once with zeroes would normally suffice to protect against item 1 above.
Prudent people have disk backups. You need to consider them also.


What underlying data structure is used to store wallet address on the blockchain?

Bitcoin's blockchain does not track total amounts of bitcoin owned by individual addresses, only the changes in amounts (i.e. transactions between addresses).

To know the total amount of bitcoin a single address owns, wallet software must search the blockchain for transactions that reference that address. Then, using those transactions, the wallet software must sum the ins and outs of bitcoin coming from and going to that address.


Is it possible to download all blockchain raw data?

Any (full) Bitcoin client will download the entire blockchain. It's stored in files on disk which you can look at after it's been downloaded. The current blockchain size is 115 GB of raw data (the size on disk will be a bit larger because of indexes created by the client).


Is it possible to deploy a python script on Ethereum Virtual Network or NEO?

First of all: I don't know anything about NEO, I can just give you what I know about Ethereum.

As far as I know it is not possible to deploy a python script in the Ethereum network. In Ethereum you can only deploy Ethereum bytecode. It is compiled from smart contracts written in Solidity, Serpent, LLL or Vyper.

Other code than Ethereum bytecode will never be stored on the Ethereum blockchain (at least not in an executable way).

When you want to build a dApp you need to write the needed smart contract and (if necessary) somewhere host your python (or whatever) frontend and/or backend.


Limit wallet to sending funds to a list of addresses

Absolutely.

The mediator, C, creates an address.

After the bet payment(s) have been made, C creates two transactions. One pays to A, and the other pays to B. He keeps both of these transactions secret. Then, he destroys the private key for the address.

Depending on who wins, the mediator publishes one of the transactions.

An attacker can't send the Bitcoins to himself, but he can choose who wins the bet, or destroy both transactions.
Downsides
If additional payments are made to C's address after he destroys its private key, those Bitcoins are lost. This could be mitigated by having the address be a 1-of-2 multisignature account, where one of the keys is an offline key held by the operator of the service.
The service is vulnerable between the time that it publishes the address and the time it creates and signs the transactions. You can't create the transactions in step two before you see the incoming transactions, either, because they will depend on the txid you're trying to spend.


how do bitcoin nodes know about the full network

There are no network level controls for this, as far as I'm aware, simply because there is no real way to discover every node in the network.

Instead, partitions are likely to not last very long as the mining power will also be distributed between the partitions. This means that for a partition with only 10% of the mining power, it will take rather long to mine six blocks, while the partition with 90% of the power will quickly establish a longer chain.

There are some efforts made to given nodes varied peers. If I'm not mistaken, the BTC DNS seeds will try and return different nodes for each request, so that you don't end up with too many nodes connecting only to each other, and have a more varied peer graph.

Additionally, if there is a minor partition, it is fairly likely the the partition will reconnect soon. At that point, since one partition will almost definitely be longer, it will become the dominant chain again. If both partitions are equal, the next block after the partition will make a dominant chain appear.


Is it possible to get the public key of a bitcoin address I do not have the private keys for with the standard client?

It is impossible to compute the public key of an address, as the address is computed from the hash of the public key. You can retrieve the public key from address with the reference client using the validateaddress RPC call (or in the debug window of Bitcoin-Qt), but that simply fetches it from the wallet, and only works if the address belongs to you.
Update: you need to use getaddressinfo now instead of validateaddress.


Is there a possibility that the whole blockchain system will be DOWN?

http://p2pfoundation.net/Blockchain

  "The blockchain is nothing more than a long string of transactions,
  each of which refers to an earlier record in the chain. But Bitcoin
  users do not directly make the updates to the blockchain. In order to
  transfer coins to someone else, you have to create a request and
  broadcast it over the Bitcoin peer-to-peer network. After that, it’s
  in the hands of the miners. They scoop up the requests and do a few
  checks to make sure that the signature is correct and that there are
  enough bitcoins to make the transaction; then they bundle the new
  records into a block and add it to the end of the blockchain."

I don't think that it will happen. As long as there is miners to "scoop" up the transactions, blockchain will still work as it should be. Miners will not stop since they are earning worth of bitcoins from transactions fees.


1) When I want to sell bitcoin through a Bitcoin Exchange, do I have
  to transfer the bitcoin to a Bitcoin Wallet created by the Exchange
  and related to my account on the Exchange, or I have just to "connect"
  my Bitcoin wallet to the account on the exchanger?

You'll have to transfer the bitcoins you want to sell to the wallet of the exchange. Each exchange implements a bitcoin wallet for every user within their system, and you can transfer money in and out of this wallet as if it were yours - please be cautious about storing large sums of bitcoins on the exchange wallet, because most exchanges have the private key of this wallet and could do whatever they want with the money on it. You have to trust the exchange to store your bitcoins.

  2) And when I will sell the bitcoin, the transaction will be displayed
  on the Blockchain right? But can this transaction be identified as a
  transaction made on a Bitcoin Exchange or not? (So that someone can
  know that I've just sold my bitcoin through an Exchange).

Since it's a bitcoin transaction, it will appear on the blockchain. A third-party can't tell it came from your specific exchange wallet. A third-party can probably only tell it came from your exchange, but can't tell it came specifically from you. Only the exchange knows you sold those coins. Obviously if the exchange database is breached (hint: NSA) then they can tell that you've sold those bitcoins.

  3) Last question: It would be a good idea to access to a Bitcoin
  Exchange through a proxy chain (Or just a proxy server) to gain more
  anonymity?

Not really. The exchange has your bank information and knows your identity. They don't expose the information to the public as I said earlier, but if someone gains access to their database, they can still tell that you've sold those bitcoins. Therefore accessing the exchange website through a proxy won't gain you much anonymity because they still have your banking details and know who you are.

I understand you're trying to sell bitcoins anonymously, but with the current way exchanges work (they need to prove your identity) this is actually quite hard to achieve. At least full-anonymity. If you're just worried about a third-party seeing that you've made a transaction, it will be quite hard for them to understand your identity unless they have access to the exchange database.


Is extranonce sometimes necessary for blocking?

Yes, it's almost always necessary.  The current Bitcoin difficulty is 48,807,487,245, which means (approximately) that if you go through all possible values for the regular 32-bit nonce, your probability of finding a valid proof of work is only 1 in 48,807,487,245.  So the vast majority of times, you will exhaust all possibilities for the regular nonce, at which point you can increment the extraNonce and continue.


Learning + checking the bitcoin address creation process at each step

Any program actually generating bitcoin addresses will always be hashing the bytes directly - what you see on the Wiki are simple hexadecimal strings representing those bytes.

The various hashing sites you have tried will treat those inputs as strings. For example, instead of hashing the byte 0xFF when you enter FF, they will hash the text FF, which is actually two bytes if interpreted as ASCII. You will never get a correct answer using such sites.


How does one set up and configure a Butterfly Jalapeño for mining?

I figured this out. A simple computer restart and software re-download fixed the problem.


A Satoshi is the smallest fraction of a Bitcoin that can currently be sent: 0.00000001 BTC, that is, a hundredth of a millionth BTC. In the future, however, the protocol may be updated to allow further subdivisions, should they be needed.

Further examples of units

1 BTC = 1,000 mBTC (millibitcoin)
1 BTC = 1,000,000 μBTC (microbitcoin)
1 BTC = 100,000,000 Satoshis
1 mBTC = 100,000 Satoshis
1 μBTC (microbitcoin) = 100 Satoshis


Where could I find Peercoin's documentation?

Peercoin's code is based on Bitcoin's code. We started a Wiki to document the differences. This Wiki can be found at this address: https://wiki.peercointalk.org/index.php?title=Main_Page

You can start with the block structure for example: https://wiki.peercointalk.org/index.php?title=Blocks

We do not have any technical paper apart from this.


Couldn't an attacker cause online (watch-only) wallets to display malicious receiving addresses?

Yes, this is possible. However, since Bob (actually, in cryptography, usually Eve, the attacker) has, apparently, got access to Alice's computer, he/she could also replace the Bitcoin application with one that does the same thing.

The purpose of this procedure is to protect Alice's existing bitcoin. It does not do other things.


Why would people buy bitcoin these days if its too expensive?

What you are probably missing is the fact that you can buy partial bitcoins, you don't have to purchase a whole bitcoin at once. You could buy a small bit of bitcoin for $20 if you wanted, it can be an affordable investment for anyone.


Why is my transaction not confirming after a month?

The simplest thing you can try is to rebroadcast the transaction and see if you get lucky. You can search for a Bitcoin accelerator and use some of the free ones.

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

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


Multisig scripts hashing (p2sh): difference between legacy and segwit

I believe the behavior you are seeing is actually a bug.

By default, addmultisigaddress uses p2sh-segwit which is the default address type for the wallet. By default createmultisig uses legacy. These are two different address types, and normally, you get two different addresses.

However segwit does not allow uncompressed public keys. So when the redeemScript is being created, if an uncompressed public key is detected, both RPCs will return legacy addresses. This is why you see the same address in the second example.

But I believe there is a bug. Your first example should also give the same legacy addresses, but it does not. I think that this is because the uncompressed pubkey is not part of the wallet, so it does not correctly detect that it is an uncompressed pubkey. Thus addmultisigaddress follows its default to give you the p2sh-segwit address and createmultisig follows its default to give you the legacy address.

  Reading raw transactions data from the blockchain, how is possible to know whether a script needs to be hashed using legacy or segwit?

For p2sh-segwit, the redeemScript is not actually the redeemScript you get from the RPCs. Rather it is the script for a P2WSH output. The "redeemScript" is actually the witnessScript for the P2WSH script that is the actual redeemScript. The script type (either in the scriptPubKey or in the redeemScript) determine whether that output is segwit or not.


Are there any services that can reasonably guess what IP address a transaction originated from?

I see this as a non-issue. By using Tor the IP address of the originator is sufficiently obfuscated.

See my two other posts for some discussion and related resources:

How can I setup Bitcoin to be anonymous with Tor?

What are main advantages of Bitcoin over Monero?


check this:

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

How is a block header hash compared to the target (bits)?

[EDIT]
Also this Calculate hash of block header


Why does Armory enforce a minimum transaction fee?

If the coins it is using have a lot of confirmations, the less likely a fee is going to be needed.

In the instance reported here, when the payment was sent using the Bitcoin.org client the funds had many confirmations and no fee was required.

When a payment for that same amount was then created using Armory, the funds did not have many confirmations and thus the client insisted on there being a fee.

This is not a difference between Armory and the Bitcoin-Qt client.  This is a difference between sending coins which had lots of confirmations versus sending coins which had fewer confirmations.   The same thing would have happened regardless of which of the two clients was being used.


Can quantum computing improve Bitcoin mining?

There are two different things here:

D-Wave machines ARE ASICs. They only solve certain particular problems. It is not really clear they take advantage of quantum effects or that they perform better than a classical ASIC working on the same problem would. In any case, they would be quantum ASICs, not general purpose quantum computers.
Mining can be improved using Grover's algorithm (http://en.wikipedia.org/wiki/Grover%27s_algorithm). When you mine, you basically have a black box that you feed with guesses and the box answers whether you have "won" the block or not. The number of possible answers is your difficulty. It is easy to produce by chance an even number, not so easy to produce a multiple of 5743.

Imagine you have a quantum computer and a classical computer each with a black box which takes the same time to check your guess. Each guess has a probability of being right equal to (#right answers)/(#total possible answers).

In a classical computer you just try one by one. On average you need about (#total possible answers)/(#right answers) tries to hit a block. In a quantum computer or a quantum ASIC implementing Grover's algorithm, you only need to use the black box (what they call the "oracle") the square root of (#right answers)/(#total possible answers) times. There are some other factors, but roughly you get a quadratic advantage.

Of course you never get this kind of fair comparison. I wouldn't really worry about quantum mining for a long time. Even if it were faster, it would probably be much more expensive. Think that you can always mine faster with more expensive equipment. You could mine faster with a supercomputer, but, at the cost they come, you better use it for something else.


You can see current fees only after registration on the btc-e.

Follow to "Finances", click "Withdraw" in the Bitcoin line.

Or login and follow the link:
https://btc-e.com/profile#funds/withdraw_coin/1

  Min amount for withdrawal - 0.002 BTC.
  Be patient, transfer of funds will be before the first confirmation.
  Fee for withdrawal is 0.001 BTC.
  Daily limit on withdrawal - 100 BTC.

Ways and fees to withdraw and to deposit are often subject to change on btc-e, thought for a long while (longer than 2 years) the Bitcoin withdraw fee is stay the same: 0.001 BTC.

When btc-e change rates, add new withdraw or deposit method - they usually tweet about it.
https://twitter.com/btcecom
Sometimes they also can add a piece of "news" when a fee is changed: https://btc-e.com/news


Why is JSON not used in the Bitcoin P2P protocol?

I do not know if there are any comparisons of the security difference between Bitcoin's P2P messages and JSON, but the binary format is certainly more compact than JSON.
I think it would be reasonable to assume that there are security implications, but security likely was not the major concern when the P2P format was initially defined. Rather ease of implementation and message size were the likely concerns.
A binary format is simply smaller and more compact than JSON strings. Strings take up a lot of space, especially strings for data that represent bytes. Furthermore, it takes more logic and time to convert binary data to a string, then convert it back from a string once received. Any string encoding for binary data is not going to be as efficient as the binary itself. For data that the user is never going to see, and with a protocol that isn't text based, using JSON is not reasonable.
Lastly, while security concerns likely were not behind this decision, there certainly are security implications for choosing a binary format over JSON. Variable length string parsing has traditionally been a source of security problems in many different software. As JSON is string based, there is the potential for anyone implementing something that uses JSON to make a mistake that introduces a serious vulnerability in their string parsing. So a binary format would be better in that regard.


Is this Merkle hash root problem existent in Bitcoin?

Yes, these kinds of attack do effect Bitcoin and are known and described. Bitcoin does not have any consensus level mitigations for them because doing so requires consensus changes which are difficult to do. It is known that Bitcoin's merkle tree design has multiple vulnerabilities.
The particular attack described on wikipedia is that an internal level can be presented as a valid document. In Bitcoin, this is theoretically possible, although it would take significant work to produce a block where the transactions produce hashes which can then be deserialized as valid transactions. If such a block were produced, it could result in a network partition due to behavior around the caching of invalid blocks. Obviously the solution to this is to be sure that cached invalid blocks are treating carefully to avoid rejecting blocks for things that are third party malleable.
In fact, this particular issue lead to a vulnerability in Bitcoin Core 0.13  that has since been fixed. A description of the vulnerability is available on the bitcoin-dev mailing list.
There is another related attack going the other direction - including a transaction in a block which could be interpreted as an internal node in a merkle tree. This attack could be used to target SPV wallets and trick those wallets into thinking a transaction was included in a block when it was not. This attack in described by Sergio Demian Lerner in this blog post.
The only true solution to this second attack requires some kind of consensus change to introduce the tree depth. But consensus changes are hard, and there are other things that can be done. SPV wallets can protect themselves by checking that no internal nodes can be serialized as valid transactions. Such an internal node is incredibly unlikely to appear randomly so this shouldn't have any real effect on the user. In Bitcoin Core, to help with protecting against this attack, 64 byte transactions won't be relayed. As 64 byte transactions are smaller than any standard transaction could be, this is safe.


Is mining the unfair part of bitcoin in the same way banks (or rather, fractionary reserve systems) are to current monetary system?

Question: Cannot we build a currency that is decentralized like bitcoin, but that doesn't have the "mining" part of it?

No need to, one was already created years ago and is still up and running today. Bitcoin depends on currency creation to record transactions, you can't get around this because that is the design of it and how it works. The only one that approaches this in a different way is Timekoin. Transactions and Currency Creation are separate. Transactions can be processed like clockwork every 5 minutes with no currency being created, provided some currency already exist to spend. Currency Creation is also produced like clockwork in very small amounts. So anyone running the server software can create currency, but in a very gradual, controlled amounts as long as the strict rules are being followed.


Why Bitcoin Core does not support importing extended public keys directly?

The structure of the Bitcoin Core wallet makes it difficult to implement importing extended public keys. This structure makes several assumptions about keys available in the keypool which xpubs do not meet. One such assumption is availability of private keys. While it isn't impossible to implement support for it, doing so is difficult to do, difficult to review, and is largely a hack on top of a hack.

Recently, native descriptor wallets was merged into Bitcoin Core so you will be able to import xpubs that are in a descriptor in 0.21. Native descriptor wallets took a long time to implement because of structural changes that had to be made to the wallet to even be able to support this.


Is it possible to monitor all crypto-coins?

You would need to install all of the coin daemons and scrape them for transactions using something like Abe, or your own custom solution using RPC commands.

If you are able to find an API which provides this information (I have yet to find one with a good amount of coins and reliable), then you could simply make calls to that; the only problem with using an API is that you are dependent on them and if they go offline, so do you.

My recommendation, get a VPS and start installing some coins :)


Original bitcoin core has one script.cpp.where is interepreter for it?I want to write hello world compiler to understand this.?

I want to understand how script is parsed into machine code.

Unlike Ethereum, Script isn't compiled. It's interpreted, like Javascript. The opcodes are evaluated on-the-fly.

  Can I write hello world such as only pushing value into the stack?

Maybe try entering

0x0c 0x48656c6c6f20776f726c6421

to https://matiu.github.io/opcodes-playground/? (0x0c is the length of the text, as a push operation)


Pre-segwit, the TXID was a hash over the scriptSig (signature data) and the outputs (value, locational data). SPV clients can not validate signature data by definition, so this is not useful information for them to have for anything but verifying the TXIDs position in the merkle tree. For segwit outputs the signatures can be stripped before being provided without altering the TXID, with massive data transfer savings.


% of full nodes running Bitcoin Core versus other node software

bitnodes.io, in its user agents chart, show an "Other" category, but probably it will include also older versions of Bitcoin Core.

On blockchair.com you can find details of which clients are used by full nodes, but they are grouped by user agents, so you need to manually count Bitcoin Core version and other clients.
on coin.dance you find exactly what you looking for, but right now is in maintenance, here there is a snapshot from archive.org: https://web.archive.org/web/20210124183839/https://coin.dance/nodes


What is the difference between on-chain scaling and off-chain scaling?

Note, I use scaling, capacity, and scalability as follows:
Scaling: Growing the network's utility in any fashion.
Capacity: The number of transactions that can be processed on the network.
Scalability: Capability of the network to handle a growing amount of work.

On-chain scaling
The term "on-chain scaling" is frequently used to exclusively refer to increasing the blockchain capacity by means of bigger blocks.
However, in the literal sense of the term, it should refer to any sort of protocol change that improves the network's capacity at the blockchain layer, including changes that facilitate production of equivalent transactions at lower cost. These approaches tend to provide at most a linear capacity increase, although some are also scalability improvements.
Examples:

Blocksize/blockweight increase
Faster blocks
The witness discount of segregated witness
More efficient new address formats
Smaller size of Schnorr signatures
Cross-input signature aggregation
Key aggregation

Off-chain scaling
The term "off-chain scaling" refers to approaches that increase the utility of the network without touching the blockchain, or by making superlinearly efficient use of the blockchain load they produce. I also include approaches that create non-equivalent transactions that result in more efficient use of blockspace.

Batching multiple payments into one transaction
Virtual payments within the system of a custodian (Tipbots, Coinbase,…)
Payment Channels/Tumblebit/Lightning Network
Sidechains
Colored Coins

Generally, off-chain solutions are scalability improvements but go hand-in-hand with a different trust model and different trade-offs. They often require additional software and complexity over on-chain scaling approaches.
For example, Lightning Network will require its users to be online to receive payments while on-chain transactions allow passive receival. On the other hand, it will easily scale the count of payments between participants, but only scale the number of participants in a limited fashion as becoming a LN user requires on-chain transactions.


Why do so many Bitcoin wallets and accounts exist?

What exactly was a bitcoin wallet intended to be?

Multiple wallets means I have to have [multiple] accounts;

The original creator of Bitcoin, Satoshi Nakamoto, wanted to create a currency for internet use which did not depend on any trusted third parties! Originally all wallets were software programs that you downloaded and ran on a personal computer. You would only have one wallet, not multiple.
There were no accounts, no exchanges or other businesses that you had to trust with your money. That was deliberate. You can still use Bitcoin like this today.
Over time people and businesses have seen an opportunity to offer services to people who either don't understand the original intent or who want to treat the currency not as a currency but as a speculative asset to be traded. These businesses have set up custodial accounts and have often described those accounts as wallets. These "custodial" wallets are not the type of wallets that the founder of Bitcoin intended.
You don't have to have multiple accounts. You don't have to have any accounts. You can use Bitcoin with no accounts whatsoever. Just download the wallet software of your choice, transfer all your Bitcoin to that wallet and close all your other accounts.

What is electronic cash?
Consider the way most USA citizens use US dollars. Very few of them ever buy and sell US dollars. They just receive their income in US dollars and spend their money at businesses that accept US dollars for goods and services. There is never any need for these people to buy US dollars or to "cash out" their US dollars.
This was how Satoshi Nakamoto and other early adopters hoped that Bitcoin would be used.
--
Two hundred years ago, many US citizens would have received their wages as US dollar bills (banknotes) and would have used those for all their spending. They
wouldn't need a bank account at all. Their finances could be totally cash based.
Nowadays many countries are moving rapidly towards a cashless society where all money is controlled by banks.
Nakamoto wanted a return to a cash based system where people, not banks, controlled their own money. But he wanted it based on an electronic currency that could be used online and which wasn't controlled by governments - because governments use inflation to effectively take money from savers.
So Bitcoin was intended as a return to a cash-based society, but one that could be used online and not subject to government or bank control
So each person would have a single wallet, no accounts.
You can still use Bitcoin like this.

The role of Cryptography

private key is used to decrypt the transaction.

The Bitcoin network does not use any encryption. So no decryption is necessary.
The private keys are used to provide a mathematical proof that you have the right to spend amounts of Bitcoin associated with a Bitcoin address (or more correctly, associated with a Bitcoin script that can usually be represented as a Bitcoin address).
Private keys are effectively used to prove ownership of money.

I also got to know that the key can also be changed.

Not really, however you can use a transaction to move money to the control of a different private key.

what is the actual key for the bitcoin account

The Bitcoin network doesn't know about or keep track of accounts. Many Bitcoin wallets don't have any sort of account concept.
If you have an account with some sort of trusted third party, the way that works is proprietary and may be different for each business.


Would fees go down once more people start using segwit addresses for day to day activity?

Transactions which spend from segwit outputs (i.e. "send from" segwit addresses) will have less weight (as in block weight) than transactions which spend from non-segwit outputs. This means that to reach the block weight limit, blocks will need to include more transactions. This effectively means that there will be more block space for more transactions. Since more transactions can be included per block, the transaction fees in general will decrease.

So yes, when segwit is widely deployed and if it is used in all transactions, the transaction fees will likely be lower.


To 'own some bitcoins' is to own the private key that allows a UTXO to be spent, so your question can be refined to "how do you verify ownership of a private key that controls a UTXO?"

There are a few ways you could do this:

Sign a generic message with the key, such as "I am the owner of bitcoin address 1a5Ag23...."
Sign a transaction with the key, spending the coins to a new address (you could post the address prior to broadcasting the tx, to prove the coins are not just moving by coincidence)
You could show off the private key itself (but this is a very bad idea! The bitcoins probably would not remain yours for long...)


Electron Cash Wallet now suddenly not accepting password?

I have not used Electron Cash myself, so I can't speak to that effect, but actually, the generation seed is exactly what would help you here. The seed words are a human readable representation of the master private key. This allows them to function as a backup of your wallet. When you use the same seed words, you'll regenerate the same wallet.


Are there advantages to having more than one private key per wallet?

Well, you don't really want one private key per wallet, you want one private key per transaction (and this is what the default client does anyway).

But you may want to have more than one wallet, because otherwise you might be mixing "accounts" that you want to keep separate: If a single transaction output is not enough for a given payment, the default client will use multiple, and that way your otherwise unrelated "accounts" become connected.


How are pools protected from a client "pretending" to mine?

Pools don't measure mining rate by how many times a client calls GetWork. They measure mining rate by how many shares are submitted. A share is just like a normal block solution, except that it is million times easier to find. If you don't mine, you don't find shares.

Related.


What is the format of the standard claim script?

In short the answer is this:

InScript length                               : VarInt (1-9 bytes)
PushData operation of R/S/Hash_all/DER bytes  : OP_PUSH (1-9 bytes)
DER sequence type byte                        : 0x30
DER sequence length                           : 0x44-0x46
DER integer type                              : 0x02
DER integer length                            : 0x20-0x21
32 R bytes, left padded with 0x00 IF leftmost byte >= 0x80 - hence varying lengths above.
DER integer type                              : 0x02
DER integer length                            : 0x20-0x21
32 S bytes, left padded with 0x00 IF leftmost byte >= 0x80 - hence varying lengths above.
Sighash_All type byte                         : 0x01
PushData operation of publickey bytes         : OP_PUSH (1-9 bytes)
PubKey version/type byte                      : 0x04
Public key in 64 bytes of data - X and Y 32 bytes each

Answer taken from here:
https://bitcointalk.org/index.php?topic=653313.0

After looking at it becomes pretty obvious that DER was a mistake on Satoshis part and something provided to him by OpenSSL.

I mean why encode unsigned integers as signed - then pad them to make them unsigned again.

Why these sequence and length definitions when we already know the length from the push byte op - why DER encode at all when its ALWAYS 32 bytes R followed by 32 bytes S?

Clearly its pretty silly.


Now what will happen if node 2 will try to relay the same message again?
How this is prevented in bitcoin network?

The transaction is the same as one that the nodes have already seen; it has the same txid, so they will ignore it.
Bitcoin does not use an accounts based system. Rather Bitcoin uses a transaction outputs model, so each input directly references a transaction output that is being spent. So there is no problem with transactions being replayed; they have already been seen so they're just duplicates that can be ignored.


How does merged mining work on a technical level?

There's actually a very good detailed specification on the bitcoin.it site.

Essentially, what it comes down to is that there's some data inserted into the coinbase transaction of the parent chain. So, assuming, for example, that Bitcoin is the parent chain and Namecoin the child chain, anyone merge-mining would be using a coinbase transaction in Bitcoin that has a particular script that looks like this:

4 bytes magic (0xfa, 0xbe)
32 bytes hash of auxPOW header
4 bytes merkle size
4 bytes merkle nonce

For now, note that the 32 byte hash of the auxPOW header is the important thing. We'll get to explaining what that is later.

The actual block submitted to Namecoin is actually slightly different. It has a few extra fields like:

Bitcoin's coinbase txn
merkle branch (essentially an SPV proof) of the coinbase txn being in Bitcoin's block
Namecoin's previous block hash

This block is called the AuxPOW block and is actually what gets submitted to the Namecoin block chain. Now, what's to stop anyone finding a block on Bitcoin and submitting the block to Namecoin by adding this extra data? This is where the hash of the AuxPOW in the coinbase transaction of Bitcoin is important.

The AuxPOW hash can be computed ahead of time and must be included in the coinbase transaction of Bitcoin in order for Namecoin to accept it. Thus, anyone merge-mining must be aware of the Namecoin blockchain as they're looking for Bitcoin blocks. Otherwise, Namecoin doesn't accept blocks that just have data added afterwards. The Proof-of-work on Bitcoin already has previous Namecoin block information in the coinbase transaction, tying the two chains together.

merkle size and merkle nonce are 1 and 0 if you're merge mining only 1 other chain. These two variables were set up so that you could merge-mine more than 1 other child blockchain, but it's actually broken. There's a workaround described here.


Is there a list of available APIs for Bitcoin exchanges?

There is now the XChange library

This is a pure Java library that has been released under the MIT license. It currently supports Mt Gox, but there are simple hooks to allow other exchanges such as Intersango and CryptoXChange to be supported.

It is currently used by the MultiBit client.


If I transfer bitcoin into Trezor that has been on a paper wallet since 7-31-17. Can I still get BCH and BTG?

The reason you cannot use the coin-splitting tool is that the private key of your offline wallet is where the new BCH and BTG coins were created at the time of the fork. By sending your BTC to Trezor, you are only spending the BTC part, the BCH and BTG are still associated with your paper wallet's key.

After your send the BTC to Trezor, you need to import your paper wallet's private key into a Bitcoin Cash and Bitcoin Gold wallet, and then send the coins to a new fork-specific addresses from there. Make sure to send the BTC away first before you start exposing your paper wallet's key, to ensure you do not lose the BTC in the process. See How to claim Bitcoin Cash & Bitcoin Gold from paper wallet for more information.


How many bytes long should nSequence be?

The sequence number is always 4 bytes, it is a fixed size, little endian, 32 bit integer which makes it always 4 bytes.

What you are missing is the scriptSig. The scriptSig always begins with the size of the script (as a compact size unsigned integer). If the scriptSig is empty, then the size must still be there to say that it is a 0 length byte. So the first byte of your "sequence" is actually the length byte for the scriptSig that says it is of length 0.


Does Ripple require users to input their ID and personal data?

Ripple has no such requirements, nor could it. It is designed to function without any central authorities. A Ripple account is created just by sending a small amount of XRP to it. The account's owner authenticates using a public/private key pair.

In principle, you could get USD into or out of Ripple without going through a gateway directly. You can meet someone in person anonymously, hand them a $50 bill, and they could give you a $50 Ripple balance. In reverse, you could sell a Ripple balance in person anonymously for cash. But in practice, to get money into and out of Ripple, you'll typically use a gateway's issue and redeem functions, and they will have identity policies.

Gateways can also require you to provide them identification just to hold balances from them on Ripple. To my knowledge, no gateway currently does this.


Getting a "couldn't connect to server" error on getblockchaininfo

Are you doing that remotely? if so please make sure that your port is open.

sudo ufw allow 8333

Also can you provide us with the last a few lines of debug.log file.


Problem In Creating Genesis Block Twister-Core using Ubuntu and (Qt Creator IDE)

chainparams.cpp contains a line of code that checks whether the chain’s genesis block is equal to a specified hash. Since you created a new genesis block, you will have to update the value to your own hash.

You can see an example for the line here:

 hashGenesisBlock = genesis.GetHash();
 assert(hashGenesisBlock == uint256("9915158279673d101912be80f25c20627f1dd8bf5231e7c46bfec5ed19737f44"));

Which I took from miguelfreitas/twister-core/…/chainparams.cpp

To figure out what to put there, you can print genesis.GetHash() and replace the old hash in the assertion.

To print it the hash of the genesis block, you can use

printf("genesis.GetHash = %s\n", genesis.GetHash().ToString().c_str());

just above the line with the assertion, which will write to the ~/.bitcoin/debug.log.


Incorporating Bitcoin into a app for person to person payments

You can build your own inner ecosystem based on bitcoin's block chain where every transacion is in bitcoins. Then you can make a gateway for outer payments using one of the existing commercial payment processors (InPay, BitPay, BitInstant etc).

Moreover you can create your own cryptocurrency using bitcoin's open-source code.
But then you have to take care of minig process by yourself and create many additional tools (wallet, minig software, blockchain API). You can also have problems to exchange your own cryptocurrency with bitcoins or dollars. So if you need connection with the outer ecosystem it will be better to use bitcoins then create your own software.


Are there any _true_ anonymous cryptocurrencies?

The short answer is no. The long answer is split into three parts, each headed by a bold word.

I will talk about the existing privacy tools in Bitcoin.
I will talk about some pie-in-the-sky theoretical crypto which would achieve full anonymity (but which can't be done feasibly today).
I will talk about CryptoNote, its limitations, and feasible ways around it that could be implemented today, specifically those that have already been implemented by Monero.

Today, you can do a lot relative to stock Bitcoin in the direction of privacy. Two strategies I should mention are CoinJoin and CoinSwap.

CoinJoin works by effectively pasting together transactions. In Bitcoin, each transaction is a list of inputs tied (by digital signature) to a list of outputs. The transaction is valid if the total output value is less than or equal to the total input value (any difference is a "transaction fee" claimed by miners), and if every input is a valid (not already spent) output of an old transaction. CoinJoin takes transactions from two or more users, combines the input and output lists, and has both users sign the resulting transaction. The result is that the standard flow analysis idiom of "all inputs are owned by the same person" and "all outputs are owned by the same person, except maybe for a change output" is broken. CoinJoin is tricky to implement well: output values should be as uniform as possible to avoid grouping them and matching them to input values; the resulting outputs should not be spent at the same time, since this also groups them; the join should involve two distinct parties, neither of whom is some central server participating in every join. Currently there are no good tools out there which satisfy all these requirements, but there are several in development (such as DarkWallet). Keep an eye open.
CoinSwap does trustless mixing, even across different blockchains (as long as each has a sufficiently rich scripting system). It is too complex to summarize here, but the result is the same as if two parties switched private keys in person, except that there is no room for cheating. That is, coins are moved between parties but the blockchain does not see this and therefore chain analysis cannot link them — except to the extent that they look funny, so if there are almost no users doing this, their transactions can be linked on this fact alone. To the best of my knowledge, there are no tools which support this. I am developing a Bitcoin wallet for experimental features such as this that will support it, but it may be several months or years away.

Total anonymity, in the sense that when you spend money there is no trace of where it came from or where it's going, is theoretically possible by using the cryptographic technique of zero-knowledge proofs. As an extreme example, you could imagine that rather than publishing blocks mapping old outputs to new ones (which is what transactions are in Bitcoin), miners published zero-knowledge proofs that they had a valid set of transactions which, in aggregate, mapped the old set of all outputs to the new set of all outputs. You could further obscure this by having the recipient choose the destination address(es) and pass different ones to every miner. That way, only the miner who gets the block (who is probably different for every block) and the recipient knows where money is going.

In what I've described, the values of all coins would still be visible, and perhaps tracking could be done by linking similarly-valued coins. We can fix this with homomorphically-encrypted values, say.

The point of this musing is that there are no strong theoretical reasons that what you want is impossible. But I'm going to burst the bubble I just created and talk about practical problems: firstly, to do this kind of general computation is zero-knowledge even remotely feasibly, you need to use a system which has a trusted setup (in cryptographic terms, the scheme is secure only in the CRS (common reference string) model). This means that some party, the scheme's creator probably, has access to secret data which will allow them to produce false proofs, effectively allowing them to undetectably print money for all time. A recent example of such a thing is the paper SNARKs for C by Eli Ben-Sasson et. al., which provides a lot of historical context.

Secondly, even with this fatal flaw, these schemes are not all that computationally feasible. Zerocoin, now superceded by Zerocash, took this approach and needed to create serious restrictions: all coins have the same value, there is no scripting (even for multisignature transactions, I believe), and even so some serious work went into special optimizations to do whatever was left (such as hashing) in zero knowledge. For ZeroCash research is going into doing the initial setup in a multi-party computation so that no individual has the secret material needed to print coins; there would be several, and as long as even one securely destroyed their data, the currency would be safe from forgery.

However, ZeroCash's trusted setup is orders of magnitude more complex than any other MPC that has ever been done. And the most efficient MPC schemes known depend on a trusted-setup as well, so we haven't gained anything.

Having said that, we can get something weaker than total anonymity, and it looks like we can do it in a feasible way. As has been mentioned, CryptoNote-based currencies use ring signatures (contrast group signatures, which involve a trusted party) rather than plain old ECDSA signatures in the proof-of-ownership part of their transaction signature scheme. Arguably the most well-known cryptocurrency that was originally based on CryptoNote is Monero. Whilst Monero has subsequently deviated substantially from its CryptoNote origins, it still implements many of the key concepts below, and additionally improves a lot of the problem areas originally highlighted in this answer.

To understand how CryptoNote works we must first recap how Bitcoin transactions work. Essentially, in Bitcoin each transaction output has a public key associated to it (identified, though not revealed, by the Bitcoin address on the output), and to spend that output you need to produce a small script including a digital signature using this key. When everyone sees that transaction, they see that the old output(s) are spent (so they can forget about it, except as far as keeping historical blockchain data for new users) and that new unspent output(s) have been created. Ring signatures, on the other hand, are associated to an arbitrary set of public keys, and knowledge of only one is required to make a signature. CryptoNote uses this by having each transaction input be a set of potential unspent outputs of the same value, signed by a ring signature using all those outputs' associated keys. It is impossible to determine which one is the "real" one that the signer is actually spending.

You might ask, if it's impossible to determine which outputs are being spent, how can double-spending by prevented? CryptoNote solves this using a special ring signature algorithm (which is a modified version of existing signatures, so this is original cryptography and their security proof should be scrutinized — fortunately it is not too complicated) in which the real signing key has a key image associated to it, which must be published alongside the signature. This key image cannot be reversed to get the original key and deanonymize the sender, but if a double-spend is attempted, users will see that the same key image is used twice and reject the second attempt.

This provides good anonymity, but even with the improvements listed presently, this is not a zero-knowledge scheme. This means that linkability is confounded but an adversary with good analysis tools will certainly be able to glean a non-zero (literally, infinity times as much as zero) amount of information.

This is a very promising direction, and these signatures are feasible to verify by ordinary computers (though they are more difficult, so scaling will be worse than Bitcoin's), but there are some serious limitations. Fortunately, all are fixable. The following list is the result of conversations between myself, Greg Maxwell, Peter Todd, Mark Friedenbach, Adam Back and several others (who I'm sure will contact me to be listed :)), and to the best of my knowledge hasn't been published anywhere. So aspiring anonymous altcoins developers, here is a wishlist:

In Bitcoin, because transaction outputs are incontrovertibly spent, the total list of unspent outputs grows only very slowly. Nodes with limited storage are able to store this, and basically nothing else: when they see a new block, they verify it then update their list of unspent outputs accordingly. In CryptoNote this is impossible since transaction outputs are never definitely spent: there is a giant list of potentially spendable outputs, and a giant list of spent key images, and both of these grow very quickly and never shrink. Current CryptoNote implementations, except for Monero, store this all in RAM, which puts a pretty serious cap on their scalability today. One of Monero's scalability improvements is to store this set on disk in a very fast LMDB database, but the set of mixable outputs is still unbounded and is expected to grow faster than Bitcoin's comparable utxoset.

However, this can be further be improved by having users store only the outputs whose keys they own (plus some extras for anonymity) and only a subset of spent key images, which I will describe. The set of outputs would be stored in an insertion-ordered Merkle tree (so a user storing almost none of the tree can easily verifiably append new outputs, but can't detect duplicates, which is fine). The set of images would be stored in a image-ordered Merkle tree (so a user storing almost none of the tree can easily add a new key image and verify that it didn't exist before, given a proof of insertion, which is basically a path from the new node to the root of the tree, along with the siblings of each node along the way). To spend an output, the user provides a ring signature including the output, with appropriate key image and proof-of-new-insertion.

Note that to produce a proof of insertion for the new key image, the user needs to store all its neighbors in the key image tree. Since key images are random-looking, how can this be done without storing the whole thing? The answer is prefix-filtering. When a user creates a new key, he creates one whose first 10 bits (say) are a specific ten-bit sequence that all his key images will have. He stores every key image that starts these ten bits so that he can produce proof-of-insertion of such images. The result is a reduction in anonymity (by a factor of $2^{10}$) since everyone will know that nearby key images are more likely to be owned by the same person than are far-away ones, but a corresponding reduction in storage requirements (by a factor of $2^{10}$) and an increase in key generation time (since on average $2^{10}$ keys will need to be generated before one with the right prefix comes along). This is a tradeoff that every user will have to make.

Peter Todd has suggested choosing a new prefix every few months or years, and retiring those in which every known key image has been used. This gets more privacy for the storage hit than simply decreasing the prefix length, since two key images in different prefix sets don't reveal their common owner.

With ring signatures, the anonymity set is only as large as you make it, probably just two or three potential keys per signature.

We can improve this to effectively CoinJoin all transactions in each block (with the caveats that (a) miners can deanonymize the CoinJoin, reducing anonymity to the smaller set provided by the ring signatures, and (b) it is possible to miners to detectably cheat, so there is a small window after mining in which block content might be invalidated by revealing its cheating, which increases complexity) (the complexity hit is because it is important that the block content, not the block itself, be invalidated, since otherwise miners could deliberately cheat then reveal the cheating later, giving them a large window in which everyone else is mining a bad chain). The exact scheme is described at the very top of this IRC log.

(The same security can be provided with fancy cryptography, specifically one-way aggregatable signatures ("just the math" by Greg Maxwell), which depends on pairing-based cryptography, which is slow and requires new security assumptions that make some people uncomfortable. The exact way these would be used is described from 21:24:58 onward in these IRC logs. It is very cool that we can get the same security with no new crypto.)

With ring signatures, your anonymity can be compromised after the fact by others in your anonymity set. For example, if you spend an output using a ring signature along with two other outputs, then those other outputs' owners spend them with a single-signature ring signature (so they are incontrovertibly spent), it is now clear which of the three you used is yours, since each can be spent only once. This can be done long after the fact, which complicates analysis.

This can be fixed by requiring a minimum size of anonymity set, as Monero has done on a protocol level since March, 2016. But then we have a new problem — there are only so many outputs of any given size, and since all outputs in an anonymity set must be the same size (so the network knows how much you are spending), this might not be possible. This can be fixed by allowing outputs of any size in the anonymity set, and taking the minimum size to be the spend amount. But then given a ring signature across several outputs' keys, people will know that the output with smallest size will be the "real" one. This is because each output can only be spent once, so if you mix it with smaller outputs, you are basically shrinking it to the size of those outputs since the network will only recognize the smaller value.

All these problems are addressed in the next point.

With ring signatures, you need all potential inputs to have same (or similar) value, which greatly restricts your anonymity set.

In fact, Greg Maxwell and I found a way such that every single output can be read as any uniform distribution of outputs (so 1BTC might be spendable as a single 1BTC output, or two 0.5 BTC outputs, or three 0.33 BTC outputs, etc.) There is a single "real" distribution, but only the creator of the output knows this, and it is not revealed except in the case of leaked keys. Therefore, literally every single output size can plausibly be claimed to be created by every output, and therefore all outputs can participate in each anonymity set. This scheme is described in this writeup.

With this is place, it is feasible to set a minimum anonymity set size, preventing people from using keys with no anonymity set and compromising their own and others' anonymity. They can still do this compromise by revealing their secret key, but it's not clear to me that this is even possible to prevent.

Monero has addressed this issue in a similarly powerful manner, by implementing a scheme based on Greg Maxwell's Confidential Transactions. This novel scheme and implementation is called Ring Confidential Transactions. Because the value of outputs is no longer known under this RingCT scheme, you are no longer forced to only mix with a small subset of outputs (ie. those of the same denomination, which in CryptoNote and pre-RingCT Monero are all ^10 denominated outputs). This massively increases the potential anonymity set, and ensures that even large outputs are not "stuck" with only a handful of matching, mixable outputs.

And by the way, Dash (formerly Darkcoin) does not provide anonymity. They attached a (broken) implementation of CoinJoin to the ordinary Bitcoin client, and at least initially released it as a closed-source software. I haven't looked into Anoncoin, but the best advice I have for folks looking into altcoins is to assume they are uninteresting (and probably dangerously broken) until someone has demonstrated a concrete technical innovation.


App for managing multiple crypto portfolios

Just clone your blockfolio app with appcloner
https://steemit.com/cryptocurrency/@tektao.tips/blockfolio-a-trick-to-manage-multiple-portfolios-on-android


The reason Bitcoin has value is because it is resistant to censorship (e.g., prohibiting transactions related to illicit purchases) and corruption (e.g., an authoritative source changing the rules). It does this thanks to the innovation known as proof-of-work.

But this proof-of-work means Bitcoin is vulnerable to attack from a party or cartel with more than 50% of the hashing capacity. The cost to perform the attack is enormous, and there is no economic incentive to do so — thus the likelihood that will occur is significantly discounted.

Litecoin also is a proof-of-work based crypto currency. The primary difference between Bitcoin and Litecoin is the algorithm used for the proof-of-work (Bitcoin uses SHA256, and Litecoin uses Scrypt) and the amount of hashing capacity needed to be successful with a 51% attack.

With an arsenal of maybe ten thousand GPUs and a distributed denial-of-service (DDoS) attack against the LItecoin pools, a 51% attack against Litecoin is likely to technically be a success. But such an attack isn’t performed to prove a point, it is performed to gain a profit. And whether there is the potential to profit from a Litecoin 51% attack depends on a few factors. Exchanges that don’t require identity would be the targets. This means the attacker won’t be double spending litecoins against the exchanges like Mt. Gox, Kraken, etc., but instead Vircurex, Cryptsy, etc, Today there likely isn’t the possibility to suddenly convert several million dollars worth of litecoins into bitcoins and then withdraw those bitcoins. Those exchanges simply don’t have that level of liquidity. So today there is no economic incentive to perform a 51% attack against Litecoin. But if an attacker were to perform a 51% attack, Litecoin is a lot more vulnerable than Bitcoin – due to the inability to acquire 2,300 Th/s of SHA256 hashing capacity, nonetheless the cost — something that would cost, using equipment prices offered today, over ten million dollars.

That doesn’t mean Litecoin or some other alt can’t reach a similar level as Bitcoin as far as there being no economic incentive for a 51% attack. And if an alt were to reach that level, Litecoin would probably be it. But Litecoin is vulnerable for a period of time until it gets there. And that’s why, other than the first-mover-advantage that Bitcoin has, that an alt is not simply a lesser-valued coin than Bitcoin. They simply have differences and the market recognizes these differences and that shows up in the price.

Now if wanting to choose between a Feathercoin and Litecoin, for instance, and the risk of a 51% is even more pronounced. And that’s why a Feathercoin, for example, has had (and likely will continue to have) successful 51% attacks performed against it. So we probably don’t need to worry about a thousand alts, each being considered suitable alternatives to Bitcoin.

The wildcard is the potential that a proof-of-stake based alt coin, which doesn’t have mining based on proof-of-work, would be an acceptable solution. But a proof-of-stake coin essentially changes the risk from an attacker acquiring hashing capacity to an attacker acquiring a sufficient quantity of coins themselves. Again, — such an attack brings no economic benefit, at least not today. But the market seems to agree that proof-of-work architecture is the right approach for a decentralized digital currency.

And of all proof-of-work based digital currencies, bitcoin's protection from a 51% today trumps all others. And that’s enough to prefer Bitcoin over the alternatives. At least, that’s the case today.

[Source: http://btctheory.com/2013/10/20/bitcoin-alt-coins-and-free-money-theory/comment-page-1/#comment-15 ]


Their wording is a little funny but it sounds like they act as a middle man and cannot guarantee a price until they have facilitated a deal. I assume the conversion rate shown on the main page is only an estimate. In that case they don't have to worry about price volatility as they are putting that burden on you the buyer.

  §4 Terms and Conditions of Service

  The Service uses the services of online payment provider Dotpay S.A.,
  whose office is located at ul. Wielicka 72, 30-552 Cracow, Poland.

  Using the 4Coins.pl via online payment provider user transfer funds to
  the 4coins.pl’s account in PLN currency. The amount received by the
  Service is reduced by 1.9 % of its value as a commission charged by
  the online payment provider.

  Service under an order for the total service credited to the account
  searches offers on the market BTC – bitcoin and mediates on the
  principle of matching user with the available range of offers.

  Due to the nature of the market BTC website does not guarantee the
  execution of transactions on the presented course. Given course is
  presented only in the form of information.

  After the service, the user will be informed about the parameters of
  the transaction, and may order the withdraw of their units BTC –
  bitcoin.


Lite-wallet transaction confirmation procedure

No, lite wallets can function just fine without storing all the block headers. Instead, what wallets usually do is confirm if there is a new tx involving one of the wallet addresses, and then download that specific tx. They will then only store the tx, and not the rest of the information.

As their UTXO set expands, they will check new blocks to see if they contain a new UTXO, or consume an existing UTXO that the wallet cares about.

Additionally, many wallets these days keep track of when an address was created, and will not scan blocks before that.


Right now, generally no. As far as I know Bitcoin exchanges dont offer peering services, and they all use CDNs (like Incapsula) to prevent DDoS attacks. So moving closer to them isnt going to help much, because you're still going to have all your traffic pass through the CDN. If you were located in China and wanted to access a US exchange, then yes it would help a some, but if you're an American trying to access an American exchange, the lower latency would be negligible.

There aren't really Bitcoin brokers as there are stock brokers. With Bitcoin you generally deal with the exchange yourself, there isnt a middle man like a brokerage. The closest thing I know of to a broker in Bitcoin is BTX Trader, which will purchase coins for you at the best price from multiple exchanges.


After using openassets issue_asset() , the asset quantity is 0

The problem is after issue_asset(), if the min_confirmation is 1, we have to mine the bitcoin block for one time. Then only after that, the asset can be seen in get_balance.


Can someone with an unlimited amount of money compromize the network?

With unlimited money, you could destroy almost anything. I don't really see why it matters. If someone with unlimited money spends a few billion dollars to destroy Bitcoin, we'll just create Bitcoin2 and maybe he'll spend another few billion destroying that. We can keep creating new crypto-currencies indefinitely. If each one gets a few billion dollars out of the hands of some evil entity, that's a win in my book.


Why doesn't the block time influence time the amount of time needed for a transaction to be confirmed?

If a block is found super fast, like 1 minute, then you have your first confirmation in 1 minute. The 10 minutes is average of time between block confirmation. In fact, since the network in increasing in speed, we are more or less confirming block at 9 minutes each.

In some case, we are out of luck and a single block can take 30 minutes.

That said, the number of confirmation required to accept a payment is totally as the discretion of the merchant. You can accept with 0 confirmation, 1 or 2. Some go more than that but that should be for very big amount (like 100,000$ +).

Another alt coin can confirmed in 10 sec, that's irrelevant because 10 confirmations in that blockchain is still less secure than a single confirmation from the bitcoin network because finding a block in the bitcoin network is harder than finding 10 block in an alt-coin.


`bitcoind` RPC: ask if syncing headers or blocks

The getblockchaininfo RPC will tell you have many blocks and headers you have. When the number of headers is larger, you're still synchronizing.


Transaction fees after 0.9 protocol update

How were transaction fees determined before the change and after the
  change?

The fees were determined on the person sending the bitcoin, or the client in many cases. One can send a tx with no fee, but it has lower priority to get included in a block. They are still determined the same way. The "default" method for determining the fee is generally 0.000055 BTC/1kB. Technically, the fees help determine the priority for a transaction to get included in a block. The formula is: priority = sum(input_value_in_base_units * input_age)/size_in_bytes, therefore, it is a function of a few variables.

  How does this change affect third-party software developers (who do
  not use Bitcoin-Qt wallet) - do they need to mimic this change?

The change needs to be implemented in wallet software that determines the transaction fee for the user (i.e. Multibit), or changed in a setting by the user (i.e. qt client).

  How does this change roll across the network? Do 51% of miners need to update to the new version before the change starts to be effective?

The change rolls across the network as the miners update their qt client to the version with the updated protocol rules, otherwise, they will mine and still play by the rules in the old client. This change doesn't necessarily require 51% of the network to adopt the new version for the lower tx fees to take effect. Theoretically only one miner would need the new version and solve a block with the client for the new tx fee rules to take effect for that block. If one uses the lower tx fees while few miners have updated their clients, the fee will be considered low, and probably would be lower than lots of current transactions, so would be placed further down in the queue. If the update is done by a few major pools, the change would be effective, although using the new tx fee might cause a slight delay if a block is solved by a miner with old client and the block is full of transactions with higher priority.


What causes the 'uncertainty' when a block is still relatively new

An attacker could try to mine a chain of 7 blocks that would not include that transaction. That chain would replace the one where the transaction happened and "undo" it.

However, doing this is very hard, it requires the attacker to control a significant amount of hashpower and isn't guaranteed to work 100% of the time since while the attacker is mining, the other honest miners are also mining. Satoshi ran some numbers (albeit his calculations were off) in the whitepaper, section 11.

The more blocks your transaction is buried under, the higher the certainty is. It exponentially increases with every block that confirms your transaction.


"Active" is used for Process BIPs, it is not used for Standards Track or Informational BIPs, which use "Final".

A quote from BIP 2: "A process BIP may change status from Draft to Active when it achieves rough consensus on the mailing list."


Check wallet address balance programmatically in PHP using Blockchain wallet api

The Blockchain Wallet API provides a simple interface Merchants can use to programmatically interact with their wallet.
  Installation

  To use this API, you will need to run small local service which be responsible for managing your Blockchain Wallet. Your application interacts with this service locally via HTTP API calls. Click here for complete setup instructions on GitHub.

So you need to install the service, then replace the blockchain.info in that link with the IP to your server, or if it's on the same machine localhost:3000


To supplement George's answer:

It would help if you would clarify what you mean by "crash" and describe exactly what happens.  (To many people, "crash" means a segfault or similar abnormal termination, but it sounds like that's not what you mean.)

If the issue is that the program appears unresponsive, this is normal: it's a well-known annoyance (perhaps not exactly a bug) in bitcoin-qt.  The program needs to rescan the transaction ledger (block chain) to find any previous transactions involving the newly imported address.  Unfortunately, while doing so it does not accept input from the GUI, report its progress, or redraw its window, which makes it look like the program has hung.  However, it should finish eventually if you don't kill it.

On my computer (laptop circa 2012 with SSD), rescanning takes 5-10 minutes.  Depending on the performance of your computer and especially your hard drive, it could take substantially longer.  I would give it at least an hour or two before assuming it is really hung.  You may also be able to see in your system's status monitor that the bitcoin-qt client is using CPU and/or doing disk I/O, which should indicate it is still working on the rescan.

As George suggests, you can disable the rescan using the rescan=false option.  However, this is usually not a good idea.  If you do so, bitcoin-qt will not know about any previous transactions on this address; in particular, if the address contains coins, bitcoin-qt will not know about this, will not update your balance to include them, and will not let you spend them.  Since the most common reason to import a private key is to claim coins that it contains, this would defeat the purpose.

If you know the address has never been used before (e.g. it is a vanity address you have just generated), then it is fine to use rescan=false, since there are no previous transactions to be found.

If you have several private keys to import, you can use rescan=false for all but the last one, to save time.  When a rescan is done, it searches for transactions for all addresses in the wallet, both old and new.  You can also force a rescan later by quitting bitcoin-qt and restarting it with the -rescan flag; again, it will appear to be hung for a while as it rescans, and the GUI window may not appear until it is done.


there are lot of grate websites where you can buy bitcoin..

example: coinbase.com, blockchain.info

https://www.bitcoin.com/buy-bitcoin <-- here are some ways to buy
http://cryptosort.com/wallet <-- here you could find something as well..

but if you are starter i suggest you to use coinbase, because there is simple interface and 3 cryptocurrencies available :)


Most exchanges which support USD exchange will be funded via international wire. Depending on your bank these charges can be between 10-50USD.

If your transferring from a different currency the rate given on conversion is better than if you were to purchase USD in cash from your high street but lower than spot on forex markets.

ACH / domestic transfers will come when domestic (to you) exchanges build more solid relationships with banks when more regulation comes in place.

Trading with locally on places like localbitcoins is the best bet if the percentage in fees is larger than 5% of the amount you plan to buy. This is a good rule of thumb.


How to confirm custom transaction with solo mining?

In Bitcoin, it is the miners' task to order the transactions. Thus, it is possible for a miner to pick which transactions they want to confirm. By default, they pick the ones that will provide the largest mining revenue to them, but often they will pick transactions to prioritize out of band.

However, you can only confirm a transaction by mining a block. That's what a confirmation is, a transaction being included in a block and thus being committed to on the blockchain.

However, it is infeasible for you to mine a block at home. Whatever minig power you may be able to acquire and run at home will likely not help you mine a single block in the next 1,000 years. I've elaborated here: In the ASIC-age, is it worth starting mining Bitcoin at home?


That can be the transaction fee charged. Do the calculation according to the Zebpay guide and validate the received amount.

E.g when you sell/transfer bitcoin to a different address, a transaction fee is charged.

Quoted from zebpay.
Zebpay transaction fees on selling bitcoins

"You will be charged a bitcoin network fee when you send bitcoins to a bitcoin address depending on the number of bitcoins you send. Fees are dynamic and updated on daily basis. Please check your app for latest fees.


How does blockchain.info determine when a payment is received?

What you're describing is one way to do it but there are much better ways. Take a look at https://bitlab.co/wallet which is an open source real-time wallet API that you can learn from. The back-end source that interfaces with the bitcoind service is at https://github.com/bitlabco/bitlab-nodejs


Is bitcoin the only entrance to buying other coins?

You can find coin exchange who sell those alt coins, see at MtGox or BTC-e
other ways to get alt coin such as Megacoin and Quark is by mining that coin


How to recover coins from a wallet that uses BIP32 Deterministic Keys?

Here's a web tool for BIP32 key derivation.

The only problem is the hardcoded 50k rounds of HMAC-SHA256. You do need to know how your wallet software exactly derived the master private key from the mnemonic or you'll get totally different keys. Unfortunately there's no standard convention for the HD wallet backup/restore process and I'm afraid this ranks quite high among the biggest downsides against Bitcoin adoption.


Bitcoind --reindex vs starting allover again

bitcoind --reindex will be faster because starting over from scratch would not only do all the work bitcoind --reindex is doing, but it'd also have to go out and re-download all those blocks too.


The developers of Zcash did try to implement their solution using the Bitcoin blockchain but it required several changes to Bitcoin core that where both difficult and more importantly difficult to come to consensus for the changes with the rest of the Bitcoin community. So the Zcash developers decided to make a new blockchain.

So technically speaking it would be possible (but hard) but convinving the Bitcoin community of the changes would be much harder.

Note that there are other anonymity proposals that will use the Bitcoin blockchain (e.g. Confidential Transactions, MimbleWimble) but I do not know the state of their implementation.


In the console do listunspent
that will show you all the UTXO in your wallet including the txids.
You can type help to get a list of commands,
then help <command> to get details about each command


How to turn off "change" address in bitcoind?

Bitcoind isn't designed for that. There isn't option for that and probably won't be. If you are interested in keeping paper backup, you should look at clients such as Electrum.


Place bootstrap.dat in the bitcoin data directory and then start Bitcoin-Qt.  It will read the file to create the blockchain.  The file will be renamed to bootstrap.dat.old when this is completed to prevent reprocessing when Bitcoin-Qt is restarted.

You can locate the data directory by reading this.


How can I determine where a BTC transfer from one of my accounts to another went wrong?

I don't know how much it will help, but you can search for the transaction using the Bitcoin addresses on a Block explorer, then maybe you can see if the destination address was wrong:
https://www.blockchain.com/explorer


I solved this with a pull request that adds a property to ExtKey and ExtPubKey that allows you to call the ChainCode property. See pull request 156.

It has been merged into NBitcoin 3.0.0.28 which is available on NuGet.


Given an altcoin, how to find its mining pools?

It is impossible to identify who a miner or mining pool is based upon the coin's blockchain. If the mining pools are private or have poor search engine optimization, then it will not show up in search engine results. Given that you cannot deanonymize miners from the block data nor can you search for all of them, you cannot get a definitive list of mining pools for any coin.


I think I know the reason now... the problem is that on the official dogecoin website, the version to download is 1.1.0, which is the one I downloaded, but is not the latest. The latest now is 1.8.0 (apparently, according to github). I switched to the new version and the problem was solved.

If the devs of the Dogecoin website are here, please upgrade it.


Let's look at what happens without the blockchain:
You create a transaction and it is relayed through the network. Every node that receives it updates their ledger to reflect your transaction. So far, so easy.

Now, while you're using the network playing fair, there is Mallory, another user, that likes to break things. Instead of just sending his transaction, he sends two conflicting versions of the same transaction (a "doublespend") at the same time to half of his peers each.
These peers do the same as before: They update their ledger and pass the transaction along. However, half the network receives one version, and considers the second invalid and vice versa.

Now, the network is split: Their ledgers are no longer synchronized. Mallory can now send a transaction building on one of the two previous and only half the network will accept it as valid.

This "doublespending problem" is what the blockchain solves for us: The mining process elects a node to author a block containing his version of the past few minutes. As there is only one author elected every ~10 minutes, these blocks can be passed through the network easily before the next is discovered.

As the author can only have accepted one of the two conflicting versions into his recount, all the other nodes know which transaction to accept and which one to drop.

Thus, the blockchain allows us to synchronize the state of the network under adversarial conditions.

I.e.:

Brings everyone on the same page.
No central decision maker.
Every new node can catch up to the current state deterministically without trusting someone not to lie to them.


How do I transfer bitcoins into a United Kingdom bank account?

The factors that matter for any cash-out decision are:

Where are you located (country)? (you mention UK)
How much are you looking to trade?
What type of cash are you looking to receive? (you mention bank transfer or PayPal)
How soon do you need access to the proceeds?
Is privacy important?

Specifically for cash-out to PayPal, options include:

http://www.FastCash4Bitcoins.com (among the lowest fees, funds not always available though)
http://www.VirWoX.com (BTC --> SLL, SLL --> USD)

BitBargain is probably your best method:

https://bitbargain.co.uk

Or, of course, you have many local cash out methods:

https://localbitcoins.com/postal_code/uk/london/

And there are local traders who will buy your coins:

http://bitcointalk.org/index.php?action=profile;u=65105
http://bitcointalk.org/index.php?topic=130949.0

You might be able to find someone willing to trade over-the-counter (OTC) but you only want to do this with a trusted counterparty.  The #bitcoin-otc marketplace's Web of Trust (WoT) will help as it has a trust history.

http://www.Bitcoin-OTC.com
http://webchat.freenode.net/?channels=#bitcoin-otc-foyer
http://webchat.freenode.net/?channels=#bitcoin-otc-uk  <-- Specific to UK

Here are more cash-out options:

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


Calculating total outgoing transaction fees associated with a single address?

The API blockchain.info provides for the address details does a ton of processing at it's backend (by accessing the blockchain for which they must have maintained a separate db for quick fetches). As far as the transaction fee is concerned, it can be calculated by finding the difference in the inputs and outputs of a transaction. This is somewhat tricky because the vin (input) for any transaction points to the output of another transaction. But the point being you can find the difference and the transaction fee.

I suggest you query the blockchain using the core Bitcoin API and maintain your own database as per your convenience. The blockchain.info API is kind of a dependency for the app and if their server goes down, so does your app. So maintaining a custom formatted data on your side is a good way to go and also ensures responsiveness.