Bitcoin Wiki - User contributions [en]

Testnet

2015-04-07T13:01:29Z

Iwilcox: /* Genesis Block */ Link to testnet3 reset commit

The '''testnet''' is an alternative Bitcoin [[block chain]], to be used for testing. Testnet coins are separate and distinct from actual bitcoins, and are never supposed to have any value. This allows application developers or bitcoin testers to experiment, without having to use real bitcoins or worrying about breaking the main bitcoin chain.

Run bitcoin or bitcoind with the -testnet flag to use the testnet (or put testnet=1 in the bitcoin.conf file).

There have been three generations of testnet. Testnet2 was just the first testnet reset with a different genesis block, because people were starting to trade testnet coins for real money. '''Testnet3''' is the current test network. It was introduced with the 0.7 release, introduced a third genesis block, a new rule to avoid the "difficulty was too high, is now too low, and transactions take too long to verify" problem, and contains blocks with edge-case transactions designed to test implementation compatibility.

==Differences==
* Default Bitcoin network protocol listen port is 18333 (instead of 8333)
* Default RPC connection port is 18332 (instead of 8332)
* Bootstrapping uses different DNS seeds.
* A different value of ADDRESSVERSION field ensures no testnet Bitcoin addresses will work on the production network. (0x6F rather than 0x00)
* The protocol message header bytes are 0x0B110907 (instead of 0xF9BEB4D9)
* Minimum [[difficulty]] of 1.0 on testnet is equal to difficulty of 0.5 on mainnet. This means that the mainnet-equivalent of any testnet difficulty is half the testnet difficulty. In addition, if no block has been found in 20 minutes, the difficulty automatically resets back to the minimum for a single block, after which it returns to its previous value.
* A new genesis block
* The IsStandard() check is disabled so that non-standard transactions can be experimented with.

==Genesis Block==

Testnet uses a different genesis block to the main network. You can find it [https://www.biteasy.com/testnet/blocks/000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943 here] or [http://blockexplorer.com/testnet/b/0 here].
The testnet was [https://github.com/gavinandresen/bitcoin-git/commit/feeb761ba07af74a7cd78b8c8f7c2a961fd9ea1c reset with a new genesis block] for the 0.7 bitcoin release.

==Mining==
[[solo.ckpool]] has a testnet bitcoin solo mining implementation available, without the need to set up bicoind locally.

==External links==

* [https://bitcointalk.org/?topic=4483.0 Testnet in a box forum topic]
* [https://sourceforge.net/projects/bitcoin/files/Bitcoin/testnet-in-a-box/ Testnet-In-A-Box self-contained testnet]
* [https://github.com/freewil/bitcoin-testnet-box Forked/Updated testnet-box]

===Wallets===

Online testnet wallets to help you test your application.

* [http://testnetwallet.com/ TestnetWallet.com]

===Faucets===

Once you're done with your test coins, it is a nice gesture to send them back to the faucets, so they become available to other developers.

* [http://bitcoinfaucet.uo1.net/ UO1 Testnet Faucet]
* [http://faucet.haskoin.com/ Haskoin Testnet3 Faucet]
* [http://tpfaucet.appspot.com/ TP's TestNet Faucet]
* [http://faucet.luis.im/ luis.im Mojocoin Testnet3 Faucet]
* [https://play.google.com/store/apps/details?id=com.mycelium.testnetwallet Mycelium Testnet Wallet for Android with integrated Testnet "faucet" function (Local Trader)]

===Block explorers===
* [http://testnet.btclook.com/ BTCLook Testnet Explorer]
* [https://www.biteasy.com/testnet/blocks Biteasy.com Testnet Blockexplorer]
* [http://pool.qdoop.net:18331/chain/Testnet3 Testnet3 ABE based Block Explorer]
* [http://blockexplorer.com/testnet Testnet Block Explorer]
* [http://tbtc.blockr.io/ Bitcoin Testnet on Blockr.io]
* [https://test-insight.bitpay.com/ Bitcoin Testnet on insight.bitpay.com]
* [https://www.blocktrail.com/tBTC BlockTrail Testnet Explorer, Testnet API and Testnet Faucet]

[[Category:Technical]]
[[Category:Developer]]

Purecoin

2015-01-25T18:20:01Z

Iwilcox: Make clearer that it's for fun only.

{{stub}}
Purecoin is a Haskell full-node implementation, by [http://r6.ca/ Russell O'Connor], available [https://github.com/laanwj/Purecoin on github] (mirrored from darcs). On its completeness and motivations, Russell comments:
* [http://bitcoinstats.com/irc/bitcoin-dev/logs/2011/11/28#l1322491573 purecoin tries to be as simiple an implementation as I can get away with. The idea is more for documentation than for real use.]
* [http://bitcoinstats.com/irc/bitcoin-dev/logs/2011/11/28#l1322495797 it doesn't handle OP_IF, but I'm pretty sure there are many more unknown incompatibilities.]
* [http://bitcoinstats.com/irc/bitcoin-dev/logs/2011/11/28#l1322495724 I guarentee that purecoin is not entirely compatible with bitcoin]
[[Category:Nodes]]
[[Category:Haskell]]

BitcoinFS

2015-01-25T18:04:52Z

Iwilcox: Created page with "{{stub}} Bitcoin F# is a full-node implementation in F# by [https://github.com/hhanh00/ hhanh00]. Commenting on motivations [https://bitcointalk.org/index.php?topic=923409.ms..."

{{stub}}
Bitcoin F# is a full-node implementation in F# by [https://github.com/hhanh00/ hhanh00]. Commenting on motivations [https://bitcointalk.org/index.php?topic=923409.msg10146701#msg10146701 on Bitcointalk], he says:
<blockquote>I'm implementing a full node for a couple of things. 1. to make sure i have a complete understanding of the implementation that goes beyond reviewing code. For me, it's like reading a book versus writing one. 2. all the implementations i have seen follow a similar logic specially wrt blockchain management and scripting. i wanted to do it my way to see if it's better or worse. 3. i'm aiming for short. no wallet, no mining, no dos protection.
These goals in mind, it is clearly not fit for wide distribution. It's working fine though - being able to sync up from the beginning while validating, holding a mempool content identical to the core client and etc.</blockquote>

Its [https://github.com/bitcoinfs/bitcoinfs project page on GitHub] says:
<blockquote>
* Bitcoin F# has fully validated the existing mainnet blockchain and passes all the integration tests including large reorg tests.
* It is also the only implementation in a functional language and comes under 2.5 kLOC, making it the smallest client too.
</blockquote>

Commenting on its completeness [https://bitcointalk.org/index.php?topic=923409.msg10204174#msg10204174 on Bitcointalk], he says:
<blockquote>it bootstraps, syncs and validates the blockchain. It passes the acceptance tests from Matt too. As a relay node, it keeps a tx pool, validates, relays new tx and you can trim old blocks just by deleting files. I've been running for a while.
At about 2k lines of code, it fits my requirement of small code that I can fit in my brain but I understand it's not 100% compatible and will never be.</blockquote>
There's a [https://bitcoinfs.github.io/bitcoinfs/index.html walkthrough of the (short!) code] available.

[[Category:F Sharp]]
[[Category:Stubs]]
[[Category:Nodes]]
[[Category:Software]]

Category:F Sharp

2015-01-25T17:30:40Z

Iwilcox: Created page with "Category:Programming Languages"

[[Category:Programming Languages]]

Category:Haskell

2015-01-25T17:29:30Z

Iwilcox: Add to Category:Programming Languages

[[Category:Programming Languages]]

From address

2014-08-07T11:58:17Z

Iwilcox: /* security implications of re-use */ Fix links

Bitcoin addresses are used to receive payments, but not to send them:
there is no concept of a "from" address in Bitcoin.

A common exchange on Bitcoin forums goes like this:
* X: How do I see the address that a transaction came from?
** or: Why does my wallet software not tell me where transactions came from?
* Y: (You can’t,) because there is no ‘from’ address.
* X: What the hell do you mean? My transaction came from somewhere!
This is an attempt to explain readably but fairly completely in one easily linkable place.

== It depends what your definition of ‘from’ is ==

OK, so before you had these coins, someone else had them<ref>Unless you were [[Coinbase|mining]].</ref> — let’s say your friend Monica paid you back her share of your restaurant bill right there in the restaurant.
The reason for avoiding the word ‘from’ is that in common English usage it’s tempting to assume that if something came ''from somewhere'', and you need to return it or correspond later about something else, that’s where you should ''return it to/reply to''.
In the case of Bitcoin transactions (and actually often in the real world) this is an unreliable assumption;
it confuses the who with the where/how.
The distinction isn’t just [http://www.deadprogrammer.com/technically-correct pedantry];
people (especially SatoshiDICE customers) have made this mistake and have lost money, so it’s primarily an effort to minimise such losses in future<ref>Secondarily, understanding why it’s unreliable is useful both for sound understanding of Bitcoin and for writing robust financial code that doesn’t lose other people’s money or cause support headaches for you.</ref>.

I suspect the following factors have contributed to the popularity of the “from” misconception:
# We often learn by comparing new phenomena to those we’re already familiar with, and in most other payment systems and sender/recipient models the sender has a single permanent identifier.
# Most blockchain explorers<ref>At least [https://blockexplorer.com blockexplorer.com], [https://blockchain.info blockchain.info], [https://biteasy.com biteasy.com] and [https://blockr.io blockr.io] (at time of writing).</ref> attempt to show all last-sent-to addresses for a transaction in an effort to be user-friendly, and either show a suggestive arrow or even (in the case of blockexplorer.com) actually label the last-sent-to as “From”. All those I checked represent addresses as having a “balance” which tempts people to think addresses operate like bank accounts.
# The depiction or use of addresses in some local wallets somewhat encourages it:
#* Multibit prefers simpler key management over privacy, [https://bitcointalk.org/index.php?topic=208808.msg2191181#msg2191181 sending change “back” to one of the last-sent-to addresses]
#* Electrum [https://iwilcox.me.uk/2014/no-from/electrum-screenshot represents addresses as having balances]
# Vanity address use can easily be interpreted as meaning there’s a one-to-one relationship between people and addresses.

<references/>

== Why there’s no ‘from’ address ==

=== By analogy ===

Relying on things that ''seem'' like ‘from’ addresses would be like:
* getting on a train/bus that just arrived from where you want to go, in the hope that all trains/buses always turn around and head back the way they came
* trying to reply to mail you recieved in a re-used envelope — by peeling the sticker bearing your address off, and using the previous address you find underneath

=== More technically ===

At the protocol level, when looking at a transaction in isolation as it appears on the wire or in a block, no part of it directly encodes a “from”.
A transaction provides solutions for some challenges and poses some new challenges, both in the form of [[Script|scripts]]<ref>Although in practice the network currently limits solution scripts to providing solutions directly; solution scripts can’t compute anything.</ref>
.
Here’s one way to depict that for a transaction like [https://blockexplorer.com/rawtx/e9e2c646890be8aa2f32b221e1ac771467839a660dab1e269d1b6d8c11b25063 e9e2....5063]:

[[Image:4ce9ef5f165d910881386f1d65fe1bf93b66ada3.png]]

None of the <code>prev_outs</code> in the [https://blockexplorer.com/rawtx/e9e2c646890be8aa2f32b221e1ac771467839a660dab1e269d1b6d8c11b25063 decoded version] directly encode addresses in any form.
It does encode ''indirect references'' to unspent coins, and maybe for some unspent coins you can infer something about ''their'' previous destination, but conceptually those are at best references to previous “to” addresses.
Even that inference is not always sensible (advanced transactions will probably [https://blockexplorer.com/rawtx/e9e2c646890be8aa2f32b221e1ac771467839a660dab1e269d1b6d8c11b25063 defeat] [https://blockchain.info/tx/54fabd73f1d20c980a0686bf0035078e07f69c58437e4d586fb29aa0bee9814f?show_adv=true most] [https://www.biteasy.com/blockchain/transactions/54fabd73f1d20c980a0686bf0035078e07f69c58437e4d586fb29aa0bee9814f block] [http://blockr.io/tx/info/54fabd73f1d20c980a0686bf0035078e07f69c58437e4d586fb29aa0bee9814f explorers]) and is never necessary or appropriate in everyday use of Bitcoin. The rest of this post will use the term “''last-sent-to'' address”<ref>Because transactions are multiple-input, multiple-output, it’s really “all last-sent-to addresses”, since without assumptions you’ve no information about whether any one is more valid than any other.</ref>.

<references/>

== Unreliable assumptions ==

So when and how does sending to the last-sent-to address fail?
Suppose you carefully reconcile your personal accounts at the end of each month and notice then that Monica overpaid.
Now you need to return some of the money.
If you send to the last-sent-to address, you’re relying on the assumptions that Monica:
* uses a local wallet rather than a shared/web wallet
* didn’t drop her phone in a puddle in the meantime
* didn’t have her phone stolen in the meantime
* used coins she received via a simple transaction to pay you
* knows (or can definitely work out) who is sending that money to her and why
* is comfortable with the security implications of address re-use
* is comfortable with the privacy implications of address re-use

If any of these assumptions turn out to be untrue you’ll lose coins, inconvenience Monica, or both.
Since this is more than you’re likely to know with sufficient confidence about her without checking with her, it’s safer and easier simply to ask her for the correct address to send the overpayment to (hopefully a freshly generated, dedicated one) when you communicate.

The following sections briefly look at why each listed assumption about the last-sent-to address is risky.

* [[#Recipient created the private key|Recipient created the private key]]
* [[#Recipient still has a copy of the private key|Recipient still has a copy of the private key]]
* [[#Recipient has maintained exclusive control of the private key|Recipient has maintained exclusive control of the private key]]
* [[#Recipient used coins they recieved through pay-to-pubkey-hash transactions|Recipient used coins they recieved through pay-to-pubkey-hash transactions]]
* [[#Recipient can work out the origin reliably|Recipient can work out the origin reliably]]
* [[#Recipient is comfortable with the security implications of address re-use|Recipient is comfortable with the security implications of address re-use]]
* [[#Recipient is comfortable with the privacy implications of address re-use|Recipient is comfortable with the privacy implications of address re-use]]

=== Recipient created the private key ===

Many web wallets/exchanges<ref>Besides some sites that provide nothing but wallet services, this includes some centralised exchanges, peer-to-peer or escrow-based exchanges, betting sites, mining pools — any site that holds coins on your behalf and doesn’t give you exclusive access to your private key, or sufficient multisig control of your coins.</ref> (shared wallets) manage addresses and private keys for you, and pool all deposited coins.
After you deposit coins to such a site they will almost always use coins you deposited to fulfill other customers’ withdrawals, maintaining your balance only as a centralised database entry.
Similarly, when you go to withdraw coins to an external address, your withdrawal will probably consist entirely of coins last-sent-to some other customer’s deposit address and/or addresses used purely internally by the site to receive [[Change|change]].

''FIXME: diagram of typical shared wallet coin-pooling, picturing your freshly deposited coins being used satisfy another customer’s withdrawal, then someone else’s coins being used to satisfy yours.''

In that case, the address Monica’s coins were last-sent-to might just be the deposit address of a completely unrelated user of the same shared wallet Monica uses, or at best, a change address used purely internally by the shared wallet, not associated with any particular user.
Either way, Monica would be unlikely ever to recover what you sent.

This wouldn’t be a problem if the last-sent-to address<ref>Or, more correctly, if the private key from which that address was derived was created with a local wallet.</ref> was created with a local wallet such as Bitcoin QT, Electrum or Multibit — but you can’t safely assume that, and even if you know Monica used a local wallet recently she may have changed her habits when creating that address, or switched wallets since.

This doesn’t mean shared wallets are misbehaving by pooling deposits;
it’s necessary for keeping most coins in cold storage.
The model has other benefits too;
they can make more efficient use of block space (and reduce fees as a result) by grouping withdrawals <ref>Bitstamp does this.</ref> and by handling transfers between customers internally, and provided they protect/expire their logs, they increase privacy.

<references/>

=== Recipient still has a copy of the private key ===

Monica may have lost all copies of the last-sent-to address’s private key since paying you, so you may be destroying coins by sending them there.
While this is unlikely if the interval is short, there are a multitude of ways to lose data:
* accidental/naïve deletion; especially:
** [http://www.reddit.com/r/Bitcoin/comments/26xw2s/lost_all_my_btc_depressed_pointless_rant/ switching devices without keeping old wallet data]
** switching wallet software without keeping old wallet data
** spending a paper wallet or “physical” bitcoin then discarding it
* physically losing the media
* data corruption
* device failure
* forgotten password or death of the owner
* bad app uninstall procedures

and most people are pretty poor at keeping suitably regular/redundant backups.
Even if Monica is fantastic at keeping regular backups, perhaps the private key is physically distant or requires some tedious recovery procedure, so it might be very inconvenient.

=== Recipient has maintained exclusive control of the private key ===

Monica may have had her private keys extracted from her by an attacker:
* fallen prey to malware
* been socially engineered
* been physically robbed/mugged
* suffered from a bug in a common wallet

or may have been negligent with it/underestimated attacks:
* used a weak password
* left her phone/laptop unattended and unlocked
* used her wallet from a USB stick in an Internet café

and have taken measures to recover, generating fresh keys/addresses.

Another way Monica might not have exclusive control of the key is if she received the coins by someone handing her a paper wallet, as a present or tip.
While a careful giver would be sure to wipe the private key from their wallet once they were sure it was spent, they may have forgotten, gone rogue or fallen victim to a wallet-stealing malware themselves.

=== Recipient used coins they recieved through pay-to-pubkey-hash transactions ===

If Monica received those coins she used to pay you at a multisignature address, she may now lack sufficient signing keys to release anything you send there, and it may be inconvenient or impossible for her to get signatures from the other keyholders.
For instance, maybe she used [https://www.bitrated.com/ Bitrated] and had a dispute resolved in her favour but the arbitrator she chose since discarded or lost their key, went rogue or died.
Multisignature addresses are just one use of pay-to-script-hash, so you can’t even infer that a pay-to-script-hash is a multisignature address;
she may have used a more exotic variety.

Even if she received those coins with pay-to-pubkey-hash transactions<ref>Or, I guess, pay-to-pubkey.</ref>, her transaction to you may have consumed multiple inputs.
How are you going to distribute your repayment between those?
Equally?
Pick one at random?
Existing use of [https://bitcointalk.org/index.php?topic=279249.0 CoinJoin] probably involves people participating in a join between external transactions, as a separate privacy enhancement step, but as more implementations appear perhaps clients will support direct payments via CoinJoins.
That would be a similar situation to the shared wallets point above.

<references/>

=== Recipient can work out the origin reliably ===

This is more about respecting a payee’s preferred payment method and making life easy for them than about avoiding loss.
To ease accounting (and other reasons) Monica might always create a dedicated address for every receive, and label it with the name of the expected sender and purpose of the transaction.
If you send to an address Monica gave out to her employer, her accounts won’t balance.
Assuming her employer and you both follow best practices regarding privacy/address re-use, she can’t tell anything about the mystery incoming funds with any certainty.

In some business (and perhaps tax return) situations having an inexplicable imbalance on an account can be a serious compliance problem;
while folks in that situation could delete all related keys to prevent that, you can’t be sure they have and even if they did, you’re destroying coins.

=== Recipient is comfortable with the security implications of address re-use ===

Established security best practices discourage address re-use because when Monica sends you the restaurant bill, she reveals the public key for the last-sent-to address;
before that, the world knew only the address (a hash of the public key) and would have had to perform a pre-image attack to find the public key.
While it’s pretty unlikely, ECDSA is relatively new and could be found to be weak;
private keys may somehow be found to be easily derived from public ones, exposing any unspent coins where the public key is known.

Re-using addresses also probably increased the [http://tradeblock.com/research/security-vulnerability-in-all-android-bitcoin-wallets/ losses suffered via the Android SecureRandom bug], since [http://www.nilsschneider.net/2013/01/28/recovering-bitcoin-private-keys.html exploiting it] required seeing two transactions with the same last-sent-to and the same r values.

The discoverers of the OpenSSL ECDSA [http://arstechnica.com/security/2014/03/scientist-devised-crypto-attack-could-one-day-steal-secret-bitcoin-keys/ “FLUSH+RELOAD” attack] estimated that under the right conditions they could recover a private key by observing as few as 200 signatures (in Bitcoin’s case, typical transactions) made with it.

Hopefully those are the last bugs we’ll see related to re-use, but we can’t be sure.

Since it’s Monica’s money at stake here, the decision on whether these threats are significant should be up to her.

=== Recipient is comfortable with the privacy implications of address re-use ===

[https://bitcoin.org/en/protect-your-privacy Established privacy best practices] discourage address re-use because it reduces privacy both for you and, [http://www.bitcoinnotbombs.com/innovations-that-enhance-bitcoin-anonymity/ infectiously], for all other users (most directly, people you transact with, but also to a lesser extent the people they transact with, and so on).
Even if you feel the simpler key management is worth the privacy cost to you and the rest of the network, it’s more polite to avoid inflicting that cost on Monica any more than you already are — again, you should let her make her own decision on this.

== Solutions ==

Perhaps we’re doomed, and Bitcoin will never see mass adoption because of traps like these that await the unwary.
On the other hand, things can be done.

If you’re telling someone about Bitcoin you should avoid mentioning the concept, except to explain how, in this respect, Bitcoin doesn’t operate like other payment systems or sender/receiver systems they might know.

Tools like block explorers and wallets should either refrain from showing inferences altogether, or should show them only in an advanced mode — with the right name and a prominent list of reasons why they’re of academic interest only.
Perhaps if folks make enough noise, they will.

Uptake of the [https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki payment protocol] and other such measures that deliver refund addresses in the same communication as payment requests/payments should be encouraged.
These hide such dirty temptations from the user.

Privacy-protecting wallets should be preferred, since those avoid address re-use anyway.

<hr/>

''2014-05-30: incorporate feedback from Andrew Poelstra and Burrito. 2014-05-31: incorporate feedback from Greg Maxwell, btiefert, dsnrk. 2014-06-01: incorporate feedback from Luke-Jr.''

''Original source: [https://iwilcox.me.uk/2014/no-from-address https://iwilcox.me.uk/2014/no-from-address]''

Private key

2014-07-15T06:31:18Z

Iwilcox: /* Base 58 Wallet Import format */ Mention that the example key is mainnet-only, since a couple of people have lost hair trying to import it on testnet.

A '''private key''' in the context of Bitcoin is a secret number that allows bitcoins to be spent. Every Bitcoin address has a matching private key, which is saved in the wallet file of the person who owns the balance. The private key is mathematically related to the Bitcoin address, and is designed so that the Bitcoin address can be calculated from the private key, but importantly, the same cannot be done in reverse.

Because the private key is the "ticket" that allows someone to spend bitcoins, it is important that these are kept secure. Private keys can be kept on computer files, but they are also short enough that they can be printed on paper. An example of a utility that allows extraction of private keys from your wallet file for printing purposes is [[pywallet]].

In order to create a transaction with a private key, it must be available to a program or service that allows entry or importing of private keys. Some wallets allow the private key to be imported without generating any transactions while other wallets or services require that the private key be swept. When a private key is swept, a transaction is broadcast that sends the entire balance held by the private key to another address in the wallet or securely controlled by the service in question.

An example of private key sweeping is the method used on [[MtGox]]'s Add Funds screen and [[BIPS]] Import screen. Just as with any other deposit, there is risk of double-spending so funds are deposited to the MtGox account after a six-confirmation wait (typically one hour). In contrast [[BlockChain.info]]'s My Wallet service and Bitcoin-QT each provide a facility to import a private key without creating a sweep transaction.

==An example private key==
In Bitcoin, a private key is a 256-bit number, which can be represented one of several ways. Here is a private key in hexadecimal - 256 bits in hexadecimal is 32 bytes, or 64 characters in the range 0-9 or A-F.

E9 87 3D 79 C6 D8 7D C0 FB 6A 57 78 63 33 89 F4 45 32 13 30 3D A6 1F 20 BD 67 FC 23 3A A3 32 62

==Range of valid private keys==
Nearly every 256-bit number is a valid private key. Specifically, any 256-bit number between 0x1 and 0xFFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4141 is a valid private key.

The range of valid private keys is governed by the [[secp256k1]] ECDSA standard used by Bitcoin.

==Base 58 Wallet Import format==
When we represent private keys in Bitcoin, however, we use a shorter format known as [[wallet import format]], which offers a few advantages. The wallet import format is shorter, and includes built-in error checking codes so that typos can be automatically detected and/or corrected (which is impossible in hex format) and type bits indicating the network it's valid on. Wallet import format is the most common way to represent private keys in Bitcoin. For private keys associated with uncompressed public keys, they are 51 characters and always start with the number 5 on mainnet (9 on testnet). Private keys associated with compressed public keys are 52 characters and start with a capital L or K on mainnet (c on testnet). This is the same private key in (mainnet) wallet import format:

5Kb8kLf9zgWQnogidDA76MzPL6TsZZY36hWXMssSzNydYXYB9KF

When a private key is imported, it always corresponds to exactly one [[Address|Bitcoin address]]. Any utility which performs the conversion can display the matching Bitcoin address. The mathematical conversion is somewhat complex and best left to a computer, but it's notable that each private key will always correspond to the same address no matter which program is used to convert it.

The Bitcoin address corresponding to the sample above is: 1CC3X2gu58d6wXUWMffpuzN9JAfTUWu4Kj

==Mini private key format==
Some applications use the [[mini private key format]]. Not every private key or Bitcoin address has a corresponding mini private key - they have to be generated a certain way in order to ensure a mini private key exists for an address. The mini private key is used for applications where space is critical, such as in QR codes and in [[physical bitcoins]]. The above example has a mini key, which is:

SzavMBLoXU6kDrqtUVmffv

==Summary==
Any Bitcoins sent to the address 1CC3X2gu58d6wXUWMffpuzN9JAfTUWu4Kj can be spent by anybody who knows the private key in ''any'' of the three formats. That includes bitcoins presently at the address, as well as any bitcoins that are ever sent to it in the future. The private key is only needed to spend the balance, not necessarily to see it. The Bitcoin balance of the address can be determined by anybody with the public [[Block Explorer]] at http://www.blockexplorer.com/address/1CC3X2gu58d6wXUWMffpuzN9JAfTUWu4Kj - even if they don't have the private key.

If a private key with a Bitcoin balance is compromised or stolen, the bitcoin balance can only be protected if it is immediately spent to a different address whose private key is not compromised. Because bitcoins can only be spent once, when they are spent away from a private key, the private key is worthless unless more coins are sent to the address.

==See Also==

* [[Paper wallet]]
* [[How to import private keys]]
* [[How to import private keys v7+]]

[[es:Clave privada]]

Gocoin

2014-06-01T21:13:25Z

Iwilcox: /* References */ Add to Google Go language category

An open-source Bitcoin solution written in Go language (golang).
It can be built for every platform that has a working Go compiler.
It uses a proprietary license, though is free to use for non-commercial purposes.

==Architecture==

Gocoin's architecture is quite different from the reference implementation (of the Satoshi client).

===Libraries===

====btc / chain / script ====
The core of the software is a library that essentially provides the blockchain protocol parser. That includes script parsing, ECDSA signature verification, but also things like address encoding, parsing of canonical signatures or extracting hashes that need to be signed for specific inputs of a given transaction.

It is a relatively big library, that contains many useful bitcoin function.

Inside the package, there is also a blocks persistent storage database (blockdb.go) - it is just a simple plain storage (that can only grow), with an index. It uses snappy compression, allowing to save about 30% of the disk space.

====qdb====
The core library interfaces directly with a UTXO database backed.
For this purpose Gocoin uses its own database engine, that has been designed to deal with the specific characteristics of bitcoin's UTXO database.

====secp256k1====
To speed up the Elliptic Curve operations [https://github.com/bitcoin/secp256k1 the secp256k1 library by sipa] has been ported to Go.

===Online client===
The online client is a kind of a server software (or a peer-to-peer node) that is meant to be running all the time.

It handles the network related communication, feeds the core lib with new incoming blockchain data, monitors balances on the wallets' addresses, manages transaction memory pool and the peers database. It also provides an interactive user interface.

===Offline wallet===
The wallet application is responsible for creating private keys (from a seed password) and for signing transactions with them.
It can also sign text messages with private keys and decode raw transactions.

Unlike the client, the wallet is not an app that is meant te be running continuously.
A user runs it with the requested task - the wallet does the job and exits (back to the command prompt).

===Blockchain downloader===
For optimized initial blockchain download, Gocoin has a dedicated application called '''downloader'''.

Among other optimizations, the downloader allows a user to skip verification of all the blocks up to a certain one that he defines as trusted. This can speed up the bootstrap process significantly (e.g. from days to hours).

After it finishes downloading of all the blocks, it will exit automatically. In that moment the client should be started and it will keep up with all the new blocks, that will appear in the network.

===Other tools===
There is also a set of more and less useful tools (''github.com/piotrnar/gocoin/tools'') that are an integral part of the Gocoin bitcoin software.

For instance '''btcversig''' can verify a validity of a bitcoin signature - it is the substitute of the reference client's '''verifymessage''' RPC-API.

The tool '''type2determ''' can, at the other hand, calculate Type-2 deterministic addresses, without a need to access the wallet (the private keys).

==Features==

Gocoin has a several unique features, that distinguish it from the original bitcoin client.
===Node / Client===
* All the unspent outputs are kept in memory, which makes switching between different wallets, as well as checking a balance of any address, relatively fast (few seconds max).
* Allows a user to limit the upload and download network bandwidth used by the client.
* Can be monitored and controlled through a web interface (from a web browser).
* Works with its own implementation of a cold storage wallet.
* Web interface allows a user to create raw transactions from specific inputs ([[Coin Control]]), as well as multisig transactions ([[P2SH]])
* The blocks are stored on the disk in a compressed form (using [https://code.google.com/p/snappy/ snappy] compression) which saves 20-30% of space.
* Supports monitoring and fetching balance of own stealth addresses (the ones implemented in Dark Wallet)

===Wallet===
* For security reasons, it is supposed to be used with a PC that has never been (and will never be) connected to a network.
* The wallet is deterministic and a seed-password based. As long as you can remember the password, there is no need for any backups.
* Additionally it can import private keys from an existing bitcoin wallet (must be in [[Private key#Base 58 Wallet Import format | Base 58 Wallet Import format]] format).
* Has very low hardware requirements. Can be run on i.e. Raspberry Pi
* Can generate [https://bitcointalk.org/index.php?topic=19137.0 Type-2] deterministic keys/addresses
* Supports (partial) signing of [[P2SH]] multisig transactions (the ones that use [[Script#Crypto | OP_CHECKMULTISIG opcode]]).
* Supports spending to stealth addresses as implemented in Dark Wallet
* Supports Litecoin

===Node-less mode===
It is possible to use Gocoin's wallet, without a need to have a running client node, which may come handy since the node requires quite a decent hardware and the block chain takes a lot of time for the initial download.

In such a case the required balance files are fetched with a tool called '''balio''', from a popular block explorer '''blockr.io'''

''Note: using this tool you will not be able to monitor balance on your stealth addresses.''

==Requirements==
===Client===
Requires 64-bit platform and at least 4GB of system memory.

The file system that stores the blockchain data must be able to handle files larger than 4GB.

===Wallet===
The wallet app has very little hardware requirements. As long as you can build it for a specific architecture, it should work there.

Gocoin wallet has been even used on Raspberry Pi model A.

For security reasons it is strongly recommended to run the wallet on an encrypted file system, with an encrypted swap file.

==Limitations==
* No GUI, though the online node has web interface
* No RPC API
* No IPv6
* No UPnP
* No support for non-confirmed transactions (they are invisible in the balance)
* No support for [[Protocol_specification#filterload, filteradd, filterclear, merkleblock | bloom filters]] protocol ([[BIP 0037]]) and the [[Protocol_specification#mempool | mempool]] command
* No routing of [[Protocol_specification#alert | alert]] messages
* No support for multisig stealth addresses (yet)

==History==

Gocoin was written by a single person for a private purposes.

The software's first public release was announced in May 2013 on Bitcointalk forum.<ref>https://bitcointalk.org/index.php?topic=199306.0</ref>
Ever since then, the software has been actively maintained and further developed, being armed with new features, further optimized and cleaned up from issues.

It happened twice that the client wasn't able to catch up with the blockchain, because of the implementation difference of the chain parsing protocol that was causing it to reject a block (transaction) that the reference implementation would accept. In both cases the issue was fixed within single days. The fist case happened in July 2013 and the fix was introduced in version 0.5.7. The second time was in March 2014 - the fix came with release 0.9.3.

==External Links==

* [http://www.assets-otc.com/gocoin Homepage]
* [https://github.com/piotrnar/gocoin Github repo]
* [https://bitcointalk.org/index.php?topic=199306.0 Bitcointalk forum topic]

==References==
<references />

[[Category:Software]]
[[Category:Clients]]
[[Category:Open Source]]
[[Category:Wallets]]
[[Category:Google Go]]

Browser-based wallet

2014-06-01T20:50:03Z

Iwilcox: Remove mentions of "'from' address" and link to "no from address" guide; balance Blockchain.info-like wallet description out with downsides

A '''browser-based wallet''' or '''wallet service''' is an online account with an external provider where bitcoins can be stored. Examples include accounts on currency exchange [[:Category:Markets|Markets]], online [[:Category:Services|Services]] and with ecommerce transaction processors. This definition also includes [[Browser-based_wallet#Hybrid_e-wallets|Hybrid e-wallets]].

<span style="color:red">Warning: When storing your bitcoins with a browser-based wallet on a third-party website, you are trusting that the operator will not abscond with your bitcoins, and that operator maintains secure systems that protect against theft, internal or external. It is recommended that you obtain the real-world identity of the website operator, ensure that sufficient recourse is available and avoid services that do not use an offline wallet ([[cold storage]]) for bitcoins that are not needed for daily transactions. Storing significant quantities of bitcoins on third party websites is not recommended.</span> (Note: some [[Browser-based_wallet#Hybrid_e-wallets|Hybrid e-wallets]] might be exempt from this warning, and adequately safe for storing large amount of Bitcoins. In any case, do your own homework and learn how each site operates).

==Benefits==
* Use of a browser-based wallet provider may help improve [[anonymity]] against third-parties who watch your IP address use.
* An account with a wallet service can generally be established in just minutes.
* Some bitcoin users store some or all of their bitcoins in a browser-based wallet to avoid having to worry about keeping a local wallet [[Securing_your_wallet|secure]].
* Since withdrawals can be made to any Bitcoin address, simply using the withdrawal feature to withdraw to an address that is not yours is functionally equivalent to sending a Bitcoin payment when running the Bitcoin client locally.
* Some services offer instant, internal transfers. This allows transactions to complete without having to wait for block confirmations.

==Things to be aware of==

When bitcoins are stored online, the provider retains full control of those amounts. You are trusting a third party to maintain your Bitcoin balance on your behalf. In comparison, if you run the Bitcoin software yourself, you are in full control of your coins so long as the wallet file stored on your computer is kept secret and secure.

Other relevant things:

* You typically have less anonymity with respect to those who run the online wallet site.
* If a payment is made from an online wallet, the last-sent-to [[address]] (often [https://iwilcox.me.uk/2014/no-from-address incorrectly called a 'from' address]) is an address for the wallet provider and not an address reserved specifically for the sender. This is because the wallet service provider may service the payment from any coins in its possession - your balance is not associated with any particular coins, any more than your balance at your local bank is associated with any specific bills. Thus if the recipient were to "return" any bitcoins to the last-sent-to address, the sender would not receive those bitcoins — but last-sent-to addresses are [https://iwilcox.me.uk/2014/no-from-address#assumptions completely unsuitable for that anyway].

* Not all wallet providers reserve a bitcoin address for the account holder indefinitely. Bitcoin addresses generally work best when one is assigned for each use. There is the risk of showing an address from a wallet provider in a directory or on a web page (for donations, as an example) as there is the possibility that at the future date when those bitcoins are sent that the intended recipient still has the wallet account. The same concern applies should the wallet provider cease operations.

* While there are ways for the wallet provider to [https://iwilcox.me.uk/2014/proving-bitcoin-reserves demonstrate that they operate with full reserves], the practice is not widespread and doesn't protect against security breaches or the owner suddenly absconding with all funds.

* Transactions to a Bitcoin address from the same wallet provider are usually completed internally and, if so, will not be processed on the Bitcoin P2P network. Auditing tools such as the [[Block Explorer]] will not show any activity for this transaction.
** Some wallet providers allow amounts below 0.01 BTC to be sent if the transaction is to another account holder on the same service. This allows an inexpensive and immediate method to detect if the recipient is using the same wallet provider.

* The wallet service provider's wallet may be vulnerable to security breaches, loss, or theft. Because Bitcoin transactions are irreversible, there may be limited or no recovery if a provider's master wallet is compromised. Wallet providers who implement preventative controls - such as keeping their reserves in an [[offline wallet]] - are likely to be safer.

==Hybrid e-wallets==

After several online bitcoin wallets were hacked, a second wave of online Bitcoin wallets entered the market. Hybrid wallets generally use Javascript in the user's browser to manage private keys and create payments.

These wallets differed from traditional online wallet services because the user actually owns the private keys inside their wallet. This approach has several advantages:

* The user can look up their account balance in the blockchain and which guarantees their account balance is correct.
* Users can easily export their private keys out of a wallet to use with another bitcoin client or wallet provider; if they take backups of the code and wallet data, this may even be possible if the provider disappears.
* The users' keys are stored encrypted on the server, offering some protection for security breaches if strongly encrypted.
* As each address has only one user, it's less likely that [https://iwilcox.me.uk/2014/no-from-address misguided attempts to "return" coins] to their last-sent-to address will result in loss of coins.

However, there are limits on what this model can achieve:

* A single server compromise or abuse of trust can still result in losses for many users if the site serves maliciously modified Javascript.
* Unless users make use of the backup/export facility, they're no less exposed to wallet data loss or confiscation by the provider.
* The user's browser still presents a relatively large attack surface for exploits.
* Facilities for obtaining entropy in the browser of a grade suitable for strong cryptography are currently poor, and custom entropy code almost never undergoes qualified review, so any keys or nonces created at the browser end may be weak.

==See Also==

* [[Buying bitcoins]]
* [[Selling bitcoins]]
* [[Bitcoin faucet]]
* List of [[:Category:HybridEWallets|HybridEWallets]]
* List of [[:Category:eWallets|eWallets]]

API reference (JSON-RPC)

2014-05-21T17:36:17Z

Iwilcox: /* Java */ Link to JSON-RPC implementations

== Controlling Bitcoin ==

Run ''bitcoind'' or ''bitcoin-qt -server''. You can control it via the command-line or by [http://json-rpc.org/wiki/specification HTTP JSON-RPC] commands.

You must create a bitcoin.conf configuration file setting an rpcuser and rpcpassword; see [[Running Bitcoin]] for details.

Now run:
$ ./bitcoind -daemon
bitcoin server starting
$ ./bitcoind help
# shows the help text

A [[Original Bitcoin client/API Calls list|list of RPC calls]] will be shown.

$ ./bitcoind getbalance
2000.00000

== JSON-RPC ==

Running Bitcoin with the -server argument (or running bitcoind) tells it to function as a [http://json-rpc.org/wiki/specification HTTP JSON-RPC] server, but
[http://en.wikipedia.org/wiki/Basic_access_authentication Basic access authentication] must be used when communicating with it, and, for security, by default, the server only accepts connections from other processes on the same machine. If your HTTP or JSON library requires you to specify which 'realm' is authenticated, use 'jsonrpc'.

Bitcoin supports SSL (https) JSON-RPC connections beginning with version 0.3.14. See the [[Enabling SSL on original client daemon|rpcssl wiki page]] for setup instructions and a list of all bitcoin.conf configuration options.

Allowing arbitrary machines to access the JSON-RPC port (using the rpcallowip [[Running_Bitcoin|configuration option]]) is dangerous and '''strongly discouraged'''-- access should be strictly limited to trusted machines.

To access the server you should find a [http://json-rpc.org/wiki/implementations suitable library] for your language.

== Proper money handling ==

See the [[Proper Money Handling (JSON-RPC)|proper money handling page]] for notes on avoiding rounding errors when handling bitcoin values.

== Python ==

[http://json-rpc.org/wiki/python-json-rpc python-jsonrpc] is the official JSON-RPC implementation for Python.
It automatically generates Python methods for RPC calls.
However, due to its design for supporting old versions of Python, it is also rather inefficient.
[[User:jgarzik|jgarzik]] has forked it as [https://github.com/jgarzik/python-bitcoinrpc Python-BitcoinRPC] and optimized it for current versions.
Generally, this version is recommended.

While BitcoinRPC lacks a few obscure features from jsonrpc, software using only the ServiceProxy class can be written the same to work with either version the user might choose to install:

<source lang="python">
from jsonrpc import ServiceProxy

access = ServiceProxy("http://user:password@127.0.0.1:8332")
access.getinfo()
access.listreceivedbyaddress(6)
#access.sendtoaddress("11yEmxiMso2RsFVfBcCa616npBvGgxiBX", 10)
</source>

The latest version of python-bitcoinrpc has a new syntax.
<source lang="python">
from bitcoinrpc.authproxy import AuthServiceProxy
</source>

== Ruby ==

<source lang="ruby">
require 'net/http'
require 'uri'
require 'json'

class BitcoinRPC
def initialize(service_url)
@uri = URI.parse(service_url)
end

def method_missing(name, *args)
post_body = { 'method' => name, 'params' => args, 'id' => 'jsonrpc' }.to_json
resp = JSON.parse( http_post_request(post_body) )
raise JSONRPCError, resp['error'] if resp['error']
resp['result']
end

def http_post_request(post_body)
http = Net::HTTP.new(@uri.host, @uri.port)
request = Net::HTTP::Post.new(@uri.request_uri)
request.basic_auth @uri.user, @uri.password
request.content_type = 'application/json'
request.body = post_body
http.request(request).body
end

class JSONRPCError < RuntimeError; end
end

if $0 == __FILE__
h = BitcoinRPC.new('http://user:password@127.0.0.1:8332')
p h.getbalance
p h.getinfo
p h.getnewaddress
p h.dumpprivkey( h.getnewaddress )
# also see: https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_Calls_list
end
</source>

== PHP ==

The [http://jsonrpcphp.org/ JSON-RPC PHP] library also makes it very easy to connect to Bitcoin. For example:

<source lang="php">
require_once 'jsonRPCClient.php';

$bitcoin = new jsonRPCClient('http://user:password@127.0.0.1:8332/');

echo "<pre>\n";
print_r($bitcoin->getinfo()); echo "\n";
echo "Received: ".$bitcoin->getreceivedbylabel("Your Address")."\n";
echo "</pre>";
</source>

'''Note:''' The jsonRPCClient library uses fopen() and will throw an exception saying "Unable to connect" if it receives a 404 or 500 error from bitcoind. This prevents you from being able to see error messages generated by bitcoind (as they are sent with status 404 or 500). The [https://github.com/aceat64/EasyBitcoin-PHP EasyBitcoin-PHP library] is similar in function to JSON-RPC PHP but does not have this issue.

== Java ==

The easiest way to tell Java to use HTTP Basic authentication is to set a default Authenticator:

<source lang="java">
final String rpcuser ="...";
final String rpcpassword ="...";

Authenticator.setDefault(new Authenticator() {
protected PasswordAuthentication getPasswordAuthentication() {
return new PasswordAuthentication (rpcuser, rpcpassword.toCharArray());
}
});
</source>

Once that is done, [http://json-rpc.org/wiki/implementations any JSON-RPC library for Java] (or ordinary URL POSTs) may be used to communicate with the Bitcoin server.

== Perl ==

The JSON::RPC package from CPAN can be used to communicate with Bitcoin. You must set the client's credentials; for example:

<source lang="perl">
use JSON::RPC::Client;
use Data::Dumper;

my $client = new JSON::RPC::Client;

$client->ua->credentials(
'localhost:8332', 'jsonrpc', 'user' => 'password' # REPLACE WITH YOUR bitcoin.conf rpcuser/rpcpassword
);

my $uri = 'http://localhost:8332/';
my $obj = {
method => 'getinfo',
params => [],
};

my $res = $client->call( $uri, $obj );

if ($res){
if ($res->is_error) { print "Error : ", $res->error_message; }
else { print Dumper($res->result); }
} else {
print $client->status_line;
}
</source>

== Go ==

The [https://github.com/conformal/btcjson btcjson package] can be used to communicate with Bitcoin. You must provide credentials to match the client you are communicating with.

<source lang="go">
import "github.com/conformal/btcjson"
msg, err := btcjson.CreateMessage("getinfo")
if err != nil {
// Do your error handling
}
// Use your username and password here.
reply, err := btcjson.RpcCommand("user", "password", "localhost:8332", msg)
</source>

== .NET (C#) ==
The communication with rpc service can be achieved using the standard http request/response objects.
A library for serialising and deserializing Json will make your life a lot easier:

Json.Net ( http://james.newtonking.com/json ) is a high performance JSON package for .Net. It is also available via NuGet from the package manager console ( Install-Package Newtonsoft.Json ).

The following example uses Json.Net:

<source lang="csharp">
HttpWebRequest webRequest = (HttpWebRequest)WebRequest.Create("http://localhost.:8332");
webRequest.Credentials = new NetworkCredential("user", "pwd");
/// important, otherwise the service can't desirialse your request properly
webRequest.ContentType = "application/json-rpc";
webRequest.Method = "POST";

JObject joe = new JObject();
joe.Add(new JProperty("jsonrpc", "1.0"));
joe.Add(new JProperty("id", "1"));
joe.Add(new JProperty("method", Method));
// params is a collection values which the method requires..
if (Params.Keys.Count == 0)
{
joe.Add(new JProperty("params", new JArray()));
}
else
{
JArray props = new JArray();
// add the props in the reverse order!
for (int i = Params.Keys.Count - 1; i >= 0; i--)
{
.... // add the params
}
joe.Add(new JProperty("params", props));
}

// serialize json for the request
string s = JsonConvert.SerializeObject(joe);
byte[] byteArray = Encoding.UTF8.GetBytes(s);
webRequest.ContentLength = byteArray.Length;
Stream dataStream = webRequest.GetRequestStream();
dataStream.Write(byteArray, 0, byteArray.Length);
dataStream.Close();

WebResponse webResponse = webRequest.GetResponse();

... // deserialze the response
</source>

There is also a wrapper for Json.NET called Bitnet (https://sourceforge.net/projects/bitnet)
implementing Bitcoin API in more convenient way:

<source lang="csharp">
BitnetClient bc = new BitnetClient("http://127.0.0.1:8332");
bc.Credentials = new NetworkCredential("user", "pass");

var p = bc.GetDifficulty();
Console.WriteLine("Difficulty:" + p.ToString());

var inf = bc.GetInfo();
Console.WriteLine("Balance:" + inf["balance"]);
</source>

== Node.js ==

* [https://github.com/freewil/node-bitcoin node-bitcoin] (npm: bitcoin)

Example using node-bitcoin:

<source lang="javascript">
var bitcoin = require('bitcoin');
var client = new bitcoin.Client({
host: 'localhost',
port: 8332,
user: 'user',
pass: 'pass'
});

client.getDifficulty(function(err, difficulty) {
if (err) {
return console.error(err);
}

console.log('Difficulty: ' + difficulty);
});
</source>

Example using Kapitalize:

<source lang='javascript'>
var client = require('kapitalize')()

client.auth('user', 'password')

client
.getInfo()
.getDifficulty(function(err, difficulty) {
console.log('Dificulty: ', difficulty)
})
</source>

== Command line (cURL) ==

You can also send commands and see results using [http://curl.haxx.se/ cURL] or some other command-line HTTP-fetching utility; for example:

<source lang="bash">
curl --user user --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getinfo", "params": [] }'
-H 'content-type: text/plain;' http://127.0.0.1:8332/
</source>

You will be prompted for your rpcpassword, and then will see something like:

<source lang="javascript">
{"result":{"balance":0.000000000000000,"blocks":59952,"connections":48,"proxy":"","generate":false,
"genproclimit":-1,"difficulty":16.61907875185736,"error":null,"id":"curltest"}
</source>

== Clojure ==

[https://github.com/aviad/clj-btc clj-btc] is a Clojure wrapper for the bitcoin API.

<source lang="clojure">
user=> (require '[clj-btc.core :as btc])
nil
user=> (btc/getinfo)
{"timeoffset" 0, "protocolversion" 70001, "blocks" 111908, "errors" "",
"testnet" true, "proxy" "", "connections" 4, "version" 80500,
"keypoololdest" 1380388750, "paytxfee" 0E-8M,
"difficulty" 4642.44443532M, "keypoolsize" 101, "balance" 0E-8M,
"walletversion" 60000}
</source>

== See Also==

* [[Original_Bitcoin_client/API_Calls_list|API calls list]]
* [[Running Bitcoin]]
* [[Lazy API]]
* [[PHP developer intro]]
* [[Raw_Transactions|Raw Transactions API]]
* [http://blockchain.info/api/json_rpc_api Web Based JSON RPC interface.]

[[Category:Technical]]
[[Category:Developer]]
[[zh-cn:API_reference_(JSON-RPC)]]

BCCAPI

2014-03-29T17:08:48Z

Iwilcox: Mention server is closed-source.

The BCCAPI (Bitcoin Client API) is a java library designed for making secure light-weight bitcoin clients. The BCCAPI connects to a server that holds the block chain, and which tracks the client’s wallet balance. The server only has knowledge of the clients public keys, and is in no position to spend funds owned by the client’s wallet.

Features include:
* Deterministic private keys, based on seed file.
* Only the seed file needs to get backed up, or generated from a passphrase.
* Send/receive Bitcoins
* Low bandwidth
* Low CPU usage
* Server does not have your private keys and is in no position to spend your coins
* Allows spending of unconfirmed-change-sent-back-to-self like the Satoshi Client
* Open source
* Free service, running on donations

Simply put the API is designed for making it easy to create light-weight secure Bitcoin wallets for handheld devices.
[https://market.android.com/details?id=com.miracleas.bitcoin_spinner BitcoinSpinner] is an Android app implemented on top of the BCCAPI and available on the Android Market.

The sources include a very simple console based client, that shows how to use it.

The donation address for BCCAPI is 143SikKpjzwhBy5Z7Qg5knu5nKXWExSqQi

The server is closed-source. Jan Moller said "The server side is however not as clean and well documented as the client side, and I am not ready to make the server side open source. At least not yet."

== Security ==

See [[Thin Client Security]]

==See Also==

The first Android wallet based on the BCCAPI: [[BitcoinSpinner]]

More information and the source code: http://code.google.com/p/bccapi/wiki/WhatIsTheBCCAPI

Forum thread about BCCAPI: https://bitcointalk.org/index.php?topic=36892.0

BCCAPI Adapter for bits of proof Enterprise Bitcoin Server https://github.com/bitsofproof/bop-bccapi

[[Category:Clients]]
[[Category:Java]]
[[Category:Software]]

BCCAPI

2014-03-29T17:00:07Z

Iwilcox: Add to Category:Java and Category:Software.

The BCCAPI (Bitcoin Client API) is a java library designed for making secure light-weight bitcoin clients. The BCCAPI connects to a server that holds the block chain, and which tracks the client’s wallet balance. The server only has knowledge of the clients public keys, and is in no position to spend funds owned by the client’s wallet.

Features include:
* Deterministic private keys, based on seed file.
* Only the seed file needs to get backed up, or generated from a passphrase.
* Send/receive Bitcoins
* Low bandwidth
* Low CPU usage
* Server does not have your private keys and is in no position to spend your coins
* Allows spending of unconfirmed-change-sent-back-to-self like the Satoshi Client
* Open source
* Free service, running on donations

Simply put the API is designed for making it easy to create light-weight secure Bitcoin wallets for handheld devices.
[https://market.android.com/details?id=com.miracleas.bitcoin_spinner BitcoinSpinner] is an Android app implemented on top of the BCCAPI and available on the Android Market.

The sources include a very simple console based client, that shows how to use it.

The donation address for BCCAPI is 143SikKpjzwhBy5Z7Qg5knu5nKXWExSqQi

== Security ==

See [[Thin Client Security]]

==See Also==

The first Android wallet based on the BCCAPI: [[BitcoinSpinner]]

More information and the source code: http://code.google.com/p/bccapi/wiki/WhatIsTheBCCAPI

Forum thread about BCCAPI: https://bitcointalk.org/index.php?topic=36892.0

BCCAPI Adapter for bits of proof Enterprise Bitcoin Server https://github.com/bitsofproof/bop-bccapi

[[Category:Clients]]
[[Category:Java]]
[[Category:Software]]

Clj-btc

2014-03-29T16:54:58Z

Iwilcox: Created page with "{{lowercase}}{{stub}} clj-btc provides Clojure bindings for Bitcoin Core's JSON-RPC API. Example use from the REPL: <..."

{{lowercase}}{{stub}}
clj-btc provides Clojure bindings for [[bitcoind|Bitcoin Core]]'s [[Original_Bitcoin_client/API_Calls_list|JSON-RPC]] API.

Example use from the REPL:

<source lang="clojure">
user=> (require '[clj-btc.core :as btc])
nil
user=> (btc/getinfo)
{"timeoffset" 0, "protocolversion" 70001, "blocks" 111908, "errors" "",
"testnet" true, "proxy" "", "connections" 4, "version" 80500,
"keypoololdest" 1380388750, "paytxfee" 0E-8M,
"difficulty" 4642.44443532M, "keypoolsize" 101, "balance" 0E-8M,
"walletversion" 60000}
</source>

Sources can be found [https://github.com/aviad/clj-btc on GitHub].

[[Category:Software]]
[[Category:Clojure]]

Bitcoinj

2014-03-29T16:44:19Z

Iwilcox: Mention renamed from.

{{lowercase}}
An open source Bitcoin client library built using Java and implements the Bitcoin network protocol. With version 0.7, it was renamed from BitCoinJ to '''bitcoinj'''.

The project was announced on March 7, 2011<ref>[http://www.bitcoin.org/smf/index.php?topic=4236.msg61438#msg61438 ANNOUNCE - BitCoinJ v0.1, a client-mode implementation in Java]</ref>. The project was built by a Google employee as a "20 percent time" project<ref>[http://news.ycombinator.com/item?id=2297686 Comment by Google's Chris Dibona on Hacker News]</ref>.

==See Also==

* [[Bitcoin Wallet]] - a standalone wallet for Android and BlackBerry devices
* [[MultiBit]]
* [[Hive]] - a wallet for Mac OS X with an integrated applications platform

== Security ==
* [[Thin_Client_Security#BitCoinJ]]
* [http://code.google.com/p/bitcoinj/wiki/SecurityModel Security Model]

==External Links==

* [http://code.google.com/p/bitcoinj bitcoinj] project page on Google Code.

==References==
<references />
[[Category:API Bindings]]
[[Category:Nodes]]
[[Category:Wallets]]
[[Category:Clients]]
[[Category:Free Software]]
[[Category:License/Apache2]]
[[Category:Open Source]]
[[Category:Java]]

Bitcoinj

2014-03-29T16:40:15Z

Iwilcox: Add {{lowercase}} template

{{lowercase}}
An open source Bitcoin client library built using Java and implements the Bitcoin network protocol. With version 0.7, it was renamed to '''bitcoinj'''.

The project was announced on March 7, 2011<ref>[http://www.bitcoin.org/smf/index.php?topic=4236.msg61438#msg61438 ANNOUNCE - BitCoinJ v0.1, a client-mode implementation in Java]</ref>. The project was built by a Google employee as a "20 percent time" project<ref>[http://news.ycombinator.com/item?id=2297686 Comment by Google's Chris Dibona on Hacker News]</ref>.

==See Also==

* [[Bitcoin Wallet]] - a standalone wallet for Android and BlackBerry devices
* [[MultiBit]]
* [[Hive]] - a wallet for Mac OS X with an integrated applications platform

== Security ==
* [[Thin_Client_Security#BitCoinJ]]
* [http://code.google.com/p/bitcoinj/wiki/SecurityModel Security Model]

==External Links==

* [http://code.google.com/p/bitcoinj bitcoinj] project page on Google Code.

==References==
<references />
[[Category:API Bindings]]
[[Category:Nodes]]
[[Category:Wallets]]
[[Category:Clients]]
[[Category:Free Software]]
[[Category:License/Apache2]]
[[Category:Open Source]]
[[Category:Java]]

Category:Java

2014-03-29T16:39:26Z

Iwilcox: Created page with "Bitcoin software written in the Java programming language. Category:Programming Languages"

Bitcoin software written in the [[wikipedia:Java (programming_language)|Java]] programming language.

[[Category:Programming Languages]]

Bitcoinj

2014-03-29T16:38:27Z

Iwilcox: Add to Category:Java

An open source Bitcoin client library built using Java and implements the Bitcoin network protocol. With version 0.7, it was renamed to '''bitcoinj'''.

The project was announced on March 7, 2011<ref>[http://www.bitcoin.org/smf/index.php?topic=4236.msg61438#msg61438 ANNOUNCE - BitCoinJ v0.1, a client-mode implementation in Java]</ref>. The project was built by a Google employee as a "20 percent time" project<ref>[http://news.ycombinator.com/item?id=2297686 Comment by Google's Chris Dibona on Hacker News]</ref>.

==See Also==

* [[Bitcoin Wallet]] - a standalone wallet for Android and BlackBerry devices
* [[MultiBit]]
* [[Hive]] - a wallet for Mac OS X with an integrated applications platform

== Security ==
* [[Thin_Client_Security#BitCoinJ]]
* [http://code.google.com/p/bitcoinj/wiki/SecurityModel Security Model]

==External Links==

* [http://code.google.com/p/bitcoinj bitcoinj] project page on Google Code.

==References==
<references />
[[Category:API Bindings]]
[[Category:Nodes]]
[[Category:Wallets]]
[[Category:Clients]]
[[Category:Free Software]]
[[Category:License/Apache2]]
[[Category:Open Source]]
[[Category:Java]]

Category:Clojure

2014-03-29T16:37:50Z

Iwilcox: Created page with "Bitcoin software written in the Clojure programming language. Category:Programming Languages"

Bitcoin software written in the [[wikipedia:Clojure|Clojure]] programming language.

[[Category:Programming Languages]]

Bitcljoin

2014-03-29T16:36:14Z

Iwilcox: Created page with "{{lowercase}} {{stub}} bitcljoin is a Clojure wrapper for bitcoinj. This wrapper exposes the following bitcoinj features as Clojure functions: * keypair generation * addr..."

{{lowercase}}
{{stub}}
bitcljoin is a Clojure wrapper for [[bitcoinj]].

This wrapper exposes the following bitcoinj features as Clojure functions:
* keypair generation
* address from a keypair
* private key import/export
* create/load wallets from a file or in memory
* send coins, and listen for receives
* basic blockchain navigation (full or headers-only)
* BIP32 Hierarchical Deterministic Key generation

Sources can be found [https://github.com/pelle/bitcljoin on GitHub].

[[Category:Software]]
[[Category:Clojure]]

Category:Objective-C

2014-03-29T03:33:07Z

Iwilcox: Created page with "Bitcoin software written in the Objective-C programming language. Category:Programming Languages"

Bitcoin software written in the [[wikipedia:Objective-C|Objective-C]] programming language.

[[Category:Programming Languages]]

Category:Nodes

2014-03-29T03:31:31Z

Iwilcox: Add to Category:Software

A Bitcoin node maintains connections with the Bitcoin network, and relays traffic based on policies.

Any alternate implementation that hasn't been '''extremely''' thoroughly tested over several months should carry the warning "under construction, alpha quality, do not trust with money" because they risk splitting the network if they do not follow the reference client 100% (bug-for-bug) yet.

==See Also==

* [[:Category:Clients|Clients]]
* [[:Category:Frontends|Frontends]]
* [[:Category:Developer|Developer]]
* [[:Category:Software|Software]]

[[Category:Software|Software]]

Clients

2014-03-29T03:29:35Z

Iwilcox: /* For developers */ Fix broken SPV link for Electrum

==Overview==

This table compares the features of the different clients. All of the listed clients are open-source.

===Feature key===

; Wallet Security : How well the client protects your [[private key]]s from people with access to the machine the wallet is stored on. The private keys can be encrypted, for example. The private keys can also be either stored on your device or on a remote server.
; Network Security : Clients which more fully implement the Bitcoin network protocol are safer -- they can't be as easily tricked by powerful attackers. A client which ''fully'' implements the protocol will always use the correct [[block chain]] and will never allow [[double-spending|double-spends]] or invalid transactions to exist in the block chain under any circumstances. Clients which only ''partially'' implement the protocol typically trust that 50% or more of the network's mining power is honest. Some clients trust one or more ''remote servers'' to protect them from double-spends and other network attacks.
; Setup Time : Some clients require that you download and verify a large amount of data before you can send or receive BTC.
; Maturity : When the project was started.

===Table===


{| class='wikitable' style='text-align: center'
! Client !! Get Started !! Audience !! Wallet Security !! Network Security !! Backups !! Setup Time !! Disk Space !! Maturity !! Multi-user !! Available for
|-
! Armory
|| [http://bitcoinarmory.com/index.php/get-armory Download] || Power users || {{CLGood|Encrypted, on-device}} || Addon || {{CLBest|One-time}} || Varies || {{CLBad|6+ GB}} || Jul 2011 || {{CLBest|Multi-wallet}} || {{CLLinux}}{{CLWin}}
|-
! Bitcoin Wallet
|| [https://play.google.com/store/apps/details?id=de.schildbach.wallet Google Play] [https://appworld.blackberry.com/webstore/content/23952882/ BlackBerry World] || {{CLGood|End-users}} || {{CLGood|Isolated, on-device}} || Partial || Manual || {{CLBest|Instant}} || {{CLGood|15 MB}} || {{CLGood|Mar 2011}} || on JB tablets || {{CLAndroid}} [[file:ico-blackberry.png]]
|-
! {{CLGood|Bitcoin-Qt}}
|| [http://sourceforge.net/projects/bitcoin/files/Bitcoin/ Download] || {{CLGood|End-users}} || {{CLGood|Encrypted, on-device}} || {{CLBest|Full}} || Manual || {{CLBad|Hours}} || {{CLBad|6+ GB}} || {{CLGood|May 2011}} || No || {{CLLinux}}{{CLMac}}{{CLWin}}
|-
! bitcoind
|| [http://sourceforge.net/projects/bitcoin/files/Bitcoin/ Download] || Programmers || {{CLGood|Encrypted, on-device}} || {{CLBest|Full}} || Manual || {{CLBad|Hours}} || {{CLBad|6+ GB}} || {{CLBest|Aug 2009}} || {{CLGood|Virtual accounts}} || {{CLLinux}}{{CLWin}}
|-
! Electrum
|| [http://ecdsa.org/electrum/ Download] || Power users || {{CLGood|Encrypted, on-device}} || Minimal || {{CLBest|Memorized}} || {{CLGood|Minutes}} || {{CLGood|5 MB}} || Nov 2011 || No || {{CLLinux}}{{CLMac}}{{CLWin}}
|-
! MultiBit
|| [https://multibit.org/releases.html Download] || {{CLGood|End-users}} || {{CLGood|Encrypted, on-device}} || Partial || {{CLGood|Automatic (local)}} || {{CLBest|Seconds}} || 50 MB || Jul 2011 || {{CLBest|Multi-wallet}} || {{CLLinux}}{{CLMac}}{{CLWin}}
|-
! My Wallet
|| [https://blockchain.info/wallet/new Web-based] || {{CLBest|Everyone}} || Encrypted, on a server || {{CLBad|Remote}} || {{CLGood|Automatic}} || {{CLGood|Minutes}} || {{CLBest|None}} || Dec 2011 || {{CLBest|Yes}} || {{CLAndroid}}{{CLiOS}}{{CLLinux}}{{CLMac}}{{CLWin}}
|-
! Gocoin
|| [https://github.com/piotrnar/gocoin Build yourself] || Power users || Designated offline PC || {{CLBest|Full}} || {{CLBest|Memorized}} || {{CLBad|Hours}} || {{CLBad|6+GB}} || May 2013 || {{CLBest|Multi-wallet}} || {{CLLinux}}{{CLMac}}{{CLWin}}
|}



==For developers==

This table shows additional information about various Bitcoin clients that may be relevant to developers.

{| class='wikitable' style='text-align: center'
! Client !! Website !! Source Code !! License !! Discussion !! Architecture
|-
! Armory
|| [http://bitcoinarmory.com/ Link] ||[https://github.com/etotheipi/BitcoinArmory/ Github] || AGPLv3 || [https://bitcointalk.org/index.php?board=97.0 Bitcointalk] || Integrated
|-
! Bitcoin Wallet
|| [https://github.com/schildbach/bitcoin-wallet Link] || [https://github.com/schildbach/bitcoin-wallet Github] [https://code.google.com/p/bitcoin-wallet/source/checkout Google Code] || GPLv3 || [https://plus.google.com/b/101256420499771441772/communities/105515929887248493912 Google+ community] / [https://bitcointalk.org/index.php?board=100.0 Bitcointalk] || [[Thin Client Security#Simplified Payment Verification (SPV)|SPV]]
|-
! Bitcoin-Qt / bitcoind
|| [http://bitcoin.org/ Link] || [https://github.com/bitcoin/bitcoin Github] || MIT || [https://lists.sourceforge.net/lists/listinfo/bitcoin-development Sourceforge] || Integrated
|-
! Electrum
|| [http://ecdsa.org/electrum/ Link] || [https://gitorious.org/electrum Gitorious] || GPLv3 || [https://lists.sourceforge.net/lists/listinfo/electrum-discuss Sourceforge] || [[Thin Client Security#Simplified Payment Verification (SPV)|SPV]]
|-
! MultiBit
|| [http://multibit.org/ Link] || [https://github.com/jim618/multibit Github] || MIT || [https://groups.google.com/forum/?fromgroups#!forum/bitcoin-multibit Google Groups] || [[Thin Client Security#Simplified Payment Verification (SPV)|SPV]]
|-
! My Wallet
|| [https://blockchain.info/wallet/ Link] || [https://github.com/blockchain/My-Wallet/ Github] || BSD* || None || [[Thin Client Security#Server-Trusting Clients|Server-Client]]
|-
! bits of proof
|| [http://bitsofproof.com Link] || [https://github.com/bitsofproof/supernode Github] || Apache 2.0 || [https://bitcointalk.org/index.php?topic=122013.0 Bitcointalk] || [[Thin Client Security#Server-Trusting Clients|Server-Client]]
|-
! Gocoin
|| [http://www.assets-otc.com/gocoin Link] || [https://github.com/piotrnar/gocoin Github] || ? || [https://bitcointalk.org/index.php?topic=199306.0 Bitcointalk] || Integrated
|-
! btcd
|| [https://github.com/conformal/btcd Link] || [https://github.com/conformal/btcd Github] || ISC || [https://github.com/conformal/btcd#irc-server irc] || [[Thin Client Security#Server-Trusting Clients|Server-Client]]
|}

==See Also==
* [[Software#Bitcoin_clients|List of clients]]
* [[Bitcoin Ladder]]

<references/>

Category:Python

2014-03-29T03:27:54Z

Iwilcox: Created page with "Bitcoin software written in the Python programming language. Category:Programming Languages"

Bitcoin software written in the [[wikipedia:Python_%28programming_language%29|Python]] programming language.

[[Category:Programming Languages]]

Category:Google Go

2014-03-29T03:26:45Z

Iwilcox: Add to Category:Programming Languages

Bitcoin software written in the [[wikipedia:Go_%28programming_language%29|Google Go]] (aka golang) programming language.

[[Category:Programming Languages]]

Category:Google Go

2014-03-29T03:24:20Z

Iwilcox: Created page with "Bitcoin software written in the Google Go (aka golang) programming language."

Bitcoin software written in the [[wikipedia:Go_%28programming_language%29|Google Go]] (aka golang) programming language.

Btcd

2014-03-29T03:16:07Z

Iwilcox: Created page with "{{stub}} btcd is a full-node implementation in Google Go by Conformal. Its [https://github.com/conformal/btcd project page on GitHub] says: "It currently properly downloads,..."

{{stub}}
btcd is a full-node implementation in Google Go by Conformal. Its [https://github.com/conformal/btcd project page on GitHub] says:

"It currently properly downloads, validates, and serves the block chain using the exact rules (including bugs) for block acceptance as the reference implementation (bitcoind). [...] btcd does NOT include wallet functionality and this was a very intentional design decision."

See also the <tt>btcd</tt> tag on [https://blog.conformal.com/tag/btcd/ Conformal's blog], especially the [https://blog.conformal.com/btcd-not-your-moms-bitcoin-daemon/ "ready for public testing" announcement].

[[Category:Google Go]]
[[Category:Stubs]]
[[Category:Nodes]]
[[Category:Software]]

Purecoin

2014-03-29T02:56:53Z

Iwilcox: Add to Category:Haskell

BitsOfProof "supernode"

2014-03-29T02:56:16Z

Iwilcox: Add to Java category, add {{stub}}

{{stub}}
[https://bitsofproof.com/ BitsOfProof]'s (BOP's) "supernode" is a Java implementation written by [https://bitsofproof.com/?page_id=142 Tamás Blummer (aka <tt>grau</tt>)]. The "Enterprise" version is closed-source, but [https://github.com/bitsofproof/supernode/commit/95629eb67db443b01b81b6ca9a3c62c230ddee7e may be open-sourced later]. The API and (in older commits) the deprecated "Community Edition" code is available [https://github.com/bitsofproof/supernode on github].

Tamas describes supernode as:
* enterprise ready
* a modern, modular implementation of Bitcoin
* having advanced features:
** Hierarchical and Deterministic Wallet (BIP32)
** Password Encrypted Private Keys (BIP38)
** easily memorized pass phrases (BIP39)

See also [https://bitcointalk.org/index.php?topic=122013.0 BOP's announcement thread on bitcointalk]. Explaining the "supernode" name, Tamas explained: "I call it supernode since it is for the big server of near future, not for the kids, not for the mobiles."

[[Category:Nodes]]
[[Category:Stubs]]
[[Category:Java]]

Haskoin

2014-03-29T02:54:17Z

Iwilcox: Add to Category:Haskell

{{stub}}
Haskoin is a Haskell implementation aiming for full-node features, by Philippe Laprade, available [https://github.com/plaprade/haskoin on github].

[[Category:Nodes]]
[[Category:Haskell]]

Protocoin

2014-03-29T02:53:32Z

Iwilcox: Add to Python category, add {{stub}}

{{stub}}
From its [http://protocoin.readthedocs.org/en/v0.1/ documentation]:

"Protocoin is pure Python implementation of the Bitcoin protocol parsing and networking. Protocoin doesn’t implement the protocol rules, only the serialization/deserialization procedures and also basic clients to interact with the Bitcoin P2P network.

Protocoin is intended to be used to build clients that will collect statistics of the network, but you can also use it to implement a full Bitcoin client."

Sources are [https://github.com/perone/protocoin on GitHub].

[[Category:Stubs]]
[[Category:Software]]
[[Category:Python]]

CoreBitcoin

2014-03-29T02:52:42Z

Iwilcox: Add to (non-existent) Category:Objective-C

{{stub}}
CoreBitcoin describes itself as "an implementation of [the] Bitcoin protocol in Objective-C. It's already a useful toolkit, but does not yet provide full node implementation."

It is missing block storage and P2P, but aims to add those features.

Sources are [https://github.com/oleganza/CoreBitcoin on GitHub].

[[Category:Software]]
[[Category:Stubs]]
[[Category:Objective-C]]

Caesure

2014-03-29T02:52:16Z

Iwilcox: Add to Python category.

{{stub}}
Caesure is a Python implementation aiming for full-node features, by [http://www.nightmare.com/~rushing/ Sam Rushing], available [https://github.com/samrushing/caesure on github].

[[Category:Nodes]]
[[Category:Stubs]]
[[Category:Python]]

Caesure

2014-03-29T02:51:47Z

Iwilcox: Add to stubs category.

CoreBitcoin

2014-03-29T02:48:26Z

Iwilcox: Created page with "CoreBitcoin describes itself as "an implementation of [the] Bitcoin protocol in Objective-C. It's already a useful toolkit, but does not yet provide full node implementation."..."

CoreBitcoin describes itself as "an implementation of [the] Bitcoin protocol in Objective-C. It's already a useful toolkit, but does not yet provide full node implementation."

It is missing block storage and P2P, but aims to add those features.

Sources are [https://github.com/oleganza/CoreBitcoin on GitHub].

[[Category:Software]]
[[Category:Stubs]]

Protocoin

2014-03-29T02:45:08Z

Iwilcox: Created page with "From its [http://protocoin.readthedocs.org/en/v0.1/ documentation]: "Protocoin is pure Python implementation of the Bitcoin protocol parsing and networking. Protocoin doesn..."

From its [http://protocoin.readthedocs.org/en/v0.1/ documentation]:

"Protocoin is pure Python implementation of the Bitcoin protocol parsing and networking. Protocoin doesn’t implement the protocol rules, only the serialization/deserialization procedures and also basic clients to interact with the Bitcoin P2P network.

Protocoin is intended to be used to build clients that will collect statistics of the network, but you can also use it to implement a full Bitcoin client."

Sources are [https://github.com/perone/protocoin on GitHub].

[[Category:Stubs]]
[[Category:Software]]

Category:Nodes

2014-03-29T02:39:28Z

Iwilcox: Add "See Also"

Category:Software

2014-03-29T02:37:24Z

Iwilcox: /* See Also */ Add Category:Nodes

Software that is related to Bitcoin.

==See Also==

* [[:Category:Clients|Clients]]
* [[:Category:Frontends|Frontends]]
* [[:Category:Developer|Developer]]
* [[:Category:Nodes|Nodes]]

[[Category:Main category]]

BitsOfProof "supernode"

2014-03-28T15:28:00Z

Iwilcox: Mark stub

[https://bitsofproof.com/ BitsOfProof]'s (BOP's) "supernode" is a Java implementation written by [https://bitsofproof.com/?page_id=142 Tamás Blummer (aka <tt>grau</tt>)]. The "Enterprise" version is closed-source, but [https://github.com/bitsofproof/supernode/commit/95629eb67db443b01b81b6ca9a3c62c230ddee7e may be open-sourced later]. The API and (in older commits) the deprecated "Community Edition" code is available [https://github.com/bitsofproof/supernode on github].

Tamas describes supernode as:
* enterprise ready
* a modern, modular implementation of Bitcoin
* having advanced features:
** Hierarchical and Deterministic Wallet (BIP32)
** Password Encrypted Private Keys (BIP38)
** easily memorized pass phrases (BIP39)

See also [https://bitcointalk.org/index.php?topic=122013.0 BOP's announcement thread on bitcointalk]. Explaining the "supernode" name, Tamas explained: "I call it supernode since it is for the big server of near future, not for the kids, not for the mobiles."

[[Category:Nodes]]
[[Category:Stubs]]

Category:Nodes

2014-03-28T00:27:58Z

Iwilcox:

BitsOfProof "supernode"

2014-03-28T00:26:20Z

Iwilcox: Created page with "[https://bitsofproof.com/ BitsOfProof]'s (BOP's) "supernode" is a Java implementation written by [https://bitsofproof.com/?page_id=142 Tamás Blummer (aka <tt>grau</tt>)]. Th..."

Haskoin

2014-03-27T23:21:07Z

Iwilcox: Created page with "Haskoin is a Haskell implementation aiming for full-node features, by Philippe Laprade, available [https://github.com/plaprade/haskoin on github]. Category:Nodes"

Haskoin is a Haskell implementation aiming for full-node features, by Philippe Laprade, available [https://github.com/plaprade/haskoin on github].

[[Category:Nodes]]

Bitcoin Wiki:Issue Tracker

2014-03-27T23:13:36Z

Iwilcox: /* Insert first issue here */

This page serves as the Wiki issue tracker.

To file a new issue, add a second-level heading (==), and describe your issue in detail.

Issue discussion should happen on the Talk page.

Do not delete resolved issues unless you are a wiki administrator, or the creator of the issue.

== Presented with SSL cert from another site ==

A few times on 2014-03-27, non-deterministically across a few pages, I got the typical "wrong SSL cert" warning from Firefox, saying I'd been delivered the cert for '''kitchensurfing.com''', issued the same day.

Caesure

2014-03-27T22:52:10Z

Iwilcox: Created page with "Caesure is a Python implementation aiming for full-node features, by [http://www.nightmare.com/~rushing/ Sam Rushing], available [https://github.com/samrushing/caesure on gith..."

Caesure is a Python implementation aiming for full-node features, by [http://www.nightmare.com/~rushing/ Sam Rushing], available [https://github.com/samrushing/caesure on github].

[[Category:Nodes]]

Purecoin

2014-03-27T22:06:10Z

Iwilcox:

Purecoin is a Haskell full-node implementation, by [http://r6.ca/ Russell O'Connor], available [https://github.com/laanwj/Purecoin on github] (mirrored from darcs).

[[Category:Nodes]]

Purecoin

2014-03-27T22:05:23Z

Iwilcox: Created page with "Purecoin is a Haskell full-node implementation, by [http://r6.ca/ Russell O'Connor], available [https://github.com/laanwj/Purecoin on github] (mirrored from darcs). Categor..."

Purecoin is a Haskell full-node implementation, by [http://r6.ca/ Russell O'Connor], available [https://github.com/laanwj/Purecoin on github] (mirrored from darcs).

[[Category:Node]]

Faq

2014-03-25T12:53:35Z

Iwilcox: Add redirect to work around /wiki/FAQ bypassing MW, hopefully letting faq be linked as https://en.bitcoin.it/wiki/faq (as well as maybe generally helping guide lost sheep)

#REDIRECT [[FAQ]]

Help:FAQ

2014-03-25T12:22:50Z

Iwilcox: Touch to hopefully force recognition, because GET https://en.bitcoin.it/wiki/FAQ seems to be returning a 77-byte application/octet-stream redirect to https://www.mediawiki.org/wiki/Manual:FAQ

Here you will find answers to the most commonly asked questions.

== General ==
=== What is Bitcoin? ===
Bitcoin is a distributed peer-to-peer digital currency that can be transferred instantly and securely between any two people in the world. It's like electronic cash that you can use to pay friends or merchants.

=== What are bitcoins? ===
Bitcoins are the unit of currency of the Bitcoin system. A commonly used shorthand for this is “BTC” to refer to a price or amount (e.g. “100 BTC”).
There are such things as [[physical bitcoins]], but ultimately, a bitcoin is just a number associated with a [[Address|Bitcoin Address]]. A physical bitcoin is simply an object, such as a coin, with the number carefully embedded inside. See also an [[Introduction|easy intro]] to Bitcoin.

=== How can I get bitcoins? ===

There are a variety of ways to acquire bitcoins:
* You can buy bitcoins from [http://coinbase.com/ Coinbase] or [[File:BIPS.gif|20px|link=https://bipsmarket.com]] [https://bipsmarket.com BIPS Market].
* Accept bitcoins as payment for goods or services.
* The most common way to buy bitcoins are the [[Buying bitcoins|Bitcoin Exchanges]]
* There are several services where you can [[Buying_Bitcoins_(the_noob_version)|trade them]] for traditional currency.
* Find someone to trade cash for bitcoins in-person through a [https://en.bitcoin.it/wiki/Category:Directories local directory].
* Participate in a [[Pooled mining|mining pool]].
* If you have a lot of mining hardware, you can solo mine and attempt to create a new [[block]] (currently yields 25 bitcoins plus transaction fees).
* Visit sites that provide [[Trade#Free_Samples_and_Offers|free samples and offers]].
* Visit [http://wheretobuycryptocoins.com WhereToBuyCryptoCoins.com] to get a guide how to start with bitcoins and cryptocurrency in general. Shows a list of markets, faucets, exchanges, miner's pools and more.

===Does Bitcoin guarantee an influx of free money?===

Since Bitcoin is a new technology, what it is and how it works may be initially unclear. Bitcoin is sometimes presented as being one of three things:
<ol style="list-style-type: upper-alpha;">
<li>Some sort of online 'get-rich-quick' scam.</li>
<li>A loophole in the market economy, the installation of which guarantees a steady influx of cash.</li>
<li>A sure investment that will almost certainly yield a profit.</li>
</ol>
In fact, none of the above are true. Let's look at them independently.

;Is Bitcoin a 'get-rich-quick' scheme?
:If you've spent much time on the Internet, you've probably seen ads for many 'get-rich-quick' schemes. These ads usually promise huge profits for a small amounts of easy work. Such schemes are usually pyramid/matrix-style schemes that make money from their own employees and offer nothing of any real value. Most convince one to buy packages that will make them earn hundreds a day, which in fact have the buyer distribute more such ads, and make minute profits.

:Bitcoin is in no way similar to these schemes. Bitcoin doesn't promise windfall profits. There is no way for the developers to make money from your involvement or to take money from you. That bitcoins are nearly impossible to acquire without the owner's consent represents one of its greatest strengths. Bitcoin is an experimental, virtual currency that may succeed or may fail. None of its developers expect to get rich off of it.

:A more detailed answer to this question can be found [http://bitcointalk.org/?topic=7815.0 here].

;Will I make money by installing the client?
:Most people who use Bitcoin don't earn anything by doing so, and the default client has no built-in way to earn Bitcoins. A small minority of people with dedicated, high-performance hardware do earn some Bitcoins by "''mining''" (generating new bitcoins, see [[#What is mining?|What is mining?]]) with special software, but joining Bitcoin shouldn't be construed as being the road to riches. Most Bitcoin users get involved because they find the project conceptually interesting and don't earn anything by doing so. This is also why you won't find much speculation about the political or economic repercussions of Bitcoin anywhere on this site: Bitcoin developers owe their dedication to the project's intellectual yieldings more than to those of a monetary nature. Bitcoin is still taking its first baby steps; it may go on to do great things but right now it only has something to offer those chasing conceptually interesting projects or bleeding edge technology.

;As an investment, is Bitcoin a sure thing?
:Bitcoin is a new and interesting electronic currency, the value of which is not backed by any single government or organization. Like other currencies, it is worth something partly because people are willing to trade it for goods and services. Its exchange rate fluctuates continuously, and sometimes wildly. It lacks wide acceptance and is vulnerable to manipulation by parties with modest funding. Security incidents such as website and account compromise may trigger major sell-offs. Other fluctuations can build into positive feedback loops and cause much larger exchange rate fluctuations. Anyone who puts money into Bitcoin should understand the risk they are taking and consider it a high-risk currency. Later, as Bitcoin becomes better known and more widely accepted, it may stabilize, but for the time being it is unpredictable. Any investment in Bitcoin should be done carefully and with a clear plan to manage the risk.

=== Can I buy bitcoins with Paypal? ===

It is possible to buy [[physical bitcoins]] with PayPal but it is otherwise difficult and/or expensive to do so for non-physical bitcoins, because of significant risk to the seller.

There is a [https://www.virwox.com?r=5495d workaround] that can be done in order to use Paypal to buy Bitcoins but it holds within it higher transaction fees. Using the [https://www.virwox.com?r=5495d Virtual World Exchange] you can buy Second Life Lindens (SLL) with Paypal and then convert your SLL to Bitcoins. This process will charge you transaction fees of around 6% but will let you purchase Bitcoins pretty quickly as opposed to a wire transfer. The reason this method works is because you do not buy Bitcoins with Paypal directly, you only buy SLL with Paypal (which is acceptable by Paypal's TOS) and then exchange your SLL to Bitcoin.

While it is possible to find an individual who wishes to sell Bitcoin to you via Paypal, (perhaps via [http://www.bitcoin-otc.com/ #bitcoin-otc] ) most exchanges do not allow funding through PayPal. This is due to repeated cases where someone pays for bitcoins with Paypal, receives their bitcoins, and then fraudulently complains to Paypal that they never received their purchase. PayPal often sides with the fraudulent buyer in this case, which means any seller needs to cover that risk with higher fees or refuse to accept PayPal altogether.

Buying Bitcoins from individuals this way is still possible, but requires the seller to have some trust that the buyer will not file a claim with PayPal to reverse the payment.

=== Where can I find a forum to discuss Bitcoin? ===

Please visit the [[Bitcoin:Community_portal#Bitcoin_Community_Forums_on_various_platforms|Community Portal]] for links to Bitcoin-related forums.

=== How are new bitcoins created? ===

New bitcoins are generated by the network through the process of "[[#What is mining?|''mining'']]". In a process that is similar to a continuous raffle draw, mining nodes on the network are awarded bitcoins each time they find the solution to a certain mathematical problem (and thereby create a new [[block]]). Creating a block is a [[proof of work]] with a difficulty that varies with the overall strength of the network. The reward for solving a block is [[Controlled Currency Supply|automatically adjusted]] so that, ideally, every four years of operation of the Bitcoin network, half the amount of bitcoins created in the prior 4 years are created. A maximum of {{formatnum:10499889.80231183}} bitcoins were created in the first 4 (approx.) years from January 2009 to November 2012. Every four years thereafter this amount halves, so it should be {{formatnum:5250000}} over years 4-8, {{formatnum:2625000}} over years 8-12, and so on. Thus the total number of bitcoins in existence can never exceed {{formatnum:20999839.77085749}} and counting. See [[Controlled Currency Supply]].

Blocks are [[Mining|mined]] every 10 minutes, on average and for the first four years ({{formatnum:210000}} blocks) each block included 50 new bitcoins. As the amount of processing power directed at mining changes, the difficulty of creating new bitcoins changes. This difficulty factor is calculated every 2016 blocks and is based upon the time taken to generate the previous 2016 blocks. See [[Mining]].

=== What's the current total number of bitcoins in existence? ===

[http://blockexplorer.com/q/totalbc Current count]. Also see [https://blockchain.info/charts/total-bitcoins Total bitcoins in circulation chart]

The number of blocks times the coin value of a block is the number of coins in existence. The coin value of a block is 50 BTC for each of the first {{formatnum:210000}} blocks, 25 BTC for the next {{formatnum:210000}} blocks, then 12.5 BTC, 6.25 BTC and so on.

=== How divisible are bitcoins? ===

A bitcoin can be divided down to 8 decimal places. Therefore, 0.00000001 BTC is the smallest amount that can be handled in a transaction. If necessary, the protocol and related software can be modified to handle even smaller amounts.

=== What do I call the various denominations of bitcoin? ===

There is a lot of discussion about the naming of these fractions of bitcoins. The leading candidates are:

* 1 BTC = 1 bitcoin
* 0.01 BTC = 1 cBTC = 1 centibitcoin (also referred to as bitcent)
* 0.001 BTC = 1 mBTC = 1 millibitcoin (also referred to as mbit (pronounced em-bit) or millibit or even bitmill)
* 0.000 001 BTC = 1 μBTC = 1 microbitcoin (also referred to as ubit (pronounced yu-bit) or microbit)

The above follows the accepted international SI prefixes for hundredths, thousandths, and millionths. There are many arguments against the special case of 0.01 BTC since it is unlikely to represent anything meaningful as the Bitcoin economy grows (it certainly won't be the equivalent of 0.01 USD, GBP or EUR). Equally, the inclusion of existing national currency denominations such as "cent", "nickel", "dime", "pence", "pound", "kopek" and so on are to be discouraged; this is a worldwide currency.

One exception is the "satoshi" which is smallest denomination currently possible

* 0.000 000 01 BTC = 1 satoshi (pronounced sa-toh-shee)
which is so named in honour of Satoshi Nakamoto, the pseudonym of the inventor of Bitcoin.

For an overview of all defined units of Bitcoin (including less common and niche units), see [[Units]].

Further discussion on this topic can be found on the forums here:

* [https://bitcointalk.org/index.php?topic=14438.msg195287#msg195287 We need names]
* [https://bitcointalk.org/index.php?topic=8282.0 What to call 0.001 BTC]

=== How does the halving work when the number gets really small? ===

Eventually the reward will go from 0.00000001 BTC to zero and no more bitcoins will be created.

The block reward calculation is done as a right bitwise shift of a 64-bit signed integer, which means it is divided by two and rounded down. The integer is equal to the value in BTC * 100,000,000 since internally in the reference client software, all Bitcoin balances and values are stored as unsigned integers.

With an initial block reward of 50 BTC, it will take many 4-year periods for the block reward to reach zero.

=== How long will it take to generate all the coins? ===

The last block that will generate coins will be block #6,929,999 which should be generated at or near the year 2140. The total number of coins in circulation will then remain static at 20,999,999.9769 BTC.

Even if the allowed precision is expanded from the current 8 decimals, the total BTC in circulation will always be slightly below 21 million (assuming everything else stays the same). For example, with 16 decimals of precision, the end total would be 20,999,999.999999999496 BTC.

=== If no more coins are going to be generated, will more blocks be created? ===

Absolutely! Even before the creation of coins ends, the use of [[transaction fee|transaction fees]] will likely make creating new blocks more valuable from the fees than the new coins being created. When coin generation ends, these fees will sustain the ability to use bitcoins and the Bitcoin network. There is no practical limit on the number of blocks that will be mined in the future.

=== But if no more coins are generated, what happens when Bitcoins are lost? Won't that be a problem? ===

Because of the law of supply and demand, when fewer bitcoins are available the ones that are left will be in higher demand, and therefore will have a higher value. So, as Bitcoins are lost, the remaining bitcoins will eventually increase in value to compensate. As the value of a bitcoin increases, the number of bitcoins required to purchase an item '''de'''creases. This is a [[Deflationary spiral|deflationary economic model]]. As the average transaction size reduces, transactions will probably be denominated in sub-units of a bitcoin such as millibitcoins ("Millies") or microbitcoins ("Mikes").

The Bitcoin protocol uses a base unit of one hundred-millionth of a Bitcoin ("a Satoshi"), but unused bits are available in the protocol fields that could be used to denote even smaller subdivisions.

=== If every transaction is broadcast via the network, does Bitcoin scale? ===
The Bitcoin protocol allows lightweight clients that can use Bitcoin without downloading the entire transaction history. As traffic grows and this becomes more critical, implementations of the concept will be developed. Full network nodes will at some point become a more specialized service.

With some modifications to the software, full Bitcoin nodes could easily keep up with both VISA and MasterCard combined, using only fairly modest hardware (a single high end server by todays standards). It is worth noting that the MasterCard network is structured somewhat like Bitcoin itself - as a peer to peer broadcast network.

Learn more about [[Scalability]].

==Economy==
=== Where does the value of Bitcoin stem from? What backs up Bitcoin? ===
Bitcoins have value because they are useful and because they are [[Controlled Currency Supply|scarce]]. As they are accepted by more merchants, their value will [http://en.wikipedia.org/wiki/Sticky_%28economics%29 stabilize]. See the [[Trade|list of Bitcoin-accepting sites]].

When we say that a currency is backed up by gold, we mean that there's a promise in place that you can exchange the currency for gold. Bitcoins, like dollars and euros, are not backed up by anything except the variety of merchants that accept them.

It's a common misconception that Bitcoins gain their value from the cost of electricity required to generate them. Cost doesn't equal value – hiring 1,000 men to shovel a big hole in the ground may be costly, but not valuable. Also, even though scarcity is a critical requirement for a useful currency, it alone doesn't make anything valuable. For example, your fingerprints are scarce, but that doesn't mean they have any exchange value.

Alternatively it needs to be added that while the law of supply and demand applies it does not guarantee value of Bitcoins in the future. If confidence in Bitcoins is lost then it will not matter that the supply can no longer be increased, the demand will fall off with all holders trying to get rid of their coins. An example of this can be seen in cases of state currencies, in cases when the state in question dissolves and so no new supply of the currency is available (the central authority managing the supply is gone), however the demand for the currency falls sharply because confidence in its purchasing power disappears. Of-course Bitcoins do not have such central authority managing the supply of the coins, but it does not prevent confidence from eroding due to other situations that are not necessarily predictable.

=== Is Bitcoin a bubble? ===
Yes, in the same way as the euro and dollar are. They only have value in exchange and have no inherent value. If everyone suddenly stopped accepting your dollars, euros or bitcoins, the "bubble" would burst and their value would drop to zero. But that is unlikely to happen: even in Somalia, where the government collapsed 20 years ago, [http://en.wikipedia.org/wiki/Somali_shilling Somali shillings] are still accepted as payment.

=== Is Bitcoin a Ponzi scheme? ===
In a Ponzi Scheme, the founders persuade investors that they’ll profit. Bitcoin does not make such a guarantee. There is no central entity, just individuals building an economy.

A ponzi scheme is a zero sum game. Early adopters can only profit at the expense of late adopters. Bitcoin has possible win-win outcomes. Early adopters profit from the rise in value. Late adopters, and indeed, society as a whole, benefit from the usefulness of a stable, fast, inexpensive, and widely accepted p2p currency.

The fact that early adopters benefit more doesn't alone make anything a Ponzi scheme. All good investments in successful companies have this quality.

=== Doesn't Bitcoin unfairly benefit early adopters? ===
Early adopters in Bitcoin are taking a risk and invested resources in an unproven technology. By so doing, they help Bitcoin become what it is now and what it will be in the future (hopefully, a ubiquitous decentralized digital currency). It is only fair they will reap the benefits of their successful investment.

In any case, any bitcoin generated will probably change hands dozens of time as a medium of exchange, so the profit made from the initial distribution will be insignificant compared to the total commerce enabled by Bitcoin. Many of the earliest users of Bitcoin have traded their coins at valuations below $1 US, or other amounts which are small compared to contemporary prices.

===Won't loss of wallets and the finite amount of Bitcoins create excessive deflation, destroying Bitcoin? ===
Worries about Bitcoin being destroyed by deflation are not entirely unfounded. Unlike most currencies, which experience inflation as their founding institutions create more and more units, Bitcoin will likely experience gradual deflation with the passage of time. Bitcoin is unique in that only a small amount of units will ever be produced (twenty-one million to be exact), this number has been known since the project's inception, and the units are created at a predictable rate.

Also, Bitcoin users are faced with a danger that doesn't threaten users of any other currency: if a Bitcoin user loses his wallet, his money is gone forever, unless he finds it again. And not just to him; it's gone completely out of circulation, rendered utterly inaccessible to anyone. As people will lose their wallets, the total number of Bitcoins will slowly decrease.

Therefore, Bitcoin seems to be faced with a unique problem. Whereas most currencies inflate over time, Bitcoin will mostly likely do just the opposite. Time will see the irretrievable loss of an ever-increasing number of Bitcoins. An already small number will be permanently whittled down further and further. And as there become fewer and fewer Bitcoins, the laws of supply and demand suggest that their value will probably continually rise.

Thus Bitcoin is bound to once again stray into mysterious territory, because no one exactly knows what happens to a currency that grows continually more valuable. Many economists claim that a low level of inflation is a good thing for a currency, but nobody is quite sure about what might happens to one that continually deflates. Although deflation could hardly be called a rare phenomenon, steady, constant deflation is unheard of. There may be a lot of speculation, but no one has any hard data to back up their claims.

That being said, there is a mechanism in place to combat the obvious consequences. Extreme deflation would render most currencies highly impractical: if a single Canadian dollar could suddenly buy the holder a car, how would one go about buying bread or candy? Even pennies would fetch more than a person could carry. Bitcoin, however, offers a simple and stylish solution: infinite divisibility. Bitcoins can be divided up and trade into as small of pieces as one wants, so no matter how valuable Bitcoins become, one can trade them in practical quantities.

In fact, infinite divisibility should allow Bitcoins to function in cases of extreme wallet loss. Even if, in the far future, so many people have lost their wallets that only a single Bitcoin, or a fraction of one, remains, Bitcoin should continue to function just fine. No one can claim to be sure what is going to happen, but deflation may prove to present a smaller threat than many expect.

For more information, see the [[Deflationary spiral]] page.

=== What if someone bought up all the existing Bitcoins? ===
Bitcoin markets are competitive -- meaning the price of a bitcoin will rise or fall depending on supply and demand at certain price levels. Only a fraction of bitcoins issued to date are found on the exchange markets for sale. So even though technically, a buyer with lots of money could buy all the bitcoins offered for sale, unless those holding the rest of the bitcoins offer them for sale as well, even the wealthiest, most determined buyer can't get at them.

Additionally, new currency continues to be issued daily and will continue to do so for decades; though over time the rate at which they are issued declines to insignificant levels. Those who are mining aren't obligated to sell their bitcoins so not all bitcoins will make it to the markets even.

This situation doesn't suggest, however, that the markets aren't vulnerable to price manipulation. It doesn't take significant amounts of money to move the market price up or down, and thus Bitcoin remains a volatile asset.

===What if someone creates a new block chain, or a new digital currency that renders Bitcoin obsolete?===

That the block chain cannot be easily forked represents one of the central security mechanisms of Bitcoin. Given the choice between two block chains, a Bitcoin miner always chooses the longer one - that is to say, the one with the more complex hash. Thusly, it ensures that each user can only spend their bitcoins once, and that no user gets ripped off.

As a consequence of the block chain structure, there may at any time be many different sub-branches, and the possibility always exists of a transaction being over-written by the longest branch, if it has been recorded in a shorter one. The older a transaction is though, the lower its chances of being over-written, and the higher of becoming permanent. Although the block chain prevents one from spending more Bitcoins than one has, it means that transactions can be accidentally nullified.

A new block chain would leave the network vulnerable to [[double-spending|double-spend]] attacks. However, the creation of a viable new chain presents considerable difficulty, and the possibility does not present much of a risk.

Bitcoin will always choose the longer Block Chain and determines the relative length of two branches by the complexities of their hashes. Since the hash of each new block is made from that of the block preceding it, to create a block with a more complex hash, one must be prepared to do more computation than has been done by the entire Bitcoin network from the fork point up to the newest of the blocks one is trying to supersede. Needless to say, such an undertaking would require a very large amount of processing power and since Bitcoin is continually growing and expanding, it will likely only require more with the passage of time.

A much more distinct and real threat to the Bitcoin use is the development of other, superior virtual currencies, which could supplant Bitcoin and render it obsolete and valueless.

A great deal of careful thought and ingenuity has gone into the development of Bitcoin, but it is the first of its breed, a prototype, and vulnerable to more highly-evolved competitors. At present, any threatening rivals have yet to rear their heads; Bitcoin remains the first and foremost private virtual currency, but we can offer no guarantees that it will retain that position. It would certainly be in keeping with internet history for a similar system built from the same principles to supersede and cast Bitcoin into obsolescence, after time had revealed its major shortcomings. Friendster and Myspace suffered similar fates at the hand of Facebook, Napster was ousted by Limeware, Bearshare and torrent applications, and Skype has all but crushed the last few disciples of the Microsoft Messenger army.

This may sound rather foreboding, so bear in mind that the introduction of new and possibly better virtual currencies will not necessarily herald Bitcoin's demise. If Bitcoin establishes itself sufficiently firmly before the inception of the next generation of private, online currencies so as to gain widespread acceptance and general stability, future currencies may pose little threat even if they can claim superior design. This is known as the network effect.

=== Is Bitcoin open to value manipulation? ===

The current low market cap of Bitcoin means that any investor with deep enough pockets can significantly change/manipulate the rate. Is this a problem?

This is only a problem if you are investing in Bitcoin for short period of time. A manipulator can't change the fundamentals, and over a period of 5-10 years, the fundamentals will win over any short term manipulations.

==Sending and Receiving Payments==

=== Why do I have to wait 10 minutes before I can spend money I received? ===

10 minutes is the average time taken to find a block. It can be significantly more or less time than that depending on luck; 10 minutes is simply the average case.

[[Blocks]] (shown as "confirmations" in the GUI) are how the Bitcoin achieves consensus on who owns what. Once a block is found everyone agrees that you now own those coins, so you can spend them again. Until then it's possible that some network nodes believe otherwise, if somebody is attempting to defraud the system by reversing a transaction. The more confirmations a transaction has, the less risk there is of a reversal. Only 6 blocks or 1 hour is enough to make reversal computationally impractical. This is dramatically better than credit cards which can see chargebacks occur up to three months after the original transaction!

Ten minutes was specifically chosen by [[Satoshi]] as a tradeoff between first confirmation time and the amount of work wasted due to chain splits. After a block is mined, it takes time for other miners to find out about it, and until then they are actually competing against the new block instead of adding to it. If someone mines another new block based on the old block chain, the network can only accept one of the two, and all the work that went into the other block gets wasted. For example, if it takes miners 1 minute on average to learn about new blocks, and new blocks come every 10 minutes, then the overall network is wasting about 10% of its work. Lengthening the time between blocks reduces this waste.

As a thought experiment, what if the Bitcoin network grew to include Mars? From the farthest points in their orbits, it takes about 20 minutes for a signal to travel from Earth to Mars. With only 10 minutes between new blocks, miners on Mars would always be 2 blocks behind the miners on Earth. It would be almost impossible for them to contribute to the block chain. If we wanted collaborate with those kinds of delays, we would need at least a few hours between new blocks.

[[File:TransactionConfirmationTimesExample.PNG]]

=== Do you have to wait until my transactions are confirmed in order to buy or sell things with Bitcoin? ===

YES, you do, IF the transaction is non-recourse. The Bitcoin reference software does not display transactions as confirmed until six blocks have passed (confirmations). As transactions are buried in the chain they become increasingly non-reversible but are very reversible before the first confirmation. Two to six confirmations are recommended for non-recourse situations depending on the value of the transactions involved.

When people ask this question they are usually thinking about applications like supermarkets. This generally is a recourse situation: if somebody tries to double-spend on a face-to-face transaction it might work a few times, but probabalistically speaking eventually one of the double-spends will get noticed, and the penalty for shoplifting charges in most localities is calibrated to be several times worse than the proceeds of a single shoplifting event.

Double-spends might be a concern for something like a snack machine in a low-traffic area with no nearby security cameras. Such a machine shouldn't honor zero-confirmation payments, and should instead use some other mechanism of clearing Bitcoin or validating transactions against reversal, see the wiki article [[Myths#Point_of_sale_with_bitcoins_isn.27t_possible_because_of_the_10_minute_wait_for_confirmation|here]] for alternatives.

Applications that require immediate payment processing, like supermarkets or snack machines, need to manage the risks. Here is one way to reverse an unconfirmed payment:

A [[Double-spending#Finney_attack|Finney attack]] is where an attacker mines a block containing a movement of some coins back to themselves. Once they find a block solution, they quickly go to a merchant and make a purchase, then broadcast the block, thus taking back the coins. This attack is a risk primarily for goods that are dispatched immediately, like song downloads or currency trades. Because the attacker can't choose the time of the attack, it isn't a risk for merchants such as supermarkets where you can't choose exactly when to pay (due to queues, etc). The attack can fail if somebody else finds a block containing the purchasing transaction before you release your own block, therefore, merchants can reduce but not eliminate the risk by making purchasers wait some length of time that's less than a confirm.

Because pulling off this attack is not trivial, merchants who need to sell things automatically and instantly are most likely to adjust the price to include the cost of reversal fraud, or elect to use special insurance.

=== I was sent some bitcoins and they haven't arrived yet! Where are they? ===

Don't panic! There are a number of reasons why your bitcoins might not show up yet, and a number of ways to diagnose them.

The latest version of the Bitcoin-Qt client tells you how far it has yet to go in downloading the blockchain. Hover over the icon in the bottom right corner of the client to learn your client's status.

If it has not caught up then it's possible that your transaction hasn't been included in a block yet.

You can check pending transactions in the network by going [https://www.biteasy.com here] or [http://blockchain.info here] and then searching for your address. If the transaction is listed here then it's a matter of waiting until it gets included in a block before it will show in your client.

If the transaction is based on a coin that was in a recent transaction then it could be considered a low priority transaction. Transfers can take longer if the transaction fee paid was not high enough. If there is no fee at all the transfer can get a very low priority and take hours or even days to be included in a block.

=== Why does my Bitcoin address keep changing? ===

Unlike postal or email addresses, Bitcoin addresses are single-use.
This means that whenever you want to receive a payment, you need to generate a new address.

While it is technically possible to receive coins multiple times with a single address, this compromises your wallet's security as well as the privacy of the entire Bitcoin network, and also makes it impossible to know for certain who sent the coins or why.

===How much will the transaction fee be?===

Some transactions might require a [[transaction fee]] for them to get confirmed in a timely manner. The transaction fee is processed by and received by the bitcoin miner. The most recent version of the Bitcoin client will estimate an appropriate fee when a fee might be required.

The fee is added to the payment amount. For example, if you are sending a 1.234 BTC payment and the client requires a 0.0005 BTC fee, then 1.2345 BTC will be subtracted from the wallet balance for the entire transaction and the address for where the payment was sent will receive a payment of 1.234 BTC.

A fee might be imposed because your transaction looks like a denial of service attack to the Bitcoin system. For example, it might be burdensome to transmit or it might recycle Bitcoins you recently received. The wallet software attempts to avoid generating burdensome transactions, but it isn't always able to do so: The funds in your wallet might be new or composed of many tiny payments.

Because the fee is related to the amount of data that makes up the transaction and not to the amount of Bitcoins being sent, the fee may seem extremely low (0.0005 BTC for a 1,000 BTC transfer) or unfairly high (0.004 BTC for a 0.02 BTC payment, or about 20%). If you are receiving tiny amounts (''e.g.'' as small payments from a mining pool) then fees when sending will be higher than if your activity follows the pattern of conventional consumer or business transactions.

As of Bitcoin 0.5.3 the required fee will not be higher than 0.05 BTC. For most users there is usually no required fee at all. If a fee is required it will most commonly be 0.0005 BTC.

=== What happens when someone sends me a bitcoin but my computer is powered off? ===

Bitcoins are not actually "sent" to your wallet; the software only uses that term so that we can use the currency without having to learn new concepts. Your wallet is only needed when you wish to spend coins that you've received.

If you are sent coins when your wallet client program is not running, and you later launch the wallet client program, the coins will eventually appear as if they were just received in the wallet. That is to say, when the client program is started it must download blocks and catch up with any transactions it did not already know about.

=== How long does "synchronizing" take when the Bitcoin client is first installed? What's it doing? ===

The popular Bitcoin client software from bitcoin.org implements a "full" Bitcoin node: It can carry out all the duties of the Bitcoin P2P system, it isn't simply a "client". One of the principles behind the operation of full Bitcoin nodes is that they don't assume that the other participants have followed the rules of the Bitcoin system. During synchronization, the software is processing historical Bitcoin transactions and making sure for itself that all of the rules of the system have been correctly followed.

In normal operation, after synchronizing, the software should use a hardly noticeable amount of your computer's resources.

When the wallet client program is first installed, its initial validation requires a lot of work from your computer's hard disk, so the amount of time to synchronize depends on your disk speed and, to a lesser extent, your CPU speed. It can take anywhere from a few hours to a day or so. On a slow computer it could take more than 40 hours of continuous synchronization, so check your computer's power-saving settings to ensure that it does not turn its hard disk off when unattended for a few hours. You can use the Bitcoin software during synchronization, but you may not see recent payments to you until the client program has caught up to the point where those transactions happened.

If you feel that this process takes too long, you can download a pre-synchronized blockchain from [http://eu2.bitcoincharts.com/blockchain/ http://eu2.bitcoincharts.com/blockchain/]. Alternatively, you can try an alternative "lite" client such as Multibit or a super-light client like electrum, though these clients have somewhat weaker security, are less mature, and don't contribute to the health of the P2P network.

==Networking==
=== Do I need to configure my firewall to run Bitcoin? ===

Bitcoin will connect to other nodes, usually on TCP port 8333. You will need to allow outgoing TCP connections to port 8333 if you want to allow your Bitcoin client to connect to many nodes. [[Testnet]] uses TCP port 18333 instead of 8333.

If you want to restrict your firewall rules to a few IPs, you can find stable nodes in the [[Fallback Nodes|fallback nodes list]].

=== How does the peer finding mechanism work? ===

Bitcoin finds peers primarily by forwarding peer announcements within its own network and each node saves a database of peers that it's aware of, for future use. In order to bootstrap this process Bitcoin needs a list of initial peers, these can be provided manually but normally it obtains them by querying a set of DNS domain names which have automatically updated lists, if that doesn't work it falls back to a built-in list which is updated from time to time in new versions of the software. In the reference software initial peers can also be specified manually by adding an addr.txt to the data directory or via the addnode parameter.

==Mining==
===What is mining?===
[[Mining]] is the process of spending computation power to secure Bitcoin transactions against reversal and introducing new Bitcoins to the system.

Technically speaking, mining is the calculation of a [[hash]] of the a block header, which includes among other things a reference to the previous block, a hash of a set of transactions and a [[nonce]]. If the hash value is found to be less than the current [[target]] (which is inversely proportional to the [[difficulty]]), a new block is formed and the miner gets the newly generated Bitcoins (25 per block at current levels). If the hash is not less than the current target, a new nonce is tried, and a new hash is calculated. This is done millions of times per second by each miner.

===Is mining used for some useful computation?===
The computations done when mining are internal to Bitcoin and not related to any other distributed computing projects. They serve the purpose of securing the Bitcoin network, which is useful.

===Is it not a waste of energy?===
Spending energy on creating and securing a free monetary system is hardly a waste. Also, services necessary for the operation of currently widespread monetary systems, such as banks and credit card companies, also spend energy, arguably more than Bitcoin would.

===Why don't we use calculations that are also useful for some other purpose?===
To provide security for the Bitcoin network, the calculations involved need to have some [http://bitcoin.stackexchange.com/questions/5617/why-are-bitcoin-calculation-useless/5618#5618 very specific features]. These features are incompatible with leveraging the computation for other purposes.

===How can we stop miners from creating zero transaction blocks?===
The incentive for miners to include transactions is in the fees that come along with them. If we were to implement some minimum number of transactions per block it would be trivial for a miner to create and include transactions merely to surpass that threshold. As the network matures, the block reward drops, and miners become more dependent on transactions fees to pay their costs, the problem of zero transaction blocks should diminish over time.

===How does the proof-of-work system help secure Bitcoin?===
Bitcoin uses the [[Hashcash]] proof of work with a minor adaption. To give a general idea of the mining process, imagine this setup:

payload = <some data related to things happening on the Bitcoin network>
nonce = 1
hash = [http://en.wikipedia.org/wiki/SHA2 SHA2]( [http://en.wikipedia.org/wiki/SHA2 SHA2]( payload + nonce ) )

The work performed by a miner consists of repeatedly increasing "nonce" until
the hash function yields a value, that has the rare property of being below a certain
target threshold. (In other words: The hash "starts with a certain number of zeroes",
if you display it in the fixed-length representation, that is typically used.)

As can be seen, the mining process doesn't compute anything special. It merely
tries to find a number (also referred to as nonce) which - in combination with the payload -
results in a hash with special properties.

The advantage of using such a mechanism consists of the fact, that it is very easy to check a result: Given the payload and a specific nonce, only a single call of the hashing function is needed to verify that the hash has the required properties. Since there is no known way to find these hashes other than brute force, this can be used as a "proof of work" that someone invested a lot of computing power to find the correct nonce for this payload.

This feature is then used in the Bitcoin network to secure various aspects. An attacker
that wants to introduce malicious payload data into the network, will need to do the
required proof of work before it will be accepted. And as long as honest miners have more
computing power, they can always outpace an attacker.

Also see [http://en.wikipedia.org/wiki/Hashcash Hashcash] and [http://en.wikipedia.org/wiki/Proof-of-work_system Proof-of-work system] and [http://en.wikipedia.org/wiki/SHA2 SHA2] and on Wikipedia.

===Why was the "Generate coin" option of the client software removed?===

The option wasn't removed, but it is now only accessible via the command-line or the configuration file. The reason for this is that many users were complaining after they turned on and expecting to receive coins. Without specialized mining hardware a user is exceptionally unlikely generate a block on their own at the network's current [[difficulty|security level]].

==Security==

===Could miners collude to give themselves money or to fundamentally change the nature of Bitcoin?===

There are two questions in here. Let's look at them separately.

;Could miners gang up and give themselves money?

Mining itself is the process of creating new blocks in the block chain. Each block contains a list of all the transactions that have taken place across the entire Bitcoin network since the last block was created, as well as a hash of the previous block. New blocks are 'mined', or rather, generated, by Bitcoin clients correctly guessing sequences of characters in codes called 'hashes,' which are created using information from previous blocks. Bitcoin users may download specialized 'mining' software, which allows them to dedicate some amount of their processing power – however large or small – to guessing at strings within the hash of the previous block. Whoever makes the right guess first, thus creating a new block, receives a reward in Bitcoins.

The block chain is one of the two structures that makes Bitcoin secure, the other being the public-key encryption system on which Bitcoin trade is based. The block chain assures that not only is every single transaction that ever takes place recorded, but that every single transaction is recorded on the computer of anyone who chooses to store the relevant information. Many, many users have complete records of every transaction in Bitcoins history readily available to them at any point, and anyone who wants in the information can obtain it with ease. These things make Bitcoin very hard to fool.

The Bitcoin network takes considerable processing power to run, and since those with the most processing power can make the most guesses, those who put the most power toward to sustaining the network earn the most currency. Each correct guess yields, at present, twenty-five Bitcoins, and as Bitcoins are presently worth something (although the value still fluctuates) every miner who earns any number of Bitcoins makes money. Some miners pull in Bitcoins on their own; and some also join or form pools wherein all who contribute earn a share of the profits.

Therefore, first answer is a vehement “yes” – not only can miners collude to get more money, Bitcoin is designed to encourage them to do so. Bitcoin pools are communal affairs, and there is nothing dishonest or underhanded about them.

Of course, the real question is:

;Can they do so in ways not sanctioned by Bitcoin network? Is there any way to rip off the network and make loads of money dishonestly?

Bitcoin isn't infallible. It can be cheated, but doing so is extremely difficult. Bitcoin was designed to evade some of the central problems with modern currencies – namely, that their trustworthiness hinges upon that of people who might not have users' best interests in mind. Every currency in the world (other than Bitcoin) is controlled by large institutions who keep track of what's done with it, and who can manipulate its value. And every other currency has value because people trust the institutions that control them.

Bitcoin doesn't ask that its users trust any institution. Its security is based on the cryptography that is an integral part of its structure, and that is readily available for any and all to see. Instead of one entity keeping track of transactions, the entire network does, so Bitcoins are astoundingly difficult to steal, or double-spend. Bitcoins are created in a regular and predictable fashion, and by many different users, so no one can decide to make a whole lot more and lessen their value. In short, Bitcoin is designed to be inflation-proof, double-spend-proof and completely distributed.

Nonetheless, there are a few ways that one can acquire Bitcoins dishonestly. Firstly, one can steal private keys. Key theft isn't something that Bitcoin security has been designed to prevent: it's up to users to keep their keys safe. But the cryptography is designed so that it is completely impossible to deduce someone's private key from their public one. As long as you keep your private key to yourself, you don't have much to worry about. Furthermore, one could theoretically create a new block chain, but due to the way in which the block chain is constructed, this would be extremely difficult and require massive amounts of processing power. A full explanation of the difficulties involved can be found in the [[block chain]] article.

Bitcoin can be ripped off – but doing so would be extremely hard and require considerable expertise and a staggering amount of processing power. And it's only going to get harder with time. Bitcoin isn't impenetrable, but it's close enough to put any real worries in the peripherals.

;Could miners fundamentally change the nature of Bitcoin?

Once again, almost certainly not.

Bitcoin is a distributed network, so any changes implemented to the system must be accepted by all users. Someone trying to change the way Bitcoins are generated would have to convince every user to download and use their software – so the only changes that would go through are those that would be equally benefit all users.

And thus, it is more or less impossible for anyone to change the function of Bitcoin to their advantage. If users don't like the changes, they won't adopt them, whereas if users do like them, then these will help everyone equally. Of course, one can conceive of a situation where someone manages to get a change pushed through that provides them with an advantage that no one notices, but given that Bitcoin is structurally relatively simple, it is unlikely that any major changes will go through without someone noticing first.

The fact that such changes are so difficult to make testifies to the fully distributed nature of Bitcoin. Any centrally controlled currency can be modified by its central agency without the consent of its adherents. Bitcoin has no central authority, so it changes only at the behest of the whole community. Bitcoins development represents a kind of collective evolution; the first of its kind among currencies.

==Help==
===I'd like to learn more. Where can I get help?===

* Read the [[Introduction|introduction to bitcoin]]
* See the videos, podcasts, and blog posts from the [[Press]]
* Read and post on the [[:Bitcoin:Community_portal#Bitcoin_Community_Forums|forums]]
* Chat on one of the [[:Bitcoin:Community_portal#IRC_Chat|Bitcoin IRC]] channels
* Listen to [http://omegataupodcast.net/2011/03/59-bitcoin-a-digital-decentralized-currency/ this podcast], which goes into the details of how bitcoin works
* Ask questions on the [http://bitcoin.stackexchange.com Bitcoin Stack Exchange]
* Use [http://wheretobuycryptocoins.com WhereToBuyCryptocoins]. It shows an cryptocurrency introduction, a getting started guide for beginners, also lists of markets, faucets, exchanges.

==See Also==

* [[Man page]]
* [[Introduction]]

[[de:FAQ]]
[[zh-cn:FAQ]]
[[fr:FAQ]]
[[ru:FAQ]]

[[Category:Technical]]
[[Category:Vocabulary]]

FlaskWallet

2014-03-13T16:56:31Z

Iwilcox: Add to user interfaces category too.

A single-user web-based flask application to manage bitcoin (and altcoin) wallets/nodes, by [http://kuttler.eu/blog Nicolas Kuttler].

Code: https://github.com/nkuttler/flaskwallet

Full documentation: http://flaskwallet.readthedocs.org/en/latest/

[[Category:Frontends]]
[[Category:User Interfaces]]

FlaskWallet

2014-03-13T16:55:13Z

Iwilcox: Add nkuttler's FlaskWallet frontend

Original Bitcoin client/API calls list

2014-01-04T17:21:00Z

Iwilcox: /* Full list */ listsinceblock: link to bug about [confs] ignored. getmemorypool: Fix bold in description.

Bitcoin API call list (as of version 0.8.0)

== Common operations ==

=== Listing my bitcoin addresses ===

Listing the bitcoin [[address|addresses]] in your wallet is easily done via ''listreceivedbyaddress''. It normally lists only addresses which already have received transactions, however you can list all the addresses by setting the first argument to 0, and the second one to true.

[[accounts explained|Accounts]] are used to organize addresses.

== Full list ==

Required arguments are denoted inside < and > Optional arguments are inside [ and ].

{|class="wikitable"
! Command !! Parameters !! Description !! Requires unlocked wallet? (v0.4.0+)
|-
| addmultisigaddress || <nrequired> <'["key","key"]'> [account] || Add a nrequired-to-sign multisignature address to the wallet. Each key is a bitcoin address or hex-encoded public key. If [account] is specified, assign address to [account]. || N
|-
| addnode || <node> <add/remove/onetry> || '''version 0.8''' Attempts add or remove <node> from the addnode list or try a connection to <node> once. || N
|-
| backupwallet || <destination> || Safely copies wallet.dat to destination, which can be a directory or a path with filename. || N
|-
| createmultisig || <nrequired> <'["key,"key"]'> || Creates a multi-signature address and returns a json object ||
|-
| createrawtransaction || [{"txid":txid,"vout":n},...] {address:amount,...} || '''version 0.7''' Creates a [[Raw Transactions|raw transaction]] spending given inputs. || N
|-
| decoderawtransaction || <hex string> || '''version 0.7''' Produces a human-readable JSON object for a [[Raw Transactions|raw transaction]]. || N
|-
| dumpprivkey || <bitcoinaddress> || Reveals the private key corresponding to <bitcoinaddress> || Y
|-
| encryptwallet || <passphrase> || Encrypts the wallet with <passphrase>. || N
|-
| getaccount || <bitcoinaddress> || Returns the account associated with the given address. || N
|-
| getaccountaddress || <account> || Returns the current bitcoin address for receiving payments to this account. || N
|-
| getaddednodeinfo || <dns> [node] || '''version 0.8''' Returns information about the given added node, or all added nodes
(note that onetry addnodes are not listed here)
If dns is false, only a list of added nodes will be provided,
otherwise connected information will also be available.
|-
| getaddressesbyaccount || <account> || Returns the list of addresses for the given account. || N
|-
| getbalance || [account] [minconf=1] || If [account] is not specified, returns the server's total available balance.<br/>If [account] is specified, returns the balance in the account. || N
|-
| getbestblockhash || || '''recent git checkouts only''' Returns the hash of the best (tip) block in the longest block chain. || N
|-
| getblock || <hash> || Returns information about the block with the given hash. || N
|-
| getblockcount || || Returns the number of blocks in the longest block chain. || N
|-
| getblockhash || <index> || Returns hash of block in best-block-chain at <index>; index 0 is the [[genesis block]] || N
|-
| getblocknumber || || '''Deprecated'''. '''Removed in version 0.7'''. Use getblockcount. || N
|-
| getblocktemplate || [params] || Returns data needed to construct a block to work on. See [[ BIP_0022]] for more info on params.|| N
|-
| getconnectioncount || || Returns the number of connections to other nodes. || N
|-
| getdifficulty || || Returns the proof-of-work difficulty as a multiple of the minimum difficulty. || N
|-
| getgenerate || || Returns true or false whether bitcoind is currently generating hashes || N
|-
| gethashespersec || || Returns a recent hashes per second performance measurement while generating. || N
|-
| getinfo || || Returns an object containing various state info. || N
|-
| getmemorypool || [data] || '''Replaced in v0.7.0 with getblocktemplate, submitblock, getrawmempool''' || N
|-
| getmininginfo || || Returns an object containing mining-related information:
* blocks
* currentblocksize
* currentblocktx
* difficulty
* errors
* generate
* genproclimit
* hashespersec
* pooledtx
* testnet
|| N
|-
| getnewaddress || [account] || Returns a new bitcoin address for receiving payments. If [account] is specified (recommended), it is added to the address book so payments received with the address will be credited to [account]. || N
|-
| getpeerinfo || || '''version 0.7''' Returns data about each connected node. || N
|-
| getrawchangeaddress || [account]|| '''recent git checkouts only''' Returns a new Bitcoin address, for receiving change. This is for use with raw transactions, NOT normal use. || Y
|-
| getrawmempool || || '''version 0.7''' Returns all transaction ids in memory pool || N
|-
| getrawtransaction || <txid> [verbose=0] || '''version 0.7''' Returns [[Raw Transactions|raw transaction]] representation for given transaction id. || N
|-
| getreceivedbyaccount || [account] [minconf=1] || Returns the total amount received by addresses with [account] in transactions with at least [minconf] confirmations. If [account] not provided return will include all transactions to all accounts. (version 0.3.24) || N
|-
| getreceivedbyaddress || <bitcoinaddress> [minconf=1] || Returns the amount received by <bitcoinaddress> in transactions with at least [minconf] confirmations. It correctly handles the case where someone has sent to the address in multiple transactions. Keep in mind that addresses are only ever used for receiving transactions. Works only for addresses in the local wallet, external addresses will always show 0. || N
|-
| gettransaction || <txid> || Returns an object about the given transaction containing:
* "amount" : total amount of the transaction
* "confirmations" : number of confirmations of the transaction
* "txid" : the transaction ID
* "time" : time associated with the transaction<ref>From block timestamp, unless transaction was already in memory pool then the local time when the client added the transaction to its memory pool</ref>.
* "details" - An array of objects containing:
** "account"
** "address"
** "category"
** "amount"
** "fee"
|| N
|-
| gettxout || <txid> <n> [includemempool=true] || Returns details about an unspent transaction output (UTXO) || N
|-
| gettxoutsetinfo || || Returns statistics about the unspent transaction output (UTXO) set || N
|-
| [[getwork]] || [data] || If [data] is not specified, returns formatted hash data to work on:
* "midstate" : precomputed hash state after hashing the first half of the data
* "data" : block data
* "hash1" : formatted hash buffer for second hash
* "target" : little endian hash target
If [data] is specified, tries to solve the block and returns true if it was successful.
|| N
|-
| help || [command] || List commands, or get help for a command. || N
|-
| importprivkey || <bitcoinprivkey> [label] [rescan=true]|| Adds a private key (as returned by dumpprivkey) to your wallet. This may take a while, as a [[How_to_import_private_keys#Import_Private_key.28s.29|rescan]] is done, looking for existing transactions. '''Optional [rescan] parameter added in 0.8.0.''' || Y
|-
| keypoolrefill || || Fills the keypool, requires wallet passphrase to be set. || Y
|-
| listaccounts || [minconf=1] || Returns Object that has account names as keys, account balances as values. || N
|-
| listaddressgroupings || || '''version 0.7''' Returns all addresses in the wallet and info used for coincontrol. || N
|-
| listreceivedbyaccount || [minconf=1] [includeempty=false] || Returns an array of objects containing:
* "account" : the account of the receiving addresses
* "amount" : total amount received by addresses with this account
* "confirmations" : number of confirmations of the most recent transaction included
|| N
|-
| listreceivedbyaddress || [minconf=1] [includeempty=false] || Returns an array of objects containing:
* "address" : receiving address
* "account" : the account of the receiving address
* "amount" : total amount received by the address
* "confirmations" : number of confirmations of the most recent transaction included
To get a list of accounts on the system, execute bitcoind listreceivedbyaddress 0 true
|| N
|-
| listsinceblock|| [blockhash] [target-confirmations] || Get all transactions in blocks since block [blockhash], or all transactions if omitted. '''[target-confirmations] is [https://github.com/bitcoin/bitcoin/issues/1153 ignored (bug)] up to (at least) v0.8.5''' || N
|-
| listtransactions || [account] [count=10] [from=0] || Returns up to [count] most recent transactions skipping the first [from] transactions for account [account]. If [account] not provided will return recent transaction from all accounts.
|| N
|-
| listunspent || [minconf=1] [maxconf=999999] || '''version 0.7''' Returns array of unspent transaction inputs in the wallet. || N
|-
| listlockunspent || || '''version 0.8''' Returns list of temporarily unspendable outputs
|-
| lockunspent || <unlock?> [array-of-objects] || '''version 0.8''' Updates list of temporarily unspendable outputs
|-
| move || <fromaccount> <toaccount> <amount> [minconf=1] [comment] || Move from one account in your wallet to another || N
|-
| sendfrom || <fromaccount> <tobitcoinaddress> <amount> [minconf=1] [comment] [comment-to] || <amount> is a real and is rounded to 8 decimal places. Will send the given amount to the given address, ensuring the account has a valid balance using [minconf] confirmations. Returns the transaction ID if successful (not in JSON object). || Y
|-
| sendmany || <fromaccount> {address:amount,...} [minconf=1] [comment] || amounts are double-precision floating point numbers || Y
|-
| sendrawtransaction || <hexstring> || '''version 0.7''' Submits [[Raw Transactions|raw transaction]] (serialized, hex-encoded) to local node and network. || N
|-
| sendtoaddress || <bitcoinaddress> <amount> [comment] [comment-to] || <amount> is a real and is rounded to 8 decimal places. Returns the transaction ID <txid> if successful. || Y
|-
| setaccount || <bitcoinaddress> <account> || Sets the account associated with the given address. Assigning address that is already assigned to the same account will create a new address associated with that account. || N
|-
| setgenerate || <generate> [genproclimit] || <generate> is true or false to turn generation on or off.<br/>Generation is limited to [genproclimit] processors, -1 is unlimited. || N
|-
| settxfee || <amount> || <amount> is a real and is rounded to the nearest 0.00000001 || N
|-
| signmessage || <bitcoinaddress> <message> || Sign a message with the private key of an address. || Y
|-
| signrawtransaction || <hexstring> [{"txid":txid,"vout":n,"scriptPubKey":hex},...] [<privatekey1>,...] || '''version 0.7''' Adds signatures to a [[Raw Transactions|raw transaction]] and returns the resulting raw transaction. || Y/N
|-
| stop || || Stop bitcoin server. || N
|-
| submitblock || <hex data> [optional-params-obj] || Attempts to submit new block to network. || N
|-
| validateaddress || <bitcoinaddress> || Return information about <bitcoinaddress>. || N
|-
| verifymessage || <bitcoinaddress> <signature> <message> || Verify a signed message. || N
|-
| walletlock || || Removes the wallet encryption key from memory, locking the wallet. After calling this method, you will need to call walletpassphrase again before being able to call any methods which require the wallet to be unlocked. || N
|-
| walletpassphrase || <passphrase> <timeout> || Stores the wallet decryption key in memory for <timeout> seconds. || N
|-
| walletpassphrasechange || <oldpassphrase> <newpassphrase> || Changes the wallet passphrase from <oldpassphrase> to <newpassphrase>. || N

|}

==Error Codes==

See [https://github.com/bitcoin/bitcoin/blob/master/src/rpcprotocol.h#L34 rpcprotocol.h] for the list of error codes and their meanings.

==See Also==

* [[Original Bitcoin client]]
* [[Protocol specification]]
* [[API reference (JSON-RPC)]]
* [[Lazy_API]]
* [[Elis-API]] - A more detailed version of this page - for developers!
* [http://code.gogulski.com/bitcoin-php/class_bitcoin_client.html PHP BitcoinClient Class Reference]

==References==
<references />

[[Category:Technical]]
[[Category:Developer]]