https://tests.bitcoin.it/w/api.php?action=feedcontributions&user=Mercurytoxic&feedformat=atomBitcoin Wiki - User contributions [en]2024-03-28T10:01:40ZUser contributionsMediaWiki 1.30.0https://tests.bitcoin.it/w/index.php?title=Testnet&diff=69794Testnet2023-07-27T04:26:43Z<p>Mercurytoxic: Marked faucet as offline</p>
<hr />
<div>The '''testnet''' is an alternative Bitcoin [[block chain]] to be used for testing. Testnet coins are separate and distinct from actual bitcoins, and are never supposed to have any value. This allows application developers or bitcoin testers to experiment, without having to use real bitcoins or worrying about breaking the main bitcoin chain.<br />
<br />
Run <code>bitcoin-qt</code> or <code>bitcoind</code> with the <code>-testnet</code> flag to use the testnet (or put <code>testnet=1</code> in the <code>bitcoin.conf</code> file).<br />
<br />
There have been three generations of testnet. Testnet2 was just the first testnet reset with a different genesis block, because people were starting to trade testnet coins for real money. '''Testnet3''' is the current test network. It was introduced with the 0.7 release, introduced a third genesis block, a new rule to avoid the "difficulty was too high, is now too low, and transactions take too long to verify" problem, and contains blocks with edge-case transactions designed to test implementation compatibility. On 21 December 2015, SegNet was deployed to test the Wuille's Segregated Witness proposal.<br />
<br />
==Differences==<br />
* Default Bitcoin network protocol listen port is 18333 (instead of 8333)<br />
* Default RPC connection port is 18332 (instead of 8332)<br />
* Bootstrapping uses different DNS seeds.<br />
* A different value of <code>ADDRESSVERSION</code> field ensures no testnet Bitcoin addresses will work on the production network. (<code>0x6F</code> rather than <code>0x00</code>)<br />
* The protocol message header bytes are <code>0x0B110907</code> (instead of <code>0xF9BEB4D9</code>) <br />
* Minimum [[difficulty]] of 1.0 on testnet is equal to difficulty of 0.5 on mainnet. This means that the mainnet-equivalent of any testnet difficulty is half the testnet difficulty. In addition, if no block has been found in 20 minutes, the difficulty automatically resets back to the minimum for a single block, after which it returns to its previous value.<br />
* A new genesis block<br />
* The <code>IsStandard()</code> check is disabled so that non-standard transactions can be experimented with.<br />
<br />
==Genesis Block==<br />
<br />
Testnet uses a different genesis block to the main network. You can find it [https://mempool.space/testnet/block/000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943 here].<br />
The testnet was [https://github.com/gavinandresen/bitcoin-git/commit/feeb761ba07af74a7cd78b8c8f7c2a961fd9ea1c reset with a new genesis block] for the 0.7 Bitcoin release.<br />
<br />
==Size==<br />
Testnet receives less transactions than the main block chain and is typically much smaller in size. As of January 2018, the size of the data on disk was 14&nbsp;GB containing data for about 6 years worth of testnet activity. Downloading this data required about 12&nbsp;GB of network activity peaking at 2&nbsp;MB/s rate of transfer.<br />
<br />
==External links==<br />
<br />
* [https://bitcointalk.org/?topic=4483.0 Testnet in a box forum topic]<br />
* [https://sourceforge.net/projects/bitcoin/files/Bitcoin/testnet-in-a-box/ Testnet-In-A-Box self-contained testnet]<br />
* [https://github.com/freewil/bitcoin-testnet-box Forked/Updated testnet-box]<br />
<br />
===Wallets===<br />
<br />
Online testnet wallets to help you test your application.<br />
<br />
* [https://CoPay.io/ CoPay.io] wallet supports TestNet accounts<br />
<br />
===Faucets===<br />
<br />
Once you're done with your test coins, it is a nice gesture to send them back to the faucets, so they become available to other developers.<br />
* [https://cryptopump.info/ Cryptopump.info Testnet Faucet]<br />
* [http://tbtc.bitaps.com bitaps.com Testnet Faucet + double spend test tool]<br />
* [http://bitcoinfaucet.uo1.net/ UO1 Testnet Faucet]<br />
* [https://play.google.com/store/apps/details?id=com.mycelium.testnetwallet Mycelium Testnet Wallet for Android with integrated Testnet "faucet" function (Local Trader)]<br />
* [http://kuttler.eu/bitcoin/btc/faucet/ nkuttler's Bitcoin Testnet Faucet]<br />
* [https://coinfaucet.eu/btc-testnet Coinfaucet testnet3 faucet]<br />
<br />
Offline (2023-07-27):<br />
<br />
* [https://testnet-faucet.mempool.co mempool.co testnet3 Faucet]<br />
<br />
Offline (2018-09-06):<br />
<br />
* [http://tpfaucet.appspot.com/ TP's TestNet Faucet]<br />
* [https://testnet.manu.backend.hamburg/faucet flyingkiwi's TestNet Faucet]<br />
<br />
Offline (2016-08-07):<br />
<br />
* [http://faucet.luis.im/ luis.im Mojocoin Testnet3 Faucet]<br />
* [https://accounts.blockcypher.com/testnet-faucet BlockCypher Testnet Faucet], also provided as a [http://dev.blockcypher.com/#faucets Testnet faucet API] for test automation<br />
<br />
===Block explorers===<br />
* [https://mempool.space/testnet Bitcoin Testnet on mempool.space]<br />
* [http://tbtc.bitaps.com/ Bitcoin Testnet Explorer on bitaps.com]<br />
* [https://www.biteasy.com/testnet/blocks Biteasy.com Testnet Blockexplorer]<br />
* [http://testnet.blockchain.info Blockchain.info Testnet Explorer]<br />
* [https://test-insight.bitpay.com/ Bitcoin Testnet on insight.bitpay.com]<br />
* [https://www.blocktrail.com/tBTC BlockTrail Testnet Explorer, Testnet API and Testnet Faucet]<br />
* [https://live.blockcypher.com/btc-testnet/ BlockCypher Testnet Explorer]<br />
[[Category:Technical]]<br />
[[Category:Developer]]<br />
<br />
{{Bitcoin Core documentation}}</div>Mercurytoxichttps://tests.bitcoin.it/w/index.php?title=Eligius&diff=69793Eligius2023-07-27T04:07:23Z<p>Mercurytoxic: Minor change to note that it's no longer in existence</p>
<hr />
<div>{{infobox company|name=Eligius|image=[[File:Eligius.png|256px]]<br />
|trading_name=Eligius<br />
|industry=[[Mining pool]]<br />
|foundation=April 27, 2011<br />
|hashrate=8.1 PHash/s<ref name="eligius">[http://eligius.st/~gateway/ Eligius]</ref><br />
|website=http://eligius.st<br />
|owner=[[User:Wizkid057|wizkid057]]<br />
|founder=[[Luke Dashjr|Luke-Jr]]<br />
}}'''Eligius''', also sometimes referred to as Éloi or "[[Luke Dashjr|Luke-Jr's]] pool", was a [[Pooled mining|mining pool]].<br />
As of October 23, 2012, Eligius is maintained by [[User:Wizkid057|wizkid057]].<ref>https://bitcointalk.org/index.php?topic=23768.msg1291494#msg1291494</ref><br />
<br />
To use it, a miner merely needs to be directed to stratum.mining.eligius.st on port 3334, with the username set to a valid bitcoin address (which receives the payout). '''No registration is needed.'''<br />
<br />
Donation address: 1E1igiusfEjs1pCaGjEERExE9gYcrFwow7 / Mx5FUQn8oBCoRdyBTUFu9JW5SsdEku56PP<br />
<br />
Basic concepts:<br />
* The pool charges no fees and shares are managed under the [http://eligius.st/wiki/index.php/Capped_PPS_with_Recent_Backpay CPPSRB] reward system at 100% value at the time of mining. <ref>http://eligius.st/wiki/index.php/Capped_PPS#CPPS_with_Recent_Backpay_.28CPPSRB.29</ref><br />
* When a block is found, all miners who have reached the minimum payout threshold (currently about 0.04 BTC and is configurable) are paid via the Generation transaction.<br />
* The pool almost never has miner's funds, as they are paid directly to the miners from the block reward.<br />
* If a block is orphaned, its shares become part of the next block's reward distribution.<br />
* No registration; bitcoin addresses are used for usernames.<br />
* A signed message based control panel was added for securely setting options for miners, including Namecoin merged mining and donation amounts.<br />
<br />
Eligius was announced on April 27, 2011<ref>[https://bitcointalk.org/index.php?topic=6648.0 Please test: New Experimental Pool]</ref>. At the time the service was operated without a name, paying out even tiny coins immediately.<br />
<br />
The [[coinbase]] signature for this pool is: "Eligius".<br />
<br />
==Connecting to Eligius==<br />
* GBT<br />
: gbt.mining.eligius.st:9337<br />
* Stratum<br />
: stratum+tcp://stratum.mining.eligius.st:3334<br />
<br />
==Eligius-related links==<br />
<br />
* [http://eligius.st Main webpage]<br />
* [http://eligius.st/~wizkid057/newstats/ Pool statistics (hashrate, found blocks, per-address balance stats)]<br />
* [http://eligius.st/~wizkid057/newstats/bot.php?poolhashrate=1&numeric=1 Total pool hashrate]<br />
* [http://eligius.st/~luke-jr/raw/ JSON API]<br />
* [http://eligius.st/~gateway/pool-apis New API and details]<br />
<br />
==See Also==<br />
<br />
* [[Comparison of mining pools]]<br />
* [[Pooled mining]]<br />
<br />
==References==<br />
<references /><br />
<br />
* [https://www.bitcoinmining.com/ Bitcoin Mining]<br />
* [https://www.youtube.com/watch?v=GmOzih6I1zs Video: What is Bitcoin Mining]<br />
<br />
[[Category:Pool Operators]]<br />
{{Pools}}</div>Mercurytoxichttps://tests.bitcoin.it/w/index.php?title=Bitcoins.lc&diff=69792Bitcoins.lc2023-07-27T04:06:46Z<p>Mercurytoxic: Minor change to note that it's no longer in existence</p>
<hr />
<div>Was a [[Pooled mining|mining pool]].<br />
<br />
This pool pays out using a proportional share reward system (your shares / total shares for the round) = % share of the rewards.<br />
<br />
The service was first available on May 27, 2011<ref>[http://bitcointalk.org/index.php?topic=10121.0 Bitcoins.lc - Finally a usuable Bitcoin Pool! (EU, IPv6, 0% fee, LP)]</ref>.<br />
<br />
==Reward distribution==<br />
<br />
* Proportional: 0% fee.<br />
<br />
==See Also==<br />
<br />
* [[Comparison of mining pools]]<br />
* [[Pooled Mining]]<br />
<br />
==External Links==<br />
<br />
* [http://www.bitcoins.lc Bitcoins.lc] web site<br />
<br />
==References==<br />
<references /><br />
<br />
[[Category:Pool Operators]]</div>Mercurytoxichttps://tests.bitcoin.it/w/index.php?title=BTC_Guild&diff=69791BTC Guild2023-07-27T04:02:07Z<p>Mercurytoxic: Minor change to note that it's no longer in existence</p>
<hr />
<div>{{infobox company|name=BTC Guild|image=[[File:BTCGuild.png|256px]]<br />
|trading_name=BTC Guild<br />
|industry=[[Mining pool]]<br />
|founder=[[Eleuthria]]<br />
|foundation=May 9, 2011<br />
|hashrate=15.2 PHash/s<br />
|website=http://www.btcguild.com<br />
}}'''BTC Guild''' was a [[Pooled mining|mining pool]] which offers proportional ([[PPLNS]]) based rewards, where your reward is equal to the block value, multiplied by your valid shares submitted during the round. The pool does not take a fee from each block solved, and calculates rewards to the full 8 decimal points supported by the Bitcoin protocol. The pool is run off the donations of users, and is offering premium services at different donation levels to encourage users to donate a small percentage of their rewards. Donations are taken from the individual user's reward when a block is calculated.<br />
<br />
2.5% donators (calculated on a per block basis) are able to claim their rewards without waiting for 120 confirmations of the block. This also acts as invalid protection, similar to [[DeepBit]], where a user can claim rewards even if the block is later invalidated/orphaned by the network.<br />
<br />
The [[coinbase]] signature for this pool is: "Mined by BTC Guild"<ref>[https://blockchain.info/tx/0a04176e074d1bc651e969929b866b8d04104a964332c96fb6913ab863e2dac0 Example of decoded coinbase]</ref>.<br />
<br />
BTC Guild first opened up on May 9th, 2011.<ref>[http://bitcointalk.org/index.php?topic=7760.0 BTC Guild - 0% Fee Pool, Long polling, JSON API, invalid insurance]</ref> It is currently for sale and a possible buyer has been found. There is a 90 day notice period. If the sale does not go through, another 90 day notice period will be announced. 30 days for the pool to stop operation and an additional 60 days for users to withdraw their mining proceeds<ref>https://bitcointalk.org/index.php?topic=49417.msg9395478#msg9395478</ref>.<br />
<br />
== Closure ==<br />
On June 15th, 2015, it was announced<ref>https://bitcointalk.org/index.php?topic=49417.msg11628010#msg11628010</ref> that BTC Guild will be shutting down on June 30th, 2015. Its operator - Eleuthria - cited concerns over low percentage of network hashrate vs funds in a hot wallet, the [[New York Bitlicense]] and possible but difficult to prove gaming of the pool by miners.<br />
<br />
==See Also==<br />
<br />
* [[Pooled Mining]]<br />
<br />
==External Links==<br />
<br />
* [http://www.btcguild.com BTCGuild] web site<br />
<br />
==References==<br />
<references /><br />
<br />
[[Category:Pool Operators]]<br />
{{Pools}}</div>Mercurytoxichttps://tests.bitcoin.it/w/index.php?title=Lightning_Network&diff=66002Lightning Network2019-01-03T06:16:48Z<p>Mercurytoxic: Typos</p>
<hr />
<div>'''Lightning Network''' is a proposed implementation of [[Hashed Timelock Contracts]] (HTLCs) with bi-directional [[payment channels]] which allows payments to be securely routed across multiple peer-to-peer payment channels.<ref name="ln_pdf">[https://lightning.network/lightning-network-paper.pdf Lightning Network paper, v0.5.9.1]<br>Joseph Poon & Thaddeus Dryja<br>''Retrieved 2016-04-10''</ref> This allows the formation of a network where any peer on the network can pay any other peer even if they don't directly have a channel open between each other.<br />
<br />
== Key features == <br />
Key features of the Lightning Network proposal include,<br />
<br />
* '''Rapid payments:''' payments within an established channel can be made almost as fast as data can travel over the Internet between the two peers.<br />
* '''No third-party trust:''' the two peers in a channel pay each other directly using regular Bitcoin transactions (of which only one is broadcast) so at no point does any third party control their funds.<br />
* '''Reduced blockchain load:''' only channel open transactions, channel close transactions, and (hopefully infrequent) anti-fraud respends need to be committed to the blockchain, allowing all other payments within Lightning Network channels to remain uncommitted. This allows Lightning Network users to make frequent payments secured by Bitcoin without placing excessive load on full nodes which must process every transaction on the blockchain.<br />
* '''Channels can stay open indefinitely:''' as long as the two parties in the channel continue to cooperate with each other, the channel can stay open indefinitely -- there is no mandatory timeout period. This can further reduce the load on the blockchain as well as allow the fees for opening and closing the channel to be amortized over a longer period of time.<br />
* '''Rapid cooperative closes:''' if both parties cooperate, a channel can be closed immediately (with the parties likely wanting to wait for one or more confirmations to ensure the channel closed in the correct state). Non-cooperative closes (such as when one party disappears) are also possible but they take longer.<br />
* '''Outsourceable enforcement:''' if one party closes a channel in an old state in an attempt to steal money, the other party has to act within a defined period of time to block the attempted theft. This function can be outsourced to a third-party without giving them control over any funds, allowing wallets to safely go offline for periods longer than the defined period.<br />
* '''Onion-style routing:''' payment routing information can be encrypted in a nested fashion so that intermediary nodes only know who they received a routable payment from and who to send it to next, preventing those intermediary nodes from knowing who the originator or destination is (provided the intermediaries didn't compare records).<br />
* '''Multisignature capable:''' each party can require that their payments into the channel be signed by multiple keys<ref name="poon_multisig">[https://lists.linuxfoundation.org/pipermail/lightning-dev/2016-January/000403.html 2-of-3 Instant Escrow, or How to Do "2-of-3 Multisig Contract" Equivalent on Lightning]<br>Joseph Poon<br>''Retrieved 2016-04-11''</ref>, giving them access to additional security techniques.<br />
* '''Securely cross blockchains:''' payments can be routed across more than one blockchain (including altcoins and sidechains) as long as all the chains support the same hash function to use for the hash lock, as well as the ability the ability to create time locks.<br />
* '''Sub-satoshi payments:''' payments can be made conditional upon the outcome of a random event, allowing probabilistic payments.<ref name="dryja_directed_graph"/> For example, Alice can pay Bob 0.1 satoshi by creating a 1-satoshi payment with 10-to-1 odds so that 90% of the time she does this she pays him 0 satoshis and 10% of the time she pays him 1 satoshi for an average payment of 0.1 satoshis.<br />
* '''Single-funded channels:''' when Alice needs to send a payment to Bob and doesn't currently have a way to pay him through the Lightning Network (whether because she can't reach him or because she doesn't have enough money in an existing channel), she can make a regular on-chain payment that establishes a channel without Bob needing to add any of his funds to the channel. Alice only uses 12 bytes more than she would for a non-Lightning direct payment and Bob would only need about 25 more [[segwit]] virtual bytes to close the channel than he would had he received a non-Lightning direct payment.<ref name="dryja_directed_graph"/><br />
<br />
== Glossary ==<br />
<br />
<br />
This section attempts to document the most frequently used terms found in Lightning Network literature that may not be familiar to a general technical audience, including both the new terms created by Lightning Network designers as well as pre-existing terms that may not be well known from Bitcoin, cryptography, network routing, and other fields.<br />
<br />
The list below should be in alphabetical order. Any commonly-used synonyms or analogs for a term are placed in parenthesis after the term.<br />
<br />
* '''Bi-directional payment channel:'''<ref name="ln_pdf"/> a payment channel where payments can flow both directions, from Alice to Bob and back to Alice. This is contrasted with Spillman-style and CLTV-style payment channels where payments can only go one direction and once Alice has paid Bob all of the bitcoins she deposited in the channel funding transaction, the channel is no longer useful and so will be closed.<br />
* '''Breach Remedy Transaction:'''<ref name="ln_pdf"/> the transaction Alice creates when Mallory attempts to steal her money by having an old version of the channel state committed to the blockchain. Alice's breach remedy transaction spends all the money that Mallory received but which Mallory can't spend yet because his unilateral spend is still locked by a relative locktime using <code>OP_CSV</code>. This is the third of the maximum of three on-chain transactions needed to maintain a Lightning channel; it only needs to be used in the case of attempted fraud (contract breach).<br />
* '''Channel''' (Lightning channel<ref name="ln_pdf"/>, payment channel<ref name="spillman_channel">[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-April/002433.html Anti DoS for tx replacement]<br>Jeremy Spillman<br>Retrieved 2016-04-17</ref>) a communication channel that allows two parties to make many secure payments between each other in exchange for making only a few transactions on the blockchain.<br />
* '''Commitment Transaction:'''<ref name="ln_pdf"/> a transaction created collaboratively by Alice and Bob each time they update the state of the channel; it records their current balances within the channel. The '''Initial Commitment Transaction'''<ref name="ln_pdf"/> is the first of these transactions; it records the initial balances within the channel. This is the second of the maximum of three on-chain transactions needed to maintain a Lightning channel; it can be combined with a ''funding transaction'' for a new channel under the cooperative conditions necessary to create an ''exercise settlement transaction''.<br />
* '''Contract:'''<ref name="szabo_smart_contracts">[http://szabo.best.vwh.net/smart_contracts_idea.html The Idea of Smart Contracts]<br>Nick Szabo<br>Retrieved 2016-04-17</ref> an agreement between two or more entities to use Bitcoin transactions in a certain way, usually a way that allows Bitcoin's automated consensus to enforce some or all terms in the contract. Often called a ''smart contract''.<br />
* '''CSV:''' (<code>OP_CheckSequenceVerify</code>, <code>OP_CSV</code>)<ref name="bip68"/> a opcode that allows an output to conditionally specify how long it must be part of the blockchain before an input spending it may be added to the blockchain. See ''relative locktime.''<br />
* '''Delivery Transaction:'''<ref name="ln_pdf"/> not really a transaction but rather the name for the outputs in the ''commitment transaction'' which Alice and Bob receive if one of them closes the channel unilaterally in the correct (current) state. If the channel is closed in an old state (indicating possible fraud), a ''breach remedy transaction'' will be generated from the output that would have paid the party closing the channel. If the channel is closed cooperatively, they'll create an ''exercise settlement transaction'' instead.<br />
* '''Dispute period:''' (dispute resolution period<ref name="poon_time_bitcoin_ln">[https://lightning.network/lightning-network-presentation-time-2015-07-06.pdf Time, Bitcoin, and the Lightning Network]<br>Joseph Poon<br>Retrieved 2016-04-17</ref>) the period of time that Alice has to get her ''breach remedy transaction'' added to the blockchain after Mallory has an old ''commitment transaction'' added to the blockchain. If the dispute period ends without a breach remedy transaction being added to the blockchain, Mallory can spend the funds he received from the old commitment transaction.<br />
* '''Dual-funded channel:'''<ref name="dryja_directed_graph">[https://docs.google.com/presentation/d/1G4xchDGcO37DJ2lPC_XYyZIUkJc2khnLrCaZXgvDN0U/edit?pref=2&pli=1#slide=id.g85f425098_0_2 LN as a Directed Graph: Single-Funded Channel Topology]<br>Thaddeus Dryja<br>Retrieved 2016-04-17</ref> a channel opened by a ''funding transaction'' containing inputs from both Alice and Bob. Compare to a ''single-funded channel'' where only Alice's inputs contribute to the balance of the channel.<br />
* '''Encumbrance:'''<ref>[http://chimera.labs.oreilly.com/books/1234000001802/ch02.html Mastering Bitcoin, Chapter 2: How Bitcoin Works]<br>Andreas Antonopoulos<br>Retrieved 2016-04-17</ref> a generic name for any conditions that must be satisfied before a bitcoin output may be spent. Early Bitcoin transactions placed all their conditions in the scriptPubKey; later the introduction of P2SH allowed conditions to be added in a redeemScript which the scriptPubKey committed to; the introduction of soft fork [[segwit]] will add a similar mechanism for detached conditions that the scriptPubKey commits to; in addition, there are even more novel ways to add conditions to outputs that are discussed but rarely used. The term &quot;encumbrance&quot; allows specifying what the conditions do without fussing over exactly where the conditions appear in a serialized transaction.<br />
* '''Exercise Settlement Transaction:'''<ref name="ln_pdf"/> a form of the ''commitment transaction'' created cooperatively by Alice and Bob when they want to close their channel together. Unlike a regular commitment transaction, none of the outputs on an exercise settlement transaction are time locked, allowing them to be immediately respent.<br />
* '''Exhausted:'''<ref name="dryja_directed_graph"/> (exhausted channel) a payment channel where no additional payments can be made in one direction (such as from Alice to Bob). The person controlling the exhausted side of a Lightning channel loses nothing from fraudulently trying to commit an old channel state, so allowing a channel to become exhausted (or too near to being exhausted) is unpreferable. (Exception: channels can be securely started in an exhausted state, such as a ''single-funded channel.''<br />
* '''Full push:'''<ref name="dryja_directed_graph"/> when Alice pays the full amount of the channel to Bob in the ''initial commitment transaction'', which ''exhausts'' the channel without incentivizing fraud because Alice doesn't have a previous ''commitment transaction'' that she can broadcast. This term is used in the context of a ''single-funded transaction'' and stands in contrast to an ''overpayment'' where Alice deposits more than she pays Bob in that initial payment so that she can continue to use the channel without needing to ''rebalance''.<br />
* '''Funding Transaction:'''<ref name="ln_pdf"/> (deposit transaction) a transaction created collaboratively by Alice and Bob to open a Lightning channel. In a single-funded channel, Alice provides all the funding;<ref name="dryja_directed_graph"/> in a dual-funded channel, Alice and Bob both provide some funding. This is the first of the maximum of three on-chain transactions needed to maintain a Lightning channel; it can be combined with a commitment transaction from a previous channel being closed under cooperative conditions.<br />
* '''Half-signed:'''<ref name="ln_pdf"/> a transaction input which requires two signatures to be added to the blockchain but which only has one signature attached. (More generally, this could be any input that has fewer signatures attached than it needs to be added to the blockchain.)<br />
* '''Hash lock:'''<ref>[https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg05135.html BIP - Hash Locked Transaction]<br>Tier Nolan<br>Retrieved 2016-04-17</ref> an encumbrance to a transaction output that requires the pre-image used to generate a particular hash be provided in order to spend the output. In Lightning, this is used to allow payments to be routable without needing to trust the intermediaries.<br />
* '''HTLC:''' (Hashed Timelocked Contract<ref name="russell_deployable_lightning">[https://github.com/ElementsProject/lightning/raw/master/doc/deployable-lightning.pdf Reaching the Ground with Lightning]<br>Rusty Russell<br>Retrieved 2016-04-17</ref>) a contract such as that used in a Lightning Channel where both a ''hash lock'' and a ''time lock'' are used, the hash lock being used to allow Alice to route payments to Bob even through a Mallory that neither of them trust, and the time lock being used to prevent Mallory from stealing back any payments he made to Alice within the channel (provided Alice enforces the contract).<br />
* '''Intermediary:'''<ref name="ln_pdf"/> When Bob has one channel open with Alice and another channel open with Charlie, Bob can serve as an intermediary for transferring payments between Alice and Charlie. With Lightning payments being secured with a ''hash lock,'' Bob can't steal the payment from Alice to Charlie when it travels through Bob's node. Lightning payments can securely travel through a theoretically unlimited number of intermediaries.<br />
* '''Limbo channel:'''<ref name="dryja_directed_graph"/> an optional special state for a Lightning channel where it cannot be immediately closed by one or both of the parties unilaterally (it can still be immediately closed cooperatively). This is used in particular for ''PLIPPs.''<br />
* '''Multisig:'''<ref name="bitcoin_0_1_code"/> (multisignature, m-of-n multisig) a transaction output that requires signatures from at least one of a set of two or more different private keys. Used in Lightning to give both Alice and Bob control over their individual funds within a channel by requiring both of them sign ''commitment transactions''.<br />
* '''Node:''' (Lightning node<ref name="ln_pdf"/>) a wallet with one or more open Lightning channels. This should not be confused with a Bitcoin [[full node]] that validates Bitcoin blocks, although a full node's wallet may also be simultaneously used as a Lightning node to the advantage of the Lightning network user.<br />
* '''Overfunding:'''<ref name="dryja_directed_graph"/> in a ''single-funded channel,'' Alice deposits more bitcoins into the channel than she pays Bob in the initial payment, allowing her to make additional payments through the Lightning network. This stands in contrast to a ''full push'' where Alice only deposits enough to pay Bob in the initial payment.<br />
* '''PILPP:''' (Pre-Image Length Probabilistic Payments<ref name="dryja_directed_graph"/>) a specific type of ''probabilistic payment'' within a payment channel where Alice creates string with a random length and Bob guesses the length; if he guesses correctly, Alice has to pay him; if he guesses incorrectly, Alice gets to keep her money.<br />
* '''Pre-image:'''<ref>[https://en.wikipedia.org/wiki/Image_%28mathematics%29#Inverse_image Image (mathematics)]<br>English Wikipedia contributors<br>Retrieved 2016-04-17</ref> (R<ref name="ln_pdf"/>) data input into a hash function, which produces a hash of the pre-image. Inputting the same pre-image into the same hash function will always produce the same hash; Lightning uses this feature to create ''hash locks''.<br />
* '''Probabilistic Payment:'''<ref>[[Nanopayments]]<br>Bitcoin Wiki contributors<br>Retrieved 2016-04-17</ref> a payment where Alice only pays Bob if some event outside of Alice's and Bob's control occurs in Bob's favor. Probabilistic payments are usually proposed for scenarios where payments can't conveniently be made small enough for technical reasons (such as not being able to pay less than 1 satoshi) or economic reasons (such as having to pay a transaction fee for every on-chain payment, making small payments uneconomical). See ''PLIPP'' for a specific type of probabilistic payment possible within a Lightning channel.<br />
* '''R:''' the variable commonly used<ref name="ln_pdf"/> in formulas to represent a ''pre-image''.<br />
* '''Rebalance:'''<ref>[https://blockstream.com/2015/09/01/lightning-network/ The Lightning Network: What Is It and What's Happening?]<br>Rusty Russell<br>Retrieved 2016-04-17</ref> a cooperative process between Alice and Bob when they adjust their balances within the channel. This happens with every payment in a Lightning channel and is only noteworthy because single-directional channels (such as Spillman-style and CLTV-style channels) are unable to rebalance and so must close as soon as Alices has paid Bob all the bitcoins she deposited into the channel. See ''bi-directional payment channels.''<br />
* '''Relative locktime:'''<ref name="bip68"/> the ability to specify when a transaction output may be spent relative to the block that included that transaction output. Enabled by BIP68 and made scriptable by BIP112. Lightning uses relative locktime to ensure ''breach remedy transactions'' may be broadcast within a time period starting from when an old ''commitment transaction'' is added to the blockchain; by making this a relative locktime (instead of an absolute date or block height), Lightning channels don't have a hard deadline for when they need to close and so can stay open indefinitely as long as the participants continue to cooperate.<br />
* '''Revocable Sequence Maturity Contract (RSMC):'''<ref name="ln_pdf"/> a ''contract'' used in Lightning to revoke the previous ''commitment transaction''. This is allowed through mutual consent in Lightning by both parties signing a new commitment transaction and releasing the data necessary to create ''breach remedy transactions'' for the previous commitment transaction. This property allows Lightning to support ''bi-directional payment channels'', recover from failed ''HTLC'' routing attempts without needing to commit to the blockchain, as well as provide advanced features such as ''PILPPs.''<br />
* '''Single-funded channel:'''<ref name="dryja_directed_graph"/> a channel opened by a ''funding transaction'' containing only inputs from Alice. Compare to a ''dual-funded channel'' where Alice and Bob both contribute inputs to the initial balance of the channel.<br />
* '''Timelock:'''<ref>[http://rusty.ozlabs.org/?p=450 Lightning Networks Part I: Revocable Transactions]<br>Rusty Russell<br>2016-04-17</ref> either an encumbrance to a transaction that prevents that transaction from being added to the blockchain before a particular time or block height (as is the case with [[nLockTime]], or an encumbrance that prevents a spend from a transaction output from being added to the blockchain before a particular time or block height (as is the case of OP_CLTV, consensus enforced sequence number relative locktime, and OP_CSV). In Lightning, this is used to prevent malicious intermediaries from holding other users' funds hostages as well as to allow victims of attempted theft to submit breach remedy transactions before the thief can respend the funds he stole.<br />
* '''TTL:''' (Time To Live<ref>[http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-July/000019.html Re: Routing on the Lightning Network?]<br>Rusty Russell<br>Retrieved 2016-04-17</ref>) when Alice pays Bob with a ''hash locked'' in-channel payment that's ultimately intended for Charlie, she specifies how long Bob has to deliver the payment (its time to live) before the payment becomes invalid. When Bob pays Charlie with his own in-channel payment that has the same hash lock, Bob specifies a slightly shorter amount of time that Charlie has to reveal the pre-image that unlocks the hash lock before Bob's payment becomes invalid. This ensures that either Bob receives the data necessary to remove the hash lock from the payment he received from Alice or the payment he made to Charlie is invalidated; Alice gets the same guarantee that either the payment she made to Bob ultimate goes through to Charlie or her payment to Bob is invalidated.<br />
* '''Unilateral:'''<ref name="ln_pdf"/> any action performed by only one of the participants in a channel without requesting or needing permission from the other participant. Lightning allows channels to be closed unilaterally (so Alice can close the channel by herself if Bob becomes unresponsive) and attempted fraud can be penalized unilaterally (so Alice can take any bitcoins Mallory tried to steal when he broadcast an old ''commitment transaction'').<br />
* '''UTXO:'''<ref>[https://bitcoin.org/en/glossary/unspent-transaction-output Unspent Transaction Output (UTXO)]<br>Bitcoin.org Developer Glossary<br>Retrieved 2016-04-17</ref> (Unspent Transaction Output) spendable bitcoins. A transaction output lists a bitcoin amount and the conditions (called an ''encumbrance'') that need to be fulfilled in order to spend those bitcoins. Once those bitcoins have been spent on the blockchain, no other transaction in the same blockchain can spend the same bitcoins, so an Uspent Transaction Output (UTXO) is bitcoins that can be spent.<br />
<br />
== See Also ==<br />
<br />
* [[Payment channels]]<br />
* [[Hashed Timelock Contracts]]<br />
* [[Off-Chain Transactions]]<br />
* [http://dev.lightning.community/resources/index.html Lightning Lab's list of resources]<br />
* [https://github.com/dan-da/lightning-nodes/blob/master/README.md List of network nodes].<br />
* [https://www.reddit.com/r/Bitcoin/comments/7pwna9/lightning_network_megathread/ Lightning Network Megathread on Reddit]<br />
<br />
== References ==<br />
<references><br />
<ref name="bitcoin_0_1_code">[http://satoshi.nakamotoinstitute.org/code/ Bitcoin 0.1 code]<br>Satoshi Nakamoto<br>Retrieved 2016-04-11</ref><br />
<ref name="bip68">[https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68: Relative lock-time using consensus-enforced sequence numbers]<br>Mark Friedenbach, BtcDrak, Nicolas Dorier, and kinoshitajona<br>Retrieved 2016-04-12</ref><br />
<references/><br />
<br />
[[Category:Technical]]</div>Mercurytoxichttps://tests.bitcoin.it/w/index.php?title=Vanitygen&diff=61424Vanitygen2016-08-08T06:08:27Z<p>Mercurytoxic: </p>
<hr />
<div>'''Vanitygen''' is a command-line vanity bitcoin address generator.<br />
<br />
If you're tired of the random, cryptic addresses generated by regular bitcoin clients, you can use vanitygen to create a more personalized address.<br />
Add unique flair when you tell people to send bitcoins to 1stDownqyMHHqnDPRSfiZ5GXJ8Gk9dbjO.<br />
Alternatively, vanitygen can be used to generate random addresses offline.<br />
<br />
Vanitygen accepts as input a pattern, or list of patterns to search for, and produces a list of addresses and private keys. Vanitygen's search is probabilistic, and the amount of time required to find a given pattern depends on how complex the pattern is, the speed of your computer, and whether you get lucky.<br />
<br />
The example below illustrates a session of vanitygen. It is typical, and takes about 10 sec to finish, using a Core 2 Duo E6600 CPU on x86-64 Linux:<br />
<syntaxhighlight lang="bash"><br />
$ ./vanitygen 1Boat<br />
Difficulty: 4476342<br />
Pattern: 1Boat <br />
Address: 1BoatSLRHtKNngkdXEeobR76b53LETtpyT<br />
Privkey: 5J4XJRyLVgzbXEgh8VNi4qovLzxRftzMd8a18KkdXv4EqAwX3tS<br />
</syntaxhighlight><br />
<br />
Vanitygen includes components to perform address searching on your CPU (vanitygen) and your OpenCL-compatible GPU (oclvanitygen). Both can be built from source, and both are included in the Windows binary package. Also included is oclvanityminer, the vanity address mining client. Oclvanityminer can be used to automatically claim bounties on sites such as [[User:ThePiachu|ThePiachu]]'s [[Vanity Pool]].<br />
<br />
Current version: 0.22<br />
<br />
Windows x86+x64 binaries [https://github.com/downloads/samr7/vanitygen/vanitygen-0.20-win.zip here]. PGP signature [http://insight.gotdns.org/~samr7/vanitygen-0.20-win.zip.asc here].<br />
<br />
Get the source from [https://github.com/samr7/vanitygen GitHub]. Includes Makefiles for Linux and Mac OS X.<br />
<br />
Main discussion at [https://bitcointalk.org/index.php?topic=25804.0 BitCoinTalk]<br />
<br />
The latest source doesn't work properly for high-end AMD cards (7XXX and greater). Solution is to change line 459 in oclengine.c from: return quirks; to: return quirks & ~VG_OCL_AMD_BFI_INT;<br />
Windows x86+x64 binaries that solve this problem plus provide support for compressed keys [https://lifeboat.com/oclvanitygen here]. PGP signature [https://lifeboat.com/oclvanitygen.zip.sig here]. If you have any problems with the binaries, join the relevant [https://bitcointalk.org/index.php?topic=301068.0 BitCoinTalk discussion].<br />
<br />
== Expected keysearch rate ==<br />
What key search rate can I expect from hardware X?<br />
<br />
'''Keysearch Rates'''<br />
{| class="wikitable sortable"<br />
|-<br />
! CPU !! GPU !! keys/s !! Comment<br />
|-<br />
| Core i5 750 @2.67 GHz || nVidia GTS 250 || 1.54 Mkey/s || 110% CPU [https://bitcointalk.org/index.php?topic=25804.msg378820#msg378820]<br />
|-<br />
| Core2 Duo 6600 || nVidia GTX 285 || 3.5 Mkey/s || 100% CPU / 90% GPU [https://bitcointalk.org/index.php?topic=25804.msg378114#msg378114]<br />
|-<br />
| Sempron 140 || AMD 5830 || 5.5 Mkey/s || 100% CPU / 60% GPU [https://bitcointalk.org/index.php?topic=25804.msg378114#msg378114]<br />
|-<br />
| || AMD Radeon r7 240 || 4 Mkey/s || [https://bitcointalk.org/index.php?topic=25804.msg11872747#msg11872747]<br />
|-<br />
| Core i7 || AMD 6500M || 4.5 Mkey/s || 98% GPU<br />
|-<br />
| || nVidia GeForce GTX 680M || 14-16 Mkey/s || [https://bitcointalk.org/index.php?topic=25804.msg11882134#msg11882134]<br />
|-<br />
| || nVidia GeForce GTX 970 || 38 Mkey/s || [https://bitcointalk.org/index.php?topic=25804.msg11851273#msg11851273]<br />
|-<br />
| Core i7-4702MQ 2.2GHz || || 1.09 Mkey/s ||<br />
|-<br />
| Core i7-4702MQ 2.2GHz || GeForce GT750M || 5.38 Mkey/s ||<br />
|-<br />
| || AMD Radeon r9 280x || 25-35 Mkey/s ||<br />
|-<br />
| || Sapphire Radeon HD 7970 || 28Mkey/s || [https://bitcointalk.org/index.php?topic=25804.msg12269936#msg12269936]<br />
|-<br />
| || AMD Radeon HD 5870 || 30 Mkey/s || [https://bitcointalk.org/index.php?topic=25804.msg12262017#msg12262017]<br />
|-<br />
| || Asus Strix GTX 970 || 40Mkey/s || [https://bitcointalk.org/index.php?topic=25804.msg12269936#msg12269936]<br />
|-<br />
| || nVidia GeForce GTX 780 Ti (3GB 384-bit GDDR5) || 50-60 Mkey/s || [https://bitcointalk.org/index.php?topic=25804.msg11944467#msg11944467]<br />
|-<br />
| Core i5-2500K @ 3.30GHz || AMD RX 480 || 57-64 Mkey/s || With AMD patch [https://nastyfans.org/download/oclvanitygen.txt]<br />
|}<br />
<br />
As vanitygen performs a lot of large integer arithmetic, running it in 64-bit mode makes a huge difference in key search rate, easily a 50% improvement over 32-bit mode. If you are using a 64-bit edition of Windows, and not using a GPU, be sure to use vanitygen64.exe.<br />
<br />
Radeon 58XX outperforms Radeon 69XX by a very comfortable margin. Oclvanitygen is sensitive to integer multiply throughput, and Radeon 58XX can multiply concurrently with other operations. At similar clocks, a hobbled Radeon 5830 will outperform a Radeon 6970.<br />
<br />
In custom builds, CPU performance will be less than expected if the OpenSSL library is an older version (<1.0.0d) or is not built with the appropriate optimizations enabled.<br />
<br />
== Difficulty of finding a vanity ==<br />
The difficult of finding a vanity address depends on its exact structure (leading letters and numbers) and how likely such an output is given the algorithms involved, which can consist of several pivots where the difficulty suddenly changes.<br />
{| class="wikitable"<br />
|-<br />
! vanity !! difficulty !! Comment<br />
|-<br />
| 1AAAAA || 259,627,881 || <br />
|-<br />
| 1QLbz6 || 259,627,881 || This vanity is alphabetically before a major pivot, the [[RIPEMD160]] hash value of 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF (address: 1QLbz7JHiBTspS962RLKV8GndWFwi5j6Qr)<br />
|-<br />
| 1QLbz7JHiBTspS962RLKV8GndWE || 2.9597E+45 ||<br />
|-<br />
| 1QLbz7 || 837,596,142 || This vanity is partially after a pivot and difficulty increases<br />
|-<br />
| 1QLbz7JHiBTspS962RLKV8GndWG || 1.6489E+47 || After a major pivot and 59 times as difficult as the 'E' vanity.<br />
|-<br />
| 1QLbz8 || 837,596,142 || <br />
|-<br />
| 1aaaaa || 15,318,045,009 || Well after various pivots and subsequently more difficult.<br />
|-<br />
| 1zzzzz || 15,318,045,009 ||<br />
|-<br />
| 111111 || 1,099,511,627,776 || A special case, leading numbers 1 (one) is especially difficult.<br />
|}<br />
<br />
== Use of vanitygen to try to attack addresses ==<br />
Using vanitygen you might think that you would be able to find the private key for a given address. In practice, this is considered impossible. Given that the difficulty increases exponentially the longer your vanity is, so does the average time required to find that vanity. The example table below shows how an increasingly complex vanity affects the difficulty and average time required to find a match only for that vanity, let alone the full address, for a machine capable of looking through 1 million keys per second.<br />
{| class="wikitable"<br />
|-<br />
! vanity !! difficulty !! average time<br />
|-<br />
| 1B || 22 || < 1s<br />
|-<br />
| 1Bi || 1,330 || < 1s<br />
|-<br />
| 1Bit || 77,178 || < 1s<br />
|-<br />
| 1Bitc || 4,476,342 (4.48E+6)|| < 10s<br />
|-<br />
| 1Bitco || 259,627,881 (2.6E+8)|| 3 minutes<br />
|-<br />
| 1Bitcoi || 15,058,417,127 (1.506E+10) || 3 hours<br />
|-<br />
| 1Bitcoin || 8.7339E+11 || 1 week<br />
|-<br />
| 1BitcoinE || 5.0657E+13 || 1 year<br />
|-<br />
| 1BitcoinEa || 2.9381E+15 || 60 years<br />
|-<br />
| 1BitcoinEat || 1.7041E+17 || 3,500 years<br />
|-<br />
| 1BitcoinEate || 9.8837E+18 || 200,000 years<br />
|-<br />
| 1BitcoinEater || 5.7325E+20 || 11,700,000 years<br />
|-<br />
| 1BitcoinEaterAddressDontSend || 1.6209E+47 || 3.3E+33 or 3.3 decillion years.<br />
|}<br />
<br />
== Outsourcing your Vanity Address generation ==<br />
The safest option to calculate your vanity address is always to calculate it yourself. Though for larger patterns, you might not have enough resources or time to calculate this. In this case you can choose to outsource your vanity address generation to a [[Bitcoin Vanity Generation Website]]. In this case you always have to be very careful and you have to make sure you never trust your full private key to any third party. The best and safest manner how to outsource this vanity address generation is by using [https://en.bitcoin.it/wiki/Split-key_vanity_address#Address_generation split-key address generation].<br />
<br />
== See also ==<br />
* [[Bitcoin Vanity Generation Website]]<br />
<br />
[[Category:Vanity address]]</div>Mercurytoxichttps://tests.bitcoin.it/w/index.php?title=Testnet&diff=44143Testnet2014-01-30T08:38:31Z<p>Mercurytoxic: Replaced closed faucet with new one.</p>
<hr />
<div>The '''testnet''' is an alternative Bitcoin [[block chain]], to be used for testing. This allows application developers or bitcoin testers to experiment, without having to use real bitcoins or worrying about breaking the main bitcoin chain.<br />
<br />
Run bitcoin or bitcoind with the -testnet flag to use the testnet (or put testnet=1 in the bitcoin.conf file).<br />
<br />
There have been three generations of testnet. Testnet2 was just the first testnet reset with a different genesis block, because people were starting to trade testnet coins for real money. '''Testnet3''' is the current test network. It was introduced with the 0.7 release, introduced a third genesis block, a new rule to avoid the "difficulty was too high, is now too low, and transactions take too long to verify" problem, and contains blocks with edge-case transactions designed to test implementation compatibility.<br />
<br />
==Differences==<br />
* Default Bitcoin network protocol listen port is 18333 (instead of 8333)<br />
* Default RPC connection port is 18332 (instead of 8332)<br />
* Bootstrapping IRC channel is #bitcoinTEST instead of #bitcoin (both on irc.lfnet.org). The built-in node list is disabled.<br />
* A different value of ADDRESSVERSION field ensures no testnet Bitcoin addresses will work on the production network. (0x6F rather than 0x00)<br />
* The protocol message header bytes are 0x0B110907 (instead of 0xF9BEB4D9) <br />
* Minimum [[difficulty]] of 1.0 on testnet is equal to difficulty of 0.5 on mainnet. This means that the mainnet-equivalent of any testnet difficulty is half the testnet difficulty. In addition, if no block has been found in 20 minutes, the difficulty automatically resets back to the minimum for a single block, after which it returns to its previous value.<br />
* A new genesis block<br />
* The IsStandard() check is disabled so that non-standard transactions can be experimented with.<br />
<br />
==Genesis Block==<br />
<br />
Testnet uses a different genesis block to the main network. You can find it [https://www.biteasy.com/testnet/blocks/000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943 here] or [http://blockexplorer.com/testnet/b/0 here].<br />
The testnet was reset with a new genesis block for the 0.7 bitcoin release.<br />
<br />
==External links==<br />
* [https://bitcointalk.org/?topic=4483.0 Test Network forum topic]<br />
* [http://faucet.xeno-genesis.com/ Mojocoin Testnet3 Faucet]<br />
* [http://tpfaucet.appspot.com/ TP's TestNet Faucet]<br />
* [http://faucet.luis.im/ luis.im Mojocoin Testnet3 Faucet]<br />
* [http://testnet.btclook.com/ BTCLook Testnet Explorer]<br />
* [https://www.biteasy.com/testnet/blocks Biteasy.com Testnet Blockexplorer]<br />
* [http://pool.qdoop.net:18331/chain/Testnet3 Testnet3 ABE based Block Explorer]<br />
* [http://blockexplorer.com/testnet Testnet Block Explorer]<br />
* [https://sourceforge.net/projects/bitcoin/files/Bitcoin/testnet-in-a-box/ Testnet-In-A-Box self-contained testnet]<br />
* [https://github.com/freewil/bitcoin-testnet-box Forked/Updated testnet-box]<br />
<br />
[[Category:Technical]]<br />
[[Category:Developer]]</div>Mercurytoxichttps://tests.bitcoin.it/w/index.php?title=Bitcoin_faucet&diff=44142Bitcoin faucet2014-01-30T08:35:34Z<p>Mercurytoxic: New faucet link</p>
<hr />
<div>Used to gives bitcoins out for free to each visitor. IP addresses that receive bitcoins were recorded, so that bitcoins were given only once to each address. It was operated by [[User:Gavinandresen|Gavin Andresen]], however it is not functioning as of Jan 30 2013.<br />
<br />
For [[Testnet]] there exists a different faucet that is working which gives out coins for people who want to do tests on the Testnet. The testnet faucet also has a simple wallet available to hold testnet coins.<br />
<br />
==See Also==<br />
<br />
* [[Trade#Getting_started|Alternate bitcoin distribution services]]<br />
<br />
==External Links==<br />
<br />
* [http://freebitcoins.appspot.com Bitcoin Faucet] web site<br />
* [http://tpfaucet.appspot.com/ TestNet Faucet] web site<br />
* [http://faucet.xeno-genesis.com/ Mojocoin Testnet3 Faucet] web site<br />
* [http://faucet.luis.im/ luis.im Mojocoin Testnet3 Faucet] web site<br />
* [http://freecoins.herokuapp.com FreeCoins] site, 0.00005 Bitcoin payouts sent every day, faucet can be used once a week.<br />
<br />
[[Category:Services]]</div>Mercurytoxichttps://tests.bitcoin.it/w/index.php?title=Testnet&diff=12686Testnet2011-07-08T16:15:31Z<p>Mercurytoxic: /* External links */ Current testnet difficulty</p>
<hr />
<div>The '''testnet''' is an alternative Bitcoin [[block chain]], to be used for testing. This allows application developers or bitcoin testers to experiment, without having to use real bitcoins or worrying about breaking the main bitcoin chain.<br />
<br />
Run bitcoin or bitcoind with the -testnet flag to use the testnet (or put testnet=1 in the bitcoin.conf file).<br />
<br />
==Differences==<br />
* Instead of port 8333 (listen), port 18333 is used.<br />
* Bootstrapping IRC channel is #bitcoinTEST instead of #bitcoin (both on irc.lfnet.org). The built-in node list is disabled.<br />
* A different value of ADDRESSVERSION field ensures no testnet BitCoin addresses will work on the production network. (0x6F rather than 0x00)<br />
* The protocol message header bytes are shifted up (0xFABFB5DA instead of 0xF9BEB4D9)<br />
* Minimum [[difficulty]] of 1.0 on testnet is equal to difficulty of 0.5 on mainnet. This means that the mainnet-equivalent of any testnet difficulty is half the testnet difficulty.<br />
* A new genesis block<br />
<br />
==Genesis Block==<br />
<br />
Testnet uses a different genesis block to the main network. You can find it at http://blockexplorer.com/testnet/b/0<br />
The testnet was reset with a new genesis block for the 0.3.20 bitcoin release.<br />
<br />
==External links==<br />
* [https://sourceforge.net/projects/bitcoin/files/Bitcoin/testnet-in-a-box/ Testnet-In-A-Box self-contained testnet]<br />
* [http://www.bitcoin.org/smf/index.php?topic=363.0 Test Network forum topic]<br />
* [https://freebitcoins.appspot.com/test/ Testnet Faucet]<br />
* [http://blockexplorer.com/testnet Testnet Block Explorer]<br />
* [http://blockexplorer.com/testnet/q/getdifficulty Testnet current difficulty] As output by BitCoin's getDifficulty]<br />
<br />
[[Category:Technical]]<br />
[[Category:Developer]]</div>Mercurytoxic