Why is mining necessary for the Bitcoin network/system? I understand that a transaction is a record of 1+ Bitcoins being given from one party to another.

I understand that a block is a collection of unverified (pending) transactions that gets verified every ~10 mins or so.

I understand that mining is the act of running specialized software that will solve some cryptographic problem, and as a result, allows a block of pending transactions to be added to the block chain (history of all transactions, ever).

So first off, if anything I have said so far is not true or misleading, please begin by correcting me!

Assuming I'm more or less correct, I'm still not seeing why mining is crucial to the system, and am (obviously) not seeing the forest through the trees here.

If I send 10 BTC to someone, why does someone else (a "miner") need to verify this? Shouldn't this transaction be stored in a DB somewhere, and verifiable by querying that DB?

You should start here: http://www.youtube.com/watch?v=GmOzih6I1zs

As the video mentions, mining is needed to ensure fairness and for keeping th network stable, safe and secure.

Now, let's see what that means. But first a very brief explanation of the principle of mining.

Mining

The Bitcoin network consists of nodes that all store a database with all transactions, called the block chain. This database consists of a long chain of blocks, each holding one or more transactions. What miners basically do is bundling all unconfirmed transaction into a block. The form of the block must satisfy certain conditions before the block is considered valid. This condition is called proof of work and is not trivial to understand. When a miner finds a block that is valid, it can send its block to the network and others will verify it. When it is indeed valid, all clients will add it to their block chain. Every time a miner finds a valid block, it has the right to assign a certain amount of bitcoins to himself, called the block reward. They also get all transaction fees of all transactions included in his block. This way, new bitcoins are added to the network and it can be ensured that transactions can be confirmed.

Fairness

Since Bitcoin is peer-to-peer and there is no central authority to control it, every one can send any kind of transaction to the network, whether or not it is valid. You could simply send a transaction that sends someone else's coins to yourself.

Luckily no one in the network will accept your transaction. When you want to spend bitcoins from a certain address, you will need to sign the transaction with the private key of that address. Other clients in the network can verify that you own that private key because they have the public key. This method is based on public-key cryptography.

So when miners try to bundle unconfirmed transactions into a block, they first need to confirm every transaction to make sure that all transactions in its block are valid. When they are not, other clients will not accept the block they mined when they send it to the network.

This way, miners ensure that people can only spend bitcoins they own.

Stability

This is the least difficult one to understand. The Bitcoin protocol sets the difficulty of the mining problem so that averagely every 10 minutes a new block can be found by some miner. This way, a transaction takes 10 minutes to be confirmed on average.

However, after a transaction has been included in a block, it still is not irreversible. This is not easy to understand, but when a miners try to mine a new block, they include in that block the number and the ID of the previous one. So let's say someone mined block 100, which follows number 99. It can happen that someone else didn't notice that someone found a valid block to follow on 99 and makes a valid number 100 itself as well, let's call it 100'. In this case, most clients will only accept the first block they received. But it can happen that another miner received 100' first and will find a block following on 100' and not on 100. Then we have following situation:

98 - 99 - 100
      \ _ 100' - 101'

When clients notice such a situation, they will always choose the longest existing chain (that only consists of block they think are valid). This means that block 100 will be discarded and that 100' and 101' or now the two last block of the main chain. This means that a transaction that was confirmed by block 100 is now possibly no longer confirmed. Luckily, the miners who found block 100' or 101' probably also knew of the transaction and most probably they also included it in one of those blocks. But it can happen that they did not and so a transaction can be undone.

For this reason, most clients and merchants require a transaction to be confirmed by at least 6 blocks. This means it must be included in a block that has at least 5 blocks after it.

The fact that a transaction will be able to be considered confirmed after averagely 1 hour, makes it a stable situation. It happens rarely that transactions confirmed for more than 1 hour will ever be reversed again.

Safety and security

The previous part about stability already included some security aspects of mining. It is clear that miners make the Bitcoin block chain trustworthy. When a transaction is included in a block and 5 or more other blocks have passed, you can be sure it is irreversible and safe to accept it as a payment.

It is also clear that the safety and security of Bitcoin as a payment system is in the hands of the miners and that every time one of them solves a block, he has the power to decide what transactions he accepted to the block chain.

Mostly, all miners are fair and they will include as much valid transactions as possible. Whenever a miner is not fair and it selectively excludes some transactions, some other miner will likely include it in the next block.

There is however one flaw. When a miner has more computation power than all other miners combined, it can always create new blocks at a faster rate than the others. This gives him much power over the block chain, and that is to be avoided at all cost. This flaw is named a 51% attack. This answer sums up the consequences of what could happen if someone would have 51% of the network computation power.

But this is a security flaw, what has this to do with why miners should mine? Well, as more people mine, the total computation power rises and it will be much much harder for someone to perform such a 51% attack. Currently, to own hardware capable of performing such an attack would be so enormously expensive that it is economically unfeasible to do, if not completely impossible. So, every miner who contributes his power to the network ensures that only fair miners will find blocks and that the network will be safe for people to trust upon.


Bitcoind blocks fell behind sometimes I ran 6 or 7 bitcoinds with version 0.93 on CentOs. I used the default configuration on all of them. Sometimes I found one or two fell behind the others. And I need restart them, then they would work. I don't where is wrong, or there is some problem on the 0.93 version. Do I need update to the 0.10 version? When will the official 0.10 release. Thank you very much.

"Is there a problem with 0.9.3 that causes it to fall behind? That's a serious problem for the network, but I haven't heard anyone else report it.  If you debug it and discover that it's Bitcoin Core's fault, please report it.  However, here are a few common reasons for problems:

Insufficient resources: if you're running Bitcoin Core on an underpowered VPS, Raspberry Pi, or other marginal hardware, you'll get all sorts of strange problems.  I recommend a minimum of 1 gigabyte memory for a full node.
Hardware problems: bad memory, failing disks, and especially CPU overheating issues can cause your node to stop working or fail validation of a block.
Suspend/Hibernate issues: when restoring from suspend/hibernate on Linux, my nodes sometimes take a long time to reestablish connections and start downloading blocks, meaning my node looks like it has fallen behind for awhile.
Clock issues: if the clock on a computer falls behind real time by more than about 2 hours, it may not accept the most recent blocks.

"Do I need to update to 0.10.0?" Right now 0.10.0 is in the Release Candidate (RC) phase, which is the last testing phase.  If you'd like to help test, feel free to upgrade.  But if you're relying on Bitcoin Core behaving correctly, staying on most recent released version (0.9.3) is advised.
"When will 0.10.0 be released? When the developers think it has been well tested, and not a minute earlier.  I know major software companies often release software on a set schedule, but they do it by holding back (hopefully) release-quality software.  Open source doesn't work that way---everyone can see the source code, so you either release when it's ready or someone else releases it for you. :-)

Debugging Tips

I highly recommend that you try to find out what causes your nodes to behave incorrectly or you're likely to have the same problem on 0.10.0 that you have on 0.9.3.  Here are some quick tips:

Check $HOME/.bitcoin/debug.log for any warnings or errors.  If you can't figure out any messages using a web search, feel free to ask here.
Start bitcoind with -debug to log additional information.  Note, this will make your log file grow in size faster than normal, and it will inhibit shrinking the logfile on startup for as long as you use it.
If you only rarely check your nodes, scanning the whole log might be hard.  I suggest starting at the time indicated in the header of the old block you're stuck on.  For example, if you're stuck on block 330,000,

run bitcoin-cli getblockhash 3330000 to get the block's header hash;
run bitcoin-cli getblock <hash> to get the block.  Note the time field
run date -ud @<time> to convert the time into human readable UTC, the same as used in debug.log.

Use bitcoin-cli to run RPCs in an every-minute cron job to log additional information.  An example cron job might be, * * * * * { date -u ; bitcoin-cli getnetworkinfo ; } >> getnetworkinfo.log


What's the rationale of using ECDSA instead of RSA? One major drawback of (EC)DSA is that it requires a good RNG, otherwise the private key may be accidentally exposed. This is also one of the major reasons (I found so far) why no(?) smartcard supports any kind of DSA. In contrast to that, RSA, while usually being used for encryption, can also be used for digital signatures and behaves deterministic, i.e. signing the same message again will yield the same signature everytime. Lacking the requirement of a RNG (other than in key generation) this is why RSA is available on many smartcards, which would make bitcoin much safer without requiring a rather complicated offline-wallet setup.

So, does ECDSA provide anything bitcoin absolutely needs that RSA cannot achieve? Or is it merely bad luck in Satoshi's choice?

I'm not sure why you think RSA is much safer than ECDSA. As you can read here: https://crypto.stackexchange.com/questions/3216/signatures-rsa-compared-to-ecdsa

ECDSA offers same levels of security as RSA, but with a much smaller footprint.

In fact, the more you increase the security, the larger the RSA keys become compared to ECDSA.  This makes RSA less fit for a system such as bitcoin which requires small packets to be sent around the network all the time (being peer-to-peer).


How can I avoid paying transaction fees? A bitcoin transaction requires paying a fee to the network, and that fee changes depending on network congestion. During busy times the fee rate may increase substantially, so how can a user avoid paying these fees in the first place?

Is there a way to transfer/import bitcoin from one address to another in order to avoid transaction fees?

(I'm posting this question because I was writing a reply to a similar question, and halfway through writing that reply, the question was voted closed)

Is there a way to transfer/import bitcoin from one address to another in order to avoid transaction fees?

No. It is not possible to move btc between addresses without publishing a transaction to the blockchain. However, there are some ways to accomplish a similar result (transferring/altering the ability to spend some coins), but I think every one of those ways will employ a different trust model than actually transacting on the blockchain. As a user, you must balance the level of trust you are comfortable with, against the need to save on transaction fees.

Some examples:

Off chain transactions using a centralized service:

This is how an exchange moves btc between accounts without incurring transaction fees. For example, when you buy/sell on a bitcoin exchange, a transaction is not actually published to the blockchain. Rather, the exchange will simply update their internal database, which keeps a ledger of all user account balances. As a user you are trusting that the exchange has a full reserve of all outstanding user $ and btc balances, and that they will not make an error in keeping track of your account balance.

Off-chain transactions by exchange of private keys

You can give someone bitcoin by simply giving them a copy of private keys for a funded address. In this situation, the recipient will need to trust that you do not own any other copies of the private keys, or that you will not spend the coins yourself if you do have a copy saved.

(as an aside, if you are sharing keys with a friend, and the coins are stolen by a third party, it may be impossible to prove to your friend that you did not simply steal the coins- and vice versa).

Off-chain transactions by exchange of private keys, which are provably not backed up

This is made possible by specialized hardware, such as that produced by OpenDime. In this case, as long as you trust that the OpenDime hardware functions as advertised, you can give someone a funded OpenDime stick and they do not have to worry that you might have a backup of the keys for those coins.

A signed transaction that is communicated off-chain

In this case, you could sign a completely valid bitcoin transaction that sends coins to your recipients address, and then send someone the raw tx data, without publishing it to the blockchain. The recipient would be able to publish the data to the blockchain themselves, but they will have to trust you to not sign and publish a different transaction using those same outputs in the meantime. This method would also only 'delay' the spending of the tx fees.

(I'm honestly not aware of any actual use-case for a scheme like this. It's probably a dumb idea that requires a lot of trust, but it is possible nonetheless)

Payment channels

In this case, two transacting parties can lock some amount of btc into a special multi-sig address, and then trade a limitless number of partially signed transactions back and forth off chain, with no tx fees, and no need to trust the other party will not steal your bitcoin. The parties involved can only exchange value up to a maximum amount (the amount they locked into the channel), but the channel can be bi-directional, so payments can be sent back and forth basically endlessly otherwise. This method still requires a transaction fee to open and close the payment channel, but that fee now account for a vast number of 'off-chain' transactions, instead of just one or two on-chain.

An implementation of this idea is the lightning network, it is currently live on the bitcoin testnet.


Is there any tool to check sum of all BTC based on transactions? Is there any tool to check sum of all BTC based on transactions? We can easily get this amonut by sum up mining rewards, but what about sum up all non zero wallet balances?

Sort of.

Bitcoin Core's gettxoutsetinfo RPC command iterates through the entire UTXO set (the set of outputs that haven't been spent yet by another transaction).

Currently, it reports:

"height": 539935
"total_amount": 17249017.33071828

This is the approach you're looking for as it is computed from the actual outputs and inputs, though with a few caveats:

It is not computed on-the-fly from the blockchain; instead, it uses a database with unspent outputs that is always maintained by the validation code.
It excludes provably unspendable outputs (OP_RETURN outputs or outputs with a script longer than 10000 characters).

Note the discrepancy with the expected amount in circulation at that height (17249200.00000000). There are various reasons for this. My answer https://bitcoin.stackexchange.com/a/38998/208 goes into the details.


Transfer of BTC the wallet address p2pkh to wallet address p2sh Is it possible to send BTC from wallet having address type p2pkh to the receiver wallet address p2psh

As long as a utxo is spendable, there are no restrictions on the types of outputs - any kind of input can be used to create any kind of (valid) output, which will usually be one of the well known ones - i.e. p2pkh, p2sh, p2wpkh, p2wsh, op_return, p2ms, p2pk.


Why would running a light node riskier and subject to more frauds than a full node? We don't NEED a full ledger, do we? I've been reading on light node and many have pointed out that the light node doesn't have the full blockchain and is riskier because they can't verify the transactions fully.

First, we can verify or validate the transaction on the website. I don't understand why do we need a full blockchain if we are not mining.

Second, doesn't miner verify the transactions before including into the block? In addition to that, the process of validating the block served like a double validation?

Third, when the block is added to the network, isn't it a third validation?

Forth, when the block has several more confirmations, isn't that a forth validation?

In this case, why do we need a full ledger? After a certain time lapse, many of the preceding blocks are seem redundant.

A light node, although doesn't have the full ledger since the genesis block, keeps a section of the most recent blocks, isn't that sufficient?

Why would a light node be riskier? Realistically, what are the chances of receiving incomplete or invalid blocks?

First, we can verify or validate the transaction on the website. I don't understand why do we need a full blockchain if we are not mining.

What website? There's no website that defines the blockchain. All blockchain explorers just show the information. If you are relying on a website to check that your transaction is valid, then that is a central point of failure. What if whatever website you are using mistakenly says an invalid transaction is valid? Do you just blindly trust the website? This has happened many times in the past, especially with blockchain.info.
The whole point of the blockchain is to remove central points of failure and to remove trust in third parties. Relying on a website to tell you what is correct defeats that purpose.

Second, doesn't miner verify the transactions before including into the block? In addition to that, the process of validating the block served like a double validation?

Miners are supposed to verify transactions before including them in a block. Just because they are supposed to verify does not mean that they actually do. Just accepting a transaction that has been included in a block does not guarantee that the transaction is valid. What if a miner included an invalid transaction?
Again, the point of a blockchain is to remove trust in third parties. By trusting miners to have validated transactions, you are trusting a third party. Verifying a block after you receive it from someone else removes that trust in a third party because you yourself has checked that the block is valid.

Third, when the block is added to the network, isn't it a third validation?
Forth, when the block has several more confirmations, isn't that a forth validation?

Kind of (to both). But again, you yourself are not verifying the blocks if you are not running a node. You are trusting that someone else has verified the blocks. That is trust in a third party, which is what the blockchain is designed to avoid.

A light node, although doesn't have the full ledger since the genesis block, keeps a section of the most recent blocks, isn't that sufficient?
Why would a light node be riskier?

No. If I had sufficient hash rate, I could produce a block that has an invalid transaction and send it directly to your light node. This block with the invalid transaction that spends a nonexistent input and could be something that defrauds you. If you have not verified the entire blockchain and constructed the UTXO set, then you do not know that the transaction is invalid because it spends an nonexistent input. You cannot verify this for yourself. You are trusting a miner that the transactions is valid. This is riskier because you could inadvertently accept an invalid transaction and thus lose money.

Realistically, what are the chances of receiving incomplete or invalid blocks?

Pretty low. But the whole point of the blockchain is to remove centralization and trust in third parties. By using a light node, you are now trusting third parties and this increases your risk for being defrauded.


Unusual Version Number in Blocks I've noticed recently that some blocks contain version numbers that are not the traditional 0x10000000 or 0x20000000.

For example, this block, has a version number of 0x3FFFE000 instead of 0x20000000 like the previous block has.

From my understanding this will not affect the actual hash digest, since it will produce a valid hash regardless of what the version field is.

A quick search on the forum did not return any results, but I am going to take a slight guess that this has something to do with miner voting to show what the consensus is for a future change? If this is the case, does it really make sense due to mining pools being a majority of hash power anyways? (Instead of miners votes individually)

If my prediction is correct, is there some list that defines which proposal coordinates to a given version number?

Thanks

but I am going to take a slight guess that this has something to do with miner voting to show what the consensus is for a future change?

No. There are currently no active consensus change proposals.

These version numbers are likely due to a mining optimization known as ASICBOOST. This optimization is due to a quirk of SHA256 and Bitcoin's block header format.

ASICBOOST is a hardware level optimization for mining chips that allows them to be more power efficient. One of the methods for ASICBOOST is to modify the block version number. The other method is to change only the first 4 bytes of the merkle root, but that requires much more computation than just changing the version number.

Even though this is a hardware optimization, the software for ASICBOOST miners also need to be aware of this optimization. This is why only some pools produce these ASICBOOST blocks, and only some machines can be used to produce them.

For more information about how ASICBOOST works, see How does AsicBoost work?


Where is the bitcoind executable on Windows 10? I have installed bitcoin core 0.17.1 version windows 10 in my laptop.

I can see the following folders: bin (bitcoin-cli.exe, bitcon-qt.exe, bitcoin-tx.exe, test_bitcoin.exe), include (bitcoinconsensus.h), lib (libbitcoinconsensus-0.dll), share (man).

I cannot find daemon\bitcoind.
My bitcoin server is already running and sync on testnet, but I cannot connect via rpc because I cannot find bitcoind.

Any help?

It's at C:\Program Files\Bitcoin\daemon.

NOTE: On the download page, make sure to choose the installer, not the zip file.

The first one:


What development stage do the version 0.13.99 nodes represent? So, obviously Bitcoin Core 0.13.0 and 0.13.1 have been released, 0.13.2 is nearing release, and 0.14.0 will have its feature freeze in a few weeks. However, there are also some hundred odd nodes that show up as 0.13.99. What does that version represent?

While releases are carefully tested, tagged and then made available as executables, it is also possible to compile Bitcoin directly from the source code.

Bitcoin Core nodes that were built directly from a commit on the master branch instead of one of the releases show up as 0.XX.99, where XX is the latest major release.


How do I spend Bitcoins from a specific address? What's happening when I use importprivkey? Are the coins merged to my existing private key or is the new key added to my wallet?

I want to import a private key, receive funds on it, and send the same coins using this key, not the others present in my wallet, is it possible with RPC commands? (for my website, I want the user to be able to see where his money is going by tracking the blockchain).

When you use importprivkey, the new private key is added to your wallet, giving you the ability to send coins received by a corresponding Bitcoin address. Your "balance" will also reflect this, including the coins accessible by this key in the total balance.

Bitcoind low level API gives you a pretty fine-grained control over your coins. Since there is no notion of a "source address" in the Bitcoin protocol, you have to specify the exact transaction and its output that you want to spend. Instead of using the common high-level RPC like sendtoaddress, you need to manually create a raw transaction, which comes in a few steps:

Prepare the transaction via createrawtransaction command, specifying outputs that you want to spend,
Sign the transaction using your imported private key via signrawtransaction,
Send it onto network using sendrawtransaction.

Be careful when using this API as Bitcoind does not protect you from making fatal mistakes, rendering your coins unspendable. Make sure you test your code on the testnet thoroughly before going live.


Bitcoin.org In Inaccessible at My University Any connection to bitcoin.org from the Iowa State University campus times out (HTTP[S] and ping).  It has been this way for years and IT "doesn't know anything about why it's not working."  I've also tried contacting Black Lotus and now Level 3, but neither replied.  I can work around the block, but I don't like doing that for every update of Bitcoin Core.

How would I go about contacting someone who has the power to troubleshoot the problem from the server's end?

I can't say for sure, but creating a ticket on the github repo for bitcoin.org is probably reasonable:  https://github.com/bitcoin-dot-org/bitcoin.org

This is the code repository for the website, and not support for the server.  However, I'm guessing someone there can point you in the right direction, if not help you outright.

But what do I know?  I'm a UNI alum ;)


How output transaction works in Bitcoin? Click here for reference.

  Note also that an output can be used only once. That's why there's a concept of "change address" in the bitcoin ecosystem: if an output of 10 BTC is available for me to spend, but I only need to transmit 1 BTC, I'll create a transaction with two outputs, one with 1 BTC that I want to spend, and the other with 9 BTC to a change address, so I can spend this 9 BTC with another private key that I own.

So what will happen if an output of 1 BTC is available for me to spend, but I want to spend 10 BTC?

Note: It is a general question and is not specific to any API feature.

So what will happen if an output of 1 BTC is available for me to spend, but I want to spend 10 BTC?

If you have 1 USD in your pocket and you want to buy something for 10 USD, you simply can't.

The cited section is equal to: If you have 10 USD and want to buy something for 1 USD the merchant gets 1 USD and you get 9 USD in change.


What is the format of the coinbase transaction? I'm trying to understand the format of the coinbase transaction. I've read that it is arbitrary and not specified. I'm wondering because I need to generate mining work and create an internal pool. As I've found out, you can change the ntime, nonce and extranonce fields. The last one should be suited in the coinbase parameter, right? So, can anyone help me analyze the content of the coinbase transaction and how am I supposed to build one, so all miners in my pool could have different headers for hashing? A step-by-step guide on an existing block would be much appreciated, links and other stuff too.

A coinbase transaction follows the same format as a normal transaction, except:

It has exactly one txin
This txin's prevout hash is 0000...0000.
This txin's prevout index is 0xFFFFFFFF
The txin's prevout script is an arbitrary byte array (it doesn't have to be a valid script, though this is commonly done anyway) of 2 to 100 bytes. It has to start with a correct push of the block height (see BIP34).
The sum of the txout's values cannot exceed the subsidy (25 BTC for now, halves every 210000 blocks) plus the fees of the non-coinbase transactions in the same block.

About the scriptSig being an arbitrary byte array, there is one caveat: the checksig operations in it are counted towards the block sigop limit (20000), so you probably don't want to accidentally trigger this. Making it a list of just push operations (including of the extranonce) avoids that.


Testvectors for dedicated hardware miner I have written my own hardware implementation for hash computation. I am participating in a pool, that is I get sent the midstate and some data which should then be hashed.

I wonder, whether there are any testvectors out there, that is I need input the midstate plus data, and see then whether my implementation finds the appropriate nonce that is also supplied with the testvectors.

Many thanks for your help,
Patrick

The block headers in the blockchain are your test vectors, they already contain the appropriate nonce. Midstate can be computed from these headers, mining software does such a midstate computation (so crib this bit from their source code).


Import bitcoin address only with public key I want to import a none spendable paper wallet. This was possible in the past. But now I am only allowed to import an adress with the private key. So this address won´t be none spendable. Was there an update which changed this?

If you are looking for watch only wallet, the Sentinel or BLuewallet watch-only would be the best option.

https://samouraiwallet.com/sentinel

https://bluewallet.io/watch-only/

They do import wallets based on the xpub(ypub/zpub). Blockchain.info in general is a very weak implementation with engineering flaws.


How would a hard fork for a new key-pair/address generation algorithm be implemented practically? If an upcoming hard fork entails a switch to new method for key-pair/address generation, how exactly is it going to be carried out? How would all the old addresses going to change to ones that are compatible with the new algorithm and how is the transfer of ownership going to be conducted exactly?
For the blockchain to keep the same state after the fork, there would have to be a new address for each old (incompatible) address that holds the same amount of BTC and has the same owner.
One way I can think of is adding support for both the old and new key-pair/address generation methods temporarily, and then prompt all owners holding addresses generated using the old method to send their BTC to new addresses generated using the newer method, and finally dropping support for the old method. With ~30 million unique BTC addresses as of today, and a current block size capable of processing 2-7 transactions per second, this transition would need between 50-173 days to complete, during which the blockchain is completely incapacitated, and miner fees being higher than usual. I suppose it could also trap any BTC that hasn't been transferred to a new address by owners in a timely manner within the old, incompatible address.

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


How to do precise accounting with bitcoind? I'm considering making a service that would be handling user deposits in Bitcoins through a server running bitcoind. Upon purchasing something through the service, I want to withdraw the precise amount of Bitcoins out of the account associated with the user along with a commission proportional to the amount of coins spent. As Bitcoin charges a fee for each Transaction depending on its size, it can vary between Transactions. I don't think there is a way of predicting how much will be charged exactly before the Transaction is executed, so it makes it hard for me to tell the user exactly how much they will be charged, or lower the commission to take into account the fee.

How should I go about doing precise accounting with bitcoind?

That feature has been requested but is not implemented in the Bitcoin.org client:

https://github.com/bitcoin/bitcoin/pull/283

Armory may be getting this feature.  See discussion in the README:

https://github.com/etotheipi/BitcoinArmory#readme


Debit cards & direct deposit? If I wanted to close my bank account and perhaps set up a direct deposit through my employer, is that possible?

Also, will there or are there any Bitcoin debit cards?

I am still trying to understand this.

You would have to ask your employer, but I have never seen that before.

For bitcoin debit cards read this:

http://www.engadget.com/2012/08/20/bitinstant-founder-says-bitcoin-debit-card-to-launch-within-next/


What files one should backup when running a pool or other Bitcoin service? There was a big problem with Bitomat at some point where that Bitcoin exchange lost its data due to some data being lost. To prevent such problems from occurring, what files should one backup? Which files need to be backed up only once, and which should be backed up regularly? For example, should a mining pool backup its wallet.dat often, or is once enough, as the data contained in it will never change?

You need to back up your wallet.dat regularly. If your pool uses "getwork" for generating work and later generating blocks, then each block is generated with a new crypto key. Also, when you send coins out to pay your miners, the "change" is always sent to a new address. So your bitcoind is always generating new crypto keys, and you must back them up so you don't lose any coins.

So any bitcoin service that sends coins or generates new blocks with "getwork" must back up wallet.dat regularly. A bitcoind that only receives coins can be backed up only once. A bitcoind that doesn't handle coins obviously needs no backup (rare case, but can be useful).

Apart from that, of course back up your database and anything else you don't want to lose.

Update: I just want to add that bitcoind has a pool of unused keys. It makes new keys when the pool runs out. Most of the time it just takes fresh keys from the pool - and you backed those up. So you don't have to run backups once per minute to be safe. If you want to do this the best way possible you could give bitcoind the "keypoolrefill" command (and wait for that to finish) before backing up wallet.dat. This way you always back up a full pool of unused keys, and the backup will "last" as long as possible. That is to say, it will take as long as possible before the pool runs out and bitcoind generates new keys for the pool that you don't have in the backup.

There is some info on the key pool here: https://en.bitcoin.it/wiki/Key_pool.

Update 2: I'm actually unsure if "keypoolrefill" only has an effect if you resize the keypool. If you don't change the size of the pool, I think bitcoind generates a new key for the pool each time it takes a key out of it. Someone correct that if it's wrong.


difference between pre-mining and mining I am new in blockchain and not an IT person.

is there a difference between pre-mining a cryptocurrency and mining a block?
I do understand the rewarding action when a miner solves a hash puzzle to add a block to the chain.  However, I do not get the pre-mining activity.  Maybe I am mixing up 2 different functionalities.

Pre-mining means that new coins have been mined before the coin has been made public. Which means the creator of the new currency had an unfair advantage and started with a large amount of coins before anyone else had the chance.
Pre-mining often deters other people from joining and any currency is useless without users.


Static receive address instead of dynamic? I have 2 BTC QT wallets (and 1 LTC QT wallet), and am looking for a generic receive address for my wallets. In Electrum, Mist/Ethereum and Rippex, I get a single unique address to receive. In the QT apps however, I need to "Request payment", which then gives me a new receive address every time I make this request. It also says [checkbox] Reuse an existing receiving address (not recommended).

Is there such a thing as a generic receive address for a QT wallet? If I need to create a new request every time I want to receive coin, that's not ideal.

Am I missing something, or how does this work?

Or can I just create a receive address once off and keep using that, not sure why it's not recommended..

You can certainly give out the same address to as many people as you want.  An address is really just a representation of the public part of a cryptographic key pair, and you will still have the corresponding private key.  That means, the address will still function, regardless of how many times you use it to receive money.

However, as the app tells you, this is not recommended.  The reason is privacy.  Remember that the blockchain is public, and your addresses are unique.  When you give out an address, you are telling that person that this address is associated with your identity.  They can then look up that address on the blockchain, and see how many other times someone has given you money through that address...and how much.

If you have given the same address out to a lot of people, then a lot of people can do this, and there's a lot more data for them to see.  This can then be used in conjunction with other blockchain analysis techniques, and you end up with a lot of people being able to gleam insights into where you get your money, how much money you have, and where you spend it.  In short, you are giving up a great deal of privacy.

On the other hand, when you use a new address every time, you are giving away very little information to people paying you.  If they look up the address, they will see that it is a completely new and never before used random number.  They will not be able to determine how many other people have been paying you, and far fewer people will know that this particular address is tied to your identity.  Blockchain analysis can still determine a few things, but with a lot less data to start with, the results won't be anywhere near as complete as they are when you reuse addresses.

Unless there is some important and unique benefit you get from reusing addresses, you really shouldn't.


How to make a genesis block of my altercoin? I create my new altercoin,but when I first run it,it already shows:"No block source available 5 week(s) behind".
And I start anther computer in the LAN, they link succefully.
I use the code of Datacoin.

static const uint256 hashGenesisBlockOfficial("f9f6d9a689f7a4093c71f397d8fe3fbef3a05cd6f919d51b4a9447aa22743dfb");
static const uint256 hashGenesisBlockTestNet("f9f6d9a689f7a4093c71f397d8fe3fbef3a05cd6f919d51b4a9447aa22743dfb");

  // Genesis block
        qDebug()<<"Genesis block";
        const char* pszStartTopic = "The Times 26/Dec/2013 Chancellor on brink of second bailout for banks";//https://bitcointalk.org/index.php?topic=325735.0";
        CTransaction txNew;
        txNew.vin.resize(1);
        txNew.vout.resize(1);
        txNew.vin[0].scriptSig = CScript() << 0 << CBigNum(999) << vector<unsigned char>((const unsigned char*)pszStartTopic, (const unsigned char*)pszStartTopic + strlen(pszStartTopic));
        txNew.vout[0].nValue = COIN;
        txNew.vout[0].scriptPubKey = CScript();
        CBlock block;
        block.vtx.push_back(txNew);
        block.hashPrevBlock = 0;
        block.hashMerkleRoot = block.BuildMerkleTree();
        block.nTime    = 1387977869 ;//http://www.unixtimestamp.com/index.php
        block.nBits    = TargetFromInt(6);
        block.nNonce   = 49030125;
        block.bnPrimeChainMultiplier = (uint64) 5651310;

        if (fTestNet)
        {
            block.nTime    = 1387977869 ;
            block.nBits    = TargetFromInt(4);
            block.nNonce   = 46032;
            block.bnPrimeChainMultiplier = (uint64) 211890;
        }

        //// debug print
        uint256 hash = block.GetHash();
        printf("%s\n", hash.ToString().c_str());

        qDebug()<<"hash:"<<hash.ToString().c_str();
        printf("%s\n", hashGenesisBlock.ToString().c_str());
        qDebug()<<"hashGenesisBlock:"<<hashGenesisBlock.ToString().c_str();
        printf("%s\n", block.hashMerkleRoot.ToString().c_str());
         qDebug()<<"block.hashMerkleRoot:"<<block.hashMerkleRoot.ToString().c_str();
        assert(block.hashMerkleRoot == uint256("a0c44c1b6dd50fcaa2bc1c4d7f8ca406506caee88578d751fb3824b41bc34d84"));
        block.print();

        assert(hash == hashGenesisBlock);
        {
            CValidationState state;
            assert(block.CheckBlock(state, true, true));
            assert(CheckProofOfWork(block.GetHeaderHash(), block.nBits, block.bnPrimeChainMultiplier, block.nPrimeChainType, block.nPrimeChainLength));
        }

Failed at assert(CheckProofOfWork(block.GetHeaderHash(), block.nBits, block.bnPrimeChainMultiplier, block.nPrimeChainType, block.nPrimeChainLength));.
And the debug.log says:

    CBlock(hash=f9f6d9a689f7a4093c71f397d8fe3fbef3a05cd6f919d51b4a9447aa22743dfb, hashBlockHeader=7d6aeeb7ca2b87d2f48bbd7a675c8374691c4f44f0db1a10de66436bfbcb0188, ver=2, hashPrevBlock=0000000000000000000000000000000000000000000000000000000000000000, hashMerkleRoot=a0c44c1b6dd50fcaa2bc1c4d7f8ca406506caee88578d751fb3824b41bc34d84, nTime=1387977869, nBits=06000000, nNonce=49030125, vtx=1)
      CTransaction(hash=a0c44c1b6dd50fcaa2bc1c4d7f8ca406506caee88578d751fb3824b41bc34d84, ver=1, vin.size=1, vout.size=1, nLockTime=0, data.size=0)
        CTxIn(COutPoint(0000000000000000000000000000000000000000000000000000000000000000, 4294967295), coinbase 0002e703455468652054696d65732032362f4465632f32303133204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73)
        CTxOut(error)
ERROR: CheckPrimeProofOfWork() : block header hash under limit
ERROR: CheckProofOfWork() : check failed for prime proof-of-work

Anything else can I change to make the genesis block work?

I think you can use this : https://bitcointalk.org/index.php?topic=225690.0
This is all you need to make your altcoin working ;)

According to this link, you need to launch your alt coin's software and see in debug.log which hash your software is waiting for.


Does speculation hurt bitcoin? Related Question: Does hoarding really hurt Bitcoin

Does speculation hurt bitcoin? I often hear people complain that speculation is destroying Bitcoin, or that Bitcoin will fail because of speculation. Is there any merit to this criticism of Bitcoin? And in particular, is the idea that speculation is hurting Bitcoin any different then the idea that hoarding is hurting Bitcoin?

It's worth noting that bitcoins would have no value if it weren't for speculation.  When Satoshi first released the client, those who put their electricity and computing resources towards mining bitcoins were speculating that the value would rise from zero, and that the coins would be accepted as payment by someone else.  Those who first accepted bitcoin payments, likewise, were speculating that the value would remain above zero, and continue to be accepted by others, and so on.

It's also worth noting that Bitcoin would likely not have received the amount of attention that it has if not for people speculating that the value would rise tremendously and buying coins in large quantities.  This attention has brought in more users, developers, and businesses, thus increasing the health of Bitcoin.

If speculation does hurt Bitcoin in some ways, it's at the very worst a necessary evil.


Running a Full Node through VPN? My ISP has blocked port 8333, due to the gigs of inbound traffic I incurred running a full node. Consequently, I would like to run a full node through VPN (specifically, OpenVPN with an OpenVPN provider).

Would I need to have the VPN forward port 8333?

Yes, incoming connections must be allowed through port 8333. If your VPN provider allows port-forwarding, it should be configurable in your account settings.

See: https://bitcoin.org/en/full-node#network-configuration


What happens if my transaction is not accepted because I did not pay fees? I was reading this thread about a client fork that does not force transaction fees and I noticed the big red warning saying that some coins might get lost if I am not careful. What does this mean? What should I do if my transaction is not accepted?

If your transaction does not get accepted, you have a few options. Right now, at least for Bitcoin itself, there are still enough miners willing to include any valid transaction. So if you just keep waiting, it should eventually get confirmed.

You may also wish to stop your client and then restart it, manually forcing it to connect to a client known to accept transactions without fees. It can help to disable incoming connections to maximize the chances your transaction will go to the client that will accept transactions without fees. It can take several hours for the transaction to get out, even if you do everything right. (The client intentionally 'dribbles' out transactions to try to hide their origin. This completely fails for transactions with too-low fees, but the client still tries.)

Otherwise, you can abort the transaction attempt. Stop your client and then make sure the transaction is not in limbo by checking the list of pending transactions. If it's not there, you can stop attempting the transaction to recover the coins. Ideally, you made a backup of your wallet before you attempted to make the transaction -- reverting the wallet and restarting the Bitcoin client with the -rescan option will remove the transaction. Otherwise, you'll have to (ouch) edit your wallet file to remove the transaction.


Bittrex API market history -- interpreting OrderType The Bittrex API has a request to get the market history:

https://bittrex.com/api/v1.1/public/getmarkethistory?market=BTC-DOGE

which gives a response containing the following fields:

"Id"
"TimeStamp"
"Quantity"
"Price"
"Total"
"FillType"
"OrderType"

"OrderType" can be one of "BUY" or "SELL". What does this refer to?

Let's assume it has a value of "SELL". Does this mean:

The person who initially placed the order was selling (Seller is Maker).
The person who closed the order was selling (Seller is Taker)

You almost have it!

BUY means that the order was the consequence of someone buying at the ask price, as opposed to creating an order at a lower-than-market price.

SELL means that the order was the consequence of someone selling at the bid price, as opposed to creating an order at a higher-than-market price.


Blockchain download extremely slow at 200 blocks per hour I am running bitcoind and the blockchain download is very slow at 200 blocks per hour.

I am  at 225146 and at the current speed, it would take bitcoind a month to catch up.

Here is my output from bitcoind getinfo

{
"version" : 32400,
"balance" : 0.00000000,
"blocks" : 225305,
"connections" : 5,
"proxy" : "",
"generate" : false,
"genproclimit" : -1,
"difficulty" : 4367876.00084220,
"hashespersec" : 0,
"testnet" : false,
"keypoololdest" : 1378312057,
"paytxfee" : 0.00000000,
"errors" : ""
}

CPU usage is at 10 Percent and I am using 50% of memory.

Any ideas why the download is so slow?

"version" : 32400

Oh my goodness. That is a very old version.

New versions dramatically improve chain synchronization times. Update from your current version of 0.3.24 to 0.8.5.

https://bitcoin.org


Convert list of BTC address(base58) to Ripemd16(base16) Are there online tool or repositories that can convert multiple base58  (BTC address) to base16 simultaneously?

In Go, you can do this very easily:

package main

import (
    "fmt"

    "github.com/btcsuite/btcutil/base58"
)

var addresses = []string{
    "1Nh7uHdvY6fNwtQtM1G5EZAFPLC33B59rB",
    "1Le1ttNd2GQ79212Epyciw39JDy2E6DYWf",
    "1LpRieyPAZfFyUSMGiZhwAarQoJw1Y8pEx",
}

func main() {
    for _, address := range addresses {
        ripemd160, _, err := base58.CheckDecode(address)
        if err != nil {
            fmt.Printf("Failed to decode address %s: %s\n", address, err)
            continue
        }

        fmt.Printf("HASH160 %x from address %s\n", ripemd160, address)
    }
}

When you have Go installed, you can run this code very easily in your terminal:

$ go get github.com/btcsuite/btcutil/base58
$ go run thefile.go
HASH160 edf10a7fac6b32e24daa5305c723f3de58db1bc8 from address 1Nh7uHdvY6fNwtQtM1G5EZAFPLC33B59rB
HASH160 d76a86f903b33835f06d7b18a1429a8f249f3ab1 from address 1Le1ttNd2GQ79212Epyciw39JDy2E6DYWf
HASH160 d96292e45d045d2269a818b96b13422555557d85 from address 1LpRieyPAZfFyUSMGiZhwAarQoJw1Y8pEx


How to move an address to a new wallet? I have a wallet with several addresses. I would like to isolate one of the addresses in its own wallet, but I don't know how to do it. I've been trying with pywallet.py, but I've been unable to do it.

Can you help me, please?

EDIT: I've made some progress:

I dumped my wallet with pywallet.py --dumpwallet >wallet.json, and searched for the key I wanted to isolate, and wrote down the field named sec.
Then moved wallet.dat to another folder, and started bitcoin-qt, so it generated a new wallet.
Opened Help -> Debug window -> console and run importprivkey  XXXXXXXX mykeylabel. It took about 4 minutes to import the key.

Now I still need to:

remove this address from the old wallet.
remove the default address in the new wallet, so it contains just the imported address.

You can do that via the default bitcoind API.

I suppose you are used to use Bitcoin-Qt? Then most probably the bitcoind daemon is also installed on your computer.

You can move an address from one wallet to another using the setaccount command. It works as follows.

setaccount <bitcoinaddress> <account>

So, when you have an address, let's say 1HDPmDGcgXkRTBbACYXNQ1SNeoCQEPvN3v, that you want to move from wallet1 to wallet2, then you can do the following command.

setaccount 1HDPmDGcgXkRTBbACYXNQ1SNeoCQEPvN3v wallet2

You can perform these commands most easily from a command line interface. In Unix systems where bitcoind is installed, you can do the following:

Make sure Bitcoin-Qt is closed.
Launch bitcoind as a daemon:

bitcoind -daemon

Do the command I mentioned above: (It's possible that you get an error that the Bitcoin server is not yet running, just wait a little.)

bitcoind setaccount 1HDPmDGcgXkRTBbACYXNQ1SNeoCQEPvN3v wallet2


Multiple bitcoin transactions between addresses in the same wallet I have two wallets: one in coinbase and one in blockchain.info. I imported several outside addresses(created in bitaddress.org) in my blockchain.info wallet. However, sometimes when I transfer bitcoins from my coinbase wallet to my blockchain.info wallet, the transaction is followed by several (usually two) transactions within my blockchain.info addreses (in the same wallet). As if the money is being bounced off within the addresses inside the wallet. Is there any reason for this?

Coinbase sometimes creates an address to move your bitcoin from cold storage. Any movement ie downloading to offline storage. will require a hash for the block chain/transaction  to "track" the bitcoin. Hence the appearance of transactions in the wallet.


Practical interpersonal address exchange How can addresses be exchanged practically & efficiently between two users?

Visually copying & keying them is impractical & faulty.

Very true! Manually copying a 34 character address is no fun.

You have three major options:

QR code. Print it out in advance.
Create a FirstBits address.
Bring your phone, and load a client that supports NFC.

By the way, if you enter someone's address wrong, the Bitcoins won't send - Bitcoin addresses have a checksum built in.


When the number of bitcoin reward halves after 4 years, doesn't the perceived value of a bitcoin about double? Let's say the price of a bitcoin is US$33,000, and all the miners mine it or not mine it if their electricity kWh price is too high, and it is at an equilibrium that it is somewhat profitable and worthwhile for the miners to mine bitcoin.
Then in year 2024 May, when the rewards changes from 6.25 bitcoins to 3.125, and if the price of a bitcoin stays at $33,000, then it become unprofitable for many miners, and they would stop the mining, and for all the miners to still keep on mining, they would think that the price of one bitcoin is more like $66,000 as before. So would the perceived price of a bitcoin double every time the reward becomes half?
Or would the price just stay low, but just that all of a sudden, a portion of the miners would stop, but when it becomes easier to "win" the block every 10 minutes, some miners will join again, until it reaches an equilibrium around this lower price?  But it seems many miners would think, it is so difficult to mine and be profitable, and therefore they are not selling their bitcoins at $33,000 but would demand a higher price.

TLDR: The price of bitcoin determines how many miners are mining, not the other way around.
Your last paragraph is on point! After a block halving, every miner unprofitable at the new reward will stop mining. They will stop mining because they need to pay for the electricity they burn. But for each miner that stops mining, the remaining miners become more profitable. The remaining miners become more profitable because it's easier to find new blocks! That means they have to use less electricity to find new blocks, and there is less wear on their mining hardware. So just like you say, after a while it reaches an equilibrium.
The big peak in this picture is May 11th, 2020, the day the previous halving occurred. You can see the estimated hash rate went from 119 to 76 Ehash/s. That's a lot of miners that had to shut off!

It's also important to note that miners don't decide what the price of bitcoin is. Miners just react to the bitcoin price. Starting their miners when it is profitable and shutting them down when it is no longer profitable. The total amount of bitcoins that are sold or bought determine the price of bitcoin.


Using a new address for every transaction? I've been reading the Developer Guide, and they seem to be really strong on the idea of using new addresses for every transaction. I understand the reasoning - anonymity - but I don't really understand the implementation. If I receive 1000 transactions, am I supposed to then keep up with 1000 addresses and how much currency was sent to them? Or is this something the wallet takes care of for me? My understanding was that a wallet had a 1-to-1 relationship with an address. Is this not the case? Can a wallet have multiple addresses?

My understanding was that a wallet had a 1-to-1 relationship with an address.

No that is not the case.

  Can a wallet have multiple addresses?

Yes, any good wallet software will support a hundred or more addresses.

  is this something the wallet takes care of for me?

Yes.  The wallet will handle all the addresses for you.


Are for-profit companies possible in Ethereum? I am getting my head around DAO in Ethereum. In a magazine I read:

  In principle you could programme a taxi company that bought cars and paid drivers to run the cars to make a profit in order to buy more cars. [...] The point is that the management, what would normally be the brains of a corporation, the control structures of a corporation, can now exist autonomously in the cloud, so to speak.

So, if I understand correctly, someone with some level of capital can set up a private, for-profit company in the DAO, use that capital to buy taxis, hire drivers, and, if the business is good, make profits? The benefit of this being that contracts are run automatically, fully transparent? If so, how is this related to descentralisation? What if, for instance, Uber is set up in Ethereum, but still owned by a few people? Does it matter? Perhaps more deeply, are DAOs fully compatible with the standard firms in capitalism (for-profit PLC)?

You can definitely write a smart contract with a designated address as the "owner" (usually implemented as owner = msg.sender in the constructor). The contract can then implement certain privileges for the owner, e.g., the right to take a 10% fee off of every transaction in the contract. The benefit compared to the centralized company is twofold:

Users interacting with the contract can see the rules in advance and are sure that they won't change (i.e., decentralized Uber, if correctly implemented, can not opportunistically refuse to pay a driver);
A third party, such as law enforcement, can not shut the whole enterprise down.

The question whether DAOs are fully compatible with standard firms requires the definition of compatible. I suppose it depends on the jurisdiction.


Can I run Armory on a Chromebook? I want to buy a cheap computer to use exclusively as a secure offline wallet for cold storage. I am considering a Chromebook.

Has anyone managed to run Armory on a Chromebook?

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

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

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


What is the recommended OS for compiling a Windows binary for Litecoin? I'd like to compile Litecoin for Windows, but have difficulties doing so. To be specific: I want to create the Windows executable (.exe) GUI (qt) Litecoin client (to be more specific I want to compile the executable for an alt-coin based on litecoin, but the code base is the same as litecoin).

Many tutorials are either focused on compiling for Linux, or they focus on Bitcoin compiling, which is a bit different nowadays than Litecoin. Rather than explaining my specific problems, which are likely unique to my situation, I was wondering what a recommended Operating System (and version) is to compile Litecoin? Who has specific (preferably smooth) experience building the GUI litecoin client for Windows?

A useful relevant topic is this one:
https://bitcointalk.org/index.php?topic=149479.0

But this is based on bitcoin, not litecoin. This referenced tutorial has a bit on Windows, but it's not too optimistic:

  Windows -Qt

  This is the trickiest one to crack of the GUI wallets. I am going to
  detail how I got this to work and offer you an easy way to get the
  dependencies in an attempt to make this work for you too. That said,
  it may not–and I’ve already said I won’t do tech support. So here’s
  the deal. I got this to work and then duplicated it on a second
  machine to ensure it wasn’t a fluke! Most of the information needed to
  compile the basic coind.exe or GUI wallet is in this thread:
  https://bitcointalk.org/index.php?topic=149479.0 Unfortunately nothing
  is as easy as it seems, and although the MinGW and QT installs went
  fine, I couldn’t compile it without a few tweaks to the .pro file.

In this tutorial, Windows is used to create the executable, but I understand one can also use Linux to create Windows executables, right? There are few experiences documenting successful or smooth compiling of Litecoin (forks) for Windows, so I was wondering if people do have good experiences doing so and what kind of OS or approach they used.

The Litecoin source tree, in the doc/ folder, provides a file regarding building on Windows, using MinGW and MSYS. I can't personally vouch for those instructions, never having used them myself, so if you go that route, good luck. The way that the release binaries are built, if I'm not mistaken, is using the Gitian builder. If you're looking to do a Windows build, I would try that. If you want to actually use Gitian, you can clone the repo, and use the readme file to get Gitian set up, and then follow the build segment of the release process to do the actual build. On the other hand, if you're not necessarily looking for determinism or the ability to reproduce the exact build, you could try taking a look at the Gitian build scripts to see what packages are being used, what commands are run, et cetera, and try to reproduce that on a Linux system.


Where to find UTXO Metadata API I'm looking for an API which lets me query for UTXOs on the base of specific meta data, e.g:

When was the transaction containing the UTXO issued?
From which address?
etc.

I have found this question: What is the best way to download a "recent" UTXO set snapshot?

But it just contains the information that it's unsafe. I'm only interested in the meta data and don't want to run a wallet on it. Therefore I'm not interested in security aspects.

Is there a war to query on the UTXO globally, without a given address? Or a way to download the whole UTXO?

This project: https://github.com/sr-gi/bitcoin_tools might be what you're looking for...The repo has resources to dump the leveldb database into a JSON like format for review and analysis. They also created a paper discussing the format of UTXO here.


Could a malicious attacker subvert the Bitcoin network by failing to create a block? I know its astronomically improbable, but say a malicious node "wins" the proof of work inherent to the Bitcoin protocol. If a malicious node simply waited indefinitely, or maliciously disconnected during the block creation process, what would the Bitcoin network do about it? If a block isn't created will the network just hang indefinitely, or is there some way of overcoming a halt like this?

The other miners will not be aware that this malicious miner has find the correct hash(win) since he has not propagate it, so they will still try to find the correct hash and some second later one of them will find it correct and propagate it, then cycle will repeat again without anyone knowing that this malicious miner has win second before the one that has officially win it.


Lightning: Is it possible to send lightning BTC outside of a lightning state channel? Let's say that I have a channel opened and I want to send some lightning BTC to someone who didn't ever used lightning, is it possible or will it be? Or will I need to open a channel first then send the btc through lighthing(with 2 transactions)?

I know the guys from Raiden want to allow that: https://medium.com/@raiden_network/creating-an-easy-onboarding-user-experience-for-the-raiden-network-4dcdc9e2eeed

There is no such thing like 'lightning BTC'. It is the same BTC, either on-chain, or comitted to a lightning channel, which is technically a 2 of 2 multisig transaction. To receive via lightning, a lightning full node or a wallet with lightning receive capability is needed. And correct, you need to open a channel first, which takes one on-chain commit, the the associated waiting time. But it is possible to transfer value at the same time by already assigning a portion of the channel funds to the receiver when setting up the 2 of 2 multisig transaction. All later value transfers inside the channel will be an just update of this transaction, which will be instantaneous. So either way, no need for a second transaction in terms of on-chain transaction. Except for the closure of the channel, if needed - which will another on-chain transaction ( channels can stay open indefinitely, though).


Lightning Onion Routing vs TOR From what I can gather BOLT #4 is applying similar methods, such as obscuring previous and future hops from intermediate nodes, to the TOR network for routing payments across the Lightning network.

If that statement is broadly correct does that mean deploying a Lightning node on the TOR network would not be very compelling? There may still be benefits for NAT traversal and other things? But for obfuscation/anonymity is the idea that the Onion Routing BOLT will be as effective as TOR?

The answer to your question is a clear NO, as two very different problems are being tackled but the onion routing in the TOR network and by the Onion Routing in BOLT 04.

The idea of the Tor network is to hide your IP address. If you run your lightning node on a tor onion you will have a tor address and not even your channel partners can know where your node stands. In particular if you receive money on that node no one can see who you are
The idea of Oninion Routing (with the help of the SPHINX paper) in BOLT 04 is that you as the payer of a network hide who is receiving the money. Also you hide that you are the sender (though every node can send back error messages to you). If you pay a person with these oninion payments and this person is NOT using TOR for their lightning node you will know who the payee is (at least you know the IP address and to some degree where the computer stands) Others on the way do not know this (only the channel partner knows that the payee is involved in the payment process but it is not clear that it is the receipient to the channel partner). If however the payee uses tor the situation like discribed above in 1.) takes place.

So in order to maximize your privacy you should run your lightning node on TOR even though the routing of payments is a source based Onionrouting similar to TOR.


Reduce bitcoin blockchain size I have a freebsd server with a bitcoind server. But the blockchain is getting to large for me. So I just bought some new sas drives so I can keep it up. I now have 218GB of total space. 40GB is for the OS, programs and all files. The rest is for the blockchain(178GB). I do not want to buy more SAS drives than I have now.

I am afraid that the blockchain will get to big again in 1 or 2 years.
Is there a way to reduce the blockchain size or is there a cryptocurrency where this problem is solved?

Yes this problem has been solved. Have a look at the pruning option. You can specify whatever maximum size you want to allow the blockchain to take up.


blockchain.info receiving address changes - is it OK to put BTC address on the website? Wallet from blockchain.info change the receiving address from time to time. I guess the rationale is to protect my privacy or something.

In reality I'd be more secure in my head if I had the same BTC address...

Solution to that would be to create own vanity address, but in the meanwhile - is it OK if I publish the address on the website and will it work in 6 months?

EDIT / UPDATE: Wish the changing addresses were better explained - https://en.bitcoin.it/wiki/Deterministic_wallet - I was quite seriously worried why my address is changing.

I'm not sure from blockchain.info because its a wallet.

You should use an address that you have to download to your computer and use a keystore file with password. No one has the keystore file or password so it'll be safe.

Try:
https://bitcoin.org/en/download
and there are many others.

You're using another company and if they go out of business (I doubt blockchain.info would ever) then you may lose your coin.


Is there database of orphaned blocks? Is there database of orphaned blocks?

https://blockchain.info/orphaned-blocks does not work right now

Does anybody keep them?

Also I am looking for those transactions which were not included in blocks (non-standard, double-spends, not enough fees, etc)

Do you need a user interface or to find them via API? We do not have UI at the moment for this (we will very soon) but you can definitely use our REST API to get them.

If the API is what you need then you can just use the following API call to filter ORPHANED blocks only.

  https://api.biteasy.com/blockchain/v1/blocks?type=ORPHANED

If the transactions weren't included in the main chain then they will either be DEAD or PENDING and you can fetch them with the following API call:

  https://api.biteasy.com/blockchain/v1/transactions?confidence=DEAD

and

  https://api.biteasy.com/blockchain/v1/transactions?confidence=PENDING

Check out the link to our documentation and also you can use our testing tool which you can find here https://www.biteasy.com/developers/sandbox


Would free energy cause a market collapse? Consider a world where energy is free and plentiful. Bitcoin, and other cryptocurrencies, are given value since they are 'proof' of work. This work comes at the cost of:

a. time
b. energy

By removing the cost of electricity, hardware expenditure becomes the ceiling for hashrates. Surely this makes cryptocurrencies less valuable. Wouldn't the market become hypersaturated as supply went up? On large enough scale, hardware turnover rates might provide some limiting factor to supply- but for the most part mining operations should be able to keep up with the increasing difficulty of the hash.

I can see otherways the blockchain would be useful, but I'm starting to wonder whether cryptocurrencies would continue to work.

Although this question might be "too broad" or "off-topic", I'll give you an answer and it's no.

  By removing the cost of electricity, hardware expenditure becomes the ceiling for hashrates. Surely this makes cryptocurrencies less valuable. Wouldn't the market become hypersaturated as supply went up?

I don't follow. By removing the cost of electricity you only remove ONE of the prohibitors. There are still other prohibitors such as equipment/bandwidth/storage costs, know-how, and time. There should be no increase in supply. The bitcoin difficulty will still remain, so blocks will still be solved in a ~10 minute target window. Even if they had free energy and built a mining chip that doubled the current hash rate it would just retarget after 2,016 blocks.


cannotsend error using python bitcoin library to send bitcoin on testnet When I run the script

from bitcoin.core import COIN, b2lx
import bitcoin.wallet
import bitcoin.rpc

rpc = bitcoin.rpc.Proxy()
addr = bitcoin.wallet.CBitcoinAddress('mfrMeTKojpEXFXpcQiRr7zA3Bff4UBgZTx')

txid = rpc.sendtoaddress(addr, 0.001 * COIN)
print(b2lx(txid))

I get the following ERROR

CannotSendRequest                         Traceback (most recent call last)
<ipython-input-23-904d1d3102d7> in <module>()
----> 1 txid = rpc.sendtoaddress(addr, 0.001 * COIN)

/home/remote_user/unix_practice/python-bitcoinlib/bitcoin/rpc.py in sendtoaddress(self, addr, amount)
    557         addr = str(addr)
    558         amount = float(amount)/COIN
--> 559         r = self._call('sendtoaddress', addr, amount)
    560         return lx(r)
    561

/home/remote_user/unix_practice/python-bitcoinlib/bitcoin/rpc.py in _call(self, service_name, *args)
    150                              'User-Agent': DEFAULT_USER_AGENT,
    151                              'Authorization': self.__auth_header,
--> 152                              'Content-type': 'application/json'})
    153
    154         response = self._get_response()

/usr/lib64/python2.7/httplib.pyc in request(self, method, url, body, headers)
    971     def request(self, method, url, body=None, headers={}):
    972         """Send a complete request to the server."""
--> 973         self._send_request(method, url, body, headers)
    974
    975     def _set_content_length(self, body):

/usr/lib64/python2.7/httplib.pyc in _send_request(self, method, url, body, headers)
    999             skips['skip_accept_encoding'] = 1
   1000
-> 1001         self.putrequest(method, url, **skips)
   1002
   1003         if body is not None and 'content-length' not in header_names:

/usr/lib64/python2.7/httplib.pyc in putrequest(self, method, url, skip_host, skip_accept_encoding)
    869             self.__state = _CS_REQ_STARTED
    870         else:
--> 871             raise CannotSendRequest()
    872
    873         # Save the method we use, we need it later in the response phase

CannotSendRequest:

Any idea how to resolve this? I used the code from

Sample Post

The issue was that addr is being provided an invalid address - a Main Net address does not work on Test Net, and vice versa.  (From the edit revisions history, the code sample you provided was using bitcoin.wallet.CBitcoinAddress('1JwSSubhmg6iPtRjtyqhUYYH7bZg3Lfy1T') which would provide a Main Net address)

Replace the address being supplied in the addr variable with a legitimate Test Net address, and it should work.


Would quantum computing be able to deanonymize CoinJoin transactions? Using the worst case scenario of this question, namely:

  Bitcoin ECDSA algorithm would be broken. Because quantum computers can easily decrypt the private key using the public key, anyone with a quantum computer can extract Bitcoins using the corresponding public key.

Given that quantum computers would be able to obtain private keys, would they be able to deanonymize CoinJoin transactions that are already present in the blockchain?

No.

CoinJoin does not rely on any cryptography to hide transaction flows. It merely combines multiple transactions into one, and randomizes the order of inputs and outputs.

Of course, as you point out, quantum computing would allow stealing ECDSA outputs...


What is the relationship between a Bitcoin Private Key / Public Key / Address? What is the relationship between a Bitcoin Private Key / Public Key / Address?  I see that a private key / public key pair is generated, but is there a possibility of generating a private key already in use?  And, also I'm assuming that a wallet address is a bitcoin address?  Does each wallet address have a one-one relationship with a private key?
Thanks

Using Elliptical Curve Digital Signature Algorithm (ECDSA), the private key is used to generate the public key, a secure hash function is then applied to the public key and a checksum appended to produce a Base58 formatted bitcoin address.
A private key collision is theoretically possible, but practically impossible due to the sheer number of them available on the network (quadrillions+).


Did I just create counterfeit bitcoins? I had 3 Bitcoins stored on my PC and I had a backup image of my PC. I restored my PC on another computer from the image and I had 3 Bitcoins on that computer also. I spent 5 Bitcoins as a test, and it worked. What just happened?

It's like two people holding on to the same $20 bill and each of them saying, "see, I have 20 dollars!".

Bitcoins can be spent/accessed by anyone that has the private key to unlock them. If two computers have the same private key stored, then they can both access the bitcoins. If one wallet spends the bitcoins, the other wallet will show them as spent as well, just like one person spending the $20 bill means it is gone for the other person.


Is there a standard wallet format? Is there a standard wallet format that can be read with different bitcoin clients, and that is likely to be compatible to future bitcoin clients as well and thus is usable for long term storage of bitcoins? Or how am I supposed to transfer bitcoins between different bitcoin clients/computers/client versions?

There is the Wallet Import Format, which should be a standard for Bitcoin wallets. As to how popular it is, I don't have any data on it. Alternatively, storing the raw private key should suffice, as it can be converted to any other fancy format whenever needed.


Where can one find the Bitcoin Dominance chart index? Is there a chart where it shows how much market cap is bitcoin compared to the rest?

Yes you can check it here: https://coinmarketcap.com/charts/

It shows the bitcoin market cap compared to the rest. You can click on the coins below the chart to enable disable them.


What happens in a small scale blockchain network? My main question here is, is this understanding correct or have I misunderstood something? If this question would be better for Reddit then I apologise in advance and I'll move to there. Thanks.

Scenario:

So technically I could download the bitcoin source code and run my own altcoin (let's call it pokercoin) on a network of 5 computers (for me and my 4 geeky friends who wanted to play poker without chips).

If I'm understanding correctly, we would each be running pokercoin source code/qt on our laptops and no other computers would be needed to keep the thing running (or maybe we would need to run something else to ensure the network works, because otherwise there is no other way of the network doing all the IP level stuff? Or do nodes do this and run something other than the bitcoin source code?).

When I make a payment, each of the other 4 computers receives a copy of that transaction, and they all add this to a block of 1 transaction which gets appended to our very short blockchain after 10 minutes (because hypothetically my computer is able to solve in 10 mins).

If 2 of us made a transaction, (the new block to be added has 2 transactions), but the other 3 computers wrote their own block which diverged in truth to my computer and my friend's computer, then this 51 percent attack would beat the previous block to be appended (or is it added only after ANOTHER block is added (because this is now the longest chain).

We all also get new pokercoin for being miners in our own system (or maybe it is only those running different code who get to be miners).

Finally, none of us actually argues over having any money, because we know that 'how much we own' is actually only made up of the network iterating over every transaction that happened in order to calculate our amounts (and this happens every time a new block is made).

We also don't argue over block sizes, because there are 5 of us.

If you were using a fork of Bitcoin Core, your small scale network would not work.

Assuming you did the basic chain parameter modification or just firewall yourself from the rest of the Bitcoin network, there are two major things that are missing: peer discover, and mining.

Bitcoin Core by default uses a process called DNS Seeding in order to discover seed nodes. If those seeders fail, it will fall back to using some hard coded seed nodes. However, these are seed nodes which are treated differently than normal nodes (even though they are still normal nodes). Seed nodes are only connected to in order to get a list of more nodes to connect to. It is nodes on that list that are eventually connected to for actual normal node operations. Your node disconnects from those seed nodes once they get this list.

So, for your network, you would need to potentially run your own DNS seeders and seed nodes. But that's actually not really necessary. You would just need to disable DNS seeding and the hardcoded seed nodes, then just have everyone on your network set multiple connect=<ip> lines in their configuration files where <ip> is the IP address of a node. This will force the node to connect only to the specified nodes. Note that this will disable further node discovery and automatic node connection, so if you add someone else to your network, not all of the other nodes will connect to the newcomer unless they are explicitly added.

The other problem will be mining. Bitcoin Core does not contain any mining logic at all. It does not automatically mine nor does it even have the ability to produce blocks. Instead you will need to install some other mining software. However, because CPU and GPU mining are pointless, you will have to build, and potentially modify, those mining software yourself in order to enable CPU and GPU mining. Otherwise you will need to get some mining hardware supported by those software. Without using any mining software, your network will not produce any blocks and no transactions will be confirmed.


Will the block reward continue halving beyond 1 satoshi if bitcoin precision goes beyond 8 decimal places? If bitcoin precision is increased beyond 8 decimals, will the block reward continue halving forever instead of eventually going from 1 satoshi to 0 satoshi?

The "8 decimals limit" is not that, but rather bitcoins are a human readable representation for 100,000,000 satoshi: The software natively computes in satoshi.

What happens under the hood is that the limit of satoshi that a miner may claim by creating a block halves. Obviously, only whole satoshi can be claimed, (as currently they are indivisible), so after block 6,930,000 when the reward limit drops from 1.164… satoshi to 0.582… satoshi per block, one cannot claim a whole satoshi anymore, as it would be greater than the limit.

If a new smallest unit of Bitcoin would have been introduced by then, we could continue to claim parts of a satoshi until the reward limit drops below that new unit.

In fact, we will be losing out on part of a satoshi in every block starting with block 2,310,001 when the reward drops from 9,765,625 satoshi to 4,882,812.5 satoshi in approximately 2049.


Why are ticker messages in the MtGox PubNub API repeated? I'm using MtGox's PubNub API to fetch ticker data. I've subscribed to the BTC/EUR ticker with id 0bb6da8b-f6c6-4ecf-8f0d-a544ad948c15 . In more than half the cases when I receive a new ticker message, the data is just the same as that of the previous message, except for the timestamp of course. I expected ticker messages only when there is new data available, so I do not understand why the ticker messages get repeated. Examples:

diff_to_previous  instant_________      last_all        last_local      last_orig       buy_____        sell____        vwap____        vol_____________    item  avg_____      high____        low_____
n/a               2013-12-12 16:31:46   EUR 628.31408   EUR 620.22000   USD 865.00000   EUR 620.22000   EUR 629.00000   EUR 647.91649   BTC 1365.61335998   BTC   EUR 649.27938 EUR 680.00000   EUR 615.00000
none              2013-12-12 16:31:50   EUR 628.31408   EUR 620.22000   USD 865.00000   EUR 620.22000   EUR 629.00000   EUR 647.91649   BTC 1365.61335998   BTC   EUR 649.27938 EUR 680.00000   EUR 615.00000
none              2013-12-12 16:31:53   EUR 628.31408   EUR 620.22000   USD 865.00000   EUR 620.22000   EUR 629.00000   EUR 647.91649   BTC 1365.61335998   BTC   EUR 649.27938 EUR 680.00000   EUR 615.00000
last_all          2013-12-12 16:32:05   EUR 617.41846   EUR 620.22000   USD 850.00000   EUR 620.23000   EUR 629.00000   EUR 647.91649   BTC 1365.61335998   BTC   EUR 649.27938 EUR 680.00000   EUR 615.00000

What kind of events trigger a ticker message to be broadcast?

PubNub MtGox API Ticker Repeat Messages

The Ticker Events are Updates that are streamed directly to you which may or may not represent a price change.  However the ticker updates are typically tied to a trade event which occur on the trade channel.

You can find the trade stream here:
http://www.pubnub.com/console/?sub=sub-c-50d56e1e-2fd9-11e3-a041-02ee2ddab7fe&pub=demo&channel=dbf1dee9-4f2e-4a08-8cb7-748919a71b21&origin=pubsub.pubnub.com&ssl=true

So in regards to the updates you may receive unchanging value updates.  You may also consider looking at historical values by using the History API: http://www.pubnub.com/how-it-works/storage-and-playback/

Also check out the related Stackoverflow article: https://stackoverflow.com/questions/20547815/convenient-way-to-extract-data-from-the-mtgox-pubnub-json-api/20553315#20553315

or

https://stackoverflow.com/questions/20495713/are-there-ready-made-java-classes-for-the-mtgox-pubnub-json-api/20500700#20500700


Createrawtransaction questions I'm in the process of assembling raw transactions and I have a couple of questions.

I'm using listunspent to get a list of the transactions I can spend....

First, should I select the oldest transaction first for inclusion? Or is there a better way to select transactions?

Second, for calculating the transaction fee, is there an easy way to estimate the size of a transaction? For example, can I say each output is X bytes and each input is Y bytes?

You don't have to select the oldest transactions, they are same as the recent transactions in blockchain's utxo view. When building a transaction, you can take the transaction size into consideration, which could affect the transaction fee.

Generally, each output is 148bytes and each input is 34bytes. Here is a more accurate way to calculate transaction fee.

How to calculate transaction size before sending


"Instantaneous" transaction verification? Jan Moritz Lindemann graciously educated me that difficulty is used not only to regulate the creation rate of a cryptocurrency but also to allow for block propagation thus prevent orphaned blocks.

Since consumers of a cryptocurrency could be presumed to desire instantaneous transaction verification, is near instantaneous transaction verfication possible and secure?  If so, how?

If by "instantaneous" you mean "right at the moment of the transaction" - well, no. Not even with Visa et al. Even if you mean that, after waiting for a reasonable amount of time (say, less than 2 mins.) you receive a definite answer about your transaction's validity, it's not possible either.

The way cryptocurrencies work, all transactions are "waiting in line" to be picked up by a miner and included in a block. Meanwhile, you can always revert it or create another that conflicts with the first one. Once a transaction's in a block, though, you can still not claim victory for they're still not part of the official coin history: other miners need to accept the block and start constructing new blocks over it - and this is the critical part.

Another miner, somewhere else in the world, may have discovered another solution to the current block and broadcasted it onto the network. From that moment on, there will be 2 chains in competition, both of them valid, but eventually only one will become the official one. Which one? Whichever gets longer first, i.e. which is picked up by the most miners to create a new block after it - remember each block contains not just its hash but also a hash of the previous block, so in effect each block "points" to its predecessor, hence the term "chains".

It's also possible for a malicious part to do this on purpose - should that part have access to vast amounts of computing power it could convince you to give you something in exchange for their bitcoins. You see their transaction appearing in 2 blocks and give the stuff, they then take the last block before your transaction appeared and rapidly create 3 blocks without the transaction. Once they broadcast their 3 blocks to the network - voilá! Their chain takes over due to length, you end up with no item and no coins.

So you never get a definite yes or no answer - you just get degrees of certainty. The more blocks your transaction appears on, the more likely it is that it will be part of the official transaction history. That's why it's commonly said you should wait for 6 confirmations in Bitcoin or 12 in Litecoin to consider a transaction 99% valid - after that number, the probabilities of an attacker trying to out-run (so to say) the combined hash power of the whole network become almost negligible.


GUIMiner does not connect on Slush's pool I checked my firewall, and I tried the solution in Bitcoin question GUIMiner won't start mining on Slush's pool.

It is still saying connecting forever.

Without seeing exactly what you are doing on GUIminer, this is just a guess because it is a very common problem beginners run into.

When GUIminer was last updated, Slush was using difference credentials to mine on his pool.

These are the current credentials to use as of this post's date, per Slush's home page:

  http://api.bitcoin.cz:8332
  (Main pool URL)

  or
  stratum.bitcoin.cz:3333
  (If you have Stratum-compatible miner)

In GUIminer you are probably using the built in defaults for Slush's pool

Notice that the Website field does not match one of the two current URL's from Slush's home page.

You will have to change the server drop down to other and then manually enter the correct credentials.

This is for the main server:

This is for the Stratum server:

Try the Stratum server first. Stratum protocol is more efficient and lessens the load on the pool. If it doesn't work then switch to the main server.

I'm sure you already know, GPU mining is no longer profitable (hasn't been for quite a while). You will likely only make about a penny or two per day worth of Bitcoin while your power cost will probably be about one to two dollars per day. I'm betting that you are just getting started and trying to learn how to do it first before trying anything else, like purchasing an ASIC. That's good. I did the same thing.


Is it possible to safely mine bitcoin at 13.5 TH/s with hardware with 10.5 TH/s? I want to mine bitcoins, and I have heard that it is possible to overclock an Antminer T9. It said "maximum +200M recommended" for the overclocking. This miner runs at 10.5 TH/s and I would like to make it run at the hashrate of a more expensive miner (the S9), albeit with higher electricity usage. I am curious about bitcoin mining because of the interesting quirks of the SHA256 hash algorithm and how I get to be paid by helping discover hashes with 18+ zeroes (as of writing).

The link for info is at: https://www.infofuge.com/question/how-to-overclock-antminer-t9-to-increase-my-profits/

Note: if there is a higher safe limit, say, 15 TH/s, I would like you to specify it.

You’re not going to get any solid answers for what is safe and possible. Mining hardware varies a lot in what the chips can actually perform at reliably, even between individual units of the same model.

Overclocking mining hardware in general is a fools errand, there’s a non linear relationship between the frequency and power usage. That is, by adding 20% more power you’re not going to get 20% more performance out, the efficiency is significantly degraded. When overclocking hardware runs out of specification for the cabling and voltage conversion, which significantly increases the risk of fire and damage.


5gpu 2psu scrypt mining rig shuts down 1hour later I built the following rig:

5x SAPPHIRE TRI-X R9 280X 3GB GDDR5 OC (UEFI)
1x AeroCool Templarius Imperator 1150W 80 Plus Gold
1x HighPower Tech 1200w Gold Plus (HP-1200-G14C-GOLD)
1x Gigabyte GA-990FXA-UD3 motherboard
1x W.D Caviar Green 500GB SATA III HDD
1x Kingston KHX1600C9D3B1/4G
2x Unpowered risers 1x 16x
3x Powered risers 1x 16x

I have the templarius PSU powering the motherboard, the HDD and 2x GPUs with unpowered risers.
The other 3 gpus are powered by the 1200w PSU and connected to the powered usb risers.

I Installed Windows 8.1 and plugged one gpu. It automatically installed the Radeon HD 7990 driver. Then connected the second gpu and followed the same process with the other gpus.

I then executed cgminer and everything looks stable at 740Khs each.

However 1h later the rig shuts down. It always shuts down aprox. 1h later..

Regards,

My brothers machine was doing this also. We fixed it by pulling a card. The motherboard was pulling too much power under load.


How do I get the originating address using Blockchain.info's recieving API? I'm using the blockchain.info/api/api_receive

I have everything working fine but when I made a payment I can't find (in the callback) the bitcoin address of the payer, only the address of the payee...

callback example:

{
   "input_transaction_hash":"0a11043d6e067bad827d4c82da2c45e99323f3a0b28f843fae156bcbd7e8a1d2",
   "shared":"false",
   "address":"1MVSoHC5M875Pbz5FfzckA35A6LpbmNcpo",
   "destination_address":"1MVSoHC5M875Pbz5FfzckA35A6LpbmNcpo",
   "input_address":"1NjbP7RFN6sQbEp6wVc21ZpKRhoR4PaLbR",
   "invoice_id":"40",
   "anonymous":"false",
   "secret":"eijfei4333",
   "confirmations":"4",
   "value":"1407217",
   "transaction_hash":"0d28f482f56c784c3f09be9e49ea45de76a49ae91efbeab43a7bfec417c37005"
}

How can I find out the payers address?
Thanks

You can use blockchain.info's API to look this up, specifically you're looking for the inputs of the "input_transaction_hash" tx:

https://blockchain.info/rawtx/0a11043d6e067bad827d4c82da2c45e99323f3a0b28f843fae156bcbd7e8a1d2

Result:

{
   "ver":1,
   "inputs":[
      {
         "sequence":4294967295,
         "prev_out":{
            "spent":true,
            "tx_index":86277579,
            "type":0,
            "addr":"1JfkMijQTFsRbfDhqTU8Sacx2JVGiSs8af",
            "value":20470771,
            "n":1,
            "script":"76a914c1ce233e2d34facb69aa2b1233db07929586691388ac"
         },
         "script":"49304602210091a3b8759a99abcf4eaa1d3205f5d89e5243faa9ea166c3a9d2f34889dd5f86c02210080738b0beb1cbede15061d2ba5e37033bcc16848b06807e6c3ab2837ef281a99012102665ea1fd74fdb940be0245633ee276bb2abc4a650a16eb77601ed0c3ffd37293"
      }
   ],
   ...

Please be aware that actually using the "from" addresses (there are often multiple) for any purpose is dangerous and strongly discouraged, please see Can a bitcoin transaction be reversed from the receiving end? for more details.

If you have a need to collect a return address for some purpose, you should consider using BIPs-70/71/72 instead.


Easy way to accept bitcoin payments without external service Is there a way to accept Bitcoin payments without running a full node or rely on an external service?

I'm thinking in some way to validate the transaction and then broadcast it to the network.

If you're not running a Bitcoin client of some sort, or referencing a 3rd party (rely on an external service) then your usability will suffer.

For example you can create private keys and address pairs for receiving funds using a library, so you can accept payments just fine without a node or a 3rd party. The draw back is you don't have a way to monitor the blockchain, check for UTXOs, or push transactions.

If you're looking to do those things as well with as little 3rd party as possible, I'd suggest use a library to create addresses, and build transactions, and then line up a series of open API's that allow you to check the UTXO set, and push a signed transaction. If one fails, then hit the next one, and if that fails hit the next, etc. It's a little extra work, but you won't have to sign up with a service, you don't have to run a node, and you don't have to feel like you're relying on an API service since you'll have fall backs.

Here are some push tx endpoints:
https://api.blockcypher.com/v1/btc/main/txs/push
https://chain.so/api/v2/send_tx/BTC/
https://btc.blockr.io/api/v1/tx/push

Here are some APIs to get the UTXO of an address
https://blockchain.info/unspent?active=1bitcoineateraddressdontsendf59kue
https://chain.api.btc.com/v3/address/1bitcoineateraddressdontsendf59kue/unspent
https://api.smartbit.com.au/v1/blockchain/address/1bitcoineateraddressdontsendf59kue/unspent


What programming language should I learn to create a new altcoin? I've been wondering. What programming language is needed to develop and maintain an altcoin? Because I've been thinking to try creating my own altcoin.

I've seen a lot of services to develop an altcoin for certain amount of money. I could pay for it, but I prefer not to since it would be boring as hell to just do that and there's simply nothing that I can be proud of.

I've seen a step by step guide, forking from Litecoin. But I kinda want to do it blindly. (Meaning doing something that I don't understand at all).

I've learned Java and VB but I don't think it's even used a single bit in Cryptocurrency.

The most likely you followed this link to create an altcoin.
If you feel that C++ is a bit cumbersome, then I would try Python.


How would you store a very large amount of crypto currency I have Litecoin, Bitcoin, Ethereum and NEM. In recent times, I've become a very lucky boy indeed!

I usually download and install the "official" wallets that download the entire blockchain but this is getting impossible now, especially for Ethereum Mist wallet which just plays up all the time causing me to delete chain data and force a so-called "fast sync".

If you were in my position, having this very large amount of coins, how would you go about storing/protecting them? For each of the above which wallets would you use and how would you split things so as to not put everything in one basket?

Many thanks

I am very happy with my Trezor, less so with my Ledger (because I find the interface annoyingly clunky).  The Trezor is extremely easy (and, I believe, extremely safe as long as you don't leave your PIN number or recovery phrase lying around).  It works fine for Litecoin and Bitcoin, and a bit more annoyingly for Ethereum (where it outsources the wallet to another provider).  I don't believe it will hold NEM.  I'm not sure if the Ledger will hold NEM, but it should be easy to look up on their website.  I hold only Ripple in my Ledger, because (among the coins I hold), this is the only one the Trezor won't handle.