Bitcoin Wiki - User contributions [en]

Bitcoin Church

2025-05-25T17:58:14Z

Calliptamus:

The '''Church of Bitcoin''' was founded on October 25th 2012 in order to grant [[Bitcoin]] users a non regional spiritual outlet and to escape oppression by existing religious groups. Its homepage may be at [http://bitprayer.com/ bitprayer.com]

The Church of Bitcoin is guided by eleven commandments:

# Praise Satoshi.
# Honor the blockchain.
# Thou shalt not fork thine own family.
# Keep the network holy.
# Thou should not covet another man's wallet.
# Do unto others as you would have them DDoS you.
# Thou shalt not swear unto another man that thine payment hath not been received until all of the blockchain hath been downloadeth.
# Salt thine passwords.
# Hack thine planet.
# Keep thine woman, [https://twitter.com/brucewagner Bruces] and [https://bitcointalk.org/index.php?topic=98695 Atlases] in separate camps if they are unclean.
# Troll harder.

[[Category:Satire]]

==See Also==
https://en.bitcoin.it/wiki/Church_of_Bitcoin

Bitcoin Core 0.11 (ch 1): Overview

2025-05-25T17:57:21Z

Calliptamus: /* Organization & Maintenance of these Pages */

==Organization & Maintenance of these Pages==

The purpose of this set of Wiki pages is to document the Bitcoin Core C++ source code, in a way that is helpful to the programmer who wants to learn how the program is designed and what the code does.

Ideally, the accuracy of the information on these pages would be checked by developers who are getting up to speed on the [[Bitcoin Core]] code base. Additionally, each new release of Bitcoin Core (0.12, 0.13, etc) could have a new set of pages that are modified to match that version.

These pages are loosely based on the set of pages called "Satoshi Client: xxx" (on this Wiki) which were written in 2011 and based on version 0.3.

This set of Wiki pages includes:

* Ch 1: Intro & Overview (this page)
* Ch 2: Data Storage
* Ch 3: Initialization & Startup
* Ch 4: P2P Network
* Ch 5: Initial Block Download (IBD)
* Ch 6: Blockchain
* Ch 7: Transactions & the Memory Pool
* Ch 8: RPC Server

These pages document the "relay node" aspect of Bitcoin Core, meaning a node which validates blocks and transactions and relays them to other nodes. The node has fully validated the blockchain, although it may not necessarily maintain a full copy of it on disk.

These pages do NOT cover:
* Wallet
* GUI (Qt)
* Mining

==Definitions==

A few definitions at the outset:

'''Consensus code'''

Code that validates blocks and transactions.

Consensus code must have bug-for-bug compatibility across versions and implementations (meaning, 0.12 must have the same consensus behaviour as 0.11, even if it is buggy; otherwise, a network fork may result.)

'''Policy code'''

Code that implements a particular node's policy (as opposed to consensus). A node's algorithm for which transactions to store in its transaction pool is an example of policy. For example, a node could refuse to relay or store any transaction that is larger than 200KB. What is important is that if such a transaction is transmitted to the node as part of a newly mined block, the node does not reject the block.

'''P2P code'''

Code relating to communications with other nodes (peers) over the P2P network. Communication includes discovering and connecting to other nodes; exchanging various P2P messages (e.g., messages containing blocks and transactions); occasionally, banning misbehaving peers. The bitcoin network uses a custom set of P2P messages. Most of the P2P code can be found in net.h/net.cpp.

'''Mempool ("memory pool" or "transaction pool")'''

A set of transactions which the node knows about and chooses to store in memory and relay to other nodes, and which have not yet been included in a block. In many cases, this may be the full set of transactions that the node has received and validated. If the node has received transactions that violate its policy, however, the mempool will be a subset. In any event, when the node receives and validates a block, it deletes any transactions in the block from its mempool.

'''Full Node'''

A full node is one that validates blocks and transactions and relays them to other nodes. A full node has validated the blockchain from scratch (although with block file pruning, it may have discarded older parts of the chain to clear up disk space.) The key characteristic of a full node is that it has validated the blockchain and continues to fully validate and relay incoming blocks and transactions. A full node can be differentiated from an SPV node, which trusts another node (or set of nodes) to validate.

'''"Basic Full Node"'''

A "basic full node" is what is documented in these pages. By "basic full node," what is meant is a node that validates and relays blocks and transactions, but does not mine new blocks or perform other optional tasks (RPC server, wallet). Extending these pages to include documentation of these optional aspects of a node is a future project.

==Architecture of a Bitcoin Node==

One developer described the architecture of a basic full node as follows:

: --------------------

: The basic architecture of a bitcoin node is as follows:

: At the core there exist fundamental bitcoin message structures, along with the code necessary for serialization/deserialization. These structures belong in their own source files with minimal dependencies so they can be reused for applications that needn't perform verification and relay - for instance, filtering and notification agents. Unfortunately, these core structures currently reside for the most part in main.h/main.cpp...

: On top of these core structures sits a network component that manages sockets, does peer discovery, and handles queueing and dispatching of messages. This component is clearly dependent on the core message structures but does not depend on the specific logic used to verify blocks and transactions nor to identify misbehaving peers nor sign transactions nor maintain a block chain database.

: Then we have a scripting engine, signature verification component, and a signing component. Historical database applications do not need signature verification/signing functionality at all. Filtering messages and sending alerts generally does not even require a scripting engine and does fine with basic pattern matching.

: The most critical high-level operations needed by a verification/relay node such as the satoshi client are transaction verification; block chain and memory pool management; and detection/management of misbehaving peers. These things are currently primarily implemented in main.h/main.cpp. These are indeed the main operations of the satoshi client - but the core low-level structures should not depend at all on this logic.

: ---------------------

See here: [https://github.com/bitcoin/bitcoin/pull/2154 PR 2154]

In the form of a (crude) picture:

Validating transactions; Managing blockchain, mempool, and peers.
|
Scripting engine / Signatures
|
Network layer
|
P2P Messages

And here is the same picture, augmented with the definitions above:

Validating transactions; Managing blockchain, mempool, peers (Consensus and Policy code)
|
Scripting engine / Signatures (Consensus code)
|
Network layer (P2P code)
|
P2P Messages

==Code Modularization / Organization==

As of 0.11, modularization of the Bitcoin Core code is somewhat limited.

Ideally, Bitcoin Core would be modularized so that the consensus code would be separated and made into a library which could be distributed to other implementations. In this way, fears of accidentally forking the network would be mitigated. As of 2016, this is work in progress (see, e.g., various "libconsensus" pull requests on GitHub.)

In December 2013, a proposal was made for modularizing the code base: [https://github.com/bitcoin/bitcoin/issues/3440 Post-0.9 modularization of Bitcoin Core]

Examples of optional modules would be:
* Miner
* Wallet
* Notifications

As of 0.11, the steps taken toward modularization were primarily separating certain classes into subdirectories, described below.

==Source Code Files==

The C++ code is in the src/ directory of the repository.

Most of the code resides in the top-level directory, although there has been some effort to modularize the code base with subdirectories (wallet, consensus, primitives, etc.) Also, certain components (QT, LevelDB, etc) live in subdirectories.

Key files in the src/ directory include: (file.* means the header file [file.h] and the source file [file.cpp])

{| class="wikitable"
|-
! File !! Description / Purpose
|-
| net.* || Manages the network (peer connections, etc.). The while(true) loop in ThreadMessageHandler controls the program's flow, signalling main.cpp when there is work to do. Key dependencies: None.
|-
| init.cpp || Initializes the node, calling functions in main.cpp as necessary. Key dependencies: main.h
|-
| main.* || main.h declares some key global variables (mapBlockIndex, chainActive, mempool, etc), constants, and functions. main.cpp is the program's longest source file (5,237 lines). main.cpp has most of the key functions for managing the blockchain, such as connecting, disconnecting, validating and storing blocks; identifying a certain block as the tip of the longest chain; and so forth. The "entry point" for most of the code is ProcessMessages (which listens for a signal from the message-handling thread.). Some of the code is run during initialization, called directly from init.cpp. Key dependencies: net.h
|-
| chain.* || The header file (chain.h) is the more notable of the two, as it declares the type definitions for the metadata about the block (CBlockIndex) and the longest blockchain (CChain). chain.cpp contains a few handy functions for managing the blockchain (e.g., locating blocks and finding a fork point between two chains.)
|-
| coins.* || The header file declares a CCoin, which is, conceptually, "a bitcoin." The source file contains methods for manipulating coins (retrieving, spending, etc.)
|-
| miner.* || Contains the mining code, including block creation and generating new bitcoins.
|-
|}

'''Subdirectories:'''

The subdirectories fall into three categories:
* Well-defined components (in some cases third-party)
* Modularization of code
* Other (unit tests, build files, etc.)

''Subdirectories - Components:''

{| class="wikitable"
|-
! Directory !! Description / Purpose
|-
| leveldb || C++ source code, docs, etc. for the LevelDB build.
|-
| qt || The GUI code (QT). QT is a C++ open-source project for GUI code, first released in 1995.
|-
| secp256k1 || Library implementing ECDSA cryptography. Purpose: This proprietary C library eliminates reliance on SSL for signature checking. This is important because SSL was susceptible to introducing consensus bugs, because newly released versions do not guarantee bug-for-bug compatibility. This library was written/released in early 2015.
|-
| zmq || From the ZMQ wiki: ZMQ (or ZeroMQ or 0MQ) is a high-performance asynchronous messaging library. It provides a message queue, but unlike message-oriented middleware, a ZMQ system can run without a dedicated message broker. The library is designed to have a familiar socket-style API.
|}

''Subdirectories - Modularization:''

{| class="wikitable"
|-
! Directory !! Key Files !! Description / Purpose
|-
| consensus || consensus.* merkle.* params.* validation.* || Code implementing (or defining, as the case may be) the block & transaction validation rules. Purpose: Moving this code into a subdirectory is a step towards modularizing the consensus code. The idea is that in a future version of bitcoin, the consensus code should be packaged as a library, so that alternative implementations of the protocol could simply include this library and guarantee validation compatibility. "...[T]he goal is not reimplementing the consensus rules but rather extract them from Bitcoin Core so that nobody needs to re-implement them again. It is not only exposing it but also separating it from Bitcoin Core so that they can be changed without having to also change/take into account non-consensus Bitcoin Core specific things." -- Jorge Timon, on bitcoin-development mailing list, 20 Aug 2015. Discussion on github: [https://github.com/bitcoin/bitcoin/issues/6714 PR6714]
|-
| crypto || ripemd.* sha256.* || Cryptographic hash functions. Both RIPEMD and SHA-256 are used in transforming a bitcoin address to Base-58 encoding.
|-
| policy || policy.* fees.* || Move validation code that is a matter of ''policy'' (as opposed to consensus) into a separate directory.
|-
| primitives || block.* transaction.* || Definitions of certain basic data types (blocks, transactions, etc.)
|-
| script || interpreter.* script.* standard.* || The script engine. Defines the op_codes (script.h). Parses and evaluates the validation script. (interpreter.cpp:EvalScript()) Defines what is a "standard" transaction (standard.h). Purpose: the Script engine validates basic transactions but also makes contracts possible.
|-
| wallet || wallet.* || Wallet code.
|}

''Subdirectories - Other:''

{| class="wikitable"
|-
! Directory !! Description / Purpose
|-
| compat || A few minor, low-level files dealing with compatibility details.
|-
| config obj obj-test || These directories relate to the build process.
|-
| test || Unit tests. Uses the Boost unit test framework. A good introduction to the Boost user test framework is here: [http://www.alittlemadness.com/2009/03/31/c-unit-testing-with-boosttest/]
|-
| univalue || Per the README: "A universal value object, with JSON encoding (output) and decoding (input). Built as a single dynamic RAII C++ object class, and no templates."
|}

==Design Patterns==

'''Object-Oriented Design'''

Naturally, being a C++ program, the code employs object-oriented design.

However, the code's use of object-oriented design is by not universal. In 0.11, objects are used mainly for defining the data structures which main.cpp uses to manage the blockchain and the UTXO set (the bitcoins). Main.h declares many functions and global variables but almost no classes; main.cpp is over 5000 lines but does not include any class methods.

The code has a relatively flat class structure, with most classes being "stand-alone".

Where inheritance is used, it often is a linear hierarchy (i.e.: A <-- B <--C <-- D)

For example:
CBlockHeader <-- CBlock
CTransaction <-- CMerkleTx <-- CWalletTx

There are only a few examples of base classes that have more than one descendant class, and multiple inheritance is only used once in the code (CWallet inherits from 2 classes.)

The program's best example of an elegant class hierarchy relates to the coins caches. It uses an abstract class that is inherited by a few subclasses that demonstrate encapsulation and polymorphism. Chapter 3 has a class diagram as well as a diagram and explanation of how the classes are instantiated and relate to one another.

'''Multithreading'''

The code uses Boost thread groups to implement multithreading. The vast majority of the action takes place in the message-processing thread, and to a lesser extent the socket thread.

'''Observer (Signals and slots)'''

The "observer" pattern uses "signals and slots" to decouple two or more areas of code. Bitcoin Core 0.11 uses the observer pattern in a limited way. Namely, it uses signals to decouple the message-gathering loop from the main.cpp code. In 0.10 and earlier a normal function call was used.

 
 
 
==See also==
[https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_2):_Data_Storage Bitcoin Core 0.11 (Ch 2): Data Storage]
 
[https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_3):_Initialization_and_Startup Bitcoin Core 0.11 (Ch 3): Initialization and Startup]
 
[https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_4):_P2P_Network Bitcoin Core 0.11 (Ch 4): P2P Network]
 
[https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_5):_Initial_Block_Download Bitcoin Core 0.11 (Ch 5): Initial Block Download]
 
[https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_6):_The_Blockchain Bitcoin Core 0.11 (Ch 6): The Blockchain]

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

Bitcoin Core 0.11 (ch 4): P2P Network

2025-05-25T17:55:49Z

Calliptamus:

Bitcoin is a peer-to-peer network, so [[Bitcoin Core]] has code to discover peers and manage those connections.

Most of the network-handling code is in net.h/cpp.

==Data structures to manage peers==

At any given time, the node is connected with a set of other nodes, i.e. peers. By default the code connects to 8 outbound peers (nodes that our node goes out and finds) and allows up to 125 inbound peers (nodes that find us through the network).

The global variable vNodes (net.h) holds the set of peers. The variable is protected by cs_vNodes.

Each peer is represented by a CNode.

The CNode contains dozens of attributes, most of which have to do with low-level plumbing (sockets, byte streams, etc.)

Some of the key attributes of a CNode include:

'''CNode'''

{| class="wikitable"
|-
! Attribute !! Description
|-
| nServices || Commonly referred to as "the service bits." This is a bitmap of what services the peer provides. As of 0.11 this is still just binary: either the node is NODE_NETWORK (it is a full node and does everything) or not (it is SPV). In future versions, these bits will convey more precise information about what the node can and can't do. For example, with Block Pruning a node may be able to serve recent blocks (say, the last week or two worth of blocks), but not the entire blockchain.
|-
| fClient || Whether this peer is a SPV node. (Here, the term "client" means "merely SPV, not a full node.")
|-
| fOneShot ||
|-
| fInbound || Whether this node is "inbound" or "outbound." Common sense suggests that a node that we discovered through the network (an outbound node) is less likely to attack us than a node that found us. So, for example, when the code looks for a peer to request historical blocks from, it prefers an outbound node, if possible.
|-
| fWhiteListed || A whitelisted node is not subject to being banned for bad behaviour.
|-
| setInventoryKnown ||
|-
| vSendMsg || Messages that we've queued up to send to the peer. This is type <CSerializeData> since we are going to send it over the network.
|-
| vRecvMsg || Messages that we've received from the peer. This is type <CNetMessage> because as soon as the data is received, it is deserialized and packed into a more useful format (an object).
|}

==Peer discovery & connectivity==

===Address manager===

IP addresses of the node's peers are managed by the address manager (see addrman.h).

The code comment explains the address manager (edited here for conciseness):

Design goals:
* Keep the address tables in-memory, and asynchronously dump the entire table to peers.dat.
* Make sure no (localized) attacker can fill the entire table with his nodes/addresses. To that end:
* Addresses are organized into buckets.
* Addresses that have not yet been tried go into 1024 "new" buckets.
* Addresses of nodes that are known to be accessible go into 256 "tried" buckets.
* Bucket selection is based on cryptographic hashing, using a randomly-generated 256-bit key, which should not be observable by adversaries.
* Several indexes are kept for high performance. Defining DEBUG_ADDRMAN will introduce frequent (and expensive) consistency checks for the entire data structure.

''Timestamps''

The address manager also keeps track of when each peer was last heard from. Timestamps are only updated on an address and saved to the database when the timestamp is over 20 minutes old. By understanding the role of timestamps, it will become more clear why timestamps are kept the way they are for each of the different ways an address is discovered.

===Peer discovery===

The program discovers the IP address and port of nodes in several different ways:
* Address database (peers.dat)
* User-specified (-addnode and -connect)
* DNS seeding
* Hard-coded seeds
* From other peers ("getaddr" and "addr" messages)

'''1) Address database (peers.dat)'''

Nodes store addresses in a database (peers.dat) which is read on startup, and loaded into the address manager.

This method does not work the first time the program is run, since it does not already know about any other nodes on the bitcoin network.

For details on when/how the code stores to the database, see the section above on the address manager.

'''2) User-specified on the command line'''

The user can specify nodes to connect to on the command line with -addnode <ip> or -connect <ip>.

Notes on user-specified IP addresses:
* Multiple nodes may be specified.
* Addresses are initially given a zero timestamp, therefore they are not advertised in response to a "getaddr" request.
* With -connect, the IP addresses will not be added to peers.dat and only the provided addresses will be used.
* With -addnode, the provided addresses will be used as a starting point, but the node will soon learn other peers.

'''3) DNS seeding'''

DNS seeding is only used if the peers.dat database is empty (as it would be when initiallly running the program) and the user has not specified any nodes with -addnode or -connect.

In this case, the node can issue DNS requests to discover IP addresses of other peers.

As of 0.11, there are six DNS servers hard-coded into the program - see chainparams.cpp.

A DNS reply can contain multiple IP addresses for a requested name.

Addresses discovered via DNS are initially given a zero timestamp, to avoid being advertised in response to a "getaddr" request.

'''4) Hard-coded nodes (last resort)'''

If DNS seeding fails, the client contains hard coded IP addresses that represent bitcoin nodes. See: chainparamsseeds.h

These addresses are only used as a last resort, and a log message will be printed: "Adding fixed seed nodes as DNS doesn't seem to be available." (net.cpp)

The idea is to move away from seed nodes as soon as possible, to avoid overloading those nodes.

Once the local node has enough addresses (presumably learned from the seed nodes), the connection thread will close any seed node connections.

Like the DNS seed addresses, the hard-coded seed addresses are also given a zero timestamp to avoid being advertised in response to a "getaddr" request.

'''5) From other nodes ("getaddr" and "addr" messages)'''

Nodes exchange IP addresses with other nodes via the "getaddr" and "addr" messages. 

Usually, an addr" message is sent in response to a "getaddr".

However, the "addr" message may also arrive unsolicited, because nodes advertise addresses gratuitously when they:
* Relay addresses (see below)
* Advertise their own address periodically. (Every 24 hours, the node advertises its own address to all connected nodes.)
* When a connection is made (in response to an initial "version" message)

When does a node send a "getaddr" message?
* In response to a "version" message from an outbound node.

Receiving an "addr" message:
* If the sending node is an old version and we have 1000 addresses already, it is ignored.
* If the sending node is a current version and is attempting to send us more than 1000 addresses, the peer is punished for misbehaving.
* If the address has been seen in the last 24 hours and the timestamp is currently over 60 minutes old, then it is updated to 60 minutes ago.
* If the address has NOT been seen in the last 24 hours, and the timestamp is currently over 24 hours old, then it is updated to 24 hours ago.

Responding to a "getaddr" message:
* The node figures out how many addresses it has that have a timestamp in the last 3 hours.
* It sends those addresses, but if there are more than 2500 addresses, it randomly selects 2500.
* It clears the list of the addresses we think the remote node has, which will trigger a refresh of sends to nodes. See SendMessages.

''Address Relay''

Once added, the newly received IP addresses may be relayed to other nodes if the following conditions are met:
* The address timestamp is recent (within 10 minutes of the current time)
* The "addr" message contained 10 addresses or less
* fGetAddr=false for the sending peer. (See the code for details.)
* The address must be routable.
* Code:
if (addr.nTime > nSince && !pfrom->fGetAddr && vAddr.size() <= 10 && addr.IsRoutable())
* If this test is passed, then the code's next step is (see main.cpp for details):
// Use deterministic randomness to send to the same nodes for 24 hours at a time so the addrKnowns of the chosen nodes prevent repeats.

===Peer connectivity===

The connection thread (ThreadOpenConnections) chooses among the available addresses and makes connections, and disconnects nodes when appropriate.

'''Use of CSemaphore for outbound connections'''

The code uses a semaphore to manage the number of outbound connections (usually 8).

Most of the code dealing with the semaphore is in net.cpp.

When a connection is opened, the semaphore grant is passed to the CNode data structure. This allows the socket thread to release the semaphore when the time comes, with:
pnode->grantOutbound.Release() // see net.cpp

The code CSemaphore grant(*semOutbound) will wait until there is a connection available.

'''Inbound connections: accepting and disconnecting'''

Inbound connections can be up to 125 total.

ThreadSocketHandler has the code that accepts inbound connections.

The socket thread loop:
* 1) Disconnects sockets that have the fDisconnect flag set on them (and have empty buffers)
* 2) Prepares all sockets for "select"
* 3) Calls "select", which is a system call which waits for activity on a set of sockets.

When the select() call returns, the node accepts any new connections, receives and sends on any ready sockets, and marks any inactive sockets to be disconnected (whether inbound or outbound).

Sockets are disconnected if:
* they are 60 seconds old and have not sent or received data.
* they have not sent or received data in the last 20 minutes (TIMEOUT_INTERVAL = 20*60) (or 90 minutes if peer is an old version)
* the socket overfills the buffer (see CNode::ReceiveMsgBytes- "Oversized message from peer=%i, disconnecting\n" in net.cpp)

==Sockets & Messages==

'''Socket Thread'''

The socket thread operates at the TCP layer.

It goes through an endless loop, reading and writing the sockets. (see net.cpp).

Its loop involves three basic activities:

1) Administrative work: disconnecting unused sockets, checking which sockets have data, adding sockets for new connections.

2) Receiving data: It reads the sockets that have data using the recv() system call and places that data into the peer's queue of CNetMessages. A CNetMessage organizes the data into two data streams - the message header and the message data (vRecv). The socket thread reads the buffer until it has processed all the messages from this particular peer.

3) Sending data: The message thread queued up messages-to-be-sent as vSendMsg objects, so the socket thread deserializes these objects and sends them using send(). (send() is a syscall and any incompatibilities across different operating systems are handled in the compat.h file.)

'''Message Thread'''

This is the program's main thread.

It operates primarily at the "business logic" level - validating transactions, managing the blockchain, etc.

In a sense, all of the node's activities take the form of processing an inbound message or preparing an outbound message.

Like the socket thread, this thread consists of a while(true) loop, processing inbound messages and queuing up outbound messages. Once the program's initialization is complete, this loop (see net.cpp:ThreadMessageHandler) is the program's high-level point of control.

The loop uses signals to notify main.cpp that there are messages waiting to be processed. The signal is picked up by ProcessMessages().

The use of signals has nothing to do with multi-threading; the signal is sent and picked up in the same thread. The use of signals was introduced in version 0.9 for the purpose of decoupling net.cpp from main.cpp. In version 0.8, the loop simply called the ProcessMessages() function. By changing to signals, the net.cpp code no longer needs to be aware of the processing code. Removing that dependency allows the code to avoid circular includes (since main.cpp requires knowledge of net.h.

The pull request introducing signals is [https://github.com/bitcoin/bitcoin/pull/2154 PR 2154.]

The commit removing the "main.h" dependency is [https://github.com/CodeShark/bitcoin/commit/6e68524e95da2bedc21b1d95c4a206b902ab7c22 here].

'''ProcessMessages (main.cpp)'''

ProcessMessages() is the entry point in main.cpp for almost all of the code that processes and validates transactions and blocks, etc.

It attempts to find a message start signature in the vRecv stream. If it finds a message start, it deletes everything prior to the start. Then it reads the header, extracts the message type, and calls ProcessMessage on the message.

ProcessMessage() is basically a large "switch" which takes action based on what type of message it is dealing with.

Often, in the course of processing a message, the code will push messages to the outbound queue. For example, when processing an incoming "getdata" message, the node pushes the outbound data into the queue.

'''SendMessages (main.cpp)'''

SendMessages() creates messages and queues them up in the peer's vSendMsg queue (a double-ended queue, or "deque" in C++). The vSendMsg objects are basically just serialized data.

SendMessages goes through various data structures looking for work to do. When it produces a message it calls the CNode->PushMessage, which queues the outbound data. (Note that there are many other places in the code that produce messages and call CNode->PushMessage; SendMessages() doesn't have any kind of exclusive license on placing messages in the outbound queue.)

Once the data is queued up by PushMessage, it sits and waits for the socket thread to come along.

The socket thread and the message thread use a peer-specific lock (node->cs_vSend) to coordinate access to the socket.

==Locks==

The main locks associated with the P2P aspect of the code are:
* cs_vNodes controls access to the CNode objects.
* cs_vSend controls access to the node's send buffer.
* cs_vRecvMsg controls access to the node's receiving buffer.
* cs_inventory

==Denial-of-Service Prevention==

DoS prevention is implemented by keeping track of misbehaving peers, and if they misbehave, banning them.

The DoS prevention framework was introduced in 2011, in Pull 517.

As summarized there:

<blockquote>
-----
The big idea: if a peer is sending you obviously wrong information, punish it by maybe dropping your connection to it, and ban it's IP address so it cannot immediately re-connect.
 The probability of dropping the connection, and the length of the ban, depend on how wrong, and how potentially wasteful/damaging, the peer is. So sending an extra 'version' message is a minor transgression that is usually tolerated, sending an more than MAX_BLOCK_SIZE block is a major transgression.
 Detailed how-it-works, using "I got a version message I wasn't expecting" as the specific example:
 Getting a version message from a peer increases that peer's 'misbehaving' score by 10, and (assuming that is the peer's first bad behavior) gives it a 10% of being disconnected. If it is disconnected, then that peer's IP address is banned from connecting for a couple of hours. If it is not disconnected, then nothing happens unless the peer misbehaves again; if it does, then its chances of being disconnected go up, and the length of time it will be banned increases.
 Misbehavior/ban information is stored only in memory, and information about misbehaving peers is never broadcast. Also, peers that are disconnected/banned are just dropped, there is no warning or reason sent.
 
 
--Gavin Andresen
 
-----
</blockquote>

Source: https://github.com/bitcoin/bitcoin/pull/517

'''Banned nodes'''

The set of banned nodes is in setBanned in net.cpp.

By default, a node is banned for 24 hours, though this can be configured with -bantime option.

==See also==
[https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_1):_Overview Bitcoin Core 0.11 (Ch 1): Overview]
 
[https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_2):_Data_Storage Bitcoin Core 0.11 (Ch 2): Data Storage]
 
[https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_3):_Initialization_and_Startup Bitcoin Core 0.11 (Ch 3): Initialization and Startup]
 
[https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_5):_Initial_Block_Download Bitcoin Core 0.11 (Ch 5): Initial Block Download]
 
[https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_6):_The_Blockchain Bitcoin Core 0.11 (Ch 6): The Blockchain]

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

Bitcoin Core 0.11 (ch 5): Initial Block Download

2025-05-25T17:54:52Z

Calliptamus: /* Background */

This page explains how Bitcoin Core downloads the blockchain when your node first joins the network.

==Background==

Once a new node joins the network, its first order of business is to download and validate the entire [[Block chain|blockchain]]. This is an integral step to the distributed nature of bitcoin because only by doing this can a node claim that it has independently validated all transactions.

As the blockchain grows in size, the time required for IBD increases unless optimizations are made to the code. Various optimizations have been made since Satoshi's original client was released, but as of 2014, with increasing transaction volume, initial download on laptop hardware with an average connection could still take up to 24 hours. Developers agreed that this was unacceptable and a new approach was developed called "headers first" mode. This approach resulted in a substantial speedup.

=="Headers First" mode==

With "headers-first" mode, a new node downloads all of the block headers first, which are very small (about 80 bytes, whereas a block can be up to 1MB). Once the node has all of the headers, from the genesis block up to the current tip of the blockchain (380,000 as of October 2015), only then does it begins downloading the full blocks.

Now that it has the headers, the node downloads blocks in parallel from multiple peers. (It downloads headers from only one peer, but that's no big deal since headers are small.) The node will download from up to 8 peers at once and will disconnect any peer that stalls for more 2 seconds, attempting to connect to a faster peer.

Headers-first IBD was merged in 2014 in: [https://github.com/bitcoin/bitcoin/pull/4468 Pull Request 4468].

As summarized in the PR comment, some of its main features are [comment is edited slightly here]:

* Do not use 'getblocks', but 'getheaders', and use it to build a headers tree.
* Blocks are fetched in parallel from all available outbound peers, using a limited moving window. When one peer stalls the movement of the window, it is disconnected.
* No more orphan blocks. At all. We only ever request a block for which we have verified the headers, and store it to disk immediately. This means that a disk-fill attack would require Proof of Work.
* We sync from everyone we can, though limited to 1 during initial headers sync.

==Checkpoints==

The Bitcoin Core initial block download code makes sure that the block headers you are downloading (from a single peer) passes certain, hard-coded "checkpoints."

Checkpoints are block hashes corresponding to a long-ago block that everyone (where "everyone" means the network participants as recognized by the Bitcoin Core commit-access developers) recognizes as being on the longest chain. The checkpoints are set far enough in the so as to be non-controversial.

The IBD checkpoints check is at main.cpp:2784 (version 0.11).

The hardcoded figures are in chainparams.cpp. (As of 0.11, there were 13 checkpoints, the first at block 11,111, the last at block 295,000.)

From chainparams.cpp:

:: /**
:: * What makes a good checkpoint block?
:: * Is surrounded by blocks with reasonable timestamps (no blocks before with a timestamp after, none after with timestamp before)
:: * Contains no strange transactions
:: */

'''Purpose of Checkpoints'''

The purpose of checkpoints is primarily DoS protection. As Greg Maxwell explained on [https://bitcointalk.org/index.php?topic=194078.0 bitcointalk in 2013]:

: User: They [checkpoints] are there so some quantum computing farm (doesn't exist, but...) can't come out of nowhere and roll back blocks by mining a long chain from far in the past.

: gmaxwell: That's not really what they're for— though they have that effect too. Most of their usefulness is that they prevent a dos attacker from filling up bitcoin node's disk space with long runs of low difficulty blocks forked off low in the chain. e.g. you start off with difficulty 1 blocks at block 0, now mine-able by the millions by a single asic— _MAYBE_ a chain that starts off that way could eventually turn out to be the longest so absent the checkpoints a node would happily follow an endlessly long chain of them. They also make is so that an attacker who has complete control of your network (and thus can prevent you from hearing the longest chain from the honest bitcoin network) from putting you on a fake (low difficulty) isolated chain unless they can also trick you into running replaced software. With the checkpoints such an attacker hast to have a ton of mining power in order to continue the chain.

'''Origin of Checkpoints'''

According to Gavin Andresen, checkpoints were originally introduced in response to the "overflow" bug which would permit anyone to spend anyone's bitcoins. [https://bitcointalk.org/index.php?topic=1647.40 see here, page 3]

'''More info on Checkpoints:'''

: First checkpoint introduced by Satoshi in July 2010 (v0.3.2): [https://bitcointalk.org/index.php?topic=437 here]
: Bitcoin talk thread on checkpoints (Nov 2010): [https://bitcointalk.org/index.php?topic=1647 here]
: Bitcoin talk thread (2013): [https://bitcointalk.org/index.php?topic=194078.0 here]

==Bitcoin Core code implementing IBD==

Most of the code is in main.h/cpp.

'''Block Status'''

The concept of block status is important (see chapter 2 and/or chain.cpp). Your node assigns a newly received block a status and updates that status as it learns more about the block. (The block status could also change in the future, for example if there is a re-organization and the block is no longer on the longest blockchain.)

'''Downloading Block Headers'''

The code starts by downloading headers from a single peer.

The download begins in SendMessages (main.cpp), which is called periodically by the message-handling thread.

If the code sees that we are not caught up and we haven't started syncing from anyone:

* We send: "getheaders"
* Peer replies: "headers" (a chunk of 2000 headers)
* We send: "getheaders"
* Peer replies: "headers" (a chunk of 2000 headers)
* <continue...>
* Peer replies: "headers" (a chunk of LESS THAN 2000 headers)

When the peer sends less than 2000 headers, we conclude that we reached the tip of the peer's blockchain.

'''Block Locators'''

A Block Locator is used to find a fork point between two nodes, which is where the nodes should start exchanging block headers.

Here is the definition (in primitives/block.h):

/* Describes a place in the block chain to another node such that if the
* other node doesn't have the same branch, it can find a recent common trunk.
* The further back it is, the further before the fork it may be.
*/
struct CBlockLocator
{
std::vector<uint256> vHave;
...
(a few basic constructor & serialization methods)
...
};

So, a Locator is basically a vector of block hashes. The vector is populated with 32 hashes which are chosen to maximize the likelihood of quickly finding a common block with a peer.

In normal operation, we would generally expect to be within a few blocks of our peers. Thus, the vector starts with the 10 last block hashes before "jumping back" exponentially. Thus the comment "the futher back it is, the futher before the fork it might be:" what is meant is that firstly, if you and your peer are within 10 blocks of one another, the fork point will be included in the list of hashes. If you and your peer are 15 blocks away from one another, you'll surely find a common block that's within a few blocks of the fork point and only one further iteration of Locator will be reuqired to find the fork point. However, if you and your peer diverge by 10,000 blocks, the Locator may only find a common trunk that's a few hundred (or more) blocks before the fork point, so another two or three Locator objects will need to be exchanged to zero in on the fork point.

See CChain::GetLocator and CBlockIndex::GetAncestor [both in chain.cpp].

'''Block Skiplist Pointer'''

Every block index contains the following attribute:

// pointer to the index of some further predecessor of this block
CBlockIndex* pskip;

The algorithm for choosing a given block's "skip pointer" is in chain.cpp:

// Determine which height to jump back to. Any number strictly lower than height is acceptable,
// but the following expression seems to perform well in simulations (max 110 steps to go back
// up to 2**18 blocks).
return (height & 1) ? InvertLowestOne(InvertLowestOne(height - 1)) + 1 : InvertLowestOne(height)
InvertLowestOne(int n) { return n & (n - 1); }

The skip pointer is used to move through the blockchain in O(log n) rather than walking the chain in O(n).

The idea behind a "skip list" is described here: [https://en.wikipedia.org/wiki/Skip_list Wikipedia page for skiplist]

'''Processing the Block Headers'''

Code path:
ProcessMessage (entry point)
AcceptBlockHeader
CheckBlockHeader (non-contextual validation checks)
ContextualCheckBlockHeader (blockchain-aware validation checks)

Non-Contextual Checks

These checks are "non-contextual" because they do not require any knowledge of the state of our blockchain.

1) Proof-of-Work Meets Claimed Requirement: Here, the code checks that the block has the POW that the miner claims was necessary when constructing the block. Later, we'll re-check it against our blockchain. An honest miner should always pass both checks. Only a miner who lies about the required POW (block.nBits) would pass this check but fail the contextual check.

2) Timestamp not-too-late: The code checks that the timestamp is less than 2 days in the future. This is context-independent because the code just compares the block's timestamp against the system time.

 Contextual Checks 

These checks require some knowledge of our node's blockchain.

1) Re-check Proof of Work: Here, we re-check the POW based on our own knowledge of the difficulty target (rather than trusting the difficulty the miner placed in the block's nBits).

2) Checkpoints (if enabled): If this block's height is a checkpoint, the block hash matches the hash stored in the checkpoint map. (see checkpoint.cpp).

3) Timestamp not-too-early: Here, we check that the block's timestamp is not prior to the previous block's median time (of the previous 11 blocks). This guarantees that the median time continues to advance from block to block. Obviously, this check is context-dependent because it requires knowledge of prior blocks in the active chain, which is obtained by retrieving the block from mapBlockIndex. For more info, see [BIP 113].

4) Version number

Add the Block

Finally, add the block to mapBlockIndex and update pIndexBestHeader (see AddToBlockIndex()).

At this point, the block indexes are VALID_TREE, since we know they are on the main chain, but we haven't yet received the transactions.

'''Downloading Blocks'''

Your node will start downloading blocks from the peer that it is downloading headers from right away.

This is so because:
* The headers-peer is surely a preferred-download peer, set when you received its "version" message (main.cpp:4056).
* Thus, your node will call FindNextBlocksToDownload for your headers-peer (main.cpp:5143).
* Your headers-peer will have a valid pIndexBestKnownBlock (main.cpp:421), since that was set in UpdateBlockAvailability() when you received the peer's headers (main.cpp:4532).
* FindNextBlocksToDownload will return a vector of block hashes, which you'll then request (see main.cpp:5145 [add block to the request vector] and main.cpp:5178 [send getdata msg to your headers-peer]).

However, you will not start downloading blocks from the other peers until IBD is complete.

This is so because:
* Your other peers are probably also preferred-download peers, so you'll call FindNextBlockToDownload just like with your headers-peer.
* However, that function call will return immediately because it won't be able to find any available blocks.
* When IBD concludes (see discussion below), you'll start exchanging headers with the other peers.
* Once you've exchanged headers with your other peers, you'll start requesting blocks.

Blocks are downloaded in chunks of 16 blocks at a time from each peer. With a block size of 1MB, if blocks are full we are talking about 16MB chunks. (See main.h - "MAX_BLOCKS_IN_TRANSIT_PER_PEER".)

''Moving Window''

The download code uses a "moving window" of 1024 blocks. The idea is that although you are downloading different chunks from multiple peers, at any given time the blocks you are downloading are fairly close together. The main purpose of this is so that blocks that are near one another on the blockchain are most likely contained in the same .dat file (where the raw block data is stored on disk). One advantage of having a correlation between blockchain location and block file location is that if the node chooses to "prune" block data at a later date, it's easier to delete older block files.

''Disconnecting a peer''

The code disconnects slow peers in order to keep the download moving. The peer can be disconnect under two scenarios.

First, any block requested from the peer must be delivered within a certain timeframe.

Usually, this timeframe is 20 minutes.

The following code is in main.cpp:
GetBlockTimeout(...) { return nTime + 500000 * consensusParams.nPowTargetSpacing * (4 + nValidatedQueuedBefore);}

nValidatedQueuedBefore are the number of blocks that are in flight to us and which we have validated. Let's call that N.

If N = 0, this code evaluates as:
: = 500,000 microseconds (1/2 second) * 600 seconds (the target block interval) * 4
: = 0.5 seconds * 600 seconds * 4
: = 1,200 seconds
: = 20 minutes

The formula can be simplified as:
: = 0.5 * (4 + N) * block_interval
: = (2 + 0.5 * N) * block_interval

Thus:
: N=0, timeout = 2 * block_interval = 20 minutes.
: N=10, timeout = 7 * block_interval = 70 minutes.
: N=30, timeout = 17 * block_interval = 170 minutes.

The second circumstance where we will disconnect a peer is where the peer manages to stall your entire download by preventing the moving window from progressing. Imagine your moving window is blocks 1000 to 2024 and you've downloaded everything from 1016 to 2024, but are waiting for Alice to serve up 1000 to 1016, which you may have requsted a few minutes earlier. In this siutation, if Alice continues to stall the moving window for 2 seconds, you will drop Alice and replace her with a more reliable peer. In the mantime, your node will request blocks 1000 to 1016 from one of your other peers so your moving window can start moving again.

'''Requesting Blocks'''

Requesting blocks is handled by sending out a "getdata" message (see main.cpp:5137 in v0.11). A "getdata" message is used to pack a vector of "inv" messages and send as a group. Thus, we can request 16 blocks from the peer with one network message, as opposed to sending 16 separate "inv" messages.

What blocks do we request? The code to figure that out is in FindNextBlocksToDownload; it uses a '''block locator''' to figure out the last block we have in common with this peer, and starts from there. A block locator is a homemade algorithm that efficiently finds the fork point between our node and a given peer. The locator will pack a list of 32 blocks, starting with the last 10 (since in steady-state we are usually within 10 blocks of our peers), and then jumping back exponentially. (chain.cpp:25).

This algorithm has proven to be effective at locating the fork point.

Once we've prepared the "getdata" message, we mark the blocks that we've requested as being "in flight" - with MarkBlocksAsInFlight (main.cpp).

'''Receiving Blocks'''

The entry point for receiving blocks is in ProcessMessage, when our node receives a "block" message from a peer.

The block is processed with ProcessNewBlock (main.cpp):

: 1) Checks on the block
:: a) Basic, context-independent checks on the block (merkle root, block size, etc)
:: b) Basic, context-independent on transactions within the block (transaction size, etc.)
:: c) Check that we requested this block (if unrequested, this may be a DOS attack - though not necessarily)
:: d) Context-dependent checks on the block

: 2) Store the block to disk

: 3) General check on the integrity of our blockchain (this may sound expensive, but is very fast)

: 4) Connect the block to the blockchain - if appropriate (see ActivateBestChain)

Note that the block's transactions are not validated (checked for a double-spend, etc.) until the last step, when the block is connected as the new tip of the blockchain. For more info, see below "Connecting a Block".

==Monitoring the Download==

You can monitor the download with the RPC call getpeerinfo, which shows (for each peer that you're connected to):

* "synced_headers": The last header we have in common with this peer
* "synced blocks": The last block in commen with this peer
* "inflight": The heights of blocks we're currently requesting from this peer

==See also==
[https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_1):_Overview Bitcoin Core 0.11 (Ch 1): Overview]
 
[https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_2):_Data_Storage Bitcoin Core 0.11 (Ch 2): Data Storage]
 
[https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_3):_Initialization_and_Startup Bitcoin Core 0.11 (Ch 3): Initialization and Startup]
 
[https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_4):_P2P_Network Bitcoin Core 0.11 (Ch 4): P2P Network]
 
[https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_6):_The_Blockchain Bitcoin Core 0.11 (Ch 6): The Blockchain]

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

Bitcoin Core 0.11 (ch 6): The Blockchain

2025-05-25T17:53:53Z

Calliptamus:

This page describes the code that manages the [[Block chain|blockchain]].

==Block Index and Block Status==

The block index database gets loaded into memory when the node starts. This means the entire block tree, not just the active chain. See LoadBlockIndexGuts() in src/txdb.cpp.

The block index (block metadata) is well commented in the code: see src/chain.h.

One of the key traits of a block is its "verification status."

Verification status captures the degree to which the code has validated this block, as well as its ancestor blocks.

The block's status is one of the following:

* VALID_HEADER = 1
* VALID_TREE = 2
* VALID_TRANSACTIONS = 3
* VALID_CHAIN = 4
* VALID_SCRIPTS = 5

The precise meaning of each status code is documented in chain.h.

Also stored in the block index are two variables worth mentioning:

: '''nTx:''' Number of transactions in this block.
: nTx > 0 means that the block has a status of at least VALID_TRANSACTIONS.

: '''nChainTx:''' Number of transactions in this block's chain, up to and including this block.
: This value will be set if and only if transactions for this block ''and all its parents'' are available.
: Thus, nChainTx > 0 is shorthand for a chain that is VALID_TRANSACTIONS. This is notable because this information is not available via the block-status enum. Namely, VALID_TRANSACTIONS only implies that its parents are TREE, while VALID_CHAIN implies that its parents are also CHAIN. In a sense, then, the expression (nChainTx !=0) is shorthand for a status that might be said to be "VALID_nChainTx = 3.5" - because it's more than VALID_TRANSACTIONS but less than VALID_CHAIN.
: Note: nChainTx is only stored in memory; there is no corresponding entry in the database.

==Key Variables==

First, a quick C++ reminder:
* map: an unordered <key,value> container (think of it as a hashtable)
* set: an ordered <key> container (think of it as a sorted linked list)
* multimap: an ordered map <key,value> where duplicate keys are allowed (thus, can hold elements <a,1>,<b,2>,<b,3>)

'''mapBlockIndex (map<block_hash, CBlockIndex*>)'''

This map contains all known blocks (where "block" means "block index"). Since a block index is created and stored in the LevelDB when a header is received, it's possible to have block indexes in the block map without having received the full block yet, let alone having stored it to disk.

mapBlockIndex is not sorted. Just think of it as your blocks/ LevelDB in memory, with the key being the block hash.

It is technically of type BlockMap, which is for readability. BlockMap is an unordered_map<block hash, block index*, comparator_function>.

mapBlockIndex is initialized from the database in LoadBlockIndexGuts, which is run at Step 7 of startup. Thereafter, it's updated whenever new blocks are received over the network.

mapBlockIndex only grows, it never shrinks. (Try searching main.cpp for mapBlockIndex.erase.) Observe also that the block index's LevelDB wrapper does not contain functionality for erasing blocks from the database - it's writing function (WriteBatchSync) only writes to the database. By comparison, the chainstate wrapper's writing function (BatchWrite) both writes and erases. (see txdb.cpp).

'''mapBlocksUnlinked'''

Multimap containing "all pairs A->B, where A (or one if its ancestors) misses transactions, but B has transactions." (comment at main.cpp:125).

The purpose of mapBlocksUnlinked is to quickly attach blocks we've already received to the blockchain when we receive a missing, intermediate block.

The alternative would be to search the entire mapBlockIndex; however, it is more efficient to keep track of unlinked blocks in a separate data structure.

Example 1:
Let A be our tip.
We receive block ''headers'' for B, C.
We receive the full block for C.
mapBlocksUnlinked = <B,C>

Upon receiving block B, we can connect C.

Example 2:
Let A be our tip.
We receive block ''headers'' for B, C, D.
We receive the full block for D.
mapBlocksUnlinked = <B,C>, <B,D>, <C,D>

Upon receiving block B, we can connect B as our tip and delete its entries in mapBlocksUnlinked, which would now consist of only one item: <C,D>.

'''setBlockIndexCandidates'''

Set of block indexes that have more total work than our current tip. (In the normal case where the block extends our current tip, it is easy enough to see that it has more total work than our tip.) Thus, they are "candidates" for extending our current blockchain (or re-organizing from our current chain to the chain that the candidate is on.) We call them "candidates" because we verify the block's proof-of-work when we receive the header, but before we receive the block. Thus, the ''header'' is a candidate for extending our chain, but we can't say for sure until we receive the full block (and if the candidate is more than one block away from our current tip, we also need to receive and verify any intermediate blocks.)

Example 1: Let A be our tip; we then receive, in order, B, C, D, such that:
A -- B
\
C -- D

We verify headers for B, C, D and they all look good. At this point setBlockIndexCandidates contains <B,C,D>. Assume B has more work than C but less work than D.

Now we receive the full block for B and it checks out. At this point, we extend chainActive with B as the new tip, and remove B from setBlockIndexCandidates. We also remove C because it has less work than B. But D still is.

Now we receive C and D. C is valid, but D has a bad transaction (double-spend, invalid signature, etc.):
* Store C to disk and keep it in mapBlocksIndex - it's a known block
* Discard D (do not store to disk) and delete it from mapBlocksIndex - it's a bad block
* Remove D from setBlockIndexCandidates

Now our chainActive is Genesis - - - - - - - A--B, and setBlockIndexCandidates is <empty>.

'''pindexBestHeader'''

This variable holds the best (most work) header that your node has validated.

It's set initially when loading the block index, and updated when adding a header to the mapBlockIndex which has more work than the current pIndexBestHeader.

A header is added to mapBlockIndex once it has passed the context-dependent and context-indendent checks.

'''chainActive (vector<CBlockIndex*>'''

chainActive is the holy blockchain. It is a linear set of blocks, consisting only of those blocks that comprise the longest chain, beginning with the Genesis block and culminating with the tip.

chainActive is a CChain, which is a vector of block indexes bundled with a few useful methods (see chain.h).

On startup, the chain is initialized in Step 10 (init.cpp), which calls ActivateBestChain (main.cpp).

'''Difference between pindexBestHeader and chainActive.Tip'''

It's important to note that pindexBestHeader and chainActive.Tip are NOT necessarily the same thing.

pindexBestHeader is a pointer to the most-work header our node has received, before having received its transactions. By comparison, chainActive.Tip is only set after we've received and validated the entire block.

==Connecting a block==

When the node receives and accepts a block that has more proof-of-work than the tip of its active blockchain, the node will attempt to make this block the new tip.

In "steady-state", where our node's active chain tip is a block B1, the typical course of events is that every 10 minutes or so, the node receives and accepts a new block B2 which was built on top of B1 (meaning B2's "prev_block" is B1's hash), notices that B2 has more work than B1, and connects B2 to B1, thereby extending the active chain.

ConnectBlock() is the key moment when a "double-spend" would be discovered. The block's transactions are validated against the current UTXO set (the coins database). Specifically, the code in ConnectBlock loops through each transaction, ensuring that all of the transaction's inputs can indeed be found in the coins database. (If a coin had been spent in a prior block, it would not be in the current UTXO set; it would have been in a different, earlier view of the UTXO set, but no longer.) The ConnectBlock code also contains some DoS protection code: for example, it ensures that the transactions do not contain an excessive number of signature operations (which are expensive).

ConnectBlock() is the last step in ProcessNewBlock. Thus, it takes place only after the block has been accepted and stored to disk. The idea is that a block can be valid in the abstract but whether its transactions are valid is dependent upon the UTXO set at the particular point where the block is being added to the chain. This may not be known until a later point in time, even in steady-state. Presume that our current tip is B1, which is then extended by B2 and B3 in rapid succession. For whatever reason, we receive B3 before B2 (perhaps B2 was created by a miner across the globe to whom we are poorly connected, whereas B3 was mined by our next-door neighbor who has a better link to the miner who created B2). At the moment we receive B3, it may (and probably does) contain transactions whose inputs do not exist in our coin database, because they are only created in B2. In any event, no effort is made to validate B3 beyond the basic checks. Later, when we receive B2, we connect it and update the UTXO set, then notice that B3 extends B2. Now B3's transactions can be validated and assuming it checks out, it becomes the new tip of the active chain.

If the entire block checks out, then the block is connected, and the undo data is created and stored to disk.

If there's a problem with one of the block's transactions, the block is not connected, and the code punishes the peer that sent us the bad block. (See InvalidBlockFound.)

==Disconnecting a block (reorganizations)==

A reorganization (re-org) occurs when your node realizes there is a longer chain that does not derive from chainActive.Tip.

Most reorganizations are only one-block reorganizations. This is likely to happen whenever competing miners find new blocks (call them A and B) at about the same time. Some of the network will receive A first, others B. Eventually a new block C will be mined on top of either A or B; which one depends on whether the miner who produced C worked on the A or B chain. Assuming C is mined on top of A, then any node which accepted B as the tip of their blockchain will need to detach B and instead attach A and C.

Here is how a reorg happens in the code:
* When we receive a new block, if it has more work than our chain's tip, we add it to the setBlockIndexCandidates (see main.cpp:ReceivedBlockTransactions)
* After the block is processed, ActivateBestChain checks to see if there's a block (such as the one we just processed) that has more work than the current chain's tip.
* ActivateBestChainStep disconnects blocks as necessary to reach the new tip. Obviously, in the usual case it is not necessary to disconnect any blocks.

'''DisconnectTip() does the following:'''
* Returns the utxo's that were consumed by this block back to the utxo set (DisconnectBlock).
* Returns the block's transactions to the mempool. (Now they need to be mined by some other block; quite likely in one of the blocks we are about to connect, in which case we'll remove them again!)
* Moves chainActive.Tip back one block.
* Updates the wallet.

Once the code has disconnected blocks back to the fork point, it connects blocks from the fork point to the new tip.

'''DisconnectBlock (returning utxo's to the utxo set)'''

This code uses the undo.dat file to "un-spend" the coins that were spent in the block now being disconnected:
* Reads the undo file from disk.
* Processes transactions in reverse order (must be reverse order because CreateNewBlock creates zero-conf transactions "in order", meaning that if a block contains T1 and T2 and T2 spends a T1 coin, then T1 must come before T2 in its transaction vector; therefore, when un-spending the coins, T2 must be un-spent before T1).
* Looks up the spent coins
* Un-spends the coins in a helper function, ApplyTxInUndo: coins->vout[out.n] = undo.txout;

==See also==
[https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_1):_Overview Bitcoin Core 0.11 (Ch 1): Overview]
 
[https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_2):_Data_Storage Bitcoin Core 0.11 (Ch 2): Data Storage]
 
[https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_3):_Initialization_and_Startup Bitcoin Core 0.11 (Ch 3): Initialization and Startup]
 
[https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_4):_P2P_Network Bitcoin Core 0.11 (Ch 4): P2P Network]
 
[https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_5):_Initial_Block_Download Bitcoin Core 0.11 (Ch 5): Initial Block Download]

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

Bitcoin Course on Udemy

2025-05-25T17:51:36Z

Calliptamus:

The first community built Bitcoin course!

This course serves as a central point of introduction to [[Bitcoin]] for anyone interested. It assumes no special skills or knowledge nor experience in computer science. All are welcome and the course shall forever be free under a creative commons license.

==External Links==

* [https://www.udemy.com/bitcoin-or-how-i-learned-to-stop-worrying-and-love-crypto Bitcoin or How I Learned to Stop Worrying and Love Crypto] course on Udemy

[[Category:Educational]]

Bitcoin Dice

2025-05-25T17:51:08Z

Calliptamus:

Bitcoin dice games are by far the most popular [[Bitcoin]] powered casino game available online. Players often regard it as the most pure form of gambling, as dice sites allow entering precise levels of risk and reward, typically at a fixed with a fixed house edge. Often you can bet if the number will be "lo" or "hi", giving players an illusion of control. Most dice sites offer a form of provably fair, to allow the player to verify the results were not tampered with.

Bitcoin Dissector

2025-05-25T17:50:43Z

Calliptamus:

A wireshark dissector for the [[bitcoin]] protocol.

==External Links==

* [https://github.com/lbotsch/wireshark-bitcoin Bitcoin Dissector]

Bitcoin Extension

2025-05-25T17:50:16Z

Calliptamus:

Check balance and send [[Bitcoin]]s from Chrome.
==This extension can access==
* Your data on all websites
* Your tabs and browsing activity
==External Links==
* [https://chrome.google.com/webstore/detail/hhbhfoohbnjkdcndbhjlicijccioklea Bitcoin Extension]

[[Category:Chrome extensions]]

Bitcoin Hedge Fund

2025-05-25T17:49:32Z

Calliptamus:

The first hedge fund to be exclusively financed with [[bitcoin]] (BTC). This fund is designed to give a return for people who want to use BTC as an investment tool while significantly mitigating the volatility of the value of BTC.

NOTE - The site does not list any address or list its location. The website domain is privacy protected and was registered just ten days before launch. The launch announcement was made by a forum member using an account that shows having joined the bitcoin forum community a few weeks prior. It isn't shown who will manage the fund. Proceed at your own risk.

Invests in a diversified group of exchange-traded funds (ETFs), domestic and international bonds, and derivatives (mainly stock options).

The purpose of the fund is the long-term capital appreciation that outpaces the S&P 500.

Bitcoins received by the fund are converted to USD.

To maintain stability and liquidity, initial deposits may not be withdrawn for a period ranging from 21 to 90 days, depending on how early the deposit was made. Withdrawals are in the form of BTCs and are sent to the bitcoin address associated with the account.

This site was launched on June 24, 2011<ref>[http://bitcointalk.org/index.php?topic=21799.0 Announcing the Bitcoin Hedge Fund]</ref>.

==Fees==

There will be no management fees through 2011. A small management fee may be initiated in 2012 (with prior notification) of up to 1%. There is no front-load fee, but there will be a back-load fee of 2%<ref>[http://bitcoinhedgefund.com/how-it-works How It Works]</ref>.

==External Links==

* [http://bitcoinhedgefund.com Bitcoin Hedge Fund] website

==References==
<references />

[[Category:Investing]]

Bitcoin Marketers

2025-05-25T17:48:50Z

Calliptamus:

[[File:Bitcoinmarketers.png]]

Bitcoin Marketers is a full-service [[Bitcoin]] creative digital agency.

==Services Offered==
*Website design
*Front end development
*Search engine optimization
*Logo, booth, and promotional design
*Landing pages, conversion optimization
*Analytics dashboards, a/b testing
*Currency trading / market making
*Mining
*News articles, press releases
*Consulting, networking, advice

==History==

Founded in 2013. Team largely consists of web developers, designers, internet marketers, journalists and currency traders.

==Past Clients==

*CAVIRTEX
*QuadrigaCX
*Cointrader
*Vault of Satoshi
*Coins-e
*Toronto Bitcoin Expo 2014
*Clearly Canadian
*Bitcoin Maps
*Pocket POS

==External Links==
http://bitcoinmarketers.com - Full Service Bitcoin Marketing Agency

[[Category:Marketing]]
[[Category:Introduction]]

Bitcoin Monitor

2025-05-25T17:46:10Z

Calliptamus:

Visualizes the activities on the [[Bitcoin]] network: Coins being moved around (transactions), recording and tamper-proofing the history of events (block creation) and exchanges with other currencies taking place (currency trade).

The service was announced on February 6, 2011<ref>[http://www.bitcoin.org/smf/index.php?topic=3218.0 Bitcoin Monitor: web-based live ticker for activity on the Bitcoin network]</ref>.

==External Links==

* [http://www.bitcoinmonitor.com Bitcoin Monitor] web site

==References==
<references />

Bitcoin News

2025-05-25T17:45:46Z

Calliptamus:

A blog which contains the major news relating to [[Bitcoin]].

Its Twitter feed shows a more complete coverage of happenings.

==External Links==

* [http://www.bitcoinnews.com BitcoinNews.com] web site
* Twitter: [http://twitter.com/bitcoinnews @BitcoinNews]
* [http://feedburner.google.com/fb/a/mailverify?uri=bitcoinnews/VUCh Daily Summary] Subscribe to receive a daily summary of posts, delivered to your inbox

[[Category:Blogs]]

Bitcoin News Magazine

2025-05-25T17:44:53Z

Calliptamus:

A blog and website for breaking [[bitcoin]] and cryptocurrency news.

==History==

Content started appearing on the magazine's website in March, 2015.

==External Links==

* [https://bitcoinnewsmagazine.com Bitcoin News Magazine] website
* Twitter: [http://twitter.com/allegro101 @allegro101]

==References==
<references />

[[Category:Marketing]]
[[Category:Introduction]]
[[Category:Blogs]]

Bitcoin NostrAdamus

2025-05-25T17:44:03Z

Calliptamus:

== Bitcoin NostrAdamus ==
Bitcoin NostrAdamus is an analytical tool developed by the team of CoinsFriendly.com. It allows to make short-, medium- and long-term forecasts on [[Bitcoin]] price fluctuation with high degree of accuracy by indicating whether the trend is going up or down in relation to the current price and by how much the price may change.

=== Supported Exchanges ===
Currently Bitcoin NostrAdamus has forecasts for the following exchanges:
* BTC-e
* Bitstamp
* BTC China

=== External links ===

[https://nostradamus.coinsfriendly.com Bitcoin NostrAdamus] web site

[https://twitter.com/bitcoin_trend Bitcoin forecasts on Twitter]

Bitcoin Porn

2025-05-25T17:43:28Z

Calliptamus:

'''Bitcoin Porn''' is an adult Bitcoin related image and news blog. The site boasts to be both Ad Free and Pop Up Free using [https://en.bitcoin.it/wiki/Browser_Bitcoin_Miner Browser Bitcoin Mining]. Through the day are postings of pornographic content both video and still images, while [[Bitcoin]] related current news, web comics, and the [http://bitcoinporncast.tumblr.com Bitcoin Porncast] are featured.

==History==

As of April 21, 20112 this site appears to no longer be publishing.

==External Links==
* [http://bitcoinporn.tumblr.com Bitcoin Porn]
* [http://bitcoinporncast.tumblr.com Bitcoin Porn Podcast]
* [http://twitter.com/bitcoinporn Bitcoin Porn Twitter]

Bitcoin Press Center

2025-05-25T17:42:56Z

Calliptamus:

A community site that provides bitcoin expert contacts for the global press and media.

Launched by Andreas Antonopoulos as a sensible reaction to the bitter infighting regarding potential press contacts within the community, this resource supports multiple languages and time zones as well as targeted searches of individuals that have expressed a willingness to be available for media interviews.

Nominations for [[Bitcoin]] experts accepted with the only criteria being accuracy of their stated credentials and confirmation that they want to be listed.

==External Links==

* [http://bitcoinpresscenter.org BitcoinPressCenter.org] website

[[Category:Marketing]]

Bitcoin Prices (extension)

2025-05-25T17:42:23Z

Calliptamus:

Firefox extension displaying current [[Bitcoin]] prices.
==Author==
Corey Farwell
==External Links==
* install: [https://addons.mozilla.org/en-US/firefox/addon/none/ Bitcoin Prices] Mozilla.org addons
* source: [https://github.com/frewsxcv/Bitcoin-Prices Bitcoin prices] GitHub

[[Category:Firefox extensions]]
[[Category:Open Source]]
[[Category:License/GPLv3]]

Bitcoincloudservices

2025-05-25T17:41:38Z

Calliptamus:

Bitcoin Cloud Services (BTC Cloud Services LTD) is a Bitcoin Foundation Silver Member and UK incorporated entity. They provide affordable [https://www.bitcoinmining.com/best-bitcoin-cloud-mining-contract-reviews/ Bitcoin cloud mining contracts] with live technical Support, no hidden fees, and instant mining contract delivery. [[Bitcoin]] cloud services sells hashing power by the gigahash (GH/s), has no pool fees, and offers daily payouts.

Bitcoin Cloud Services sells hashing power by the Gighash (GH/s)
Contract length is 5 years
Minimum contract purchase of 50 GH/s
Maximum contract purchase of 70 TH/s

==External Links==

* Website [https://www.bitcoincloudservices.com/ Bitcoincloudservices.com]

[[Category:Mining contractors]]
[[Category:Mining]]
[[Category:Mining contracts]]
[[Category:ASIC mining]]

Bitcoini.com

2025-05-25T17:40:16Z

Calliptamus:

[https://bitcoini.com/ Bitcoini.com] is the only Bulgaria-based market place for Bitcoin exchange in the country and worldwide. The primary aim of the website is to popularize [[Bitcoin]] and offer a quick, cheap and secure way to sell or purchase Bitcoins. Bitcoini.com offers various methods for purchasing/selling bitcoins depending on the location of the buyer/seller: bank transfer (Bulgarian or Romanian bank), ePay (financial transactions system in Bulgaria), Econt (Bulgarian courier service), Bulgarian Posts (Postal order), and “in cash” (only for the territory of Sofia), Western Union and MoneyGram (for international customers).
The only payment method available in Romania is bank transfer in EUR. Internationally,
[https://bitcoini.com/ Bitcoini.com] offers only a “buy” service for bitcoins in USD, using Western Union or MoneyGram.

== Buy bitcoins ==

===Buying process for international customers (in USD)===

The user needs to register at bitcoini.com and place an order through their profile. The order can be placed only after the user enters an amount of bitcoins he is willing to buy (minimum 0.5 BTC), provides a valid Bitcoin address and selects either “Western Union” or “MoneyGram” as a payment method.
For both payment options the user needs to follow the same instructions, namely:

1. Place an order, determining the amount of bitcoins he is willing to purchase, provide a valid Bitcoin wallet address and select one of the two payment options.

2. Visit a Western Union or MoneyGram office and transfer the amount that is mentioned in the order.
(He can view the payment details after he places the order)

3. After initiating the transfer, Western Union/MoneyGram will provide the user with a MTCN number.

4. The user needs to submit this number to bitcoini.com, using the fill-in from that will automatically appear in the newly created order, together with the name under which the money transfer has been made.

Once and MTCN and a valid name have been submitted by the user, bitcoini.com will use this information to acquire the cash from a Western Union/ MoneyGram office. The user's order will be fulfilled and the bitcoins will be sent to his bitcoin wallet address only after the money is physically acquired by [https://bitcoini.com bitcoini.com].

For faster order fulfillment it is recommended that users use the services of Western Union.

===Buying process in Bulgaria (in BGN)===

The user needs to register at bitcoini.com and place an order through their profile. The order can be placed only after the user enters an amount of bitcoins he is willing to buy (minimum 0.1 BTC), provides a valid Bitcoin address and choses from one of the following payment methods:

====Bank transfer====
After entering an amount of bitcoins for purchase, submitting a valid Bitcoin wallet address and selecting “bank transfer” as a payment option, the user needs to transfer the amount mentioned in the order to a bank account, which will be provided after the order is placed. After the transfer is completed and the money has arrived on the bank account of bitcoini.com, the bitcoins are send to the user’s Bitcoin wallet address.

====EasyPay====
After entering an amount of bitcoins for purchase, submitting a valid Bitcoin wallet address and selecting “EasyPay” as a payment option, the user has two options: either to visit an office of EasyPay and initiate an order to the Clinet ID of bitcoini.com (provided after the order is placed) or to transfer the funds directly through ePay, a Bulgarian electronic payments system (this option requires a valid ePay account with a registered debit/credit card). After the money has arrived at bitcoini.com account at ePay, the bitcoins are send to the user.

====Econt====
After entering an amount of bitcoins for purchase, submitting a valid Bitcoin wallet address and selecting “Econt” as a payment option, the user needs to visit an office of Econt and initiate a money order using the details, provided to him after placing the order.

====Bulgarian Posts====
After entering an amount of bitcoins for purchase, submitting a valid Bitcoin wallet address and selecting “Postal order” as a payment option, the user needs to visit an office of Bulgarian Posts and initiate a money order using the details, provided to him after placing the order.

====Payment in cash====
This payment option is available only for the territory of Sofia. After entering an amount of bitcoins for purchase, submitting a valid Bitcoin wallet address and selecting “Cash” as a payment option, the user needs to contact bitcoini.com using either the online chat service or the phone number that will be provided to him after placing the order.

===Buying process in Romania (in RON)===

The user needs to register at bitcoini.com and place an order through their profile. The order can be placed only after the user enters an amount of bitcoins he is willing to buy (minimum 0.1 BTC), provides a valid Bitcoin address and selects “Bank transfer” as a payment method.

The user needs to visit a bank and make a money transfer to the bank account of bitcoini.com in Romania (details will be provided after placing an order). After the money has successfully arrived in that bank account, the relevant amount of bitcoins is sent to the user.

==Sell bitcoins==

===Selling process for Bulgaria (in BGN)===

The user needs to register at bitcoini.com and place an order through their profile. The order can be placed only after the user enters an amount of bitcoins he is willing to sell (minimum 0.1 BTC), transfer the bitcoins to the Bitcoin wallet address of bitcoini.com and selects a payment option. There are two ways for the user to be credited for selling his bitcoins
bank transfer or “in cash”

====Bank transfer====

The user needs to place a selling order at bitcoini.com by entering an amount he is willing to sell, sending that amount of bitcoins to the Bitcoin wallet address of the website, entering the BTC transaction number (visible after the initiation of the bitcoin transfer at the user’s Bitcoin wallet), proving first and family name, the IBAN number of his bank account, as well as the BIC code of his bank. After receiving the bitcoins at the bitcoini.com Bitcoin wallet, the money is transferred to the bank account of the user.

====Selling in cash====

This service is available only for the territory of Sofia. The user needs to place a selling order at bitcoini.com by entering an amount he is willing to sell, sending the bitcoins to the Bitcoin wallet address of the website, entering the BTC transaction number (visible after the initiation of the bitcoin transfer at the user Bitcoin wallet), and contacting bitcoini.com to schedule a meeting using either the online chat service or the phone number that will be provided to him, after placing the order.

==Speed of service ==
The speed of the services offered by bitcoini.com depends on the time that is required for the owners of the website to be 100% certain that:

1. In the case of a user purchasing bitcoins – the required amount, mentioned in the user’s order, has been delivered to one of the various accounts (depending on the payment method) of bitcoini.com, or have been delivered “in cash”. As soon as the 100% level of certainty that an order has been paid is reached, the bitcoins are send to the user. This can take from a couple of minutes to a maximum of 12 hours, since any order is active for only 12 hours. Payments in cash are organized at a convenient for both sides place and time.

2. In the case of a user selling bitcoins – the bitcoins have been delivered to the Bitcoin wallet of bitcoini.com. Added to this is the time required for the bank, or in the case of international users – Western Union or MoneyGram, to process the payment, initiated in the name of the user by bitcoini.com. Payments in cash are organized at a convenient for both sides place and time.

==News Service==

For Bulgarian customers, bitcoini.com offers a news service in Bulgarian, which is primarily composed of English articles translated into Bulgarian. Proper references regarding the original sources of the texts are always included. Original articles prepared by bitcoini.com are provided irregularly.
News services for the Romanian and English versions of the website are RSS feed-based.

==Fees==

Bitcoini.com determines the “buy” and “sell” prices for bitcoins on the basis of the price of other exchanges and adds a small managing fee. The buy price is usually lower than the buy price at Mt.Gox.

==Security==
The owners of the website are trying to provide customers with the best possible Bitcoin buying/selling service in an uncertain regulatory environment. The development of the bitcoini.com brand name demands high quality customer relations and a high level of customer satisfaction.

==Affiliate program==
The website offers an affiliate program for its users, which is a good way of earning bitcoins by popularizing bitcoini.com
The user can use one of the pre-made banners available at the website and place it in his forum signature, on his website, or in Facebook.
If another user clicks on the banner, registers at bitcoini.com and makes an order, the original user earns a 2% fee from the amount of the bitcoin order of the new user.
Various banner sizes in English are available at: [https://bitcoini.com/en/affiliate.php?mode=banners]
The same banners are also available in Romanian and Bulgarian.

==See also==

[https://bitcoini.com/en/about.php FAQ]

[[Category:Exchanges]]

Bitcoinfactswiki

2025-05-25T17:39:41Z

Calliptamus: /* An Unusual Fork */

== Historical Note Only ==

The BitcoinFactsWiki has been removed from its original location; Tom Zander being its originator has resigned from the -classic project and this resignation is likely reflected in the removal of projects like the BitcoinFactsWiki.

== An Unusual Fork ==
The website represented by [http://bitocinfactswiki.github.io The Bitcoinfactswiki] and announced in the Reddit story from its apparent creator [https://www.reddit.com/r/btc/comments/4n44oi/bitcoin_wiki_renamed_to_bitcoinfactswiki here] is not actually a "renamed" version of this site, but a plain fork, contrary to the claims in that story. The person behind it, Thomas Zander, is the (apparently only remaining,) developer of Bitcoin Classic.

The facts on Bitcoinfactswiki are in multiple cases wrong and the information thereon regarding technical information about Bitcoin appears to be politically-motivated and -edited. For example, as of this writing the page [https://bitcoinfactswiki.github.io/NLockTime/ on Bitcoinfactswiki about nLockTime] states:
<blockquote>
'''This tag is deprecated and OP CHECKLOCKTIMEVERIFY is the suggested replacement.'''
</blockquote>
This is incorrect. nLockTime is not deprecated nor is it insecure.<ref>[https://www.reddit.com/r/btc/comments/4uv21m/announcing_blockstreams_greenaddress_acquisition/d5t9rm8 Greg Maxwell stating clearly thet nLockTime is alive and well.]</ref>

It is likely that due to the obstacle that nLockTime presents to the hard-forking narrative, it is being downplayed as a technical objection and stated to be a deprecated function even though it has been an integral part of [[Bitcoin]] [[transaction]] structure almost from Bitcoin's inception. In particular, nLockTime (or lock_time based transactions) can be used as a form of escrow. In the event of certain forms of advocated hard forks, the result would be the confiscation and/or destruction of nLockTime based escrowed funds.

== References ==
<references/>

Bitcoined

2025-05-25T17:38:16Z

Calliptamus:

=== Bitcoined is a blog which discusses various Bitcoin-related topics. ===

The Bitcoined blog was described as being a weekly [[Bitcoin]] news and review blog with various topics relating to Bitcoin, including exchange rates, tangible items, new innovations and more. Look out for new website alerts and new shops, as well as a brand new range of information pages, including Mining, Useful Links and What is Bitcoin.

==History==

The service never published updates.

==External Links==

* [http://bitcoined.wordpress.com Bitcoined]

Bitcoincatalog.com

2025-05-25T17:37:41Z

Calliptamus:

== The Directory ==

BitcoinCatalog's primary objective is to provide the Bitcoin community with a definitive directory of sites that either accept Bitcoins for goods and services or offer Bitcoin-related information, software or currency exchange. The site is similar to a yellow pages directory for [[Bitcoin]]. BitcoinCatalog is organized into categories to make it easy to find whatever one is looking for and to help people discover whatever they are looking for in the Bitcoin community all around the world.

Adding your site to the directory is absolutely free, so if you accept Bitcoins or have a Bitcoin-related site, you can add it to the directory. There are clear directions for adding your site [http://bitcoincatalog.com/policies/getting-listed here].

=== Information & Resources ===

In addition, BitcoinCatalog has other areas of the site to help bring together resources and tools to help the Bitcoin community keep up with all the latest news and information surrounding Bitcoins. There are news feeds, blogs and links to other informative sites. BitcoinCatalog encourages visitors to submit their articles and commentaries. To submit an article, click [http://bitcoincatalog.com/contact-us here].

=== Community ===

BitcoinCatalog has also built a Facebook-like social network for the Bitcoin [http://bitcoincatalog.com/news-feeds/home community]. Everyone that registers gets a free profile so they can get to know others from around the globe, upload galleries, write blogs and create or join user groups. Bitcoin enthusiasts can also network and chat with other members. In addition to the social community, they offer a [http://bitcoincatalog.com/forum/main-forum/categories forum] where people can seek out answers to Bitcoin-related questions.

BitcoinCatalog can be contacted [http://bitcoincatalog.com/contact-us here].

Bitcoinica

2025-05-25T17:36:34Z

Calliptamus:

Was an online service that enabled leveraged speculation in its contract-for-difference (CFD) market against the [[Bitcoin]] to USD (BTC/USD) exchange rate.

==History==

The service was launched on September 8, 2011<ref>[https://bitcointalk.org/index.php?topic=42267.0 Bitcoinica - Advanced Bitcoin Trading Platform]</ref>. On March 1st, 2012 the site suffered a significant financial loss when a web hosting had an internal security breach that gave the attacker access to a wallet in which Bitcoinica stored funds. More than 43K bitcoins were stolen by the attacker. The operator provided a statement that reserves were sufficient to cover the loss<ref>[http://bitcointalk.org/index.php?topic=66979.0 Bitcoinica lost 43,554 BTC from Linode compromise, suspicious TXIDs publicized]</ref>.

Announced on April 20, 2012 was that Bitcoinica had "reorganized" and was now operated as Bitcoinica LP and had become a registered Financial Services Provider<ref>[http://bitcointalk.org/index.php?topic=77523.msg861805#msg861805 Bitcoinica is now a registered Financial Services Provider!]</ref>.

On May 11, 2012 Bitcoinica suffered for the second time a security incident in which a large amount of coins were stolen from its hot wallet<ref>[http://bitcointalk.org/index.php?topic=81045.0 Bitcoinica site is taken offline for security investigation]</ref>.

On August 1, 2012 the Wendon Group investment fund as creditor to Bitcoinica LP announced that it will appoint a receiver under New Zealand law<ref>[http://bitcointalk.org/index.php?topic=97272.0 Bitcoinica Consultancy abandons customers. Bitcoinica to enter Liquidation]</ref>.

==References==
<references />
[[Category:Defunct products or services]]

Bitcoin Money

2025-05-25T09:14:55Z

Calliptamus:

'''Bitcoin Money''' is a blog relating to various financial aspects of Bitcoin.

The blog's most popular post, [http://bitcoin.tumblr.com/post/2560941112/rebooting-of-money The Rebooting of Money] is an audio podcast that provides an introduction to [[Bitcoin]].

==External Links==

* [http://www.bitcoin.tumblr.com BitcoinMoney.com]
* Twitter: [http://twitter.com/bitcoinmoney @BitcoinMoney]

[[Category:Blogs]]
[[Category:Investing]]
[[Category:Financial]]

BitBuyer

2025-05-19T23:05:02Z

Calliptamus:

'''[http://bitpoker.biz/bitbuyer/ BitBuyer]''' is a [[Bitcoin]] Concierge service, enabling members (and the general public) to order anything from travel reservations to pizza. They also run an affiliate program in which members can make commission on sales generated from their links, similar to the Amazon affiliates program.

Bitcoin Road Trip

2025-05-19T21:01:49Z

Calliptamus:

A coast-to-coast journey where no dollars are being spent, only bitcoins. The trip was made by [[Bitcoin]] community member Plato between April 2011 and June 2011.

The plans for the trip were communicated on March 21, 2011 which described the motivation and the method for traveling from Hartford to L.A. spending no dollars for expenses or other purchases<ref>[http://bitcointalk.org/?topic=4752.0 PLATO's Bitcoin Road Trip]</ref>.

The trip is being blogged and tweeted. Tweets use the hashtag #BItcoinRoadTrip.

While on the leg of the trip through Alabama, Plato's trip was put on hold to assist with the cleanup following the tornadoes that occurred close by to Plato. Plato made a plea for donations from the Bitcoin community and funds were received were then donated to a tornado victim from a trailer park<ref>[http://bitcointalk.org/?topic=6752.msg101417#msg101417 ALABAMA DISASTER RELIEF FUND]</ref>.

On May 25th Plato was interviewed on the Corbett Report<ref>[http://www.youtube.com/watch?v=gcn8cNCk9hM The World's First Bitcoin Road Trip]</ref>.

Plato arrived in Los Angeles on June 13th 2011<ref>[http://www.bitcoinmoney.com/post/6501258333 Plato’s #BitcoinRoadtrip has arrived in L.A.]</ref>. The first thing he purchased with US Dollars was a broccoli cheddar breadbowl at Panera in Venice Beach.

==External Links==

* [http://therealplato.tumblr.com/ http://therealplato.tumblr.com/] blog (with RSS at the bottom)
* [http://goo.gl/CflUH Map]
* [http://twitter.com/therealplato @TheRealPlato] Twitter account
* [mailto:therealplato@gmail.com therealplato@gmail.com] email

==References==
<references />

[[Category:Marketing]]

Bitcoin SMS Alert

2025-05-19T05:30:38Z

Calliptamus:

'''Description:'''

Bitcoin SMS Alert is a Windows based PC application that sends SMS text alerts directly to a user's phone. The current version obtains price information using API's from either [http://www.MtGox.com MtGox.com] or [http://www.BitcoinCharts.com BitcoinCharts.com] in three different currency denominations (USD / GBP / EUR), and will alert the user if price and/or price percent changes have have exceeded a given upper or lower bound. Other features to prevent too many text alerts, and different update intervals are included as well.

Unlike some other monthly services that exist, this program costs only a one time fee of $2.99 USD payable via [http://www.MtGox.com MtGox] instant [[Bitcoin|BTC]] checkout. Updates are provided free of charge if an e-mail address is supplied upon checkout. The author claims that custom tweaks / upgrades can be made for small donations.

'''Current Version:''' v1.1 (Made available on August 28, 2012)

More information and a video demo can be found on the [http://www.BitcoinSMSAlert.com website].

[[File:Bitcoin_SMS_Alert_DemoPicture.jpg‎]]

Bitbrothersllc.com

2025-05-18T22:58:43Z

Calliptamus:

Hello Fellow Bitcoiners,
This is the owner of the new exchange website called bitbrothersllc.com . As a compnay, we do things differnently than most exchange companies in that we accept not only bank transfers and other forms of regular paymant, but that we accept cold hard cash mailed in orders. This allows some of our customer base to stay completely anonymous. Ironically, many of our competitors have eliminated the possiblity of staying anonymous through a transaction which was the entire point of the [[bitcoin]] buzz in the first place. We can also asure our custumers that when it comes to bitcoin exchanges, no one can parellel the customer servece in terms of speed and honesty than bitbrothersllc.com . We hope to do some exchanges with you.

http://www.bitbrothersllc.com

Bitcoin roulette

2025-05-18T22:58:01Z

Calliptamus:

The Bitcoin roulette that is mostly offered in gambling and roulette sites is based on the European roulette. There are many other notable forms of roulette that include but not limited to European roulette, American Roulette, and French Roulette. These are all variations of European roulette who's differences include the addition to 0 and 00 on the table felt. The French version has variations on the layout of the board, which mirrors the sequence of numbers on the wheel instead of the numerical layout.

When you bet on roulette with [[Bitcoin|bitcoin]]s, you will notice that you wager on inside and outside bets, just like in roulette games offered by regular online casinos. However, thanks to the use of bitcoins, the process of betting has become a lot easier.

Some roulette sites allow players to simply send their wager directly from their BTC wallet to the dynamically registered address of their bets. This process doesn’t require a registered account. On the other hand, some gambling sites require players to create an account and deposit bitcoins so that they can place their bets.

There are many places to play [https://www.wagerx.com/live-roulette bitcoin roulette]. When choosing an online casino you must take into consideration jurisdiction, regulations in your country or state of origin, legislation in our country, personal preferences to promotions, ease of use, and game availability.

Bitcoin Report

2025-05-18T22:57:06Z

Calliptamus:

'''The Bitcoin Report''' was a blog focused on publishing various statistics about the state of the Bitcoin P2P network. Its content was related mainly to the examination of various bitcoin [[Transaction|transactions]] and included 'Top 100 Rich Lists' of [[Bitcoin]] addresses by balance.

The blog was announced on January 16th, 2011.<ref>[http://www.bitcoin.org/smf/index.php?topic=2818.0 The Bitcoin Report]</ref> Last update was posted on December 4th, 2011.

In September 2019 the blog was still online, although some of its charts were no longer available.

==External Links==

* [http://bitcoinreport.blogspot.com Bitcoin Report] blog

==References==
<references />

[[Category:Blogs]]

Bitcoin Slots

2025-05-18T16:57:57Z

Calliptamus:

In the Bitcoin gambling community you can find the classic slots, powered by bitcoin and providing in the same time a provable fairness system.

Most [[Bitcoin]] dice betting sites boast of their provable fairness. With provably fair gaming in existence, you can verify both your own spins and those of anyone else at any point.

Bitcoin Slots

2025-05-18T16:57:26Z

Calliptamus:

In the Bitcoin gambling community you can find the classic slots, powered by bitcoin and providing in the same time a provable fairness system.

Most [[Bitcoi]] n dice betting sites boast of their provable fairness. With provably fair gaming in existence, you can verify both your own spins and those of anyone else at any point.

Bitcoin Sports Trade

2025-05-18T16:12:59Z

Calliptamus:

[http://www.bitcoinsportstrade.com Bitcoin Sports Trade] is a new user vs user bet matching site.

This betting platform lets you to choose your own point totals at even odds. This gives players the power to dictate what the ‘true’ line is.

To simplify this concept think of it in terms of a bitcoin exchange (like bitstamp, campbx, coinbase , ect) in the sense that there is no actual “Real” set price of [[Bitcoin|BTC]], the price is determined by the supply and demand of the customers and a recommended price is then set on the exchange based on what the last trade(s) closed at. This is how players determine what the “True” line is, just like a bitcoin exchange does.

No Juice!

In addition to being able to create your own lines you can do so without paying any additional Juice! All bets are always at even money.

Traditional sportsbooks offer the ability to take a better number on a current line but they will charge you extra juice which can make the bet far too expensive.

What are the fees?

The only fee is the bet matching fee of 3.5% which is deducted from completed bets.

Anonymous Betting

To create an account all you need is an email address.

Instant Payouts

As soon as a contest is competed your account balance will reflect your winnings and you’ll be free to withdraw your BTC instantly.

No Minimum Withdrawals

There are no withdrawal minimums so whatever amount you win you can instantly withdraw at any time.

No Withdrawal Fees

There are no withdrawal fees.

Live In-Play Betting

Bet while you watch the game. Not only can you place bets prior to the game starting, you can bet at any point during the game. You can follow the game and make bets on the fly.

Earn 100% Affiliate Commissions!

The affiliate program features 100% affiliate commissions for the first month! After the first month earn up to 50% commissions by simply referring 2 new members each month. All commissions are paid in BTC.

Your Commission Earnings are Paid Out Instantly!

Unlike traditional affiliate programs that usually take over a month to get paid, commissions are paid out as soon as you earn it! Your account balance is credited instantly.

Visit [http://www.bitcoinsportstrade.com Bitcoin Sports Trade] for more information and to create an account.

Bitcoin Stock Exchange

2025-05-18T15:20:26Z

Calliptamus:

The Bitcoin Stock Exchange(BSE) is an online trading platform intended to provide a venue from which Bitcoin related stocks can be issued, bought and sold, using Bitcoin exclusively. We welcome anyone to open an account, whether it be as a trader or as a company. No initial cost or fees are required to do so.

The idea that held promise of the BSE was conceived in spring 2011, and after undergoing some time in the developmental stages, it came to fruition in the summer 2013. Thus beginning to take shape as the exchange we see today.

The general philosophy behind the exchange is to help catalyze progression in the development of the [[Bitcoin]] infrastructure, thus solidifying Bitcoin as a practical means of exchange instead of only being the mere vessel of pure price speculation.

===External links===
[http://www.bitcoinstockexchange.org/ Bitcoin Stock Exchange Website]

[http://forum.bitcoinstockexchange.org/ Bitcoin Stock Exchange Forum]

[[Category:Defunct exchanges]]
[[Category:Investing]]
[[Category:Stock Exchanges]]

Bitcoin Text Message

2025-05-18T15:19:31Z

Calliptamus:

'''Description'''

Bitcoin Text Message is a simple Web based service which offers to send SMS alerts to registered users mobile phones when the price of [[bitcoin]] changes.

'''Website address'''

http://www.bitcointextmessage.com/

'''Details'''

Site was launched on 23-Feburary-2013

'''Current Features'''

Notify user when Mt Gox exchange rate goes above a threshold.

Notify user when Mt Gox exchange rate goes below a threshold.

SMS price alerts on bitcoin price changes to your mobile phone

Bitcoin Ticker

2025-05-18T15:18:38Z

Calliptamus:

Keeps track of the current [[Bitcoin]] market prices - Chrome extension.
Detailed market information, collected in real time from:
* https://mtgox.com
* https://www.tradehill.com
* https://bitcoin7.com
* https://bitomat.pl
* https://britcoin.co.uk
==This extension can access==
Your data on:
* Sites above
==External Links==
* [https://chrome.google.com/webstore/detail/bkjcngcenokaadmhbmcokmkanjibmmje Bitcoin Ticker]

[[Category:Chrome extensions]]

Bitcoin Venezuela

2025-05-18T15:17:17Z

Calliptamus: /* Generador de billetes/cheques en jQuery */

[http://bitcoinvenezuela.com Bitcoin Venezuela] fue creada el día 11 Octubre de 2012 para dar a conocer Bitcoin en Venezuela. Con presencia en España y Venezuela, tenemos el objetivo principal de dar a conocer esta nueva forma de pago y orientar a los nuevos usuarios.

== Nosotros ==

Bitcoin Venezuela es un proyecto para crear presencia de los bitcoins en este país. Nuestro objetivo principal es dar a conocer la moneda en Venezuela y establecer unas bases de conversiones para quienes las quieran seguir a las monedas internacionales.

== Venezuela ==

Venezuela se encuentra actualmente bajo un régimen socialista-comunista en el que existen restricciones para la adquisición de divisas y esto dificulta la compra/venta de productos extranjeros, así como la salida de dinero del país para viajes, compras o ahorros.

Al existir un control cambiario la cantidad de divisas (dólares, euros...) que puede adquirir una persona a precio de mercado es excesivamente limitada; disparándose así el precio, debido a la alta demanda, de estas modenas extranjeras en el mercado paralelo.
El precio actual del Dólar regulado (Dólar CADIVI) es de 4,29 Bs [http://bitcoinvenezuela.com/venezuela.php (ver precio actualizado)], pero comprarlos en la calle a este precio es imposible. El precio que se maneja es el del Dólar Paralelo (Dólar Permuta, Lechugas...) que ronda los 13,95 Bs [http://bitcoinvenezuela.com/venezuela.php (ver precio actualizado)].

== Servicios y herramientas ==

=== Generador de billetes/cheques en jQuery ===

Existen algunas herramientas para generar billetes/cheques de Bitcoin para poder usarlos como pago físico, pero estas están recibiendo muchas críticas debido al uso de lenguajes de programación que funcionan desde el servidor (PHP, Python, etc) y el miedo que esto supone al existir la posibilidad de enviar los datos al servidor.

Bitcoin Venezuela ha creado una herramienta que funciona con jQuery y por tanto ningún dato introducido en el formulario es enviado al servidor para la creación del billete. Al usar jQuery funciona desde el navegador cliente y no es necesario instalarlo en un servidor para funcionar. Se puede utilizar sin conexión a internet para mayor seguridad una vez cargada la página.

Consiste en dos campos de texto, uno para la Dirección [[Bitcoin]] y otro para la Llave Privada. Una vez introducidos se genera el billete y simplemente hay que imprimirlo.

[http://bitcoinvenezuela.com/billete.html Ir al generador]

== Enlaces externos ==
* [http://bitcoinvenezuela.com Bitcoin Venezuela] - web oficial
* [mailto:contacto@bitcoinvenezuela.com Contacto] - email [http://pool.sks-keyservers.net:11371/pks/lookup?op=vindex&search=0x637E773CF6DDEE8F009F84616930CFE70FA4130C (PGP)]
* [https://twitter.com/btcven @btcven] - Twitter
* [https://www.facebook.com/btcven Página de Facebook]
* [https://plus.google.com/103832285759023829835/posts Google+]
* [https://bitcointalk.org/index.php?action=profile;u=70647 Usuario en Bitcointalk]

Bitcoin Wednesday

2025-05-18T15:14:44Z

Calliptamus: /* Start Your Own Local Community */

Bitcoin Wednesday is a global meetup event scheduled for the first Wednesday of every month.

The [https://bitcointalk.org/index.php?topic=248358.msg2635123#msg2635123 genesis] of this event was a forum post highlighting the coincidental synchronicity of nearly a dozen local bitcoin meetups.

If you are a member of any of the [https://en.bitcoin.it/wiki/Meetups local bitcoin meetups], you should make every effort to promote a special meeting for Bitcoin Wednesday.

Add your city here, or on [https://bitcointalk.org/index.php?topic=248358.msg2635123#msg2635123 the discussion for this event].

==Start Your Own Local Community==
# '''Find a good location'''. It helps if the meeting place is accessible, has WiFi, and food and beverages. The merchant does not have to accept Bitcoin yet.
# '''Add your city to the list'''. Also announce your meetings in the [https://bitcointalk.org/index.php?topic=248358.msg2635123#msg2635123 forum topic].
# '''Invite local Bitcoin people'''. Some great resources to find locals are [http://bitcoins.meetup.com Meetup.com], and [http://LocalBitcoins.com LocalBitcoins.com]. You may also find numerous regional groups on social media sites like [http://reddit.com/r/bitcoin Reddit], Facebook, and Google Plus.
# '''Show up and have fun'''. If the meeting spot merchant will allow it, consider making a banner/display that identifies your group as [[Bitcoin]] friendly. This will advertise your presence to other patrons and generate more interest.

==Event Agenda Ideas==
* Socialize with other great people interested in Bitcoin: Newcomers, gurus and early pioneers, writers, entrepreneurs, economists, investors, activists, etc. Celebrities have been known to drop in on these events. Don't see someone you think should be there, just bring them along.

* Learn more and teach others.

* Buy, sell, barter. Keep the coins circulating in the community.

* Talk about how to spread Bitcoin to more people, more businesses.

* Engage in fascinating conversations.

* Demonstrate or pitch your latest Bitcoin project.

* Hold presentations and debates.

* Indulge in good food and drink.

==Cities With Bitcoin Wednesday==
{| class="wikitable"
! City !! Description
|-
| [https://www.meetup.com/BitcoinWednesday/ Amsterdam] || Talks and drinks organized by [https://www.BitcoinWednesday.com Bitcoin Wednesday]
|-
| [http://BitcoinsInVegas.com Las Vegas] || Bitcoin Lunch Mobs every Wednesday
|-
| Sydney || General Bitcoin-related discussion.
|-
| Vancouver || General Bitcoin-related discussion.
|-
| Munich || General Bitcoin-related discussion.
|-
| Pittsburgh || General Bitcoin-related discussion.
|-
| Toronto || General Bitcoin-related discussion.
|-
| Austin || General Bitcoin-related discussion.
|-
| Paris || General Bitcoin-related discussion.
|-
| Buenos Aires || General Bitcoin-related discussion.
|-
| Cinncinnatti || General Bitcoin-related discussion.
|-
| [http://www.meetup.com/bitcoin Stockholm] || Lunch with general Bitcoin-related discussion.
|-

Bitcoin Yellow Pages

2025-05-17T22:21:00Z

Calliptamus:

Bitcoin Yellow Pages is a leader in search, design, and advertising for Bitcoin business. The site offers a completely free search directory for users to locate [[Bitcoin]] businesses based on keyword, location, or category. Users can browse the globe using the world map feature to find businesses accepting bitcoin payments close by. Companies are able to list themselves for free on the site by simply registering and following several simple steps. Additional services include graphic design, web design, branding, and creative development for Bitcoin businesses.

The site was launched in July, 2013. The site aims to contain more listings with higher quality details than any other directory service.

==External Links==

* [https://bitcoinyellowpages.com Bitcoin Yellow Pages]
* [https://bitcoinyellowpages.com/free-business-listing/ Bitcoin Yellow Pages - Design and Development]
* [https://bitcoinyellowpages.com/design-and-development/ Bitcoin Yellow Pages - List Your Business]

BitcoinSentiment

2025-05-17T20:05:20Z

Calliptamus:

'''BitcoinSentiment''' is a non-profit, ad-free site tracking the voter's sentiment towards [[Bitcoin]] through the means of continuous polling. The idea is to provide the technical means required for tapping into the power of crowd-sourcing.

The quality of the data increases as the number of voters increases and you can contribute, by putting voting widgets on your site. To encourage the use of widgets, they are designed to be non-intrusive and to not "steal your visitors".

The data generated on the site is free for use and can be downloaded by anyone.

The site offers a variety of charts, with the purchasing power of Bitcoin plotted in terms of other asset classes such as gold and inflation-protected US Treasuries.

==External Links==
*[http://bitcoinsentiment.com/ BitcoinSentiment website]

[[Category:Trading]]
[[Category:Investing]]
[[Category:Economics]]

OpenVMarket

2025-05-17T19:38:13Z

Calliptamus:

A service where job seekers can post resumes and search job listings and where employers can search resumes and post job listings.

The site lists its mission is to foster the [[Bitcoin]] ecosystem with the latest technologies in hopes of creating a larger Open Virtual Market for a more Social and Rich Internet for the future.

The site can be cutomized to store Searches and Jobs.

==External Links==
* [http://www.OpenVMarket.com OpenVMarket] web site

==References==
<references />

Uc bitcoin

2025-05-17T16:09:30Z

Calliptamus:

'''uc_bitcoin''' is a [[Bitcoin]] payment method for the Ubercart shopping cart for Drupal.

uc_bitcoin is free and unencumbered public domain software.

==External Links==

* [http://github.com/mikegogulski/uc_bitcoin uc_bitcoin] on Github
* [http://www.nostate.com/3955/uc_bitcoin-a-bitcoin-payment-method-for-ubercartdrupal Project homepage]

[[Category:Shopping Cart Interfaces]]

Unichange.me

2025-05-17T16:08:42Z

Calliptamus: /* Buy options */

[[Category:Exchanges]]

==Unichange.me==

Unichange.me is created to serve all people willing to make fast, secure and reliable buy, sell or exchange operations with Bitcoin.
Its team consists of experienced players of e-currency exchange market, striving to provide high-level of work to our clients. Unichange.me staff members have more than 8 years of experience in financial sphere.

==Features==

* Highly secured transactions: SSL encryption is used for all orders placed on the website.
* Large reserves: amount of reserves is appropriate for any bulk buyer or wholesaler.
* Reliable service: All orders of Unichange.me are completed in a timely manner and on the conditions stated on the website.

==Buy options==

Unichange.me offers the clients wide variety of [[Bitcoin]] wallet deposit methods - Perfect Money USD/EUR, OkPay USD, FasaPay USD, JustForex USD.

[https://unichange.me/order/simple/perfect_money_usd_bitcoin Perfect Money USD]

[https://unichange.me/order/simple/perfect_money_eur_bitcoin Perfect Money EUR]

[https://unichange.me/order/simple/okpay_usd_bitcoin OkPay USD]

[https://unichange.me/order/simple/fasapay_usd_bitcoin FasaPay USD]

[https://unichange.me/order/simple/justforex_usd_bitcoin JustForex USD]

==Sell options==

Unichange.me propose the customers a wide choice of Bitcoin withdrawal methods among which bank transfer USD/EUR, Western Union USD money transfer, Unichange.me debit card, personal credit/debit card USD/EUR, Perfect Money USD/EUR, OkPay USD, FasaPay USD/IDR, Paypal USD, JustForex USD.

[https://unichange.me/order/simple/bitcoin_wire_transfer_usd Bank transfer USD]

[https://unichange.me/order/simple/bitcoin_wire_transfer_eur Bank transfer EUR]

[https://unichange.me/order/simple/bitcoin_western_usd Western Union USD]

[https://unichange.me/order/simple/bitcoin_unichange_card_usd Unichange.me debit card USD]

[https://unichange.me/order/simple/bitcoin_credit_card_usd Debit/debit card USD]

[https://unichange.me/order/simple/bitcoin_credit_card_eur Debit/credit card EUR]

[https://unichange.me/order/simple/bitcoin_perfect_money_usd Perfect Money USD]

[https://unichange.me/order/simple/bitcoin_perfect_money_eur Perfect Money EUR]

[https://unichange.me/order/simple/bitcoin_okpay_usd OkPay USD]

[https://unichange.me/order/simple/bitcoin_fasapay_usd FasaPay USD]

[https://unichange.me/order/simple/bitcoin_fasapay_idr FasaPay IDR]

[https://unichange.me/order/simple/bitcoin_paypal_usd PayPal USD]

[https://unichange.me/order/simple/bitcoin_justforex_usd JustForex USD]

==Bitcoin debit card ==

Unichange has designed special offer for active Bitcoin users - Unichange debit card for fast Bitcoin withdrawal to fiat money.

Basic features of Unichange card:
*the cost of the card is $14
*possibility to order Unichange card in USD, EUR or GBP currency
*card maintenance fee is $1/month
*high limits (posibility to withdraw up to $60,000/€60,000/£48,000)
*the card can be used for offline, online shopping and ATM withdrawals

More information about the card check here https://unichange.me/debit_cards

==Fees==

Fees on Unichange.me are constantly changing as service propose large amount of offers and deals, so it is better to check rates for all exchange directions on website directly. You can check all Unichange.me fees here https://unichange.me/fees

==Affiliate program==

Unichange.me service invites everyone to participate in Affiliate program and earn % of referrals' exchange commission.

Clients of Unichange.me service meet all benefits of the Affiliate program:

* Simple and transparent Affiliate Program.
* Wide choice of promo materials for your website.
* Free participation, requiring no additional conditions.
* Attractive fees for affiliates, 3 levels of Affiliate program.
* Reliable and stable service with supportive team.
* Wide variety of withdrawal methods.

You can check detailed information about Affiliate Program here https://unichange.me/partner_program

==External links==
*[https://unichange.me/ Unichange.me website]
*[https://unichange.me/registration User registration]
*[https://unichange.me/debit_cards About Unichange.me debit card]
*[https://unichange.me/fees Unichange.me fees]
*[https://unichange.me/partner_program Affiliate Program]

UpDown.BT

2025-05-17T16:08:09Z

Calliptamus:

[https://updown.bt UpDown.BT] — New beautiful service which allows you to trade binary options on Gold/Silver/Oil and various currencies with [[Bitcoin]]. Became a gold member of Bitcoin Foundation in April 2014.

Uquid

2025-05-17T16:07:37Z

Calliptamus:

'''About Uquid'''
 
Uquid aims to connect the cryptocurrency enthusiast with the merchants worldwide through the decentralized [[Bitcoin]] blockchain technology. The all-in-one solution offered by Uquid enables bitcoin and altcoin payments with just one click. With the Uquid bitcoin debit card, users can spend their coins worldwide, in millions of online or offline stores.

'''Uquid on Social Media and media'''
* Email: hello@uquid.com
* Facebook: https://www.facebook.com/uquidcard/
* Twitter: https://twitter.com/uquidcard
* Google+: https://plus.google.com/100328624017217144735
* Website: https://uquid.com
* https://cointelegraph.com/news/uquid-allows-40-different-altcoins-to-use-visas-global-network
* https://www.okcoin.cn/t-1016455.html
* https://www.cryptocoinsnews.com/load-visa-card-40-altcoins/
* https://bitconnect.co/bitcoin-news/348/uquid-load-a-visa-card-with-over-40-altcoins
* http://bitcoinist.com/uquid-visa-card-altcoins/

'''Services Provided'''
 
Uquid provides access to cryptocurrency payments in bitcoin. The wallet can be used in three different fiat currencies, such as USD, EUR and GBP. The transfers from the wallet to the debit card happens instantly at real time market rates, so users can spend the coins right away.

They target the unbanked population and the travelers for their services who wish to transfer many in an easy, cheap and hassle free way. The cards can be used at retailers to top up mobiles, pay utility bills, pharmacy or food, purchase transportation ticket or anything else, clients would buy with an ordinary debit card. Clients can also receive money to the Uquid cards from freelancing activities, gambling sites and even from PayPal. The ATM withdrawals are available at more than 34 million ATM cash machines worldwide.

Both physical and virtual cards are available at UQUID. The PIN codes are available in the Uquid platform after activating the card. The physical cards are delivered to over 178 countries worldwide. Users in many African countries and in the Middle East are not able to use Uquid’s services. Residents of India and the United States are also on the excluded countries list.

The shipping takes 1-2 weeks depending on the workload of the issuing bank. The standard shipping is free of charge. Expedited shipping costs 35 USD and means users can get hold of the bitcoin cards within 5 business days. UQUID limits the number of cards belonging to one email address, if clients want to order additional cards, they have to sign up for the services with a new email address.

The Uquid bitcoin debit card can be loaded through several methods. Bank wire transfers are available for customers who can verify their identities. For anonymous usage, clients can opt for top ups with Paysafecards, bitcoins, any of the 40 other altcoins. They accept alternative payment service providers as well, like Alipay, CashU and 17 other payment provider which operates in different countries.

Uquid have two different levels of service depending on the Know Your Customer (KYC) identification processes. The Silver package is for those users who do not wish to disclose their identity. The VISA issued debit card requires no identification or credit check before ordering. The cards can be topped up with 2500 USD without identity verification, the ATM withdrawal is limited to 200 USD per transaction, up to a maximum 1000 USD.

With identity verification which means providing ID or passport and proof of residence, client are eligible for the gold package. Verification takes 3-4 working days after providing the documents. The identity verification lets the clients use the Uquid bitcoin debit card for unlimited amount of money. Only the daily ATM withdrawals are set to 2000 USD with two transactions and the daily top ups is maximized in 20000 USD. Otherwise the verified cards are truly available for unlimited usage.

'''Fees and Pricing Schedule'''
 
* The creation of the virtual Uquid bitcoin debit card costs 1 USD, the plastic card is charged at 16.99 USD. The monthly maintenance fee is also 1 USD, however this fee is only payable if the card has any balance. Obtaining the PIN code is free for the first time, then changing it costs 1 USD.

* Domestic ATM withdrawals are charged at 2.50 USD per transaction, the international cash withdrawals cost 3.00 USD. Uquid charges 3% currency exchange fee if the base currency of the card is different compare to the purchase currency.

* The loading fees vary depending on the top up method chosen. The wallets can be loaded with bitcoins and altcoins with free of change. The wire transfers costs 1.5% per transaction, Alipay top ups costs 5%, CashU is 2%.

* If clients wish to withdraw the deposits from the Uquid accounts, an additional 3% transactions fee is charged each time on the bank transfer.

'''Uquid User Experience'''
 
Uquid website has a nicely designed platform, however their English ruins the experience. Missing words, incorrect conjugation and sentences that are structured inappropriately makes the content sometimes even difficult to understand.

Uquid platformThe platform is available in eight different languages. Beside English, clients can reach the site in German, Italian, French, Turkish, Chinese, Russian, Vietnamese and in Arabic. The services are also reachable for smart phone users both in the App Store for iPhone users and in the Google Play for Android users. Two factor authentication is available for the website logins.

Their support team is reachable by email and through a contact form that creates a ticket number which enable easier tracking of issues. They promise to respond to user queries within 24 hours window.

'''Overall Conclusion'''
 
Uquid offers prepaid debit card option in three fiat currencies (USD, EUR and GBP) and connects 40 different cryptocurrencies to it. The card fees are on the average market level and delivered to most countries worldwide. After verification, clients may use the Uquid bitcoin debit cards without any limits. Although Uquid has a very good service structure, it is disappointing that the website has poor English language, which may distract many prospective clients.

Vera&John

2025-05-17T16:06:48Z

Calliptamus:

Vera&John is the first licensend and regulated online casino to support deposits and withdrawals in [[Bitcoin]]. NetEnt, Play'n GO, Betsoft, IGT, Nextgen Gaming, Bally Technologies. Operated by Dumarca Gaming Ltd. Northfields, Apartment 2, Suite 6, Independence Avenue, Mosta, Malta. Licence issued and regulated by Malta’s Lotteries and Gaming Authority: LGA/CLl/552/2009

==Games==
Baccarat
Blackjack
Roulette
Video Poker
Card Games
Scratch Cards
Slots & Video Slots
Keno

==External Links==
[http://www.verajohn.com/ Vera&John]

[http://www.verajohn.com/about/bitcoin How to use Bitcoin at Vera&John]

==Reviews==

*[http://www.bitcoingg.com/bitcoin-gambling-sites/vera-and-john/ Vera&John Bitcoin Review]

Waiting For Bitcoin

2025-05-17T16:06:16Z

Calliptamus:

Waiting For Bitcoin is a site that was originally designed to allow restaurant waiters and bartenders to print their own payment cards and easily accept [[Bitcoin]]. [[Image:4btco_Card.png|frame|Example Card from Waiting For Bitcoin]] [[Image:WFB-Logo.png|321px|thumb|Waiting For Bitcoin logo]] 

Now, the site facilitates: 
* Buying at [http://buybt.co buyBT.Co] 
* Selling at [http://sellbt.co sellBT.Co] 
* Paying Bills at [http://billbybit.com BillByBit.com]

The site features various delivery options to suit your specific needs.

==External Links==

* [http://waitingforbitcoin.com Waiting For Bitcoin] Website

==References==
<references />

[[Category:Defunct exchanges]]
[[Category:Local]]
[[Category:Directories]]
[[Category:eWallets]]

Wollit

2025-05-17T16:04:37Z

Calliptamus:

'''A simple and secure web-based client-side encrypted Bitcoin wallet.'''

wollit aims to facilitate mainstream adoption of [[Bitcoin]] by providing a simple, secure and clean way of sending, receiving and managing Bitcoin [[transaction]]s.

wollit also provides merchant functionality for utilising Bitcoin as a payment mechanism and offers developers full [[Block chain|blockchain]] browser functionality

=== Fees ===

There are no fees for using wollit

=== History ===

The service launched in beta in May 2013

=== Wallet Security ===

* The wallet available from this service is considered a hybrid EWallet.
* Bitcoins are not stored with wollit, but instead held in your browser.
* There is an encrypted copy of your wallet stored on wollit's servers,
* wollit cannot spend/lose of even access your Bitcoins.

* aes encryption
* iso10126 padding
* 500 rounds of PBKDF2 on users password as key

=== External Link ===

[http://wollit.com wollit]

[http://blog.wollit.com wollit blog]

[[Category:EWallets]]
[[Category:Wallets]]
[[Category:Exchanges]]
[[Category:Shopping Cart Interfaces]]
[[Category:Services]]
[[Category:Frontends]]
[[Category:Clients]]
[[Category:Mobile]]

XZZX

2025-05-17T16:02:05Z

Calliptamus: /* Supported currencies */

== About the company ==
'''[https://xzzx.biz xzzx.biz]''' was founded in 2008. The mission of the company is to provide convenient automatic e-currency exchange services

==Supported currencies==
[[Bitcoin]], Litecoin, Webmoney, Perfect Money, Wire USD

[[Category:Defunct exchanges]]
[[Category:Financial]]