text:
Transaction overriding in lightning network
I'm reading the lightning network whitepaper, and at some point it states this:

Therefore, it is possible in bitcoin to devise a bitcoin script
  whereby all old transactions are invalidated, and only the new
  transaction is valid.

I would like to know the specifics of how this can be done. Seems to me that what they are describing here is some kind of transaction overriding? It is somewhat different from the mechanism I understood a micro payment channel works.

Lightning payment channels are established by two parties Alice and Bob paying into a 2-of-2 multisignature address. Concurrently, they create two "exit-transactions", one for each participant which pay out the current allotment of the payment channel, txAliceExit_1 and txBobExit_1. These exit transactions lock the fund of the executing party for some blocks.
When a payment is performed between Alice and Bob, they update the balance, create two new "exit-transactions", txAliceExit_2 and txBobExit_2.
To invalidate the previous "exit-transactions" each party gives the counterparty another transaction that builds on the previous exit transaction by spending the party's output to the counterparty if the old "exit-transaction" were broadcast to the network, txAliceExit_1-TakeAll and txBobExit_1-TakeAll. I.e. if Bob executes txBobExit_1 the funds are time-locked for a little bit, meanwhile txAliceExit_1-TakeAll would become valid and Alice could take them before he can spend them.

Excellent explanation!! thank you very much! I assume this would require the implementation (or acceptance) of new currently not supported opcodes, am I right? or can this scripting be done with the bitcoin protocol as it is now? (april 2016)

@Bilthon: This relies on multisignature transactions and the use of the recently activated OP_CHECKLOCKTIMEVERIFY. AFAIK it also requires the transaction malleability fix that will be introduced with SegWit. Currently, an attacker could use malleability to change a previous exit transaction, invalidating the follow-up TakeAll transaction.

@Bilthon: According to Rusty Russel and David Harding we'll need OP_CHECKSEQUENCEVERIFY additionally for the anti-cheat transactions. This op-code is not implemented yet.

What mechanism is used to ensure the invalidation transaction can only be spent if the old exit transaction is posted?

@BT: Since the 'TakeAll' transaction builds on top of the invalidated 'ExitTransaction', it is only valid if the ExitTransaction was posted first.

@Murch Ok, so in that case, if Alice posts an outdated exit transaction, what prevents her from posting a transaction that uses that transaction as an input to another transaction before the invalidation transaction has time to post? Even if both parties post transactions at the same time, it seems like there's still a 50% chance Alice will be able to steal some money via the outdated exit transaction.

@BT There are two exit transactions, because they will lock the funds for the one that publishes the exit transaction for a period of time in the range of a few hours to a week (up to the channel owners) which gives the other time to publish the anti-cheat transaction in case they have it, as there is no wait for that.

But where is the money for an anti-cheat transaction coming from? It can't be from the opening address, because then people could steal money at any time using the anti-cheat transaction. And it can't be from the destination of the exit-transaction because then it wouldn't be valid for 1 week. So what address is this money coming from?

The destination of each exit-transaction has two possible resolutions: Either it was a valid unilateral channel closing, matures through the wait period and becomes spendable to the closer, or it was an attempt to steal funds, and the channel partner has the secret to spend the money even before the wait is over. The wait time only applies to the closer. The secret is revealed to the channel partner when the partners agree on a new state of the channel, so the channel partner will be able to punish transgressions to this agreement.

@BT: I think the question you're looking for is this one: https://bitcoin.stackexchange.com/q/48053/5406

Does this protocol use decrementing timelocks in 2 parties lightning channel or is decrementing timelocks another implementation of lightning channel (or decrementing timelocks is not used in 2 parties lightning channel)?

@croraf: You're thinking of Christian Decker's Duplex Micropayment Channels.

I'm talking about https://m.youtube.com/watch?t=174s&v=MpfvhiqFw7A. So lightning network doesn't use decrementing lock times?

I'm talking about m.youtube.com/watch?t=174s&v=MpfvhiqFw7A and https://youtu.be/8zVzw912wPo?t=10m42s. So lightning network doesn't use decrementing lock times?

Lightning network uses commitment transactions that are invalidated every time the balances in the channel are updated. I don't think that this requires decrementing lock times.

A commitment transaction is a transaction that sends person A's bitcoins to person A, and person B's bitcoins to an intermediate address (let's call it B*). B* can be spent by person B, but only after the input to that transaction is 1000 blocks deep (ie after about a week). But person A can also spend from B* if person A obtains B's commitment secret.
So once new commitment transactions are created (which use fresh secrets and hashes), both parties exchange their old secrets allowing, for example, A to spend from B*. Since B* will only receive money if B posts an outdated commitment transaction, B* wouldn't have any money for A to spend. But if B does post an outdated commitment transaction, A has 1 week to notice and spend B*'s money for himself.
So the exchange of old secrets is what invalidates the old transaction. But some machine still has to watch the blockchain to ensure that action is taken if an outdated transaction is posted.
You can read more details here: https://governology.wordpress.com/2017/07/21/so-you-wanna-understand-bitcoin-part-2/

Is there a decrementing time lock in this implementation of lightning channel, or is there a second implementation with decrementing time lock? Or is decrementing time lock used only in lightning network (multiple interconnected channels)


text:
What are pros and cons of txindex option?
I am reading "Mastering Bitcoin" written by Andreas and I found this explanation about "txindex option"

Transaction Database Index and txindex Option
By default, Bitcoin Core builds a database containing only the
  transactions related to the user’s wallet. If you want to be able to
  access any transaction with commands like gettransaction, you need to
  configure Bitcoin Core to build a complete transaction index, which
  can be achieved with the txindex option. Set txindex=1 in the Bitcoin
  Core configuration file

I am not sure what situations should I enable the option. In my understanding, I can set txindex=0 if I use bitcoind as just a transmission tool of Bitcoin so that I can save data and time to sync the blockchain data. Otherwise, if I intend to make a blockexplore site like Blockchain.info, I need to set txindex=1.
Is my understanding of this correct?

If you're using Bitcoin Core just for your own personal use, you probably don't need the -txindex=1 option. But, if you're using Bitcoin core for development or blockchain analysis of some sort, you will need to set -txindex=1 to be able to get transactions data for any transaction in the blockchain.
The tradeoff is just that keeping an index is slightly slower, but allows you to do things like:
bitcoin-cli getrawtransaction aec2729f5e46750b310b6feadcf853098aa86df74f93322a701c29cd68b22568

(where aec2729f5e46750b310b6feadcf853098aa86df74f93322a701c29cd68b22568 is the ID of a transaction that does not affect your wallet at all).
Also, if you have been running your client for a while but haven't had txindex=1 set, then it might take a few hours to build the index. If you want to rebuild, launch with the -reindex option.

♦ Thank you very much for your prompt reply. I understood it. I expected that I could save a lot of time to sync the blockchain but it would be not true as far as I read your answer.

Does setting txindex=1 or reindex=1 cause a new download?  The prod chain is so big, I would like to avoid that if possible.

@SteveHibbert no, it doesn't re-download the data, because you should already have the data on disk, it just reprocesses the data you have. It is still time consuming, though.

@StephenM347 Great, thanks for that, much obliged.

By default -txindex=0 Bitcoin Core doesn't maintain any transaction-level data except for those

in the mempool or relay set
pertinent to addresses in your wallet
pertinent to your "watch-only" addresses

If "txindex" is set to true (1), Bitcoin Core maintains an index of all transactions that have ever happened, which you can query using the remote procedure call (RPC) method getrawtransaction or the RESTful API call get-tx.
Several popular wallet and "block explorer" programs require -txindex=1. Note that txindex does not alter the behavior of Bitcoin's peer-to-peer interface.

Funny because I Googled into this and found myself reading an answer that was flat-out wrong. To my surprise when I got to the end, I saw my own name! I just rewrote my answer.

Bitcoin core does maintain transaction-level data for all unspents, regardless of whether the address belongs to you or not. Otherwise it won't be able to validate incoming transactions.

@kaykurokawa : I don't know precisely what's included in the "relay set" but that's the terminology consistently used by the developer documentation on bitcoin.org. Of course it must include unspents, but what else is in there?

ah I see, I was not aware of that term.

@chrisamesen That's really cool- It didn't occur to me wiki information correction also works with your past and future selves.

In addition, txindex=1 used to be required if you wanted to use LND (lightning network daemon). See https://github.com/lightningnetwork/lnd/pull/751

@Janus: I've rejected your edit since it changes the content of the answer completely. You should rather add a new answer to mention ElectrumX.

In addition to the other answers, txindex=1 is required if you want to use your wallet with Counterparty.
See the installation instructions at https://github.com/CounterpartyXCP/counterparty-lib

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/

authors: Александр Блинов

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

sort: votes


text:
Hive Wallet recovery without PIN
If  I don't have my pin, but I have my 12 word passphrase, how do I recover the wallet without pin?

Not a good idea to post your passphrase publicly.

As you can find from the FAQ, the passphrase is the only part you need to access your wallet. The PIN allows easy access from a machine that you've already logged in from (using your full, secure passphrase). You can force Hive to allow you to reset it by clearing your browser cache/data (assuming you're using the web interface; other clients may or may not have an equivalent function), or entering an incorrect PIN five times.
Since you have now made your passphrase public, DO NOT CONTINUE TO USE THIS PASSPHRASE since people can easily steal any money stored there (well, you can log in with it just to see how that works, but don't transfer money to it). Generate a new one, and NEVER reveal it publicly.
Since there's no current balance in your account (I logged in to check, and possibly "steal" it for you before someone else did; I saw one transfer in and one out, 0 balance now), there's nothing to worry about at the moment, as long as you're not planning on sending money to that account again.

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
Is the probability of generating invalid blocks reduced by mining transactions unknown to others?
I've got a question concerning a possible mining strategy.

I've not found any proof of the strategy, but it seems reasonable to me.
If two mined blocks inserted in the block chain include the same transaction (not a double spent, but simply a transaction mined two times), one of the two blocks is discarded (assuming that all the other transactions in the two blocks are legit).
This is a probable fact, since each transaction is shared/"broadcasted" by a user.
Therefore, a possible mining strategy may let miners keep a list of transactions, mine them without letting others know such transactions exist, hence publish/spread them, just before sending the just mined block.
In this way, the probability to generate a potentially invalid block is reduced.
Am I right? Is this strategy adopted or not? Is it reasonable?

No, this strategy makes no sense because of how blocks are structured in the blockchain. Also, it is trivial for network participants to keep track of which transactions are confirmed, because that's the whole point of mining and the blockchain.

It is possible for miners to keep transactions secret and publish them when they discover a block. This may make sense when a transaction is secret in the first place, and has particularly large fees.
However:

Most transactions are not secret.
Usually, transactions get relayed via the Bitcoin network to the miners, so everyone else knows about the transactions as well.
Blocks compete in other ways besides the transactions included.
Blocks reference their predecessor. Therefore, when two blocks are found at the same time they will both reference the same predecessor. However, only one of the competing block can be part of the longest chain since the following block can only reference one or the other.
The problem of accidentally including a confirmed transaction is non-existent.
Every network participant keeps track of which Unspent transaction outputs (UTXO) exist. Transactions that try to spend a UTXO that was already used are invalid. This includes doublespends, and a replay of a confirmed transaction. Since each node will always consider exactly one block to be the current blockchain tip, it is trivial to notice that a transaction was previously confirmed. (Or rather, that it is no longer available to be confirmed.)

Thank you.
Ok, for the first point.
Concerning the second point, what I mean is that each mined transaction is legit, but the same transaction is included only in one block. So, since each block includes >2000 transactions, it is possible to have the same (legit) transaction in two blocks, hence making the whole block invalid (one of the mined blocks is accepted/valid, while each other isn't).

Including a previously confirmed transaction would make a block invalid, however, this only occurs in practice when two blocks are competing at the same height. Otherwise, the set of confirmed transactions is completely known, and it would be a completely avoidable mistake by the miner that includes an already confirmed transaction.

Am I right?

No. Blocks are checked by PoW, not by containing the same transactions

Well, transactions are checked by miners, in order to avoid double spent.


text:
Can I detect a 51% attack as a developer
I am a developer building an application that accepts payments in cryptocurrencies.
Is it possible, in the occurence of a 51% attack, to build a script that detect this, so we can suspend withdrawals automatically?

potential duplicate: Can a 51% attack be detected and dealt with?

Generally, no, not until it's too late.
A typical 51% attack would look like this:

Attacker privately starts mining their own chain, which diverges from the main chain at some block N.
Attacker deposits coins to your business, sending them from address A.  Call this transaction X.
Attacker inserts in his own chain a transaction X' which conflicts with X; typically X' sends the coins from address A to another address belonging to the attacker.
Attacker waits for several confirmations of transaction X, in blocks N+1, ..., N+6 (replace 6 with however many confirmations your business wants) of the main chain.
Once there have been enough confirmations to satisfy you, you deliver goods or services to attacker.
Attacker releases his own chain, which now has blocks up to, say, N+50.  Being longer, this chain is accepted by the network.  This chain doesn't contain the transaction X but instead X', so you don't have the coins you thought you did.

Notice that up until Step 6, everything on the network looks completely normal; only the attacker knows what is going on.

After step 6, would everybody know the IP address of the attacker?

@AlexMillar Yes, unless he used a VPN.

@NickODell: I don't think everyone would know, with or without a VPN.  The attacker will expose his address (or that of his VPN, or Tor exit node) to all the other nodes to whom he sends his chain, but he could plausibly claim that he received it from someone else and was only relaying it.  Likewise, an innocent node who relays the blocks can't necessarily prove that they are not the attacker who generated those blocks.


text:
What Ripple API libraries are available?
I am wondering, what libraries are out there for communicating with Ripple through its API (either websocket or JSON RPC)?

Ripple labs have created a number of GitHub repositories relating to Ripple, including ripple-lib for JavaScript and a work in progress ripple-lib-java for Java.
Rubble Labs have released their ripple library for Golang
CodeShark has released a C++ library for communicating with Ripple through a websocket

There is a Dart library as well. Even though it's not 100% finished yet, it works quite well.
https://github.com/stevenroose/ripple-lib-dart


text:
Bitcoin Core cannot obtain lock
I downloaded Bitcoin Core (64 bit) and I am still waiting for it to synchronize. But just now, when I open the software, it loads from 1% to 100% and then a message appears with the inscription

Cannot obtain a lock on data directory C:/Users/ADMIN/AppData/Roaming/Bitcoin. Bitcoin Core is probably already running.

Then the program disappears to the task bar and I can't open it from the task bar. Please, any help?

when I try to open the software it says " cannot obtain a lock on data directory C:/Users/ADMIN/AppData/Roaming/Bitcoin.Bitcoin Core is probably already running"

Try opening your data directory and deleting the file .lock
Make sure Bitcoin is closed while you're doing this.

please, i  deleted the .lock and after re-launching the bitcoin core software the same problem exist. It loads from 1% to 100% and after it is done loading it disappears. But I realize the .lock file which I deleted is restored after software was launched. This is really giving me headache pls help me

Nick, please help me !!!

Right now, another problem has appear. Bitcoin core software has totally freeze at "loading block index" I have 1 BTC on it. Should I forget it ???????

@pearl: The .lock should be present while Bitcoin Core is running. It ensures that only one instance of the program is being run at the same time. For the new problem, you should create another question post. Please add as much useful details as possible. [Oops, I thought it was this month, not last month.]

You must have forcibly shut down the bitcoin client previously, or maybe the daemon is still running and you are attempting to run another client listening at the same port.
To kill all bitcoin client instances, you need to know the processes listening to the port.
Open a command prompt with administrator privileges and type in the following command to get the details of services running
netstat -o

This will list all the services listening to the various ports. Find the one with the bitcoin service (you can also see the port, 8332 for the actual bitcoin client and 18332 for the testnet client). Once you have acquired the process IDs, you need to forcibly kill the processes by typing in the command
Taskkill /PID <process_id_here> /F

Try restarting the client.
Useful links I used as source:
netstat
Killing Processes


text:
Miners Create Their Own Work?
Conceptually, even if the network doesn't have any "real" transactions, the very act of mining creates new transactions to be mined. Self fulfilling prophecy.
So, what is the real purpose of mining if the network is virtually dead? I suppose at that point the currency would be worth nothing and no one would mine it.
This is a bit of a philosophical question :-)
Likewise, is this similar to how pre-mining works? Where the creators mine the coin ahead of it's release?

The goal of mining is essentially to (i) create new coins out of thin-air and (ii) to secure the network from double-spending attacks.
So no, the act of mining does not create new transactions to be mined, and it does not create work for itself. It validates transactions and keeps the nodes of the network on the same state.

You're playing with words. Here I'm describing the end-goal of mining, its purpose. Which is to create coins out of thin air and to secure the network. The initial, and still ongoing, distribution of coins wouldn't happen without mining.

Oh come on... "mining does" or "The goal of mining" are effectively the same thing. Again, you're playing with words. I just edited it to make it clearer what I meant. The meaning of my message doesn't change.

"the distribution, initial to final, could've all be done in one swoop with a premine" sure but that's not how Bitcoin does it! And this is a question about Bitcoin.

But the question was about creating "new transactions to be mined". Not whether mining created new transactions.


text:
How is the transaction malleability issue being fixed?
With the upcoming release of Bitcoin Core 0.9, I am wondering how the transaction malleability issue is being fixed and what are the consequences of the fix?
It appears that transaction malleability is causing a few problems for the Bitcoin network:

The network is DDoSed by multiple apparent double-spends being relayed
Senders of the transactions need to avoid spending 0 confirmation transactions in case they become invalidated by malleability
When saving TxIDs of spent transaction for record keeping one has to make sure the TxID did not get changed later

Will all of those issues be addressed in the upcoming update, and if so, how will they be addressed?

The second and third items are outside the scope of the basic Bitcoin client and wallet software; they'd be issues for an exchange's custom software to address.

The release notes for Bitcoin Core 0.90 (the reference client) lay out several fixes for transaction malleability: https://bitcointalk.org/index.php?topic=495683.0

Transaction malleability is a consequence of the features of Bitcoin. The input data (scriptSig) for claiming outputs is purposely malleable to allow for useful scenarios where one would want to claim outputs in different ways.
The consequence of these features is that the hash of the transaction changes and shouldn't be considered as a useful piece of information other than referencing outputs of transactions that have been confirmed.
With that being said, I'm not sure what changes the client could implement to prevent the hash from changing. Perhaps it can enforce specific rules, like making non-canonical data pushes non standard, however that may interfere with later extensions to Bitcoin.

If the scriptSig is purposefully malleable, can't it just be excluded when calculating the txid?


text:
As of Feb 2015, what's the most technically secure wallet for Android?
I want a wallet on my Android phone that is rooted. I'm new to Bitcoin and I'd like to know which one is technically secure.

There's no such thing as "Canadian bitcoins". You might be located in Canada and buying them from someone in Canada (which in theory could affect your wallet choice), but these are the same bitcoins, all over the world.

It's a difficult question to answer because an Android rooted device is never going to be secure 100%.
That being said, the safest options will be 2FA enabled wallets at a bare minimum, and multisig solutions being the best bet.
GreenAddress.it allows for wallet functionality on par withBlockchain.info but with increased security through P2Script using ntimelock. It also allows for 2FA: be sure to use TOTP (eg Google Authenticator); do not use the same device for mobile SMS authentication since intercepting sms on a rooted device is extremely simple.
GreenBits is a new app which integrates with GreenAddress and utilises 2FA and P2Script also.
Options like BCI and Mycelium are not ideal for a rooted phone as the security concerns make either choice quite vulnerable to being emptied by malicious software stealing the pin code.


text:
How do you create a planet-specific cryptocurrency that will ignore longer block chains from other planets?
I'm sure that cryptocurrencies will play a huge part of the economy across the solar system, when we have colonized many different planets, moons, and asteroids. But there are problems with using a single coin for the entire solar system. Let's just start with the example of a Mars colony. Long distances mean long delays in communication so it would take a very long time to get confirmations of Bitcoin transactions that originate on Mars. That could be problematic. Additionally, people on Mars could never hope to mine bitcoins because the average communications delay between Earth and Mars is 20 minutes one way, which is twice as long as the ten-minute blocks of Bitcoin. So I believe that a different coin would be best for each planet. But here's the crazy part. Even if Mars had its own coin (let's call it Marscoin), Earth would most likely have more computer processing power, so miners on Earth could download Marscoin's block chain and extend it faster than the miners on Mars. Then the miners on Mars would no longer be able to mine Marscoin. Then we would be back to the same problem of using Bitcoin on Mars. So, I think someone would have to create a coin that can somehow be planet-specific, so that longer block chains from other planets will always be rejected.

People on Mars could use a different mining algorithm.

I think that would lessen the risk of having another planet taking over, but I don't think that eliminates the risk.

Will this even be necessary in the future? I believe by the time we have terraformed and colonized Mars, Quantum Entanglement will be the primary method to instantaneously transmit data...

http://physics.stackexchange.com/a/78130

There are a few technical issues with your statements, however, using theoretical quantum links for data transfer will be instantaneous.

Simply limit the block target (i.e. 10 minutes) to the speed of light (300,000 km/s).
Unless there is some wormhole or other unknown to reduce this limit, Bitcoin is safe from honest mining from any planet outside of 180,000,000 kilometers away (300000km/s * 60 sec * 10 minutes) since any miner can't keep up with the blockchain and would get any block at about the time the next block comes out.
Someone with more advanced technology / more hashing power could create a 51% attack and submit it to disrupt the Bitcoin economy even outside of this radius.

That's probably the only way. Quite an ingenuous idea. But I don't know if a block time can be that short. Surly there's a reason all of them (afaik) being a few minutes or so.

The first attempt at drastically lowering the block time was GiestGeld, which had a block time of one or several seconds. This caused huge issues with massive blockchain forks and concurrency issues due to latency between nodes. It has been generally agreed that 60 seconds is the lowest reasonable time to target for generating a block, propagating to the network, and expecting most miners not to have found a block by then (if it takes 6 seconds to transmit a block to the whole network with a 60 sec target, 10% of blocks will be stale/rejected because they would be found during this time).

As you mentioned, a small block interval does not protect from another planets mining efforts if it has more mining power. I've given an explanatory example in another answer.

If hashes are cheap on Earth, you want them exported to
Mars to improve the security of the Martian block chain.  Exporting
hashes is easy to do in the stateless manner we expect from
decentralized Bitcoin technology.
Each block on a block chain is protected against modification by the
proof of work it shows and by the proof of work shown by the blocks
that follow it. This proof of work is communicable---the work done in
one chain can be applied to another chain.
So, for example, we have Marscoin and Bitcoin.  Bitcoin (still focused
on and near Earth) is by far the stronger chain.  Marscoin is great for
local transactions on Mars, but nobody trusts it for serious savings
because its network difficulty is much lower than Bitcoin.
However, some people on Earth start to include hashes of recent Marscoin
block headers in their transaction outputs (maybe using
ContractHashTool to
do this as a part of their regular transactions).
Following a soft fork of Marscoin, Marscoin full nodes download both the
Bitcoin block chain and the Marscoin block chain. Looking at the Bitcoin
block chain, they find the first Marscoin header hash encoded in an
output and look at how much proof of work is protecting that transaction
on the Bitcoin block chain. They add that proof of work to the
corresponding block on the Marscoin block chain---now that block is
protected by the combined hash rate of two planets! For example:

Bitcoin Block 10,000,000

Confirmed 100 times
Protected by proof of work equal to 10^72 hashes
Has a transaction that references Marscoin block 50,000

Marscoin Block 50,000

Confirmed 200 times
Protected by native proof of work equal to 10^48 hashes
External proof of work adds an extra 10^72 hashes

The Marscoin full nodes perform the same calculation for any other
Marscoin header hashes found in the Bitcoin block chain. Now attacking
all but the most recent Marscoin blocks requires attacking Bitcoin at
the same time.
To prevent denial-of-service attacks against recent blocks, methods like
Gavin Andresen's require-priority
idea
can ensure high-priority Martian transactions get through even if
malcontents try using cheap Terran hash rate in short-chain 51% attacks.
Now Terrans and Martians can live in peace and harmony---all thanks to
Bitcoin. :-)

TL;DR: Whatever block interval one employs, another planet with greater mining power will eventually overtake the local blockchain. It would only be possible to lock other miners out by adding low-depth checkpoints.
Gedankenexperiment:
MarsCoin starts a new blockchain with a 2 minute block interval, they have one Unit of Mining Power [UMP] at their disposal with a new MarsCoin specific mining algorithm.
Some traders from Earth start using MarsCoin for their transactions with Mars colonists. They get blocks with a 20 minute delay (as proposed in the question). After a while they realize that the MarsCoin mining rewards are quite juicy and technology is much cheaper on Earth than in the underdeveloped colony: They create mining equipment with 2 UMP, allowing them to find blocks twice as fast than on Mars.

-20 minutes: Mars is at Block X and broadcasts it to Earth.
…
0 minutes: Earth receives Block X from Mars, and starts their own mining effort. The difficulty has not increased yet, so they can mine one block per minute for the time being. Mars is at Block X+10.
2 minutes: Earth receives Block X+1 from Mars, but Earth is already on Block X+2 on their own chain. Earth subsequently outperforms Mars and continues mining on their own chain. Mars is at Block X+11.
…
21 minutes: Mars receives the first block Block X+1 from Earth and discards it, because Mars found Block X+20 at 20 minutes. Earth is at Block X+21, and received Block X+10 last from Mars.
…
61 minutes: Mars receives Block X+41 from Earth, Mars is at Block X+40. Earth's chain's total proof of work is greater than Mars' chain's. Mars' chain is discarded in favor for Earth's. Mars' miners lose the mining reward of the last 40 blocks. Earth is at Block X+61.

Conclusion:
Neither distance, nor block interval are sufficiently prohibitive. As long as the other planet has more mining power it will eventually overtake the local blockchain.

Addendum: Short block interval with checkpoints at low depth
When I just read this question again, I thought of another thing. If one was hellbent to keep non-martian mining efforts from bearing fruits, one could introduce a sliding checkpoint scheme. In my above example, where I was prescribing a block interval of two minutes and terrestrian mining was twice as fast as martian mining, it would take a reorganization of more than forty blocks for the terrestrian chain to replace the martian.
If the community of Mars agreed upon forbidding chain reorganizations of more than 15 blocks (which at two minute intervals is less time than that of a radio wave roundtrip) by adding every block with 15 confirmations to the checkpoint list, terrestrian miners would be able to fork themselves from the Marscoin chain, but would never be able to take over the martian mining.

This came from bubfranks on reddit:
"Oh fun! Let me try.
Given a random stream of bits that was impossible to predict, but agreed upon by local miners, reject blocks that do not include a valid bitstream. The probability of getting scooped by a cooperation between external hashpower and an internal node would be a function of the speed of light, distance between the attackers, and length of a valid bitstream."

I think this could be a good answer, but as it is presented right now, it is hard to understand and should be explained further.

why don't we just increase block confirmation time from 10 minutes to 1 day for specific interstellar fork. I think the whole day of unconfirmed transactions is okay for interstellar network & will expand the radius draasticaly.

That wouldn't stop another planet from taking over the chain with more mining power, leaving us with both drawbacks, the latency for confirmations and huge block intervals. So, there would be no benefit over just having to wait for 50 minutes to get the first confirmation on the Bitcoin blockchain.


text:
Can the service providing the bitcoin wallet know how much value has the user loaded into his wallet?
Say for example I run an ecommerce website which mandates users to have a minimum balance of 1 bitcoin in their wallets to access the platform. In the event the balance in his wallet falls below 1 bitcoin he should not be able to access the platform and he should see a message on his screen saying "Please load to minimum balance".
So, the question is, can I, or the Bitcoin wallet provider I use, read the bitcoin balance of the users so as to fulfil the above business requirement?

Are you hosting the wallets for them, so that only you have control of the private keys? If not, this requirement is impossible.

We are planning to host multisig wallets where we will have only one of the private keys but the overall control on the wallet will be completely in the hands of the user.

So basically if i have got this correct this would meaan that I can write a script which calculates the unspent balance on a particular public address (associated with a user in the system) and at any given time if it goes below a particular predefined value, then it sends out a message to the owner of that address to take corrective action?

All Bitcoin transactions are publicly available. This is fundamentally why Bitcoin can work as a truly decentralized currency. Bitcoin is different from the traditional banking system specifically because anybody can see and validate everyone's transactions. If only a few could access the information about people's balance, then it wouldn't be fully decentralized, it would be just like traditional banking.
So yes, you can calculate the balance of any Bitcoin address in the network.

Yes you can calculate the balance of an address, but you can't really know that it belongs to that user. Even if you require a signed message, you don't know if it's the user or if they asked for/paid for someone else to sign the message for them.

We are planning to host multisig wallets where we will have only one of the private keys but the overall control on the wallet will be completely in the hands of the user. –
So basically if i have got this correct this would mean that I can write a script which calculates the unspent balance on a particular public address (associated with a user in the system) and at any given time if it goes below a particular predefined value, then it sends out a message to the owner of that address to take corrective action?

@Abhishek exactly.

okay thanks.
just one last question, will the same logic be applicable to deterministic wallets with multiple public addressees too?

The service provider can know the balance of the wallet, if the wallet is "hosted" one.
The service provider must know all the addresses associated with the wallet (this is pretty much the definition of a Bitcoin wallet in the first place). However, you do not need to know private keys needed to send out Bitcoins from the wallet, you can have "read-only" knowledge about the wallet.
However from your service it sounds like you are already using hosted wallets, so finding out the balance of the wallet should be just summing up unspent balance on the public addresses of the user wallet.

We are planning to host multisig wallets where we will have only one of the private keys but the overall control on the wallet will be completely in the hands of the user. –
So basically if i have got this correct this would mean that I can write a script which calculates the unspent balance on a particular public address (associated with a user in the system) and at any given time if it goes below a particular predefined value, then it sends out a message to the owner of that address to take corrective action?

I think there is some general confusion as to what a wallet is, and how you interface with one. I'll try to be detailed but not too nitty-gritty.
A wallet is really two connected things. First it is a collection of private/public keypairs. In the case of standard addresses (P2PKH) each public/private keypair matches to 2 distinct Bitcoin addresses. This is because you can derive two addresses from the keypair because there is a compressed and uncompressed representation.
In the case of multi-signature the address is constructed based on all of the public keys involved in the transaction. This can create many addresses that represent the same keypairs or combinations thereof.
Based on the comment above you want to run a site that does 2ofN multisignature. Which means you control one of the keys at least, this means that your wallet is a collection of addresses that you have partial control of. At any time you can sum the balance of every address you mutually control with the user and come up with a total balance.
So, the answer is yes, you can contact the user when the balance falls below a certain amount since you have total knowledge of all keys that the user is using since you are  party to them. This lets you compute based on the public ledgers information. This is also true for HD wallets / Keys so long as you compute a collection of multisig addresses derived from the HD keys.


text:
Do I need an app and internet on my smartphone to enable a Lamassu ATM to detect and scan my QR code?
I want to send bitcoins to a friend through a Lamassu ATM. She has emailed me her request QR code and when I went to the Lamassu ATM point, after pressing on the start button and  showing the QR code on my smartphone, nothing happens. I learned that the atm is supposed to scan the QR code and send bitcoins to the request QR code after putting in cash.
I am wondering, if I may need an app or internet on my smartphone to enable the Lamassu ATM to detect and scan the QR code on the phone screen.

You don't need internet or an app. Actually, the machine can either scan a paper QR code or a mobile phone.
The problem would either be that the QR code encodes different information than what you thought it does, or that the scanner of the ATM does not recognize the QR code on the screen. What you need to show is a Bitcoin address.
Try to set your screen to full brightness, be sure not to block any part of the screen when presenting it, and check whether the QR code actually contains a Bitcoin address, and not something else such as a private key or payment request.

Thanks for the quick answers. I will like to know if I can also print my bitcoin address on an ordinary white paper and show it to the lamassu atm machine to scan and send bitcoin to my wallet direct or I may need special paper for that.

Sorry for the delay, I was on the road for a couple days. Regular paper should be fine.

I had a similar problem today using ATM type Lamassu, it wouldn't allow my laptop screen near the 'scanner' since it was deeply embedded within the 'nest' for the metal keypad. Translating the 256 characters of a receiver ID into QR is hilarious to me read INCREDIBLY frustrating, I could have just typed them in..

tried taking a picture of the laptop screen and showing the picture
on my phone screen to the scanner - FAIL obviously(?) with angles or
possibly simply brightness/contrast.
Tried simply saving the image to the laptop HDD then xferring that
directly to the phone and then displaying it full brightness. FAIL!
SOLUTION i downloaded an incredibly simple android app called Bitcoin
Wallet or such from aptoide. And that scanned fine. now I think I can just give the wallet file directly to my friend or send it through the network for pennies in fees.

In my case i think it's due to the terrible design of at least that scanner aspect of this ATM type Lamassu with the scanner tucked deep inside and up top of the metal keypad enclave. Narrow minded approach to product design, I mean I remember seeing some hackerspace with a pop machine able to discern a QR from like nearly anything front of it and this was WAY BACK like I mean within just a few years of Satoshi returning to their dimension. ;]
ps better late then never this was just so frustrating today i had to vent somewhere and maybe help someone in my position


text:
How do I pay Utility Bills anonymously with Bitcoin?
I can get my salary with Bitcoin: https://bitwage.com/
I can get loans with Bitcoin: https://bitbond.com/
Can I pay my utility bills with Bitcoin? If the naming pattern follows, there's a https://bitutility.com out there for me. I just haven't found it, yet.
So far, I've found bitwala.com, but I can't tell if they require a name on the payment.
Say, hypothetically that a Bitcoin user had reason to ensure his name goes with his physical address on as few documents as possible.
Assuming that a Bitcoin user has a pseudonymous account, how can that user, in general terms, use Bitcoin to pay utility bills with Bitcoin anonymously?
Alternatives:

Anonymous PayPal
One of those $200 prepaid VISA debit cards
Cash at the Utility's office

I imagine that the issues are mostly logistics, as the companies do not care who pays a bill as long as it's paid, right?

A company does not care whose wallet the money ultimately came from as long as they know that YOU paid YOUR bill, but if one customer pays double and ten pay nothing (assuming for simplicity that they all had the same charge on their accounts), then how would they choose which of the non-payers to give the grace to? The way they do things is to keep track for each customer the exact difference between what your bills have been and what you've paid.

If you are in canada, Bylls.com is exactly what you are looking for. It is for Canadians only though.

It looks like bitwala.com provides this service, although I'm not sure whether we may use it to pay bills in the US.
https://www.billpayforcoins.com/ and https://coinsfer.com/ look worth trying for this, too, but I'm not sure yet what level of privacy they allow, if any.
If they allow privacy, they could be used, perhaps, to anonymously pay someone else's bills as a surprise.


text:
bitcoind getrawmempool without downloading the full blockchain
I'm running bitcoind from a small virtual machine on digitialocean.
I'm interested only in looking at the new transactions in bitcoind getrawmempool
Is there a way to get these transactions without downloading the whole blockchain?  Currently, I'll need a minimum of 40GB instance to have the whole blockchain on the VM.

May be you are looking something like this? https://github.com/sebicas/bitcoin-sniffer You do not need to have bitcoind at all

Bitcoin core does not provide this functionality (as far as I know).
The mempool is where transactions are stored until they get put into a block. It would be hard to determine you had the correct mempool if you didn't keep track of the whole block chain, though. For example, someone could broadcast an older transaction, and you would have no way to determine that you shouldn't just add it to your mempool if you didn't keep track of the whole block chain. Transactions also have to pass some basic validation before they can be added to the mempool, validation which requires having all the blockchain data.
If there were a program to implement this, it would at least have to process all new blocks as they came in, in order to determine which transactions to take out of the mempool as blocks get solved.
With this said, you can set up a light-weight node that just monitors what transactions are being spread around on the network, but without the full blockchain data you won't be able to validate that the transactions are candidates for inclusion in the next block.
As Amaclin pointed, one such program to do this network watching is

https://github.com/sebicas/bitcoin-sniffer.

If you're looking for unconfirmed transactions without loading the blockchain, you're going to have to trust someone since you can't verify the transactions yourself. Probably the easiest way to get these transactions is by using a third-party API service.
Blockchain.info provides a very good one here:
https://blockchain.info/unconfirmed-transactions?format=json
The command line to get this would be something like:
curl https://blockchain.info/unconfirmed-transactions?format=json


text:
What is the average number of hashes it takes to mine bitcoins?
I'm just curious about this. I'm not sure if the length of zeros in the hash result is directly proportional to the probability, or how to calculate this.

Yes, the length of zeros in the required hash result is directly proportional to the probability of finding a matching hash.

(Average hashing power of network per second between the last difficulty adjustment and the difficulty adjustment that came before it) * 600
or (2^32 * difficulty)

Where can I find out this information?

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

As relative Answer in terms of Coins per day:
                                                          A      B
coins = reward / (difficulty * 4294967296 / hashsPerSec / 3600 / 24)

A is the number of seconds in an hour
B is the number hours in a day

Source: bitcointalk.org - Formula to calculate litecoins generated per day by hashrate


text:
How do hard forks avoid peering with each other?
I understand that in a hardfork (e.g. the actual Bitcoin vs. Bitcoin Cash/Gold) the blockchains would diverge because the miners and clients have different rules to accept a valid block. It makes sense to me how you could get two or more divergent databases in this way, theoretically.
What's less clear to me is how the actual network joins itself together in practice. Are full nodes on one chain constantly bombarded by the blocks of the other? What keeps a spend [of pre-fork holdings] on one chain from accidentally — or for that matter intentionally! — propagating to the other?

Related: https://bitcoin.stackexchange.com/a/111968/5406

Ports
One way that forks can deliberately separate themselves is by using a different TCP port number for network communications.

Currency
Port

Bitcoin
8333

Litecoin
9333

Handshake
When two Bitcoin-like programs communicate with one another, there is an expected initial pattern to the communication, an expected form of data exchanged and some expected data values. We call this a handshake. Programs can use this to identify whether the other program they are communicating with looks sufficiently like themselves (whether their handshake feels right). See protocol documentation,  especially version message details and protocol-version number.
Discovery
Another route for separation might be differences in the peer-discovery process. It would be natural for dissenting groups creating new forks to replace the seed nodes with ones they run themselves.
Shunning
Another mechanism is that BTC nodes reject "bad" data provided by BCH or BSV nodes on port 8333, and vice versa. This is because of consensus rule conflicts. That would eventually cause each set of nodes to blacklist the other. As Pieter Wuille commented: "Relaying an invalid block is a protocol violation (in most cases; there are exceptions), and (in Bitcoin Core) will cause the peer to be considered misbehaving. Misbehaving peers are eventually put on a "discouraged" list, which means their connection slot will be dropped and replaced by another when a non-discouraged IP connects. Bitcoin Core further has a mechanism to temporarily actively seek out extra connections when it appears none of its peers have a recent valid block".

The P2P handshake may also be different (https://en.bitcoin.it/wiki/Protocol_documentation#version). It depends really whether the hard fork was trying to disrupt Bitcoin as much as possible or it was happy to "play nice" and have a different port, P2P handshake etc

@Michael, Thanks, I'll add that to my answer.

@RedGrittyBrick The shunning is correct. Relaying an invalid block is a protocol violation (in most cases; there are exceptions), and (in Bitcoin Core) will cause the peer to be considered misbehaving. Misbehaving peers are eventually put on a "discouraged" list, which means their connection slot will be dropped and replaced by another when a non-discouraged IP connects. Bitcoin Core further has a mechanism to temporarily actively seek out extra connections when it appears none of its peers have a recent valid block.

@Pieter: Thanks, I have added that information to the answer.

Thanks for finding my old question and offering such a well-rounded answer after all these years! Makes sense that any of these mechanisms could keep the forks mostly separate, and especially when working all in combination.

It looks like there is no standard on network joins itself together in practice. According to A History of Bitcoin Hard Forks:
   The fact that no one person or group can determine when and how bitcoin should be upgraded has similarly made the process of updating the system more complex. In the years following the Genesis Block, there have been several hard forks.
Additionally, this is the general rule of hard fork (Hard Fork (Blockchain)):


text:
What prevents rewriting the history of a chain with a different difficulty?
It looks like the difficulty is deterministic, but only if the timestamps are trusted.
What's to prevent a large miner from starting back much earlier in the chain (when difficultly was miniscule) and quickly making their own chain with forged timestamps? Wouldn't it be possible to quickly "catch up" and surpass the block height of the real chain, and thus convince clients to switch to a chain built with a non-competitive difficulty?

I think this would be considered a time warp attack.
What prevents this strategy from working is actually quite simple, as explained in https://bitcoin.stackexchange.com/a/37960/26673:

Bitcoin nodes do not compare chains by their height. (Although they used to do this.) They calculate the total work in each chain (nChainWork), and compare by that. This is calculated by looking at the number of attempts it would take, on average, to find each block, and summing it.

My question assumed that blockchains were compared by height — but they are actually compared by the amount of work encapsulated. So a chain mined with competitive difficulty would clearly represent more work than a forged one "solo mined" with a much lower difficulty reached per block.

I assume the other nodes would reject the malicious chain because it's blocks would have a nonce that does not actually create a hash lower than the difficulty. Is this assumption true?


text:
Bitcoin migrating to a ASIC resistant mining algorithm like RandomX used on Monero
What would need to happen for Bitcoin to fork to a ASIC resistant mining algorithm like RandomX used by Monero for CPU mining only?

The bitcoin community would have to decide that they don't particularly care about having significant security anymore. ASIC-resistance weakens the security of proof of work chains because it eliminates the need to invest in a chain in order to attack it.
Someone who owns lots of expensive ASICs will not want to let them be used to attack the chain they are mining because if they harm that chain, they will significantly reduce the value of their own ASICs. By contrast, if you can mine with commodity hardware, attacking the chain does not significantly reduce the value of your hardware, so you have no real incentive to prevent your hardware being used to attack the chain. Worse, commodity hardware is easy to rent or steal (with malware) to attack a chain.
So the entire bitcoin community would have to change their opinion on how to make a chain secure to a worse opinion.
It's also important to understand the security is a huge limiting factor on price. If the benefit from causing a double spend exceeds the cost of doing a double spend, there will be double spends. Nobody wants that. So market forces will act to keep the benefit of a double spend below the cost of a double spend.
ASIC-resistant algorithms have much lower cost to do double spends (because you don't need to invest in ASICs but can instead rent or hack commodity hardware) so the profit from a double spend must necessarily be much lower. That will mean either waiting for many more confirmations, dropping the price of bitcoin, or some of each. Who wants that?

How is ASIC resistance weakening the security of the proof of work?

@toolforger Read what I wrote above. If a chain is not ASIC-resistant, you have to invest in ASICs to attack it, and then attacking it makes your ASICs worthless. If it's ASIC resistant, you can rent access to commodity hardware to attack it and you lose nothing in the attack. It's very hard to rent, borrow, or hack into someone's SHA256d ASICs to attack bitcoin because everyone knows that such an attack makes their expensive ASICs less valuable. You can rent, borrow, or hack CPU time easily.

If commodity hardware is useful for mining, then a malicious miner has to outmine a much larger normal user base. Given that I haven't heard of any attacks against ASIC-resistant blockchains, and assuming that such blockchains already do exist and are worth an attack, it seems to me that this outweighs the ability to attack.

@toolforger there have been many attacks against ASIC-resistant chains, cost of ASICs does seem to be a larger factor than ‘a much larger normal userbase’. See: vertcoin, eth classic, verge, etc. In any case, ASIC-resistance leads to more centralization of hashing power, as it is impossible to create an algorithm which is most efficient to mine on commodity hardware. It will always be possible to create optimizations in the hardware, ASIC-resistance just makes it harder to do (which means, less people are capable of doing it = more centralization of mining power). It’s bad all around.

Agree with David's answer, but the security detriments of ASIC resistance (of which there are many) is somewhat besides the point.
The entire value proposition of bitcoin, and what makes it so valuable above all other coins, is that it cannot be controlled by humans. If such a large change were to be made, the chain would not be considered "bitcoin" by current miners (who mine with ASICS and thus have everything to lose) nor the community (who recognize the importance of protocol stability).

I essentially disagree with David Schwartz here. The aim of bitcoin was decentralisation, and never high prices. And to say commodity hardware promotes the idea of attacking the chain is simply ridiculous. Why will anyone who has the ability to bring so much malicious hardware together, will ever use it to make all his bitcoin useless? Since compound interest is obviously better than a one time cash out.
So do we want decentralisation or higher prices is essentially the question. Do we give power to centralisation of ASICs and forget decentralisation, or actually go back to the roots of the problem. Can hear anyone's suggestion on this one.

"Why will anyone who has the ability to bring so much malicious hardware together, will ever use it to make all his bitcoin useless?"
Yes, keyword is "short position" - if you can profit from making BTC worthless, then you  suddenly have a completely different set of incentives. This is also a point against David's argument btw. If a 5B$ investment into hardware can move a 650B market downwards and you can profit from that, then you don't really care if you sell your hardware to the second market later. All these arguments about how safe BTC is, work only for miners with a long position.

Why would an entity choose a one time cash out of bitcoin after investing so much money into the hardware, in effect making the recurrent income possibility of bitcoin mining essentially 0?

Because if you know you could do it, then you know that someone else could do it and there goes your recurrent income possibility.

Fair point. Will have to think through it.

This answer seems to be mostly based on the assertion that ASIC-resistance would lead to a more decentralized outcome in the long run. This assumption as well as the notion that decentralization is opposed to the Bitcoin network being economically successful are not clear to me and should be substantiated further.

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
Do exchanges charge fees from base currency or from counter currency?
I'm building some trading robots for a while already but I keep seing that something is wrong with my end of day balances.
My robot does arbitrage across multiple exchanges and I always take into account the fees but for some reason, the numbers are not always as I expect.
I suspect that I am either not applying the fees in the right place in my algorithm or maybe I don't have the right fees up to date.
I want to ask you:

Just to make sure that I have the latest fees, do you know where can I get the most reliable information on the fees for the exchanges Cryptsy, Btce, and Bitfinex?
I would like to understand better, for each exchange from which currency the fees are deducted, when buying and selling. Is it the counter or the base currency, that one is charged from? How could I find out this?


text:
How can I import a private-key to Blockchain.info in order to use it?
I recently bought a BTC-wallet from my friend. It has a cold storage wallet ("Watch only") and a private key (which is a bunch of numbers and letters). How can I use it in Blockchain.info? How do I make (confirm?) transactions with it?

Welcome to Bitcoin.SE. Your question was not clear as it was originally stated, so I edited assuming that you are trying to import the private key to Blockchain.info. Please check whether the question is still aligned to your issue and edit it as you see fit.

you question is not clear, what exactly have you bought?
anyhow if you have the private key you can import them in blockchain.info wallet in the Import/Export section. but if you bought it from someone else he/she also has the private key and so the ability to spend the bitcoins.

authors: Тарас Буділін


text:
How do I extract my private keys from a protobuf wallet?
Recent changes to Andreas Schildbach's Bitcoin client for Android have removed the option to export private keys. This has been replaced by an option to back up the entire wallet. Unfortunately, the wallet data of the Schildbach client is stored in an arcane format called protobuf (short presumably for Protocol Buffers). The Schildbach client can restore a protobuf wallet from its AES-encoded backup file. But the protobuf wallet cannot be imported into a different Bitcoin client such as the Bitcoin Core (QT) client.
For emphasis, I'm aware of the command line method of decoding the back-ups created by Schildbach's client, which in the past allowed the private keys to be saved in AES encrypted format to /sdcard/Download. The following command worked in the past to produce a human readable copy of my Bitcoin private keys:
openssl enc -d -aes-256-cbc -a -in encrypted-wallet-keys -out decrypted-wallet-keys

This no longer works. The following command instead produces a non-AES-encrypted protobuf wallet.
openssl enc -d -aes-256-cbc -a -in bitcoin-wallet-backup-2014-07-19 -out bitcoin-wallet-backup-2014-07-19-decrypted

The -out file is not an ASCII copy of my private keys but a copy of the protobuf wallet used internally by the Schildbach Bitcoin client (found at /data/data/de.schildbach.wallet/files/wallet-protobuf).

Since "when you're a developer it's easy" is probably not sufficient for most people, here is the full step-by-step from a Android Bitcoin Wallet to importing the private keys in Electrum which (finally...) worked for me. This solution uses bitcoinj. The approach using the .proto definition file and opening the wallet in Python was also tested, but seems more error-prone.
Requirements:

Android Bitcoin Wallet in a new version (to my knowledge, some older versions do not allow a backup).
Bash shell: tested with the Windows Bash, but should work on native Linux or OS X. Basic knowledge (cd etc.) helps.
On my system, maven and openjfx were required. Install them with sudo apt-get install maven, sudo apt-get install openjfx
Electrum (current: 2.9.2)

Step by step:

Backup: save the encrypted wallet (Safety -> Back up wallet) and move the backup file to your computer (e.g. via file transfer, Dropbox, e-mail...).
Decrypt: open the bash, move to your data directory and use openssl enc -d -aes-256-cbc -a -in bitcoin-wallet-backup > bitcoin_decrypted as stated above, which will ask for the encryption password.
Install bitcoinj:

git clone https://github.com/bitcoinj/bitcoinj.git
cd bitcoinj
git fetch --all
git checkout v0.14.4
mvn install (fails at GroupTest in Windows bash, but works anyway)
cd tools
./wallet-tool

load the decrypted wallet and dump the private keys:

./wallet-tool dump --wallet=/mnt/d/path/to/wallet/bitcoin_decrypted --dump-privkeys > /mnt/d/path/to/wallet/bitcoin_decrypted_dump.
Please note that this saves the unencrypted private keys in the file "bitcoin_decrypted_dump". Move this file to a save location (e.g. TrueCrypt/VeraCrypt container) or delete it after use.

Create a new wallet with the private keys in Electrum: File - New/Restore - filename - 'Standard wallet' - 'Use public or private keys', then list the 'priv WIF' keys from the dump file.

On handling the BTC/BCH question with Electrum and Electron Cash, please read the notes on the Electrum webpage.
If there are any questions, feel free to ask. Good luck!
Sources:

This page
https://github.com/bitcoin-wallet/bitcoin-wallet/blob/master/wallet/README.recover.md

When installint bitcoinj, I get:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.2:compile (default-compile) on project wallettemplate: Compilation failure: Compilation failure:
[ERROR] ~/wallettemplate/src/main/java/wallettemplate/utils/easing/EasingInterpolator.java:[27,24] package javafx.animation does not exist
And many similar errors after that (javax.something does not exist). Any ideas?

This helped.

My file bitcoin_decrypted_dump contained errors, see this pastebin what should I do now? I don't understand error messages but I can execute/understand terminal commands.

@jacob: the error message states that the Java Development Kit (jdk) is missing. You can install it with "sudo apt-get install openjdk-8-jre". Please confirm if this solves the problem, then I will update the instructions.

@Colluphid I got a guy to help me with this to install java and set PATH variable. However, the output file does not contain my private key. It's a large file and it looks like I can see the block that contain the transactions that I my wallet did.

@jacob: If I remember correctly I got the transaction list when using the dump command without '--dump-privkeys'. Can you check that you included that option?

I tried to dump private keys but i couldn't.
Using wallet-tool, I obtain a text file with public keys, addresses, some other information, and the words: "Seed is encripted".
So I use this phyton script to obtain seed, and it apparentely worked.
Then I use this standalone page: https://raw.githubusercontent.com/iancoleman/bip39/master/bip39-standalone.html to obtain private keys to import in a BCH wallet.
I "found" only 85% of BCH that I expected (BTC pre fork). How could be possible ? I tried to import a lot of keys beyond the key associated to the last used address....

Update: I figured out. I had to use as derivative path m/0'/1 on the standalone page linked above (with derivation path BIP32). Some BTC were on addresses of this kind.

I had a load of trouble, but I got there in the end.  I decided to write it up; see https://recoverbch.azurewebsites.net for an in-depth guide. Hope this helps!

To work with bitcoinj wallets (and backups of wallets) you can use wallet-tool. It's part of bitcoinj and allows you to dump all your deterministically derived private keys.

Protocol Buffer is an open source serialization library from Google.
If you can code, it should not take you too long to create a script (for instance in Python) to get out the content of the field you are interested in. In this case the field containing the private key.
Here is the doc for the Python protocol buffer library: https://developers.google.com/protocol-buffers/docs/reference/python-generated
The protocol buffer library use a .proto file to describe the possible fields in the serialized format. I presume that you do not have access to it. This will have the disadvantage that you will not have the name of the fields when you will deserialize the wallet.
That should however not prevent you from deserializing. You will then need to guess which value is the private key.

The schildbach wallet uses BitcoinJ serialization. This is the .proto file https://github.com/bitcoinj/bitcoinj/blob/master/core/src/wallet.proto

I don't know if you are a developer, because you could dump the private keys with very little effort. The app relies on bitcoinj and the protobuf format you mention is bitcoinj serialization format for the wallet. Export the wallet file to your desktop and write a simple Java app that uses bitcoinj to access the wallet, then use the DumpedKey class to output the private keys in the widely used WIF encoding.

Would any of you have an easier way to get at these keys from the protobuf format? I'm trying to help someone get these keys out of the app on their phone (to control their Bitcoin Cash) and we've made it this far in decrypting the backup wallet, but without having any programming knowledge we are stuck here.

I just posted an answer. I had the same problem.

This script seems to do the work
https://github.com/jleni/wallet-decrypt
You just need to create a backup and it will give you back a mnemonic that you can use in electrum or electrum cash.


text:
Is it impossible to GPU mine without OpenCL?
I have an Nvidia 7300 GX and want to start mining with it. This card doesn't support OpenCL. Can I still use it for mining? With BitMinter I can only use CPU mining; it doesn't see the Nvidia card.
I am using Linux Ubuntu 11.10 (Oneiric Ocelot) with all extras...

OpenCL allows all graphic cards to be handled in a higher level in a uniform fashion. As all GPU mining software relies on OpenCL, you would need to create your own software to mine on non-OpenCL card. Whereas it is possible, the process would be very complicated and the reward probably wouldn't be worth it (NVIDIA cards aren't good for mining).
So all in all, no, if the graphic card does not support OpenCL, you can't use it to mine.

The 7300's GPU isn't sufficiently software programmable to be used for mining. There's no known way to get it to mine Bitcoins.

Try using CudaMiner since it was written specifically for Nvidia cards and does not require OpenCL.

cudaminer requires CUDA, which isn't supported by the 7300 either.


text:
Can I CPU mine other coins to win Bitcoins?
I have a useless Nvidia, until now, unconfigurable to mine (7300)
So, if I mine just with CPU, can I get more coins mining others coins like NMC,LQC,LTC,SC, or whatever, and trading after for BTCs?

This is largely what the sCrypt() based forks are intended for - both utilizing un-tapped CPU power on dedicated rigs or allowing casual miners to use their CPUs. At present, the difficulty on the Bitcoin network is so high that it's not even a question of profitability but capability - even with pooled mining, CPU mining is so slow that you may not actually submit even a single share for each round. That said, let's do the math. I'll use Tenebrix (TBX) as an example since I have numbers handy for it.
Keep in mind that the numbers presented are based on difficulties and exchange rates right now and as such will change. I will provide sources for all values and calculations so that you can re-calculate at any time.
A decent dual-core CPU will net you about 3 kH/s on Tenebrix (0.003 MH/s) and our friend the Bitcoin Mining Calculator says that at the current difficulty of 0.288 you should mine 10.48 TBX per day. BTC-E has the current TBX/BTC exchange rate at 0.000195, so that's worth 0.0020436 BTC per day. The same math could be done for FairBrix, LTC or any other sCrypt() derived forks.
Now for the BTC side of the fence: At the current difficulty of 1379647.43921 (auto-populated in the calculator, but available from the same blockexplorer clone I linked earlier) the same CPU will run about 3 MH/s on the Bitcoin network worth approximately 0.00219 BTC, roughly the same result.
So there's your (hopefully future-proof) answer: let the math guide you. As of this exact moment, mining TBX about the same efficiency though you'll probably see smoother returns with an sCrypt() fork (i.e. more shares per hour)

I think you make a fundamental mistake in your calculations.  My CPU will hash faster on the Bitcoin network than on the Tenebrix network, since Bitcoin uses a simpler hash.  My dual-core CPU gets around 4000 kH/s on Bitcoin, not 3 kHs, approximately 1000 times faster, and so multiply the 0.00000219 by 1000, get 0.00219, and find that the expected rewards seem to be pretty much the same as for Tenebrix.  I've been mining on P2Pool for 16 days at 4000 kH/s and have received 0.0856 BTC.  That's 0.005 BTC per day.

You're correct, my apologies. So yes, roughly the same result. My answer has been edited to reflect the correct math. :)


text:
How to sell bitcoins for cash money?
I'm asking about how to turn bitcoins into cash (USD or EURO) that you hold in your hands, so I can use it in real life not on the internet.
I don't have a credit card, and I'm in a country (IRAQ) where banking services aren't so profound and people don't use credit cards.
What do I need to do this?

This has been asked a bunch of times before: http://bitcoin.stackexchange.com/questions/tagged/sell-bitcoins

By the way, the process of converting something into cash is technically referred to as "selling". So what you're trying to do is sell Bitcoins.

There are many ways to solve your problem. It all depends on the amount.


text:
Can miners choose which transactions to mine?
I'm curious if miners can choose which transactions to mine?  I know that there are limits to the minimum size of a transaction fee (around 5400 satoshis) but I'm wondering if miners can ignore those limits for certain transactions.  For example, if I gave a mining pool a list of addresses and offered an incentive to them to mine them even though the transaction was non-standard, could they do it?

I know that there are limits to the minimum size of a transaction fee (around 5400 satoshis)

Actually, some transactions can sent for free.

For example, if I gave a mining pool a list of addresses and offered an incentive to them to mine them even though the transaction was non-standard, could they do it?

Absolutely. A miner can include any transaction that doesn't break network rules, for any reason.

Then what happened if at the same time, one miner sends a block solved with transaction #1#2#3 and another sends a block solved with transaction  #1#4#5: which one is the first to enter blockchain? Is the #1 transaction double confirmed?N


text:
Get work on custom solo mining software
I'm making a bitcoin solo miner, what is the URL to get the current block header a with JSON call? I also need the URL where the work will be sent if a valid solution is found.
Right now I'm trying to understand how the solo mining process works. From what I've found on the internet, to get and receive data from the bitcoin network I need to make some JSON calls, but I don't know the URL and the format. If I understand correctly, this is how I think the miner works:

Get header from the network
Find the nonce that makes the header hash to a low enough value
Send the data out to the network
If the nonce is correct get paid

Am I correct? Are there any tutorials or can someone give me an explanation of how this process works?

Welcome to the bitcoin stack exchange! If you need help getting familiarized, there's the help center and the tour. In order for you to get the help you need, I would suggest adding some more detail to your post, such as how your current setup is configured and what you have tried already.

So I need a detailed explanation ( or links to examples ) of how it works in theory for each step I mentioned.( except step 2, I know how that works )
I haven't started to code the miner yet, I'll do that after I know exactly what I'm doing

This is a complete implementation of a getwork miner: https://github.com/jgarzik/pyminer

related: http://bitcoin.stackexchange.com/questions/12603/the-bitcoin-mining-algorithm-from-a-programmers-viewpoint


text:
Why does `connect` perform worse than `addnode` for synchronization?
I've manually set many nodes in my bitcoin.conf file via the connect= property.
I can see that, when run, bitcoind connects to most of these nodes successfully.
However, I never see any blocks being downloaded.  I can only get blocks downloading if I either change the connect= properties to addnode=, or remove the connect= properties altogether.
Does anyone know why this is the case?

If you use connect your bitcoind will exclusively connect to the nodes that you have specified in conjunction with connect.
When you use addnode your bitcoind will preferably connect to the specified nodes, but will also announce itself to other peers that are connected to them and try to make more connections.
The nodes that you had specified with connect might have been overloaded and therefore hadn't sent any data or even didn't accept the connection request. On the other hand, using addnode might have allowed your daemon to find additional peers that have seeded the data instead.

I guess I'll just have to try more nodes - thanks @Murch.


text:
i would like to know how long it will take me to mine 1 bitcoin with a 12 th/s mining rig
I am going to start mining bitcoin.  I plan to use 6 antminer s4.  that would give me 12 th/s.  with this set up how long would it take me to mine one bitcoin?

It will take about a week.
You can use a calculator like this one.
https://alloscomp.com/bitcoin/calculator


text:
Negative Dogecoin Balances?
Through dogecoin-cli, I sent half the dogecoins I own to an external address. Now, when I call the listaccounts function, I get this:
[root@web ~]# ./dogecoin-cli listaccounts
{
    "" : -25001.00000000,
    "doge" : 48136.85072100
}

Notice how the "" has -25001.00000000. I am using a query from php to get the balance of "doge" and display it to users. That returns 48136.85072100, which is a problem, because I only have 23135.85072100 doge. How can I fix this problem? Thanks!

This is a problem general to all Bitcoin-derivatives. Perhaps you should edit your question to make it more general.

If you have multiple accounts: use sendfrom to send from a specific account. If you don't care about the accounts, use getbalance

Problem

rricci2009 commented:
After few transaction by sendtoaddress command, balance in "" became negative. I solved with the "move" command from another account to "". [...]

Cause

sipa commented:
That is expected behavior, if your incoming transactions credit accounts other than "", but outgoing transactions debit account "" (the default if you're not using sendfrom), the "" account will go negative. [...]

Mitigation

Tectract commented:
[...] So, is there a way to do something like a sendtoaddress command that won't leave me with odd negative balances?
gavinandresen commented:
Use the sendfrom RPC command.
And you can use the move RPC command to reset account balances to what you expect (and listaccounts to see all accounts / balances)

Source.


text:
How do I check the checksum of a Bitcoin address?
I'm working on a Bitcoin ATM. We want to detect addresses that are entered incorrectly.
There's a checksum on Bitcoin addresses - but how can we check it?

ah.found it          if(!validateAddress(rcp.address))
{
return InvalidAddress;
}

If you can choose the option of answering your own question for future queries that'd help!

@WizardOfOzzie: Right on. Also, if you know that the information is correct, feel free to use any "comment answer" as a starting point to create a full answer. It might be nice to quote the original commenter, but anyone has my blessing to the reputation for the answer if he does that.

The way Bitcoin checks a public address is using what is called Base58Check. While the Bitcoin Wiki covers Base58Check, I'll outline how it works in both abstract and technical terms.

The whole idea of Base58Check is to prevent invalid addresses. This is done by adding digits to the start (00) and end of the Base58 value (4 bytes of double SHA256 hash).

Add 00 to the start of Base58 value ie 00 + BASE58 ==> 00BASE58
Checksum = 1st 8 digits from SHA256(SHA256(00BASE58))

BASE58Check = (00)(BASE58_SHA256RIPEMD160_HEXADECIMAL_VALUE)(CHECKSUM) (parenthesis for visualisation only, all other data is correct in size, ie CHECKSUM = 8 chars)
The best way to visualize all this is with The Piachu's App

Excellent answer and infographic!

Rosetta Code has several example implementations in multiple languages.
Python 2 & 3
import codecs
from hashlib import sha256

digits58 = '123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz'

def to_bytes(n, length):
    s = '%x' % n
    s = s.rjust(length*2, '0')
    s = codecs.decode(s.encode("UTF-8"), 'hex_codec')
    return s

def decode_base58(bc, length):
    n = 0
    for char in bc:
        n = n * 58 + digits58.index(char)
    return to_bytes(n, length)

def check_bc(bc):
    bcbytes = decode_base58(bc, 25)

    if bcbytes[0] not in [0x00, 0x05]:
        return False

    return bcbytes[-4:] == sha256(sha256(bcbytes[:-4]).digest()).digest()[:4]

if __name__ == '__main__':
    print(check_bc('1111111111111111111114oLvT2'))

This cannot be used to validate bitcoin addresses. Returns True for the following strings:DPPGKttReEyzL5iQJExKvmS68QWTFvaecJ, MfwMaegJ8qB4QMvtFqgfaD8o2FrYse7LU, mtcrV4Wux9xPapqHz13eAEmynVhyfNTY7u

If you wish to check the version byte, check that too.


text:
What transactions will be included in the next block?
The miners decide whether a transaction will be included in the block.
What information do miners have about unconfirmed transactions?
How can I know, in detail, what transactions are going to be included in the block?

Willipm, I've attempted to clarify your question. If I've changed the intent of your question, feel free to use the 'rollback' feature. (It's under the revision history.)

I thought maybe the original question was asking about what details of transactions do miners see?

@Nick ODell  Chuck got me.Since George's answer has coverd both of the question,no bother to do the roll back.


text:
How does the Bitcoin network checks if the miner has changed the mining reward?
You know the mining reward is just a number in the code,what if a miner changed it?

It's possible you mean 1 of 2 things by "mining reward":

Coinbase transaction.

Currently this reward is 25 bitcoins per block. If a miner changes this to be higher, it is an invalid block and other nodes will not accept this as a valid block. If the block is not accepted by other nodes, it doesn't go into the blockchain and the miner will not get any bitcoins.
The miner can change the reward to be lower than 25 bitcoins currently. This is potentially a way to slow down bitcoins coming into existence, but is otherwise not harmful. There is an economic disincentive for a miner to do this, but it is possible.

Transaction fee.

This is the difference between the sum of the inputs and sum of the outputs in any given transaction. As the transaction is signed by a private key, any changes to either inputs or outputs will cause the signature embedded in the transaction to be invalid. If this transaction is included in a block, the block itself is invalid and will result in other nodes not accepting this block. Similarly as (1) the block being invalid will cause the block to not get into the blockchain causing the miner to not get any bitcoins.
Basically, the miner is heavily incentivized to act honestly as that's the only way a miner can get bitcoins.

(or lower) There's no rule against that, actually.

@NickODell So the miner can do that?

I stand corrected. I'll change the answer.

ok, I think I get it


text:
Naming convention: MilliBit or Millibitcoins (mBTC), microbitcoin or Mikrobitcoins (μBTC)?
I heard about many use: Bitcents, Bitmills (or Bitmilles)

1.02 - One bitcoin and two bitcents
  0.001 - One millibitcoin (nickname "one Millie")
  0.000001 - One microbitcoin (nickname "one Mike")
  0.00000001 - The bitcoin base unit (nickname "one Satoshi")

millicoins, microcoins, and nanocoins
Which are the official naming conventions and should Bitcoin be capitalized when you are referring to the unit?

Normally, currencies aren't capitalized.

Closely related: http://bitcoin.stackexchange.com/questions/114/what-is-a-satoshi

Also related: What is the difference between BitCoin, Bitcoin, and bitcoin?

Prevalent units of bitcoin
To my knowledge, only bitcoin and satoshi are subunits universally used for Bitcoin.
As of 2014/2015, one also often sees bit as a moniker for one microbitcoin, i.e. 100 satoshis.
BTC has been used as the abbreviation for bitcoin for a long time, yet, in September bitcoin was added to ISO 4217, as XBT, where X means not associated with a country, just as  in XAG (Silver) and XAU (Gold), and opposed to national currencies, e.g. USD (US Dollar). However, it seems to me that XBT has not been adopted by the community, BTC remains prevalent.
Origin of millibitcoin and microbitcoin
Millibitcoin and microbitcoin follow the conventions of the International System of Units, and thus are derived from the main unit bitcoin with a prepended "m" for millibitcoin and a prepended "μ" for microbitcoin.
Following the same conventions and starting from the common abbreviation BTC for bitcoin, one would use mBTC and μBTC.
Millibit and microbit are confusing
While usually people will understand the meaning, using the abbreviations "millibit" or "microbit" gives the impression that they are assiociated with bit as the main unit. This is especially confusing with the advent of bit as a nickname for microbitcoins.
"bit"
Bit is a terrible name for two reasons: Bit, the binary digit, is the basic unit of information. It is used a lot in the context of anything related with computers and therefore shouldn't be doubled as a subunit of bitcoin. Second, due to people using "millibit" and "microbit" it is terribly confusing to anyone that is new to Bitcoin, but familiar with the International System of Units.
Millie and Mike
"Millie" and "Mike" were proposed nicknames for millibitcoin and microbitcoin, but I haven't seen them get much usage. I don't think that they will see adoption.
Units in English
In general currencies are not capitalized in English, unlike the name of the protocol. So, you would write about the Bitcoin protocol, but five bitcoins.
Overview
I would argue for the following usage of units:
Unit       Value in bitcoins  Value in satoshis   Abbreviation   Symbol
------------------------------------------------------------------------
bitcoin        1.0               100,000,000             BTC        ₿
millibitcoin   0.001                 100,000            mBTC       m₿
microbitcoin   0.000001                  100            μBTC       μ₿
bit            0.000001                  100             bit        ƀ
satoshi        0.00000001                  1         satoshi        ṩ

Note that there neither bit nor satoshi have a widely used symbol, and these two are my personal preference.

So, the question is, what is mBTC?
Well, for starters, there are quite a few different mBTC tokens, and they can stand for multiple things because there are multiple tokens with mBTC. So, to begin, I have two notes with 20 mBTC on them. They are Blockchain bitcoin notes. Based on what I assume and studied, they might be 'Mirrored Bitcoin', because if it were 'millibitcoin', I would have a note that says '0.00' followed by some BTC amount in mBTC.
Therefore, the number 20, representing the coins, must be greater than 1.0 or equal to 1.0 to have 20 coins equaling 20.0 mBTC. From my study, I found that there are several mBTC variants: Mirror Bitcoin, microbitcoin, Moon Bitcoin, Bitcoin Chromatic, Meta Bitcoin, Mstable Bitcoin, and millibitcoin. All of these are mBTC denominations. So, if your coin's value starts with a number before the decimal point in the equation, you have more than one coin. It's not 1 millibitcoin, as having less than one coin would result in a millibitcoin.

Hi Kyle, I don’t understand how your answer relates to the question. I have never heard of “Mirror Bitcoin, Moon Bitcoin, Bitcoin Chromatic, etc.” as subunits of a bitcoin. Do you perhaps want to take another look at this?

Do you mean notes as in paper currency bank notes? Something like pseudo-accounting entries?

If you have a new question, please ask it by clicking the Ask Question button. Include a link to this question if it helps provide context. - From Review


text:
Does bitcoin-qt support mining in a pool?
I am having difficulty getting guiminer to share a pool with me but if I mine on bitcoin-qt -gen 1 it starts hashing straight away. So I'd like to know if the official bitcoin client supports pooling?

No. Also the hashing implementation in the client is very, very limited. It is not optimized for different architectures AFAIK and does not support any other calculation medium other than regular CPU. That means no GPU, FPGA or ASIC mining. And CPU are extremely slow in comparison with these (see for example Why a GPU mines faster than a CPU).
For this reason the standard Bitcoin GUI client (bitcoin-qt) does not support mining anymore.


text:
Can I mine bitcoin without damaging my hardware?
I have a 900w gold certified power supply, an AMD fx 6350 @ 4.39ghz, a nvidia gt 630 2gb GPU with a fan and 8GB DDR3 RAM at 1600MHz. I'm wondering what mining for about 8 hours a day would do to my hardware. I'm not concerned about my graphics card as I only use it for mining but my CPU, RAM, motherboard and other components I am concerned about. My case has very well airflow with 3 exhaust fans and 2 intake, I also have aftermarket cpu cooler. This would be my first time mining along with using this site and I'm curious on whether or not it will do any damage or degrading to my PC.
Thanks

Is there some reason you would want to do this?

You're 1.5 years (of  exponential growth) too late with that kind of hardware. You'll get 0 bitcoin for wasting electricity and just wear on your fans.

CPU mining ended in 2011 and GPU mining in 2013.

That would depend on your definition of damage.
First of all your equipment is going to 'wear down' much faster if the CPU is at 100% load longer than an hour or so. Normal computer usage lets the CPU throttle somewhere between 20% load and 100% for let's say 6 to 8 hours a day. CPU coolers are made to prevent the CPU from overheating in all possible situations, so it won't burn out your CPU immediately.
But with normal computer usage your CPU will heat up, cool down a bit (a bit less hot), heat up again, etc. With mining on a CPU, the CPU will heat up and continue heating up to the point where the heat exchanged by the CPU cooler will be equal to the heat produced by the CPU. This is called an equilibrium (or balance).
There are temperatures your PC would be OK with running 24/7, but that does not mean anyone would recommend you doing so. You won't ruin your computer right away, but the chances of it will definitely be higher.
Next to that, the amount of bitcoins you can generate letting your CPU mine bitcoin right now (December 2014) would be around 0.00000001 a week... ? That's about accurate. (Not taking power usage into account.) If you really want to mine cryptocoins on your CPU, look for a CPU-only cryptocoin and then exchange the mined coins to Bitcoin, that way you'll get much more in most cases.
If you absolutely want to mine Bitcoin directly without mining an altcoin, look at this: How do I start mining?

Yes, you can. The question is similar to "Can I play Battlefield w/o damaging hardware" ;)
Hardware that you have does not give you to much bitcoins now, even in long term mining.
Check this out:
https://en.bitcoin.it/wiki/Mining_hardware_comparison
http://www.coinwarz.com/cryptocurrency


text:
How do I set up GUIMiner to use my cpu?
I'm using GUIMiner. It's not using my CPU. My CPU is at a very low utilization (~10%).
What I can do to use my CPU?
Why isn't CPU mining turned on by default?

What are you trying to do? What does this have to do with bitcoind?

What coin are you mining?  For most coins, CPU mining costs far more in electricity than the revenue you can expect to get from it.  That's why it isn't on by default.

CPU mining ended in 2011. You will earn less than what the electricity costs, so the more you mine the more money you lose. You will never earn the minimum amount required to cash out from a pool, so you actually won't be earning anything at all, just burning electricity.
This is why CPU mining is disabled, and why noone should use it.


text:
How does one checks which customer made a payment?
One question I'm not able to properly answer when asked is

How exactly can  the blockchain verify the identity of the user without a centralized trusted party such as VeriSign?

I know this is done in a decentralized way and the ECDSA algorithm should do the trick, but other applications still need a centralized trusted party in order to verify if the user is really who he says he is even when they're using ECDSA as well.
But how exactly can I guarantee that nobody can pretend to be someone else and spend their bitcoin instead?
Yes, I know the basic of how public-key cryptography works, but Information Security is not strong with me.

Edit: let me explore the question further.
Suppose I own a coffee house with intense flow of customers. How can I be sure about costumers that had already paid and others how didn't pay?
Let's say that Bob and Anna are my customers. Bob orders a Macchiato, Anna orders a Capuccino. Both coffees have the same price. How can I know which payment came from each one of them?

Do you really care which customer paid, or do you care which bill was paid?
Say you have customers Anna and Bob, who both order something. Bob notices he's out of money, so Anna says she'll pay for both. If you really want the sender to reveal their identity, your system would already fail, as Bob never pays anything.
In almost all cases, all you care about is which bill is paid, and you have no need for the payer's identities (which could be a privacy violation in some cases).
The normal way to do this in practice is by creating a new payment address for each payment you want to receive. You track which bill was paid by tracking at which addresses you received money. Creating new addresses is very cheap, and they are sufficiently long that it is exceedingly unlikely that the same one will ever be produced twice.

It would be good to also make clear how vast the bitcoin address space is: there are so many possible addresses available that you can easily create a new address for each new bill without worry that you will run out of new addresses.

This could for example be done with a reference to Is each Bitcoin address unique?

You should care who paid for it. As a former e-commerce site owner, we were always concerned that someone would fraudulently pay for goods with someone else's money, as that resulted in lost money for us (restocking, shipping fees, labor time spent dealing with banks, etc).

@corsiKa Sure, for something like that. In a retail setting like the coffee house mentioned here, it really doesn't matter very much, unless you want to be able to call out the customer's name when their order is ready.

@corsiKa: A good (or bad) feature of Bitcoin is that if someone fraudulently pays you for goods using someone else's money, you still get to keep the money: there is no technical way for the rightful owner to claw back the funds from you.  Just like cash, there are no chargebacks.  So in that sense, you actually don't have to care who paid.

@corsiKa: in the case of Bitcoin, if someone can spend your money, then that means you have been careless with your private key. With no government to enforce law, and the mathematics making law enforcement pointless, it's your own fault for not taking better care of your private key.

The payer's identity is often irrelevant in Bitcoin payments. The important check is that the payment was authorized by the owner. In Bitcoin, whoever controls the private key owns the funds, and therefore it is sufficient that the transaction was signed with the correct private key (which is a given for a valid transaction).
What's important to the shop owner is to know that they got paid. As Bitcoin payments are irreversible, it's not important whether Bob gives his name, just like the barista wouldn't care to get Bob's name when Bob walks into the café and pays for a Macchiato with cash.
To distinguish payments, you give out a new receiving address for each invoice. That way, when an address receives money, you know which invoice was settled. Luckily, the Bitcoin address space is sufficiently huge that everyone can make as many addresses as they need.

Different orders have different Bitcoin payment addresses.
The order is paid when the address in question receives the requested amount of Bitcoins.

The only practical way to verify the identity of a user is to make the user sign something with their private key. The only identity information that you get at that point is that the user has access to the private key. On the bitcoin blockchain, the owner of the private key is the only one that can move the bitcoins locked to that key because a signature is needed to do so. Essentially, if you try to pretend to be someone else, you won't succeed since you won't be able to produce a signature.

simple answer: give each customer your different address
never reuse addresses


text:
Is mining an instant process or it generates fraction of coins constantly?
There are hashing calculators in the internet that tells the average amount of bitcoin you'll make in a period of time. I know that when you generate a block you gain 25 BTC (I guess it is still the reward). How is this possible? It's saying you gain ~10000 dollars when you generate a block? The only way to mine bitcoin is either by generating an entire block, which they say will reward you with 25BTC. But the calculators say something like $200/month. How is this possible? For me, the only way to gain is by winning 25BTC + fees of the block, or not gaining anything.

You are correct, bitcoin mining is a very binary thing. Either you find the hash and you get rewarded bitcoins (currently 25 BTC) or somebody else finds it and you get nothing and have to try your luck on the next block. But because solo mining is such a crapshoot, people tend to join their miners together into what is known as a "mining pool". In this way, because a pool of miners has much more processing power than a solo machine, there is a much better chance that it will find a block and get the reward. When this happens, the reward is split amongst everyone who contributed to the pool based on the amount of processing power they contributed. You get much less BTC than if you had found the block yourself, but the rewards are more consistent. Those hashing calculators are never exact because bitcoin mining is, by design, meant to be random. All they can do is make an assumption, probabilistically, of the average amount of BTC you might make based on your hashrate.

The mining reward is assigned to the miner by the very block he finds. This happens in the first transaction in the block, the Coinbase transaction. So, yes, there is only one mining reward given out every block, and it is currently 25BTC + fees.
As finding a block is a rare event, miners organize in mining pools. They pool their work, but then also share the revenue. That way, the time between finding blocks is shortened, and payouts are more frequent but smaller. Mining pools buffer miners from the variance of solo mining.


text:
How to get BitPay to process each settlement using a new address?
Since receiving multiple payments using the same address isn't safe, is there a way to get BitPay to settle the balance using a new address each time? It wouldn't be feasible for the user to log in and submit the new address manually every time. Is there a secure API for this?
Thanks

Receiving multiple payments at the same address isn't "unsafe," though it does decrease anonymity. Spending multiple times from the same address may be unsafe if your wallet software isn't properly crafted to produce unique k (nonce) values for each ECDSA signing (see http://rdist.root.org/2010/11/19/dsa-requirements-for-random-k-value/).

Yes, deanonymity is my concern.