Is there a way to know the Bitcoin Network transaction fee BEFORE actually submitting the transaction?

Yes.

Use createrawtransaction with the outputs you want, but no inputs.
Use fundrawtransaction to make the wallet add inputs and a change output if necessary.
Check what fee the resulting unsubmitted raw transaction has. If you like the result, continue:
Call signrawtransaction to sign the inputs.
Call sendrawtransaction to broadcast it on the network, and as a side effect, list it in the wallet.

You can't control the network fee directly (as it is per byte, and you don't know the size beforehand), but you can set the feerate using -paytxfee. In a new release, you'll also be able to pass the feerate to fundrawtransaction.


How can I use Bitcoin privately with the Electrum wallet and Tor?

Electrum v3.1.3 and earlier includes a setting to use Tor

When Tor is correctly setup on your system, it is possible to directly configure Electrum to connect via Tor for all connections, both to Electrum servers and, to third-party services.

Using these steps you can be anonymous in only five minutes.

Setting up Electrum and Tor

These instructions work on Fedora 27 and assume a default installation of Electrum v3.1.3 and Tor v0.3.1.10 or newer. Fedora is a modern operating system that will run on most standard modern hardware. The configuration is the same on Windows, but the instructions are different. There are some instructions for setting up Tor on Windows here.

Further instructions for other *nix based systems are available here. NOTE: You do not need to configure your Tor client as a relay or exit node for Tor to operate, so you can skip the step for 'Put the configuration file /etc/tor/torrc place:' in that guide. You will still need to use all of the following steps in this guide.

Setup Electrum

Install the Electrum package:

sudo dnf install electrum

Run Electrum. If you start Electrum with the -o offline switch the first time you run it your details don't leak out.

Choose Automatically Connect and click on Next.
Name your wallet if you like or accept the default and click on Next.
Select Standard Wallet and click on Next.
Select Create a new seed and click on Next.
Select Segwit and click on Next.
Securely, privately and accurately store your seed. This is your wallet backup. If it is lost all your BTC is gone permanently. Click on Next.
Type your seed in the box and click on Next to verify you have it correctly.
Set a good password that you will never forget. This must be secure to ensure your wallet cannot be stolen. Click on Next.
Your wallet is setup.

Setup Tor

Install the tor package:

sudo dnf install tor

Start the tor daemon and make sure it starts at boot:

sudo systemctl enable tor
sudo systemctl start tor

With Electrum setup and running:

Go to Tools -> Network
Click on the Proxy tab
Place a tick for Use Tor proxy at port 9050
Note that Electrum will momentarily disconnect and reconnect via Tor
Click on Close
Exit and restart Electrum normally (to go online)
Check that your password works and that you remember it before you use your wallet.
Look for the icon to turn turquoise indicating that you are online. You can click it to check status.

Done! Enjoy being anonymous!

Appendix 1 - Monitoring Tor

You can monitor (and further tweak/break) Tor using nyx.

There are several installation methods available. On Fedora 27:

sudo dnf install nyx

To start nyx simply type nyx in the console and it will connect to Tor if it is running. Requires control port 9051 to have been uncommented in /etc/tor/torrc.

Footnotes

There are more configuration options available, and additional ways you can support the Tor network. Please see the several pages available here for information.

*by default, Tor will participate in the Tor network.


Sending multiple output transaction with total output exceed the total input value

No, it is not. The individual values of the inputs and outputs don't matter, only the sum matters. So the sum of the inputs is compared against the sum of the outputs. And since the sum of the outputs is greater than the sum of the inputs, the transaction is invalid.
Bitcoin does not take Bitcoin from particular inputs and map it to a particular output. Instead it's like all inputs in the transaction get mixed together, and then that total amount is split out into outputs and fees. So only the sum matters.


How is the human end of the Bitcoin network secured?

In an ideal world, we would want all programs to be auditable/verifiable(we can verify every execution path to be secure and correct). But that's far from reality, when you download a binary from a source(for example, Bitcoin Core), you have the following choices.

1) Trust the developers of the binary on their claim "binary works as intentded"

2) Verify the source yourself (It's open source for this reason) and build your software yourself.

All PR's to Bitcoin Core are visible to everyone, so everyone will be able to detect any harmful PR. An effective attack would involve bribing all people who actively watch the repository.

The best solution review the code yourself. If this attack really gives you nightmares, reviewing code yourself is the only way in which you don't have to trust anyone.

A more realistic solution is what happens today, you can rely upon hunderds of people who keep a watch on bitcoin repository to report if there are any backdoors in code.

EDIT: As pointed out by Peter Wuille, Bitcoin Core has a deterministic build process. You can repeat the build procedure for any release yourself, and verify that the resulting binary is identical to the release binary which you downloaded. This means that you don't necessarily have to trust just developers that the binary is created from publicly audited source code.


testnet is usually running on port 18333. did you check that port?


Is there any format change in block #498557

From what I can tell, by testing your script, is that it is failing on Segwit transactions. This would make sense, if you haven't accounted for it, because it changes what is used to produce the tx hash. This was introduced with BIP141. Currently, not all transactions are required to be in this format, so you will have to account for both. The txid still uses the entire transaction structure, this is why you might notice bitcoin-core rpc calls will return a different txid than the tx hash (wtxid) for segwit transactions.

  Definition of txid remains unchanged: the double SHA256 of the
  traditional serialization format:

  [nVersion][txins][txouts][nLockTime]

  A new wtxid is defined: the double SHA256 of the new serialization
  with witness data:

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

see BIP141

What you'll need to do is look for the segwit flag 0x01 in the serialized transaction. It's an optional 2-byte array right after the first version bytes, see https://en.bitcoin.it/wiki/Transaction


What do I need to do to protect my wallet on my computer?

There is a lot of info about securing your wallet on bitcoin.org

http://bitcoin.org/en/secure-your-wallet


How can there exist businesses that "specialize in blockchain analysis looking for patterns of usage that reveal how money is being used"?

And now somebody claims that there are entire actual businesses that do nothing but analyze the Bitcoin blockchain looking for patterns, and somehow make money from this? .. Can somebody explain to me how this makes them money?

These chain analysis businesses make money by selling data to interested parties, such as regulators, other businesses, police/gov enforcement agencies, etc.

As example, in many jurisdictions, businesses that act as bitcoin exchanges (trading fiat <-> bitcoin) are required to comply with 'anti-money laundering' (AML) and 'know-your-customer' (KYC) rules and regulations. This ultimately means that these businesses will need to catalogue data about who is using their service, and for what reasons. So they will employ the services of a chain analysis firm that can supply data about what is happening on the bitcoin network, in an effort to appease regulators.

  And what, more precisely, do they do when they "look for patterns"?

Chain analysis firms will work to obtain as much information about the economic activity happening on the bitcoin network as possible. This includes:

The structure of transactions (number of inputs/outputs, value of inputs/outputs, address types, etc)
The relation between different transactions / addresses (eg, attempting to group clusters of addresses to outline a user's wallet, etc)
The messages exchanged P2P on the network (eg, where do new blocks/transactions originate from)
Publicly available data (eg, when a user posts an address of theirs to a forum online)
Privately available data (eg, buying or trading data about customers from private businesses)

By combining clues gained through the above methods, a chain analysis business can make guesses about which users own certain UTXOs, as well as the relationships and economic flows that exist between these users. Since this data is of value, these businesses can exist.

For a thorough explanation of these different types of attacks on privacy, the Bitcoin wiki has a great page: https://en.bitcoin.it/wiki/Privacy#Blockchain_attacks_on_privacy (as suggested by MCCCS in a comment)

An important thing to note is that many of the metrics used by chain analysis firms rely on certain heuristics that do not always hold true. This means that in many cases the resulting analysis is false, or perhaps just nonsensical. Bitcoin privacy is a back-and-forth battle, with many developers working on tools and techniques that directly attack the validity of heuristics used by chain analysis (eg, coinjoin, payjoin, etc).

On the other hand, a chain analysis company would be expected to overstate the validity of their results, since their revenue is contingent upon this validity, and they want to convince customers and regulators that the fees they charge are worthwhile.

Ultimately,  a user can interact with the bitcoin network in a way which grants them zero privacy against these businesses, or they can interact in a way which allows them extremely high levels of privacy. It really just depends on the user's habits, and the tools available to them.

So the true effectiveness of chain analysis is hard to discern, but in any case it is an attack on the privacy and security of bitcoin users worldwide. Note that even if the conclusion of a chain analysis firm is false, there is nothing to stop an overzealous regulator from persecuting an individual based on the result anyways. The stakes are apparently high, for everyone involved.

So I do agree that it is offensive, though perhaps for different reasons.


What development tests should I do when creating a Base58Checked parser?

I'm using BigInteger in .NET so these tests are unique to this scenario but may be adapted to Java or other languages.

The tests I've found helpful is when translating to or from hexadecimal at any intermediate step make sure the data is correct when:

The first or last byte of the checksum is one or more 0's
The first or last byte of the address is one or more 0's

Often times this may cause two's compliment errors depending on the implementation of BigInteger that is being used.

I'll run my own version of vanity gen to generate addresses that have these errors and will post them here.


How and why we need to validate a transaction?

So far, i couldn't understand what is the utility of adding the transactions merkle tree root on the block header.

To ensure that the transactions in the block are committed to by the block hash.

The block hash is not actually the hash of the entire block, it is the hash of the block header. If there were no merkle root, the block header would not contain anything that ensures that the transactions that are part of the block are actually part of the block. By hashing all of the transactions together into the merkle root and putting that in the block header, blocks received must contain all of their transactions so that the block header is valid.


What benefit does a non-mining client provide to the network?

A non-mining client will:

Propagate transactions to other peers, including the mining pools.
Propagate peer list, so everyone will have a wide list of peers to connect to.
Propagate the blockchain.
Help decentralise the network by doing all that.

So it essentially takes the burden off the bigger nodes by sharing data. It is especially true for the block information, as it can get quite lengthy.

This is a bit less true for clients working without forwarded ports, as they connect to few nodes, usually some bigger ones that are connected to many peers.


I have created a page on the Wiki called "First time buyers guide". It is only a rough version at the time of writing, but hopefully it will be revised into a go-to guide for anyone wanting to make a payment with Bitcoin with as little unnecessary information as possible.


Can I set up cgminer to mine in different pools, by a defined ratio?

You can run cgminer --help to see the options or you can just research them online. A good example is this website: https://github.com/pshep/cgminer

I've never done it but I think you can add a rotate option:
--rotate <arg>      Change multipool strategy from failover to regularly rotate at N minutes (default: 0)

80% / 20% would be roughly 19 hours / 5 hours or 1140 minutes / 300 minutes

Now, with the --rotate <arg> you will rotate the pools regularly, so it's easy to set it to 50/50on two pools, 33/33/33 on three pools etc.

I think you could achieve an 80/20 split by using a scheduled start and stop times.

--sched-start <arg> Set a time of day in HH:MM to start mining (a once off without a stop time)
--sched-stop <arg>  Set a time of day in HH:MM to stop mining (will quit without a start time)

Say, you start mining at 00:01, you set the rotate setting to 19 hours (1140 minutes), at 7 PM the pools will switch, set a stop time for 23:59 and 2 minutes later the miner should start mining using the first pool again. The only problem could be if after the miner stops, it could start mining still on the second pool, in which case you should start at midnigh, only use the --rotate 1140 and always restart cgminer at midnight manually or maybe using a shell script (or bat if on Windows).


Why is my transaction so big and thus so expensive?

I think you answered your own question.  Yes, the transaction is so expensive because you are combining multiple inputs.  This makes the transaction high in terms of bytes, but low in terms of value.  As such, the transaction fee (which is based on bytes, not value) may not be worth the transfer you are attempting.

However, since it sounds like what you are actually trying to do is access the BCH (Bitcoin Cash) that you also own due to the fork, you can instead leave your bitcoin where it is on the main Bitcoin blockchain, and instead perform your transfer on the Bitcoin Cash blockchain where the fee will likely be cheaper.  This is, of course, assuming you need to move your bch at all.  Unless you need to spend it, you can just leave your bch where it is as well.


Yes, the output address can be chosen entirely independantly from the input address. So you can send all the money from one address to itself if you don't pay transaction fees.

"Proof of ownership" can be done easier and faster though, without performing a transaction at all. You can just use the private connected to the address to encrypt a random message from the other person. She can then decrypt it with your public key and assert that the result is the original message (and that the public key corresponds to your address). This process is called digital signing and actually happens when bitcoins are transacted.


Error: Wallet backup failed! (code -4) when setting up bitcoin-qt for first time

I've looked at Bitcoin's backupwallet code, and that error is triggered by a filesystem error. I can't tell what kind of filesystem error it is, though. Please open debug.log in the Bitcoin directory. There should be a line like

<date + time> error copying wallet.dat to <path> - <kind of error>

This is the most common type of error:

error copying wallet.dat to <dest> - boost::filesystem::copy_file: Access is denied: "<src>", "wallet.backup"

This means Bitcoin is trying to backup your wallet to C:\Program Files\Bitcoin. You don't have the permissions to backup there. To fix this, run

backupwallet "C:\Users\<username>\AppData\Roaming\Bitcoin\wallet.backup"

instead.


Generally the definitions are as follows:

A Segwit transaction is any transaction which contains witnesses. This means that the transaction has at least one input which spends from a segwit output (P2WPKH, P2WSH, P2SH wrapped versions of those two).

A Segwit transaction does not have to produce any segwit outputs.

A transaction which produces segwit outputs but spends non-segwit outputs as inputs (so it does not have any witnesses) is not considered a segwit transaction.


Should we still mine nowadays with CPU/GPU?

it is now impossible for normal CPU/GPU to mine bitcoin, you need to get some ASICS or Gpus (e.g Rx480) and mine in a pool. of course you should buy devices with high Hashr power to increase your chances to get rewarded. Here is a simulator to check the potential profit you could make by determining your hash power : https://www.cryptocompare.com/mining/calculator/btc

some details about the mining pool and the network hashrate :

https://btc.com/


Would a service for automated repurchasing of Bitcoins encourage spending?

This seems rather odd to me. I try to time my purchases with Bitcoins for times when the price is high. And I try to time my purchases of Bitcoins for times when the price is low. If I use a service like this, I'll either be buying high or selling low, which is not my personal preference.


Solving block with number current number of transactions

As a miner, you get to choose which transactions you include in a block. Ideally, you would choose the set of transactions which maximises your incoming transaction fees, but you may choose any set of transactions you like (including none).


Why does calling BlockExplorer's checkaddress JSON API do nothing?

You are trying to cross domains.

Look into jsonp for that:

https://github.com/jaubourg/jquery-jsonp


How is "engine lag" on Mt Gox calculated?

It is the difference between current timestamp and the submission timestamp of the oldest order submitted, which has not yet been processed by the order book.


How do miners decode the input transaction?

No, that is not how transactions work.

First of all, transactions are not strings but rather blobs of binary data.

Secondly, the transaction hash that is included in the inputs of a transaction is not an encoding of the previous transaction but rather an identifier. Since sha256d is a secure hash (meaning that there will be a unique hash for basically all inputs), each sha256d hash uniquely identifies the transaction which it is the hash of. This is why transaction hashes are referred to as transaction ids (txids). A node, when it indexes the blockchain, can store in its database the transaction id as a key and the transaction itself as the value. This means that once the node needs the previous transaction for an input, it can easily use the given txid to lookup the transaction in its database and pull the necessary data.


How can I send bitcoins to my coinbase.com account for conversion to USD?

I actually had this same issue today.

You can find your BTC deposit addresses on coinbase.com under...

Account Settings / Integrations tab / Bitcoin Addresses (scroll to bottom)

Here you can add new addresses as well as "view all"

I hope this helps!  :)


Simulating -walletnotify option in Electrum

An old question - by the time I saw it - but the Electrum daemon - assuming it is running on Linux of some type must be polled from an external source with software or a cron job.

see Checking/polling a balance of an address in Electrum via the command line/RPC


How does Trezor recover all public keys from different blockchains?

Trezor follows (and helped design) BIP44.

BIP44 details how a single mnemonic may be used to create individual keychains for different blockchains, and how multiple accounts may work within those keychains.

This is not a foolproof system - if you deviate from the expectations of BIP 44 (such as using addresses beyond the 20 address gap limit) automated recovery software will not be able to locate all of the used addresses - This makes it somewhat unfit for commercial uses, since most companies and exchanges need to give out addresses without assuming they will be used sequentially.

For individual wallets, this is a safe assumption, and one that Trezor makes.


You can use pywallet to look at all the addresses and keys.

The console command listaddressgroupings should also give you all your addresses, grouped by known co-ownership. You can then use dumpprivkey to get the corresponding key.

However, backing up just specific keys is not a recommend practice, you should back up the wallet file. If you do want a more concise method, you should use a client that supports deterministic wallets.


How do transaction fees exacerbate instability in Bitcoin in the future?

As Nick answered quite adequately:

After subsidy has diminished sufficiently as soon as a block is mined that clears out the mempool there will be no income for a miner that mines a successor block, but full income if they successfully remine the prior block. Even once more transactions show up, it will continue to be more profitable to remine the last block for some time especially since they can also take the new transactions that show up.

I wanted to also offer an answer to talk about some of what we've been doing about it.

This issue has been known about in the Bitcoin community for a long time, we've normally discussed it under the name "fee sniping"-- and it was one of the points I raised in my first post in the modern blocksize debate.

Already implemented in Bitcoin Core and some other wallets is a anti-fee-sniping technique where wallets nlocktime their newly created transactions to the current block height. The effect of this is that a sniping miner can take the transactions in the prior block, but not newly arriving ones.  This makes the incentive to go forward build faster. Future enhancements to this move could might be to set the locktime further in the future when the user authors a transaction which has a feerate below the next block worth of transactions, or just don't care about confirmation speed.

The primary response, which is why it came up in a post about the block size, is that the blocksize limit helps tremendously: If there is a consistent backlog there is still a drop of income immediately after a block but it is much less significant.  The paper doesn't really consider this case, basically dismissing it, and noting that fees are not isotropic. They aren't but they don't need to be to substantially diminish instability and even today we find that when the network isn't under-loaded the backlog appears to be enough to produce stability.
(Red: Block template fees immediately before a block was found, green is immediately after)

Finally, it has been proposed that if/when the network is hardforked the rules be adjusted so that coinbase transactions can spend immature coinbase outputs. Among other things, this would allow miners to pay forward excess fees to encourage other miners to confirm their blocks.  Analysis of the strategies seems to suggest that there is no stable equilibrium when there is no block size limit or back-log,  but it seems likely that there is with a limit (e.g. pay forward the difference between your candidate block and a hypothetical double-size alternative, down scaled by your opponents odds of successfully getting two blocks in a row). But this is an open area for research.

Unfortunately the paper you cite just considers perpetual inflation to be the solution and doesn't consider it too carefully. It even advocates Ethereum which at most has an inflation rate which asymptotically tends to zero (meaning even if inflation rescues them from this issue now, it will eventually do so no longer)-- and thats even if it goes that far: It is my understanding that the Ethereum Foundation has recently stated an intent to lower the inflation rate to combat the price falling.


Getting balance/downloading blockhain with bitcoinj

OK, now I get it.

I can't.

Bitcoinj saves only the headers. And - what I did not know - you can't get the balance with just headers.

For more ingormation you can see the exact description what is in the headers here https://en.bitcoin.it/wiki/Block_hashing_algorithm

What I can do, however, is saving the wallet right afterwards. Which I will do.

previous "answer"/thinking out loud:

I am poking around in source code.

It seems like the important part is when sendTransactionsToWallet is called in BlockChain.java - but it gets only called during connectBlock and nothing else.

connectBlock is called only during add. And the only added blocks are the new blocks from the network, not the ones from BlockStore.

But I will look around the code a bit more.

I am not sure, what terrible would happen, if I rewrote the constructor of BlockChain.java from:

/**
 * Constructs a BlockChain connected to the given list of wallets and a store.
 */
public BlockChain(NetworkParameters params, List<Wallet> wallets,
                  BlockStore blockStore) throws BlockStoreException {
    this.blockStore = blockStore;
    chainHead = blockStore.getChainHead();
    log.info("chain head is at height {}:\n{}", chainHead.getHeight(), chainHead.getHeader());
    this.params = params;
    this.wallets = new ArrayList<Wallet>(wallets);
}

to (writing from my head, getters/setters might not be right, etc)

/**
 * Constructs a BlockChain connected to the given list of wallets and a store.
 */
public BlockChain(NetworkParameters params, List<Wallet> wallets,
                  BlockStore blockStore) throws BlockStoreException {
    this.blockStore = blockStore;
    chainHead = blockStore.getChainHead();
    log.info("chain head is at height {}:\n{}", chainHead.getHeight(), chainHead.getHeader());
    this.params = params;
    this.wallets = new ArrayList<Wallet>(wallets);
    StoredBlock sBlock = blockStore.getChainHead();
    Sha256Hash prevHash = sBlock.header.prevBlockHash();
    while (prevHash!=Sha256Hash.ZERO_HASH) {
        for (Wallet wallet:wallets){
            sendTransactionsToWallet(sBlock, NewBlockType.SIDE_CHAIN, wallet, sBlock.transactions);
        }
        sBlock = blockStore.get(hash);
        prevHash = sBlock.header.prevBlockHash();
    }
}

but again, I don't want to reinvent the wheel or anything.


Hashrate falls by factor of 1000x when now block is found?

How long does the fall last?

It's so that when a pool receives a new block, it has to remove all transactions that have been removed in that new block from the pool of transactions it was trying to put in their block.

So what I guess happens (I never wrote or examined any mining software) is that your miner receives a notification that a new block is found and so knows that it makes no sense to continue trying to find a new block because it will contain already-confirmed transactions. It will then wait until the pool received the new block as well, pruned its own transaction pool and started again with distributing work among miners.

I think this process can really only take mere seconds.


Authorization required error when accessing bitcoin using json RPC

Figured it out. Turns out that (at least on Bitcoind 0.8.1 on Ubuntu), specifying the conf file when starting bitcoind doesn't do anything. I was starting it with:

bitcoind -daemon -conf=./bitcoin.conf

from a bitcoin directory I had created /home/vijay/btc/. But bitcoind automatically uses the conf file in ~/.bitcoin/bitcoin.conf and mine was being completely ignored. Not sure what the point of the "-conf" option is!

So the solution was just to add my rpc username and password to the default conf file, which fixed the authorization failed error.


Armory Closing after Building Databases completes

From the Armory Support Page:

While Armory is still in Beta, there are still some subtle bugs that cause Armory to misbehave on systems. Armory developers are always working to fix these problems, but it usually requires a bug report submitted from Armory, or you can open a support ticket so we're aware of the problem and can try to fix it. One thing you can try, is to go into the start menu and find the entry for “Armory Bitcoin Client”. Click on the option that says “Armory (offline)”. This will load Armory without most of the operations that cause loading problems. Once that is open, you can go to “Help”–>”Revert All Settings”. This is effectively a “factory reset” of Armory to the state it was in before the first time you used it.


You need to run your bitcoinjs-server exit with --testnet.

bitcoinjs run --testnet

Source

Are there any existing public bitcoinjs exits running in testnet mode? I don't know.


How to implement Multisig transaction without using OP_CHECKMULTISIG

Yes, you can use a redeemScript that has a lot of OP_CHECKSIGs and boolean operations. You would have to enumerate all possible combinations of signatures however.

As a simple example, if you used a 2-of-2 multisig, traditionally your redeemScript would be

OP_2 <pubkey1> <pubkey2> OP_2 OP_CHECKMULTISIG

and the scriptSig is then

OP_0 <sig1> <sig2> <redeemScript>

Without OP_CHECKMULTISIG, your redeemScript would be

<pubkey1> OP_CHECKSIG OP_SWAP <pubkey2> OP_CHECKSIG OP_BOOLAND

and the scriptSig would be

<sig2> <sig1> <redeemScript>

For more complex multisigs with more keys and m-of-n, the scripts will be much more complicated with more OP_SWAPs, OP_BOOLORs, and OP_BOOLANDs.


could trezor be used to store passwords like 1 pass?

Have not used 1password or lastpass, but the USB-based Trezor hardware device does support:

Essentially a 2-factor keepass capability. See Trezor Password Manager TPM. TPM works fine across computers using Chrome and having Dropbox accounts.
A recoverable Universal Two Factor (U2F) authentication capability (unlike Yubikeys) just like the Ledger Nano. See U2F for Trezor details. For major sites supporting UTF see this Dongle List that is  broken up into different industry verticals.


Do I need the bitcoin client running in order to receive bitcoin?

No, you do not need to have the client running to receive payment on an existing address. Your transaction would go through because bitcoin transactions aren't contained on a local file, but a distributed ledger called the "blockchain."

You don't need to be logged in or anything to receive bitcoin.  What's important is to keep your wallet file containing your bitcoin private keys secret and backed up, as without those, you have no access to the address with your bitcoin.

In fact, a lot of people, fearing their computers being compromised by hackers, actually advocate you store large amounts of bitcoin in a wallet that's generated offline and stored on an offline computer, USB flash drive, or piece of paper.  This practice is called cold storage, and is a very good idea for large amounts of bitcoin you don't want to lose and have no intention to spend quickly.  So, the paranoid strategy would be to never have your wallet online, believe it or not.


Stores that accept bitcoins & Alternatives to Bitmit?

Sure, plenty of places accept bitcoin.

Here are a few links:

https://www.spendbitcoins.com/places/ - General list.
https://en.bitcoin.it/wiki/Trade - General list.
http://www.gyft.com/ (enables you to use giftcards at major retailers, from your phone and paid in BTC.)
http://coinmap.org/ for local places accepting bitcoin.
http://www.foodler.com for dinner.
https://www.bitcoinstore.com/ for electronics.
https://www.corkket.com/ for selling locally.


Yes, this is possible. Modify this code:

CAmount GetBlockSubsidy(int nHeight, const Consensus::Params& consensusParams)
{
    int halvings = nHeight / consensusParams.nSubsidyHalvingInterval;
    // Force block reward to zero when right shift is undefined.
    if (halvings >= 64)
        return 0;

    CAmount nSubsidy = 50 * COIN;
    // Subsidy is cut in half every 210,000 blocks which will occur approximately every 4 years.
    nSubsidy >>= halvings;
    return nSubsidy;
}

to read

CAmount GetBlockSubsidy(int nHeight, const Consensus::Params& consensusParams)
{
    int halvings = nHeight / consensusParams.nSubsidyHalvingInterval;
    // Force block reward to zero when right shift is undefined.
    if (halvings >= 64)
        return 0;
    if (nHeight == 1)
        return 200 * COIN;

    CAmount nSubsidy = 50 * COIN;
    // Subsidy is cut in half every 210,000 blocks which will occur approximately every 4 years.
    nSubsidy >>= halvings;
    return nSubsidy;
}


Is atomic swaps available for someone reasonably techical right now?

Atomic swaps can be performed, yes, they aren't just a theoretical thing. For example here is a tool on GitHub for creating atomic swap transactions between Decred, Bitcoin Core, Litecoin and a couple of other coins: https://github.com/decred/atomicswap

But I do not know of any exchanges or markets which support doing atomic swaps, you would probably have to manually find someone who is willing to sell ETH for BTC and do an atomic swap with you at an agreed price. LocalBitcoins might be a starting place to look, I'm unsure.

Hope that helps though


Exporting private key from expired bitcoin address (now showing as watch-only)

It is not possible to compute the private key for an address, ever, unless there are severe bugs in the wallet that holds the key.

Also addresses don't expire. For privacy reasons it is bad to reuse them, but their security does not depend on this.

In addition the "now showing as watch-only" in your question seems confused. Addresses don't become watch-only by being used; if it's watch-only it's because it has always been watch-only.


Double spending from "green addresses" & mitigation

If service1 trusts service0's green address implicitly, it can send the coins immediately; there is no advantage to waiting. The recipient can then decide how many blocks to wait for before treating the payment as confirmed.

If service0's green address isn't trusted, service1 needs to take into account that if service0 double-spends, service1 will be liable for the reversed transaction to service2. He can remedy it by resending with different coins, but it still won't look good.
The inputs of a transaction can reference outputs of transactions in the same block. So the block will include (interspersed with other transactions) a sequence of transactions where each one references the previous one.
As far as I know, no. An input can only reference the output of a previous transaction, where "previous" is either in a previous block or an earlier (in listing order) transaction in the same block. I couldn't find a definite confirmation for this, however.

Why - it makes sense and it makes sure there can be no cycles.

How - I suppose that when a client builds the list of transactions to include in a block, it puts aside any transactions which reference a transaction which was not yet included. Afterwards it can go back to add these transactions (multiple passes may be needed if there is a chain of multiple consecutive transactions).


Total number of hashes performed for bitcoin purposes?

Assuming the numbers in the link are correct, then I think this would be right.

I got the same result by multiplying every entry by (1,000,000,000,000 * 3600 * 24 * 2) and adding them up. Came out to 2.008E^26.

But the total number of hashes is much higher. Every block in the blockchain is hashed by every client, every transaction is created using several hashes, etc, etc.


How to get the list of transactions that has gone into an address with the amount and date?

You could achieve this by getting the transactions an address has been involved in and filtering on the outputs with that address hash.
We've just released our own free API called Blocktrail and provide SDKs for PHP, Python and NodeJS which make getting blockchain data trivial.
Assuming PHP you could do the following:

Initialise the Blocktrail SDK
use \Blocktrail\SDK\BlocktrailSDK;
$client = new BlocktrailSDK("MY_APIKEY", "MY_APISECRET", "BTC", false);

Get the address' transactions
$address = "1A4NfSJDzxzKgRrgfjxSAQ8hCPJJWKcmzX";
$page = 1;
$limit = 500;
$sortDir = "desc";
$transactions = $client->addressTransactions($address, $page, $limit, $sortDir);

For each transaction get the amount sent to this address from the outputs
$deposits = array();
foreach($transactions as $tx) {
    foreach($tx['outputs'] as $txout) {
      if($txout['address'] == $address) {
        $deposits[] = $txout['value'];
      }
    }
}

Tutorials and Examples
We'll be creating in-depth tutorials really soon, but for now you can check the API documentation for code examples and descriptions of the data returned.
There is also an example project on github: A Simple Block Explorer


How can I securely create a QR code from a bitcoin address?

Use any software you normally use to create QR codes. Ask it to create QR for text bitcoin:<address>.
That's all you need: a QR generation tool you trust.


https://en.bitcoin.it/wiki/Bitcoin_Jobs
http://workforbitcoin.com
http://www.btcworkers.com
http://bitgigs.com
http://www.rugatu.com
http://www.bitcoinerr.com
http://www.reddit.com/r/Jobs4bitcoins
http://coinworker.com
http://bittask.com

All of these boards are ugly, though. Wait for StackExchange to start using Bitcoins.


-SOLVED- I was Making a new genesis block and i got this error

Following this guide solved my problem my psztime was so long, so I had to make it short and they all were solved :) It successfully compiled and ran pretty well.


Bitcoin-Qt/bitcoind will reject new blocks whose timestamp is more than a couple hours  ahead of the previous block.  This means you could be nearly two hours behind and your node would still accept most new blocks.


bitcoind -- how can i get the number of peers to exceed eight?

8 peers is the number of outbound connections the client makes. So if you always have 8 connections, that probably means that people can't make inbound connections to your machine. This really has no harmful effects. You can't at all trust people who connected to you anyway. (You might have 70 inbound connections that are all from the same miscreant.)

The most likely reason for the difference is that one client has UPNP support and the other doesn't or doesn't have it enabled. If your machine is behind a NAT device that supports UPNP, that's probably the reason.


Ripple: a strange send I don't quite understand

The short answer: using the info you and your friend provided, Ripple did what was best for everyone.

I don't know how to pull up the details of the transaction number you link to (I have no affiliation with Ripple other than as a user). But using the Ripple Live Graph I can infer the account of your friend and I note that currently your friend has no trust line to Bitstamp.

  why didn't it send entirely Bitstamp BTC to Bitstamp?

So I'm guessing that what happened was that your friend had 0.1022 BTC IOU from Bitstamp but had the trust set to zero indicating they don't want more and would like to get rid of what they have (i.e. your friend told Ripple they don't trust Bitstamp). Your friend had specified that they trust you to pay them back BTC by opening a trust line to you

It's in your friends best interests to hold an IOU from a trusted source (you) rather than an untrusted source (Bitstamp). It's in your interest to have Bitstamp get the funds you asked to send in the cheapest way possible.

The way Ripple found to achieve both those results at once was to route part of your payment through your friend. Both directly sending back Bitstamp's IOU and routing through your friend had no transfer fee, only the 0.000010 XRP transaction fee) so either should be equally good to you.

  how are [we] supposed to settle that?

As with any loan between friends it's up to you. With some friends I've made my repayment policies very clear, with others I'm more informal. [As an asside, I'll note that previous ripple implementations like classic.ripplepay.com wouldn't let your friend trust you without you agreeing.]

  i.e. should I explicitly send BTC through Ripple to my friend

No, that would add to the debt, giving your friend more of your IOUs.

  or simply when he tries to spend them he'll tap from my pool (hence no explicit action is needed)?

That is most likely the best option, and certainly the simplest. When they next send a payment, Ripple will consider going through you. If the recipient trusts you then they may end up with your IOU (by the way your IOUs have no trasfer fee, Bitstamp IOUs have a 0.2% transfer fee).

If the recipient trusts Bitstamp (and you still hold the Bitstamp IOU) then the recipient may get Bitstamp IOUs and your IOU will decrease or zero.

If before this, you were to use your Bitstamp IOU in payments (e.g. to Bitstamp for withdraw) then you'd have a negative balance and your friend would be unable to use (spend) your IOU except to others that accept it (trust you).

If your friend wants to explicitly redeem your IOU (i.e. asks you to pay him back) you could send him actual bitcoin outside of Ripple and at the same time he'd pay you the matching amount in Ripple to zero/decrease your debt. If you hold Bitstamp IOUs (perhaps you get some more via a deposit just so you have enough to cover your debt because you were asked to) you can just tell your friend to simply pay himself via his Bitstamp account.


With Zebpay, you can sell directly and get your INR. You do not have to wait for a third party to buy your bitcoins like in a typical exchange.

I believe it is same with Coinbase to sell and get USD.

Sandeep Goenka, co-founder, Zebpay.


I'm worried I have lost my BTC from sending on my BTC Core 0.13.2 wallet

I think I am all good. Thanks Pieter for your input, maybe that is so. but I was worried as  none of the web blockchain transaction displayers showed a thing, but core was happy to display all funds gone. So I think it was just not getting out at all with Bitcoin Core, even though it was providing the "not found" (by blockchain etc) hashes of transactions.
I started a (Kleopatra verified!) Electrum wallet. This seems to be a Godsend. So much nicer to use, and no waiting for the blockchain. More data at the fingertips, specify fiat, it knows your capital gain, etc. etc.
Yes, I know the blockchain on your own device is the most robust way of handling your BTC but, oh the wait! The size! The stress (in my case)! The money lost whilst waiting for that chain to download the first time I bought in 2017 (which I didn't know at the time but I don't think I had to do. I could have bought 6 months before the peak, instead of the 2017 peak). The recent repartitioning / merging of hard drives and moving & deleting that had to go on to handle 300 Gb+ of chain... The many hours left on overnight even to catch up from 2015 onwards (when used in 2017-18 I had downloaded the whole chain but for some reason I lost a whole batch when I tuned back into crypto now things are moving again.) Overall, the headache of the locally held chain for me is something, as a newbie, I could have really done without (not to mention the sleepless night last night!)
Electrum took my private key and automatically acknowledged the full 0.2 BTC. I then made a transaction and for whatever reason I could see much better the satoshi per byte level and compare it with https://bitcoinfees.earn.com/#fees to make sure there was plenty enough to get it moving with the miners. Now the transaction is in progress and it's confirmed three times so far... a few more and it will be where I need it.
In the end the solution was so simple, I'm very disappointed in the staff at the 'exchange' who didn't know more to give me the tip. You think if you did this stuff all day you would at least have a clue about core wallets and potential problems/fixes. Another hardware data recovery mob that I spoke to here in Australia said that they often had people calling up with similar requests, but they couldn't help either, citing "some USA companies are beginning to get into this sort of recovery."
If there's any further problem I'll add it here, but otherwise assume happy endings (SFW) from one bitcoin 'newbie' that was scared witless he'd lost about 15 grand Aussie about half a day ago thru to now.
--Wow that was fast, 7 confirmations and my money is in the right spot. Phew! Hope this helps anyone in a similar space.


Where is the source code that allows new coins to be generated?

You are looking for the method CAmount GetBlockSubsidy(int nHeight, const Consensus::Params& consensusParams) in main.cpp.

CAmount GetBlockSubsidy(int nHeight, const Consensus::Params& consensusParams)
{
    int halvings = nHeight / consensusParams.nSubsidyHalvingInterval;
    // Force block reward to zero when right shift is undefined.
    if (halvings >= 64)
        return 0;

    CAmount nSubsidy = 50 * COIN;
    // Subsidy is cut in half every 210,000 blocks which will occur approximately every 4 years.
    nSubsidy >>= halvings;
    return nSubsidy;
}

Further explanation:
 nHeight is the number of blocks that have been found.
 consensusParams.nSubsidyHalvingInterval are 210000 blocks, the interval of the halvings
 COIN is 10^8, the number of satoshi in one bitcoin
 nSubsidy finally gives the number of satoshi that the coinbase may create


How do I know that a node provides the accurate blockchain

Edit: this answer is written assuming you are asking about ‘SPV’ or ‘light wallet’ implementations, not a full node implementation

  How do I know that that particular (malicious) node has the most recent or valid blockchain?

This is two separate questions: are you up to date? And is the info valid?

Up to date: it is possible for light wallets to query data from multiple network peers, though not every implementation will do so. This helps ensure no single node is ‘lying by omission’, which means they are withholding information from you (Interesting related info: ‘fraud proofs’ are apparently very, very difficult to craft. It is an ongoing area of research in the field). If you are only connected to malicious nodes, this may become an issue, though in practice it is not a difficult issue to overcome (see: Sybil attacks / eclipse attacks).

Some light wallets will connect to a server run by the developers of that wallet, while others will connect directly to a node(s) in the bitcoin network. Using a service that does not hardcode their own server into the wallet is probably better, though if they follow a standard HD wallet scheme it should be no problem importing your seed phrase to a different wallet in case that service goes down.

I think the best advice is to run your own node. Many light wallets allow you to point your wallet at your own node as a manual setup option. This gives you sovereignty, and greatly increased privacy as well.

Validity: light wallets work by downloading the chain of block headers, and then requesting info related to the wallet’s address’ from connected nodes. By only downloading the blockheaders, resource usage stays low enough for the wallet to work on mobile (less than 100mb for the entire bitcoin history, currently).

The header contains the transaction merkle root, which can be used to locally verify that a valid transaction is included in a certain block, without having all of that block’s data. A node will serve the transaction in question to the wallet, along with the intermediate hashes in the merkle tree. This allows the node to recalculate the merkle root locally, giving proof that the transaction is confirmed on the bitcoin network (and thus valid according to the network’s rules). If even one bit of information is changed, the merkle root will be calculated differently, and the wallet will know the transaction served is invalid.


Bitcoin core database gone after error no more free disk space? How can I recover my bitcoins?

This is not a complete answer, but the question implies a possible misunderstanding which this attempts to correct.

Summary: if you can rescue wallet.dat, you're fine.

The only valuable file in the Bitcoin Core user system is wallet.dat. The blockchain files are necessary for the application to be able to see the transactions on the blockchain that sent bitcoins to you and to figure out how many bitcoins you "own" (can spend). What is actually in wallet.dat are your private keys, which is all you need to have.

If Bitcoin Core doesn't have access to the blockchain data then it doesn't know that you have any bitcoins. Once it has access again -- after re-downloading (takes a long time!) -- on this or on another computer, you will be able to see your bitcoin balance.


Your 41.6 GH/s is certainly wrong. According to https://bitcoinwisdom.com/bitcoin/difficulty it's currently 757,561,871 GH/s = 757,561 TeraHash/s.

Also: it's "Tera", one r and capital T. Capitalization is important in the Metric prefixes.  https://en.wikipedia.org/wiki/Metric_prefix

Note also that cloud mining is usually a scam. Why would they give you money? Answer: they don't.


The levelDB gets corrupted if bitcoind stops abruptly, like during an outage.

I'm not that familiar with running bitcoin core on Windows, but this fixes the issue on Linux. It isn't the quickest or best solution, but if manually transferring wallet.dat isn't an option (and you can't dump the private key as another person suggested because bitcoind won't run) this may work for you:

Go into your bitcoin data folder and delete the 'blocks' and 'chainstate' directories and restart bitcoind. It will of course have to re-download the blockchain and re-index which will take a long time, maybe even a week, but it will eventually catch up and you can use bitcoin core again.


developing an app that integrates with bitcoin

If you are integrating with bitcoin directly, then you can use the bitcoin testnet (https://en.bitcoin.it/wiki/Testnet).

If you are using a payment processor, Coinbase does not have sandbox feature like PayPal, although they have expressed interest in creating one based on bitcoin's testnet.  Coinbase does allow sending test payment notifications (IPN) from their merchant settings page (https://coinbase.com/merchant_settings).

Bitpay's FAQ (https://bitpay.com/faq) states that they too do not have a sandbox, and advises testing with small amounts of BTC.


I can't find much on writing data to the litecoin blockchain, you might need to code something yourself, perhaps taking the data you want to upload, chunk it and write it by using many transactions. To read it back you need to read these transactions from the blockchain and put the data chunks back together.

If I were you I would look into Ethereum instead. Ethereum has the ability to let you write customized smart contracts that can accept files/pictures data and store it forever on the Eth blockchain. If this gets too expensive you can offload storage using IPFS, so that the Eth blockchain would need to store only the hash of the files instead of the whole files.


Armory appears to be written in C++ and Python, two languages that are not supported by ChromeOS by default. You can take a look at the Armory source code here.

Because ChromeOS doesn't support these languages, there is no way to run Armory on a Chromebook without significant modifications, like rooting the device to get to the system shell or formatting the disk and installing Linux. I have heard of people doing both of these things in the past, but I'm not sure which specific device is required or how much effort they take.

If you are looking for a cheap computer to use for this sort of thing, the simplest bet in my opinion would be to purchase a low cost Linux desktop/laptop. This would provide you much more flexibility in what client you use, and would also help keep your wallets private. ChromeOS is pretty secure when it comes down to it, but Google+ is integrated very deeply with the OS, which may not be desirable for what you want to do.


If the top 6 mining pools started mining empty blocks, what would happen?

There would be a lot of empty blocks and the number of unconfirmed transactions would increase dramatically. But at the same time, miners who are including transactions in their blocks will start being paid more and more. Those miners including transactions in their blocks will be able to collect all of the transaction fees that are being paid. Because the number of transactions that can be confirmed in a given amount of time has significantly decreased, people will begin paying more and more in transaction fees in the hopes that their transaction gets selected. So the miners who are still including transactions are going to get paid even more than they were before.

This scenario is unlikely to happen, or if it did, it would not last long. Bitcoin's incentives structure makes it so that miners will want to include transactions in their blocks. Otherwise they will be missing out on money that they could be earning. We expect miners to be greedy (after all, most people want to have more money) and them being greedy is exactly what maintains the network.


Assuming these are exchanges with their own wallets, you would need to first transfer your coins to your wallet on that exchange, while of course paying the required fees.. Using the numbers in your example, it would seem far more prudent to sit on your funds until you can sell at a gain (you don't lose until you sell).

Regardless, yes, you can game different exchanges. The risks are (IMO)

1) you pay a fee
2) you hope that the price doesn't drop on your intended target
   during your pending transaction.


What happens under the hood when I use BTC to buy an Altcoin on an exchange?

Nothing will happen "under the hood" in the blockchain of a cryptocurrency when you trade on an exchange. The exchange has many wallets where the funds of the user are stored. The exchange has also a database where they store the information about the assets of the user, their trades and their resulting balance. Example:

A person A deposits 1 btc to exchange XY. Person B deposits 10 eth to exchange XY (these are transactions which you can see in the public blockchain of the respective blockchain).

Now the exchange has 1 btc and 10 eth and in their database they write analogous: "A has 1 btc; B has 10 eth".

Now person A wants to exchange his 1 btc into eth. So he buys 10 eth from person B and pays with 1 btc. This trade will not cause any transaction which will be added to the blockchain, because it is an exchange-specific process. When the trade is executed, exchange XY write in his database something like "A has 10 eth; B has 1 btc". (When person A, for example, now wants to withdraw his 10 eth to his ethereum-cold-wallet this would cause a transaction in the ethereum-blockchain.)


There is no way to reverse a bitcoin transaction. Transactions on the bitcoin network are designed to be permanent and irreversible.

You can use a Bitcoin Cash blockchain explorer to see where the BCC now resides by checking the address you sent from and to.


Cannot check balance with blockchain.info API

You are using the old, version 1, blockchain wallet API which was deprecated earlier this year.  None of the calls you are trying will work.

The new, version 2, API requires you to run a local nodeJS service to handle the calls. This will require you to have root access to your webserver so you will need to use a VPS instead of a basic shared web host.

You will need to request an API key here https://blockchain.info/api/api_create_code

Install nodeJS
Install NPM
Install blockchain-wallet npm install -g blockchain-wallet-service
It should install to usr/local/bin
Run the service node blockchain-wallet-service start --port 3030
Now it's running, but you still need to complete the handshake with blockchain's server. We can do that with a cURL request in a PHP file.

some_file.php

//replace with your GUID, password and API key
 $url = "http://127.0.0.1:3030/merchant/YOUR-GUID/login?password=YOUR-PASSWORD&api_code=YOUR-API-CODE";
 $ch = curl_init();
 curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
 curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
 curl_setopt($ch, CURLOPT_URL, $url);
 $ccc = curl_exec($ch);
 $json = json_decode($ccc, true);
 var_dump($json);

Save the above and run it on your server. The file should keep spinning and loading since blockchain doesn't recognize the IP address. Wait for it to timeout about 60 seconds, and then check your email. Blockchain should have sent you an API access attempt showing what IP tried to connect. Follow the link and authorize the attempt, also the IP address from the email and whitelist it in your wallet account settings.

Now try running the file again.
If you did everything correctly you should see a response that lists your GUID followed by Success TRUE

Now you're connected and you can start sending requests with your wallet.

Check their API documentation for example calls once you're set up. https://blockchain.info/api/blockchain_wallet_api


The comment stating n “has to be prime” is a bit confusing.

The order of base point “has” to be prime in the sense that this is a requirement in the particular documents defining standard curves—for example, in SECG, which includes secp256k1. Bitcoin's base point order r is prime.

In SECG, it is also stated that cofactor of secp256k1 curve is 1, which makes n = r × 1, again prime. A group of prime order is obviously cyclic.


How to create an inventory message and send it?

You can use Peter Todd's python-bitcoinlib, which contains builders for all the network messages.

Simple example, given a list of hashes:

from bitcoin.net import *
from bitcoin.messages import *

m = msg_inv()
for h in hashes:
    assert len(h) == 32
    inv = CInv()
    inv.type = 1  # TX
    inv.hash = h
    m.inv.append(inv)

inv_msg = m.serialize()

This assumes that the list of hashes you have are little endian unhexlified strings.


Quote from: theymos [BitcoinTalk.org admin] on April 17, 2013, 11:20:31 PM:

  I'll probably release Satoshi's PMs and logged IPs addresses in ~8 years. This'd probably be of great historical interest. (Though he always used Tor, as far as I can tell.)


Which mining pools do not require account creation?

You can try http://p2pool.info/

And P2Pool.info does not keep fees, they redistribute it ;)

In general you don't have to subscribe to P2P Pool (just search for "p2p bitcoin pool").


What are the standard formats of transaction outputs?

AFAIK there are 5 different standard non-SegWit transaction types, and 4 SegWit ones.

Non-SegWit:

Pay to public key (P2PK)

PUSH (1 byte) + <compressed/uncompressed_pk> (33/65 bytes) + OP_CHECKSIG (1 byte)

Pay to public key hash (P2PKH)

OP_DUP (1 byte) + OP_HASH160 (1 byte) + PUSH (1 byte) + <hash_160(PK)> (20 bytes) + OP_EQUALVERIFY (1 byte) + OP_CHECKSIG (1 byte)

Multisig (P2MS)

<number_of_PKs> (1 byte) PUSH (1 byte) <PK_0> (33/65 bytes) PUSH (1 byte) <PK_1> (33/65 bytes)  ... PUSH (1 byte) <PK_n-1> (33/65 bytes) OP_CHECKMULTISIG (1 byte)

P2MS allow up to 15-15 scripts, however only up to 3-3 are standard.

Pay to script hash (P2SH)

OP_HASH160 (1 byte) + PUSH (1 byte) + <hash160(redeem_script)> (20 bytes) + OP_EQUAL (1 byte)

OP_Return

OP_RETURN (1 byte) PUSH (1 byte) <0 to 83 bytes of data>

SegWit:

Regarding segwit types, there are two non-native and two native ones.

Native Pay to witness public key hash (P2WPKH)

OP_0 (1 byte) PUSH (1 byte) <hash 160(PK*)> (20 bytes)

Native Pay to witness script hash (P2WSH)

OP_0 (1 byte) PUSH (1 byte) <script_hash> (32 bytes)

Pay to witness public key hash encapsulated in a pay to script hash (P2SH-P2WPKH)

The redeem script follows the same structure than native P2WPKH:

redeem_script = OP_0 (1 byte) PUSH (1 byte) <hash_160(PK*)> (20 bytes)

While the external structure of the script (scriptPubKey) is as any other P2SH:

OP_HASH160 (1 byte) + PUSH (1 byte) + <hash_160(redeeem_script)> (20 bytes) + OP_EQUAL (1 byte)

Pay to witness script hash encapsulated in a pay to script hash (P2SH-P2WSH)

The redeem script follows the same structure than native P2WSH:

redeem_script = OP_0 (1 byte) PUSH (1 byte) <script_hash> (32 bytes)

While the external structure of the script (scriptPubKey) is as any other P2SH:

OP_HASH160 (1 byte) + PUSH (1 byte) + <hash_160(redeeem_script)> (20 bytes) + OP_EQUAL (1 byte)

*In P2WPKH scripts the hash 160 should correspond to a compressed public key, otherwise the funds will be lost.


I know that for a mining reward, a (special?) transaction is included in the the block (in the merkle tree I believe?)

Yes, the so-called coinbase transaction that sends (currently) 12.5btc to the address of the mining node/pool/etc.

  But how is a transaction fee payed out exactly?
  Is this also a special transaction?
  I would imagine the sender of the transaction has to then also include an extra transaction to pay out the fee?

The fee is payed implicitly and it is not a special transaction. Each transaction has some inputs (addresses) and some outputs (addresses). The transaction fee is equal to: inputs value - output value. e.g. if the inputs are 1btc in total and sends to outputs a total value of 0.9995btc the remainder of 0.0005btc is payed as a transaction fee to the address specified in the coinbase transaction (miners address).


What are the advantages for an user that is running a Bitcoin full node?

You validate your own UTXO without any external services that may play for your disadvantage, no middleman needed
It's the most privacy-preserving and secure way of using bitcoin. Lightweight-clients have some privacy issues, not too many people are reviewing their code.
The process of setting it up and using bitcoin core is a major step in one's education when it comes to bitcoin. More knowledge = advantage.
You have some voting power on consensus rules, like in UASF.


How is the reward that you got after calculating the right hash added in the blockchain?

When you are mining, you always compute hashes of blocks assuming that you will be the one to find the block. So you already include this special transaction, known as a coinbase transaction (not to be confused with a transaction made using the service Coinbase - here coinbase just means coin generation), in the block you're hashing. If you're right, then great, you've found a block and included a transaction that sends 25 BTC + transaction fees to yourself. If you're wrong, and someone else finds the block first, there's no harm in that. Just give up on the current block and start working on the next one.

For a more technical side, when you compute a hash you're really hashing the block header. It includes a bunch of things, one of which is the hashMerkleRoot, a hash of the transactions in the block.


If BTC.com has the highest hash rate, then why is it not the only pool prodcuing the blocks?

Because it is like a lottery. You're not bound to win all the time, even if you "bought" the majority of tickets.

Everyone basically has a % chance of finding a new block ( which correlates with the amount of hashpower you have  ofcourse.)

Unless ofcourse you do a 51% attack, https://www.investopedia.com/terms/1/51-attack.asp, where certain blocks would be orphaned (not confirmed, since nodes are bound to follow the longest chain.

You could basically prevent other miners from mining any blocks, since you hypothetically will always find a block before they do ( and thus creating the longest chain.)


A blockchain cannot be fraudulent. The blockchain that is "the blockchain" is the valid chain with the most work. If there were a chain which included a transaction that was the double spending transaction but not the original and that chain had more work than a different chain, then that chain is "the blockchain" and is the correct one.

If a blockchain contains two transactions which conflicts with each other (i.e. the original and the double spend are both in the chain), then that blockcahin is completely invalid and no one would accept it unless they specifically modified their software to accept it.

If a user is defrauded because someone performed this sort of attack (broadcast a double spending transaction and the double spend confirmed), the user has no way to tell the network nor does the network care if such an attack occurred. What happened was completely valid to the network so long as only one of the two transactions (either the original or the double spend) is included in the blockchain. This risk is why it is recommended that you wait for a transaction to be confirmed and have multiple confirmations before accepting a payment. The chain containing that double spend is not fraudulent.


Statement: for an attacker to change history, they must solve computational puzzles at a faster rate than the rest of the participants combined

I will answer my own question for anyone that might be wondering the same.

If a majority of CPU power is controlled by honest nodes, the honest chain will grow the fastest and outpace any competing chains. To modify a past block, an attacker would have to redo the proof-of-work of the block and all blocks after it and then catch up with and surpass the work of the honest nodes.


Why do I get this error when I try to install CGMiner on my RaspberryPi?

Might as well give this old question an answer.

cgminer 3.7.2 (which was obsolete even when this question was asked) required scrypt to be enabled as a compile-time option with ./configure --enable-scrypt.  The asker evidently did not enable it, which is why it does not work.

It appears that current versions of cgminer have removed scrypt support altogether.

As Hồ Tuấn Kiệt points out, a Raspberry Pi would be hopelessly underpowered for CPU mining of any kind, so this would be a really ineffective idea even if it worked.

The asker probably got this idea because there is lots of discussion on the Internet about using the Raspberry Pi for mining.  However, most people use it in a very different way: not to do the mining itself, but as a controller for ASIC mining devices (typically for Bitcoin and other SHA256 coins, not scrypt).  It is well suited to the latter task, since controlling ASIC miners requires very little in the way of CPU performance; just the ability to run a minimal operating system with network access, and some simple software to fetch work from the network and feed it to the ASICs.  The Raspberry Pi is certainly capable of that task, and it is cheap and uses little electricity of its own.  But it isn't suitable for actually mining with its own CPU or GPU.


Armory does not work if the blockchain is pruned. You must have the full blockchain in order for Armory to work.


Should I always run "make clean" between building different PR branches of Bitcoin Core?

You could always run make clean between builds but a lot of the time it won't be necessary and it is slower.
Pieter Wuille usually doesn't run make clean and only runs it when the build fails.
If it still fails after that he runs git clean -dfx. Warning: This deletes everything and resets your work directory to a fresh checkout. You'll need to autogen.sh again.
(Glen Willen suggests running git clean -dfX instead of git clean -dfx as X only removes ignored files, x also removes locally added non-ignored files, including e.g. new code you did not yet call git add on)
make clean is only necessary when the configuration changes. This could be because you run ./configure with different flags or it could be because there are substantial changes to the autoconf/automake scripts when changing branches. Of course the act of changing branches isn't relevant as the build system doesn't know or care that you are using Git. The build system just sees some code and/or configure scripts changed and re-runs them as necessary. Without make clean it will just see existing .o files not realizing that the rules used to build them have changed
Jon Atack usually doesn't run make clean but does if there is slight weirdness or if switching to fuzz build or back.
Thanks to Pieter Wuille, Jon Atack, Marco Falke and Glen Willen for answering this question on IRC.


Would proxying a lightning hot-wallet with a lightning cold-wallet make the hot-wallet safer?

First of all at this stage all lightning network nodes implementations are hot wallets. There are people / teams working on hardware wallets in lightning. Also I don't get your base assumption why you would trust casa which I believe  is not open source more than trusting btc pay server which I believe is open source. The only reason I see is that you control the hardware of your casa node and it is not some machine somewhere on the web in some datacenter.

But let us assume your setup and assumptions are valid then in step 6 and 7 of your process you don't need to close the channel. You could just withdraw the funds from your HWN to your casa node. As the entire channel balance is now at casa side there is no risk with HWN being compromised. This is as good as closing a channel moving funds and create a new one but saves onchain tx and fees.

In step 3 it is important to note that if you casa ode owns those payment channels your casa node can't receive funds or error payments to the HWN. Casa needs inbound capacity. So either you have others open channels to you (e. G. Your customers) or you have to use one of the many submarine swap services that exchange onchain to offchain funds. Such a service could also be used in step 6 and 7.

Overall the node of btc pay server could be private and configured to only accept traffic on port 9375 from your casa node. In this way you make sure only you have a payment channel with it. Since without rendez vous Routing all invoices of your store point to your casa node your cars node might now be at risk.

That all being said it seems to me that for the concerns that you have you don't need this setup with a proxy node. I am not saying that such a setup might not make sense for other reasons.


How can hackers cash out stolen bitcoin?

Interesting points Paper, here some of my thoughts...

As you said, on the underground (i.e. TOR) there are forums where thieves are selling dirty coins, with a favorable exchange rate (1 clean coin for 2 dirty coins for example). But to avoid scam I suppose they will use some kind of anonymous escrow service to perform the exchange, to guarantee that both parties are willing to complete the transaction.

Mixing service are also risky since they only guarantee anonymity if there are actually other user's coins to mix with. I remember some time ago, when a thief sent a huge amount of stolen coins at once to a mixing service, the returning coins were practically the same since on the mixing service there wasn't other users mixing such big amounts.

I don't get the point about "his network of Bitcoin address" what you mean? You can generate thousands of addresses and send coins back and forth, but this will actually just obfuscate (you can always track from start address to destination). The only way to really mix them, is to mix with other user's coins.

Furthermore many stolen coins are probably used to purchase illegal items from hidden markets  (drugs, weapons, pretty much anything). So they are actually "enjoying" them without the need to exchange them in "real" currencies.

And last but not least, in person exchange (for example thorough localbitcoins.com or another local directory for Bitcoin buyer and sellers)

Cheers


Or is is possible to allocate multiple cores(not threads) to JSON rpc

No. The problem is not to do with thread or core allocation. Rather Bitcoin Core makes use of locks to keep the chain state consistent when multiple threads may access it. In this case, you will need to access the chain state to get transactions so multiple getrawtransaction calls cannot really be run in parallel (locks aren't held for the entire call, but they are held for the parts that matter). So adding more cores or threads won't help at all.

The only thing that does help is to use the blockhash parameter. Without it, getrawtransaction will wait until Bitcoin Core isn't in the middle of processing multiple blocks, and the check and wait for this takes some time. However if you specify the blockhash, it will know immediately which block to look in and quickly look it up, no blocking or waiting for blocks to be processed. So this will be faster than without.

Otherwise there's nothing else that you can do.


How to calculate low/medium/high fee transaction fee?

Here is a post The Challenges of Bitcoin Transaction Fee Estimation discussing the determination of Bitcoin fees.


Is there a significance as to why bitcoin mining "costs" time/energy/money?

I have heard that [...] when more miners join, the value of bitcoins would rise because there would be additional resources that would be used to process the transactions.

I do not see why more validation power would make the currency unit more valuable. But before this discussion, lets clarify the technical side.

In general, the idea behind the Bitcoin protocol is to achieve a consensus view on the common transaction ledger in a decentralised way, i.e. no third-party intermediary to act as a clearing agency etc.
To avoid double-spending of coins, transactions need to be verified by miners before insertion into the blockchain - also, all nodes will synchronise with the longest chain available, so effectively the system works on a majority-based consensus system (majority of the miners determine the global chain).

Now, this would open up to security problems - one example is the Sybil attack, where an adversary simply creates countless virtual identities who all vote for his (potentially false) chain.

This is where the Proof-of-Work (PoW) scheme used in Bitcoin's mining protocol comes in. It is purposefully made computationally difficult for miners to verify blocks. Because of this, miners need to invest resources (energy, money) in order to participate - the rationale is that it is much harder to fake computational power in the network than simple identities, preventing a Sybil attack.

Back to the value of Bitcoin: Note that the following is rather subjective, and highly controversial.

I argue that it is simply determined by market supply and demand. Following this basic logic, the value of 1 BTC must increase in the number of users to join the network, since the monetary base of Bitcoin is limited by design. Because this is unrealistic in the long run, this argument can not be final.

On top of this, we can see extreme levels of speculation on cryptocurrency exchanges, driven by developments such as

adaptation (e.g. recognising Bitcoin as legal tender in some countries, more vendors' acceptance...)
news flow on upcoming updates, increasing awareness of cryptocurrencies and the resulting interest by the public and corporations
negative economic/political activity in some economies might lead to more demand for bitcoin

  On the contrary, miners enter or leave the mining process based on whether the potential reward for successfully mining a block is "worth" the work, with the value of the reward being strictly based off the current market value of a bitcoin.

Yes, this is correct. A causality between hashing power and the market value of 1 BTC is not apparent, other than that new miners will likely participate in the system themselves, increasing demand. Rather, as the market value increases, mining becomes more attractive in the short run. Note that after each 2,016 blocks, mining difficulty is adjusted to maintain a fixed mining rate, so then it becomes more expensive and miners will have to decide if they continue participating.


How do I update offline Electrum wallet after receiving payment with Online seedless wallet?

If you have a seedless wallet the coins received there will need to be signed from the offline computer to be able to spend them. History will be showed in your online PC.

Thanks for pointing out the outdated info.

UPDATE:

You don't need the offline wallet to know how much coins it has, only the online needs that. When you make a payment from the online seedless wallet it knows how much it owns, so the client will spit out the unsigned transaction that needs to be transferred to the offline wallet (with a USB stick or webcam) for it to sign it and then transfer it again to the online PC in order to broadcast it from Electrum.


Most transactions contain a digital signature which signs a hash of the transaction. Usually this hash includes the entirety of the transaction, so changing any part of the transaction would invalidate the signature and thus invalidate the entire transaction. The miner won't be able to change the output values you signed, because it would change the hash.


"Fork choice rule" : A general term? or a specific algorithm?

A fork choice rule is a general term.

For some history I've found, one of the early written descriptions of the term is from March 2017
https://medium.com/@VitalikButerin/minimal-slashing-conditions-20f0b500fc6c

  A fork choice rule is a function, evaluated by the client, that takes
  as input the set of blocks and other messages that have been produced,
  and outputs to the client what the “canonical chain” is.

August 2015 may be the first time "fork-choice rule" was written in a blog post.
https://blog.ethereum.org/2015/08/01/introducing-casper-friendly-ghost

The 2013 GHOST paper is one of the earliest, prominent publications of a fork choice rule different from Bitcoin's, but it did not specifically mention the term.


Answers to your respective questions:

Since 0.12, bitcoind supports cookie file authentication. This means that on startup of bitcoind, a file with a random key in it is created. Anyone who can present the contents of that file to the running bitcoind is allowed access. Since bitcoin-cli runs locally and as the same user, it can read this file and do so.
Bitcoin does not have any concept of accounts (at least not at the protocol level). Generated funds by bitcoind's built-in miner are sent to an address taken from your local wallet. If you want to modify that, use mining software instead of the built-in miner (which is only there for testing purposes).
The built-in miner is off by default. You can enable it by setting gen=1 in the bitcoin.conf file, but I would strongly discourage you from doing so. The chance of finding a block using that setup is about 1 in a billion, if you leave it running for 10000 years. If you insist on using your CPU for mining (which won't ever be profitable), at least use optimized software like bfgminer, and sign up with a pool, so you can get small rewards for work, rather than waiting for a lottery you'll never win.

Update august 2016: The internal miner is removed entirely in Bitcoin Core 0.13.


How are transactions efficiently distributed to network nodes before inclusion within blocks?

Have a look into the specifications https://en.bitcoin.it/wiki/Protocol_specification

Check the "inv" --> "getdata" --> "tx" sequence of transaction distribution


The “taint” of a Bitcoin transaction evaluates the association between an address and earlier transaction addresses. The more “‘taint” the stronger the link between the two addresses.

https://bitcoin-class.weebly.com/taint-analysis.html


creating a hash that starts wtih 9 zeros

This exercise is actually a good way to understand proof-of-work. In order solve your problem, you need to pass your input into SHA256 until you get a hash with 9 zeros, there is no other way around it other than brute force. This is because SHA256 is a one-way function which cannot be solved in reverse. As you've already learned, brute forcing will take many guesses. It would be a good exercise to calculate just how many guesses it would take and how fast normal hardware could do this:

Get the target value. Your maximum target is:
000000000fffffffffffffffffffffffffffffffffffffffffffffffffffffff

Divide by ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff, which is the maximum value of a 256-bit number. You now have the probability of a single hash solving a block. Or, as you pointed out, you can calculate the probability of getting 9 zeros in a row in base 16 (1/16^9). Using wolframalpha,
target / max256 = 1.46E-11

Take the reciprocal of the probability to get the average number of hashes to solve a block.
1/1.46E-11 = 6.85E10 or
68.5 Billion

Divide the average number of hashes by the hashrate of your hardware (a typical laptop does can maybe do around 100k Hash/sec) to get the average number of seconds required to solve a block.
6.85E10 / 100,000 = 685,000 seconds or just over a week

Nowadays Bitcoin is mined using dedicated hardware (ASICs) that can do terahashes/second and solve this in less than a second, however, they are usually configured to mine on a pool using a specific protocol (e.g. stratum) so it would require either modifying the miner software or the pool software if you wanted to pass in arbitrary data to hash. Since this is a finance class, this is not likely the purpose of the assignment and was probably designed for you to fail to teach a lesson.
Also, here is another resource that might help: Generation Calculator.


The easyest way for you would be somthing like localbitcoins. But you can use any exchange where you can transfer money to from your bank (Bitstamp, Justcoin, Bitcurex, ...)


Free version to the previously proposed paid version:

  Actually, you CAN get the whole Bitcoin trades history from Bitcoincharts in CSV format here : http://api.bitcoincharts.com/v1/csv/

  it is updated twice a day for active exchanges, and there is a few dead exchanges, too.

  EDIT: Since there are no column headers in the CSVs, here's what they are : column 1) the trade's timestamp, column 2) the price, column 3) the volume of the trade

Please search first.


What is the point of a permissioned blockchain?

If your nodes are trusted, though, a blockchain isn't necessary at all, you know the code isn't malicious. So what is the point of a permissioned blockchain?

Knowing someone's identity is not necessarily equivalent to trusting them, and not all trust is equivalent.

Consider the typical example of a permissioned blockchain. Two (or more) banks want to batch hundreds of payments a day into a single daily settlement payment. Each bank trusts the other banks to be solvent, and to pay whatever they owe. However, none of the banks trust the other banks to calculate the payments correctly. Instead, they all do the calculation separately, and only make payments if they agree about the result.

You could trust your business partners to do the calculation themselves, but they could give you the wrong number, either by accident, because of a rogue employee, or intentionally. Trusting someone's honesty is not the same thing as trusting their competence.

Let's also consider the opposite of the first example, where you don't know the identities of everyone involved. Imagine you have a Bitcoin sidechain, where instead of mining, a permissioned set of nodes creates blocks. In addition, instead of transaction fees, you give out API keys, which are permitted to create a certain number of transactions per hour. Some of the people who are creating transactions are people who you don't know.

In this example, you trust other nodes to not spam the network with useless transactions, but you don't allow them to spend other people's money, or create money out of thin air.


How does first seen replace by fee work?

Right now, for the most part, Bitcoin miners follow a First-Seen-Safe rule: If 2 conflicting transactions show up in the mempool, the miner sticks with the one it saw first.

Replace-By-Fee would enable miners to remove transactions from the mempool based on which transaction pays the higher fee. This is problematic because it enables fraud. If I pay a merchant and walk out, I can then easily broadcast a conflicting transaction which sends the money back to me with only a slightly higher fee. The merchant doesn't get paid, but I get the goods for a slightly larger transaction fee.

With Child-Pays-For-Parent, an unconfirmed transaction(parent) can be raised in mining priority by spending their output(children). The extra fees that would come from children offer incentive for the miner to include the parent transaction. CPFP relates to RBF as a way for a merchant to fight fraud. If a merchant detects that a payment they were expecting has been rerouted, they can raise the priority of their preferred transaction using CPFP. This is a contentious solution to make RBF acceptable.

First-Seen-Safe Replace-By-Fee follows the RBF rules, but puts some requirements around replacing transactions in the mempool. When replacing a transaction based on higher fee, all the amounts of all the outputs from the original transaction need to be met. You can add and remove inputs, increase past output amounts, and add new outputs. You are allowed to modify transactions as long as you meet or exceed the past outputs.

With FSSRBF you can safely accept transactions that spend confirmed outputs, but not unconfirmed transactions spending outputs of other unconfirmed transactions. CPFP is useful beyond RBF, but is not necessary for FSSRBF usability.


Error compiling altcoin-qt for Windows, getting a GCC internal compiler error

Most likely cause: the compiler ran out of memory.


Everything should transfer just fine, but as with any change to your system you should take a backup of your wallet before upgrading, just in case.


How complex can bitcoin multi-signature addresses be?

The limits of such constructs are the 520 bytes of the redeem script (its opcodes). A signature is roughly 70 Bytes (length code, r-key, s-key ...), so you can calculate what n-of-m versions fit into 520 bytes.
All your ideas are possible with bitcoin.

E.g. you can create a 2 out of 6 multisig for B,C,D,E,F and G.

When you say "A" can sign it, I believe it is the same as "H".
Then you run into 8 keys (8x70=560 bam...), so you are beyond the limits.
You might circumvent this when creating a simple "smart contract":

if <pubkey A> OR <pubkey B> else <2-of-6 msig>

then you are again in the limits. These type of ideas are explained e.g. in Andreas' book "Mastering Bitcoin, 2nd edition", chapter 7 "Advanced Transactions and Scripting".


Bitcoind to use static RPC authentication cookie from file?

You can't. The cookie file is for bitcoind to write it's automatically generated credentials to for other software to read. If you want to set the RPC credentials, you need to do so within the bitcoin.conf file using the rpcauth option (or rpcuser and rpcpassword but these are deprecated). These could also be specified on the command line.


Does bitcoin deflate or does it appreciate?

Since bitcoin is appreciating, the amount needed to buy the same stuff will be less in the future. That makes the economy around bitcoin deflationary.


Why use the master key to encrypt private key? And why just store unencrypted master key in memory?

1、Why not directly use the key derived based the wallet's passphrase?

Encrypting a master key which is then used to encrypt the actual keys is a fairly standard practice for encrypting data. Doing this allows the master key to remain the same so that changing the password does not result in having to decrypt and then re-encrypt all of the encrypted data. It only requires decrypting and re-encrypting the encryption key.

  2、Why the unencrypted master key is stored in memory, why not private keys?

A wallet can contain thousands of keys (or tens of thousdands, or even hundreds of thousands). Keeping all of these keys in memory will use memory and possibly take up so much memory that the system is unable to keep running bitcoind. A master key is fixed size though, and fairly small, so keeping that in memory is not a burden.


Mining costs, impact on long term viability of BTC

As Bitcoin expands there will be much greater numbers of transactions while the cost of maintaining the network will remain relatively constant, if not decrease, as power-inefficient GPUs and higher consumption ASICs are replaced by more efficient ASICs. The cost per transaction will thus drop.

Also, keep in mind that it isn't replacing nothing, it's replacing centralized accounting which has a significant cost per transaction.


Pros & Cons of Using the "Satoshi" Method to Track User Deposits

That's a question about Ethereum, a system that's notoriously difficult to accept payments with due to some incredibly bad design decisions. Ethereum has operational costs for making new addresses which make this sort of poor engineering attractive.
We have no need to do anything ridiculous like that to try to distinguish payments, we can just make a new address per payment and have people pay to it. There's no need to try to re-use addresses as there's no resource being consumed by you creating new ones. All this would serve to do is cause mass confusion, difficulty when people made two transactions to pay an invoice, and unmitigated confusion about who owns what payment if anything goes awry.
There is no pros at all to what you're describing.
One new address, per invoice, per user. There's no reason to over think it.


I'm going to make a wild stab in the dark, that you are probably moving bitcoins from an exchange, because if you are new to this you are probably not making multi-party payments.

The earlier of the two transactions (green) is showing several previous addresses, paying several others. This would occur for instance when you withdraw from an exchange: ie they will be paying many people who are all making withdrawals, from coins that were deposited at many addresses.

The second payment, I am going to assume is a consolidation payment. As you say you only made one transaction, I can only think that this is either an exchange consolidating your deposit (because your first transaction was from one exchange to another), or else you withdrew to an online wallet service which is doing the same thing - consolidating. (Beware)

There is a third alternative, and that is that your machine has been compromised and you have just lost some bitcoins. I hope not.


There are a few ways that you can create cold storage.

One possibility is to make a new installation of Bitcoin Core on an offline PC, one that is never connected to the internet. This PC will generate addresses and you can add those as a 'watch-only' address on an online PC to monitor incoming payments.

It is possible to update your offline PC, for example, using a bootstrap.dat file so that it will have the blockchain without ever needing to connect.

This will work with Windows 7 and any platform where Bitcoin Core can be installed including on several versions of Linux.

Paper wallets do not require a computer until you want to import the keys. You can import the public address as a 'watch-only' address or when you are ready to spend your BTC somewhere, you can import the private key.


How can I recover from a corrupted blkindex.dat on Ubuntu 12.10?

On Linux, the Bitcoin client data is kept in the .bitcoin directory in your home directory. Go to ~/.bitcoin/ and you'll see the files in there. You may need to toggle Show Hidden Files in your file manager in order to see the directory.

If you remove blkindex.dat, the client will have to redownload the blockchain. I just tested this locally by moving my copy of the file to another file name temporarily - the client resync'd.

Since your copy of the index is corrupted apparently, it sounds like you need to delete it and resync.

A note: be careful to do not erase your wallet.dat. I recommend you back it up before. Your wallet.dat is your private keys.


How to deal with the wallets with very small amount of Bitcoins?

Two ways:

Create a transaction with no fee and wait as long as it takes for it to confirm.
Aggregate several such accounts into a single wallet so you can combine them in a single transaction.

Neither way is likely to be worth the effort though, unless you have a large number of such accounts.


It works fine.  Your wallet will have the option to create receive addresses.  When you withdraw coins from your broker, you give them this address, and they send coins there; after the transaction confirms, you can spend those coins any time you want, by sending them out to someone else's address.

You could give both brokers the same receive address if you want, but it is better to use different ones, as this makes it harder for people to track your activities.  Any decent wallet should be able to create as many receive addresses as you want, with no practical limit, and they will all work equally well.  When you spend coins, the wallet will automatically select coins residing in one or more of your addresses; so even if you receive coins from different parties via different addresses, you can still spend them all in one shot if you need to.


The idea was around for some time, and as Pieter mentioned, using addresses without any additional obfuscating seems like a bad implementation.
There are few other projects, the one that is most serious is Microsoft's ION decentralized identity project. It's not the chat-app itself, rather the way of signing into apps using bitcoin-generated identity.
When it comes to chat apps, there is a pretty rapid development in the field of lightning network. As messages on LN are onion-routed, it seem to be a good idea for privacy-preserving communication.
There are two projects I heard about, self-custodial Juggernaut and centralized (so what's the point) Sphinx.
I'd be very hesitant in using these solutions, they are working as untested, beta-version projects, so they may not be as stable and secure.


What did you actually import in Electrum? A master privatekey, or a list of private keys?
In the first case, it could be that your gap limit (i.e. the addresses actively monitored by Electrum) is set too low, so it doesn't see some of your UTXOs. You can check this out :

wallet.gap_limit

Then increase the number you will see, for example if it tells you "20" try something like "50"

wallet.change_gap_limit(50)

wallet.storage.write()

Restart Electrum and see if your balance is back.


Block headers contain timestamps. Those timestamps cannot be changed without redoing the work on those blocks. If we have consensus about which chain has the most work, we also have consensus about what the next difficulty should be. Those timestamps might not be correct: you rightly note that a miner might lie about what timestamp a block was mined at.

What mitigations does Bitcoin have against miners lying? If a block timestamp is before the median of the last 11 blocks, the block will be rejected. If a block timestamp is more than 2 hours later than the clock of the node validating the block, the block will be temporarily rejected.


Confirmations never stop. Confirmations is simply the number of blocks that have been mined on top of the block that contains your transaction. It will keep incrementing as long as blocks are being mined.

  Is it normal to get 60 confirmations for a transaction in blockchain and still it is not received and confirmed

All wallets I'm aware of show even unconfirmed transactions, and definitely show confirmed transactions with even 1 confirmation. If your wallet is not showing the transaction you are:

Connected to a node that is not fully synced for a light wallet.
Using a wallet that is attempting to scam you
Behind some kind of internet restricting proxy or firewall that prevents a wallet from communicating with nodes
Using a Bitcoin full node directly that is not fully synced.


Speeding up confirmation by double-spending a transaction stuck in mempool

Yes, it is quite possible to successfully double-spend an unconfirmed transaction.  Only about 20% of hash power today strictly mines the first transaction seen.

Here is a chart showing the convergence to 80% success when the time gap between the two transactions is 15 seconds or more.

I'll leave it to other resources to give details on how to use the rawtransaction API to do this.  Be very careful, as you can easily end up sending much more to fees than you intended.

Edit: Core Dev Peter Todd actually wrote a tool to do exactly this:

  Increases the fee on a transaction by double-spending it with a second
  transaction paying the original recipients.


Where is the location of the private keys of my wallet on my PC?


How do I create a new address in Electrum?

With Electrum 2.x, a wallet can contain either keys you've imported from elsewhere, or keys which are generated (deterministically) by Electrum. You cannot store both types of keys in a single Electrum 2.x wallet.

Since your wallet is of the former type, Electrum will refuse to generate any new keys for your wallet. I suspect the reason for this is to make it as clear as possible what you need to back up: with your type of wallet, you are responsible for backing up all of your individual keys. With a deterministic wallet, you need only write down and store your one recovery seed.

You have two options:

Create a new wallet (File -> New/Restore), choosing a new "Standard wallet" when prompted. Be sure to write down your recovery seed and keep it in a safe location!
Create additional keys via some other means, and import them into Electrum (Wallet -> Private keys -> Import), and handle your own backups.

I'd choose option 1 if I were you....


do you think bitcoin futures exchanges (CBOE/CME) are a positive or negative for bitcoin price and why?

I do not consider the Futures Exchanges to be a good thing.

I don't trust large institutional traders.  They can and will manipulate prices in their favor.  I believe they are currently running up the price artificially ahead of the start of Futures trading.

Once futures trading begins, they'll short BTC then dump it.  The price will plummet, and their shorts will make a fortune.  Then they'll trumpet how they were right all along about it being a bubble; a bubble of their own creation, burst to benefit them.