https://tests.bitcoin.it/w/api.php?action=feedcontributions&user=Tril&feedformat=atomBitcoin Wiki - User contributions [en]2024-03-29T11:03:53ZUser contributionsMediaWiki 1.30.0https://tests.bitcoin.it/w/index.php?title=Fallback_Nodes&diff=46302Fallback Nodes2014-04-10T01:36:50Z<p>Tril: /* Tor nodes */ change my onion address and add a 2nd node</p>
<hr />
<div>This is a list of nodes which are considered reliable.<br />
<br />
== How to use this list ==<br />
<br />
=== Connect to nodes ===<br />
<br />
You can connect to these nodes with the ''-addnode=ip'' switch instead of the usual node harvesting process (through IRC or via the embedded nodelist). You can connect to more than one node by using ''-addnode=ip'' more than once. It is usually a good idea to connect to more than one of these nodes.<br />
<br />
==== Nodes without a fixed ip ====<br />
<br />
If the node IP is not fixed (see "Fixed" column), you will have to resolve the node's name (first column) each time the IP changes. Some nodes may have their ip change once a day, some others once a month, and some others may stay on the same IP for years. Still, as long as the IP is not fixed, there is no guarantee it will stay the same.<br />
<br />
In order to enable hostname lookups for the ''-addnode'' and ''-connect'' parameters, you must additionally provide the ''-dns'' parameter. Example:<br />
bitcoind -dns -addnode=bitcoin.es<br />
<br />
Versions prior to 0.3.22 do not support hostnames to the ''-addnode'' parameter, so you must do the resolving part for it. For example on linux:<br />
bitcoind -addnode=$(dig +short bitcoin.es)<br />
<br />
=== IP Transactions ===<br />
<br />
You can also send [[IP Transactions]] to these nodes. If you include your bitcoin address in the "message" field, you may have your coins back.<br />
<br />
=== Tor network ===<br />
<br />
To use Bitcoin-Qt over Tor hidden services, in a terminal/console enter:<br />
bitcoin-qt -proxy=127.0.0.1:9050 -onlynet=tor<br />
<br />
To use Bitcoin with one specific Tor node, run<br />
bitcoin-qt -proxy=127.0.0.1:9050 -connect=abcde.onion<br />
, where abcde.onion needs to be substituted with one of the [[Fallback_Nodes#Tor_nodes|Tor nodes below]]. These parameters can be added to [[Running_Bitcoin#Bitcoin.conf_Configuration_File|bitcoin.conf]] to make them permanent.<br />
<br />
You can find detailed information on running clients and hidden services within Tor in the [https://github.com/bitcoin/bitcoin/blob/master/doc/tor.md documentation].<br />
<br />
== Nodes list ==<br />
<br />
=== IPv6 Nodes ===<br />
{|class="wikitable sortable"<br />
! Hostname !! Owner !! IP !! Fixed !! Status !! Last Seen (GMT) !! Accepts IP transactions<br />
|-<br />
<!-- BEGIN NODELIST --><br />
| InductiveSoul.US || [[User:Inductivesoul|Inductive Soul]] || 2601:7:6680:2ac:4d29:40ff:7513:fcc7 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || 11-13-2013 (MDY) || Yes<br />
|-<br />
| caffeinator.net || [[User:Atrophy|Atrophy]] || || || {{Fallback Nodes/Node Up}} || 2013-05-10 ||<br />
|-<br />
| 2001:470:8:2e1::40 || ? || 2001:470:8:2e1::40 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes<br />
|-<br />
| x.jine.se || jine || 213.112.52.246 || {{Table Value No}} || {{Fallback Nodes/Node Down}} || || Yes<br />
|-<br />
| messier.bzfx.net || BZFX/[[User:A Meteorite|A Meteorite]] || 2001:41d0:1:d632::1 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || ||<br />
<!-- END NODELIST --><br />
|}<br />
<br />
=== IPv4 Nodes ===<br />
{|class="wikitable sortable"<br />
! Hostname !! Owner !! IP !! Fixed !! Status !! Last Seen (GMT) !! Accepts IP transactions<br />
|-<br />
<!-- BEGIN NODELIST --><br />
|-<br />
| btcnode1.evolyn.net || Evolyn || 85.214.251.25 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || 2014-01-26 || Yes<br />
|-<br />
| InductiveSoul.US || [[User:Inductivesoul|Inductive Soul]] || 67.186.224.85 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || 2013-11-13 || Yes<br />
|-<br />
| archivum.info || Ferraro Ltd.|| 88.198.58.172 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || || Yes<br />
|-<br />
| 62.75.216.13 || exMULTI, Inc. || 62.75.216.13 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || No<br />
|-<br />
| 69.64.34.118 || exMULTI, Inc. || 69.64.34.118 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || No<br />
|-<br />
| 79.160.221.140 || K-Norway || 79.160.221.140 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes<br />
|-<br />
| netzbasis.de || unknown3 || 81.169.129.25 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes<br />
|-<br />
| btc.turboadmin.com || osmosis || 98.143.152.14 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || No<br />
|-<br />
| fallback.bitcoin.zhoutong.com || Zhou Tong || 117.121.241.140 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || No<br />
|-<br />
| bauhaus.csail.mit.edu || imsaguy || 128.30.96.44 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes<br />
|-<br />
| jun.dashjr.org || Luke-Jr || 173.242.112.53 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || <br />
|-<br />
| cheaperinbitcoins.com || Xenland/Shane || 184.154.36.82 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes<br />
|-<br />
| django.webflows.fr || unknown2 || 188.165.213.169 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes<br />
|-<br />
| 204.9.55.71 || toasty || 204.9.55.71 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes<br />
|-<br />
| btcnode.novit.ro || ovidiusoft - novit.ro || 93.187.142.114 || {{Table Value No}} || {{Fallback Nodes/Node Down}} || || Yes<br />
|-<br />
| porgressbar.sk || progressbar hackerspace || 91.210.181.21 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || || Yes<br />
|-<br />
| faucet.bitcoin.st || bitcoin street || 64.27.57.225 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || || Yes<br />
|-<br />
| bitcoin.securepayment.cc || SecurePayment CC || 63.247.147.163 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || || Yes<br />
|-<br />
| x.jine.se || jine || 213.112.48.166 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || || Yes<br />
|-<br />
| www.dcscdn.com || [[User:Danw12|Danw12]] || 199.115.228.181 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || ||<br />
|-<br />
| ns2.dcscdn.com || [[User:Danw12|Danw12]] || 199.115.228.182 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || ||<br />
|-<br />
| coin.soul-dev.com || Soul-Dev || || || {{Fallback Nodes/Node Up}} || ||<br />
|-<br />
| messier.bzfx.net || BZFX/[[User:A Meteorite|A Meteorite]] || 91.121.205.50 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || ||<br />
|-<br />
| btcnode1.bitgroup.cc || BitGroup || 198.211.116.191 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || || Yes<br />
|-<br />
| btcnode2.bitgroup.cc || BitGroup || 162.243.120.138 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || || Yes<br />
|-<br />
| btcnode3.bitgroup.cc || BitGroup || 95.85.8.237 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || || Yes<br />
<!-- END NODELIST --><br />
|}<br />
<br />
There is a list of nodes which have been seen on the network recently at http://blockchain.info/connected-nodes<br />
<br />
=== Tor nodes ===<br />
<br />
{|class="wikitable sortable"<br />
! Hostname !! Owner !! Status !! Last Seen (GMT) !! Accepts IP transactions<br />
|-<br />
| btcnet3utgzyz2bf.onion || anonymous || Up || 2014-01-27 || Yes <br />
|-<br />
| evolynhit7shzeet.onion || Evolyn || Up || 2014-01-27 || Yes <br />
|-<br />
| bitcoin2u5jnjzzz.onion || anonymous || Up || 2014-01-27 || Yes <br />
|-<br />
| btc4ulpftizx5b72.onion || TorNode || Up || 2013-05-10 || Yes<br />
|-<br />
| vso3r6cmjoomhhgg.onion || echelon || Up || 2013-05-10 || Yes<br />
|-<br />
| yyl3ipdmyjkfypmx.onion || redemerald || Up || 2013-05-10 || Yes<br />
|-<br />
| pqosrh6wfaucet32.onion || bitcoin street || Up || 2013-05-10 || No<br />
|-<br />
| zy3kdqowmrb7xm7h.onion || Tril || Up || 2014-04-09 || No<br />
|-<br />
| z55v4ostefnwfy32.onion || Tril || Up || 2014-04-09 || No<br />
|-<br />
| e3tn727fywnioxrc.onion || Zedd || Up || 2013-05-10 || No<br />
|-<br />
| 6hgmaxwellgpv2oe.onion || Gmaxwell || Down || 2012-07-01 || No<br />
|-<br />
| kjy2eqzk4zwi5zd3.onion || sipa || Up || 2013-05-10 || No<br />
|-<br />
| siqdznszjf4e6v5j.onion || Tuxavant || Up || 2013-05-10 || ?<br />
|-<br />
| sjdntqu5roj4q6lo.onion || torservers || Down || 2012-05-19 || ?<br />
|-<br />
| bitcoin2bkgm3fke.onion || ? || Down || 2012-05-19 || Yes<br />
|-<br />
| 7hxvg2lvr2ashzli.onion || Tuxavant || Down || 2013-05-10 || ?<br />
|-<br />
| j43z65b6r2usg3vk.onion || Dybbuk || Down || 2011-02-11 || Yes<br />
|-<br />
| pvuif6nonbhj3o3r.onion || ? || Down || 2011-02-11 || Yes<br />
|-<br />
| c5qvugpewwyyy5oz.onion || ? || Down || 2011-02-11 || Yes<br />
|-<br />
| mutqcuh7hwxmhx3k.onion || Xirafe || Down || 2012-06-23 || ?<br />
|-<br />
| ijzt2eeizty3p5xe.onion || ? || Down || 2011-02-11 || Yes<br />
|-<br />
| r4de4zf4lyniu4mx.onion:8444 || ? || Down || 2012-06-26 || ?<br />
|-<br />
| bitcoinprwwpuinm.onion:8333 || ? || Down || 2012-06-26 || ?<br />
|-<br />
| x3danbeag2kyx644.onion || redemerald || Down || 2013-01-04 || Yes<br />
|-<br />
| bitcoinbudtoeks7.onion || ? || Down || 2011-02-11 || ?<br />
|-<br />
| iy6ni3wkqazp4ytu.onion || ? || Down || 2011-02-11 || ?<br />
|-<br />
| h4kklwodpcmo6cbq.onion || ? || Down || 2011-02-11 || ?<br />
|-<br />
| vv6kcfscuntybrzm.onion || ? || Down || 2011-02-11 || ?<br />
|-<br />
| nlnsivjku4x4lu5n.onion || ? || Down || 2011-02-11 || ?<br />
|-<br />
| xqzfakpeuvrobvpj.onion || ? || Down || 2010-11-13 || No<br />
|-<br />
| 4lmduyac3svgrrav.onion || ? || Down || 2011-02-11 || No<br />
|-<br />
| usasx4urod3yj4az.onion || ? || ? || 2011-02-11 || No<br />
|}<br />
<br />
== Adding a node ==<br />
<br />
Before adding yourself as a fallback node, you should be sure your node will stay online for a long time. If a node is offline for more than 24 hours it will be removed from the list.<br />
<br />
To add a node in this list, you just need the ip/hostname and your name, the other fields will be filled automatically. Insert the following lines before the <tt>END NODELIST</tt> line:<br />
<br />
<nowiki>|-<br />
| ip || your name</nowiki><br />
<br />
==See Also==<br />
<br />
* [[Network|Bitcoin Network]]<br />
* [http://nodes.bitcoin.st Fallback Nodes] List of longest running Bitcoin Nodes listed by Country.</div>Trilhttps://tests.bitcoin.it/w/index.php?title=Raw_transactions&diff=30139Raw transactions2012-08-27T06:04:10Z<p>Tril: /* Validate a transaction without broadcasting it */ it's -> its</p>
<hr />
<div>== Overview ==<br />
<br />
The "raw transaction API" was introduced with Bitcoin-Qt/bitcoind version 0.7. It gives developers or very sophisticated end-users low-level access to transaction creation and broadcast.<br />
<br />
== JSON-RPC API ==<br />
=== listunspent [minconf=1] [maxconf=999999] ===<br />
Returns an array of unspent transaction outputs in the wallet that have between minconf and maxconf (inclusive) confirmations. Each output is a 5-element object with keys: txid, output, scriptPubKey, amount, confirmations. txid is the hexadecimal transaction id, output is which output of that transaction, scriptPubKey is the hexadecimal-encoded CScript for that output, amount is the value of that output and confirmations is the transaction's depth in the chain.<br />
=== createrawtransaction [{"txid":txid,"vout":n],...] {address:amount,...} ===<br />
Create a transaction spending given inputs (array of objects containing transaction outputs to spend), sending to given address(es). Returns the hex-encoded transaction in a string. Note that the transaction's inputs are not signed, and it is not stored in the wallet or transmitted to the network.<br />
<br />
Also note that NO transaction validity checks are done; it is easy to create invalid transactions or transactions that will not be relayed/mined by the network because they contain insufficient fees.<br />
=== decoderawtransaction <hex string> ===<br />
Returns JSON object with information about a serialized, hex-encoded transaction.<br />
=== getrawtransaction <txid> [verbose=0] ===<br />
If verbose=0, returns serialized, hex-encoded data for transaction txid. If verbose is non-zero, returns a JSON Object containing information about the transaction. Returns an error if <txid> is unknown.<br />
=== signrawtransaction <hex string> [{"txid":txid,"vout":n,"scriptPubKey":hex},...] [<privatekey1>,...] [sighash="ALL"] ===<br />
Sign as many inputs as possible for raw transaction (serialized, hex-encoded). The first argument may be several variations of the same transaction concatenated together; signatures from all of them will be combined together, along with signatures for keys in the local wallet. The optional second argument is an array of parent transaction outputs, so you can create a chain of raw transactions that depend on each other before sending them to the network. Third optional argument is an array of base58-encoded private keys that, if given, will be the only keys used to sign the transaction. The fourth optional argument is a string that specifies how the [[OP CHECKSIG|signature hash]] is computed, and can be "ALL", "NONE", "SINGLE", "ALL|ANYONECANPAY", "NONE|ANYONECANPAY", or "SINGLE|ANYONECANPAY".<br />
Returns json object with keys:<br />
* hex : raw transaction with signature(s) (hex-encoded string)<br />
* complete : 1 if rawtx is completely signed, 0 if signatures are missing.<br />
If no private keys are given and the wallet is locked, requires that the wallet be unlocked with walletpassphrase first.<br />
<br />
=== sendrawtransaction <hex string> ===<br />
Submits raw transaction (serialized, hex-encoded) to local node and network. Returns transaction id, or an error if the transaction is invalid for any reason.<br />
<br />
== Motivating use cases ==<br />
=== Multisignature transactions ===<br />
Funds are sitting in one or more multisignature transaction outputs, and it is time to gather signatures and spend them.<br />
<br />
Assumption: you know the multisignature outputs' {txid, outputNumber, amount}.<br />
<br />
* Create a raw transaction to spend, using createrawtransaction.<br />
* Use signrawtransaction to add your signatures (after unlocking the wallet, if necessary).<br />
* Give the transaction to the other person(s) to sign.<br />
* You or they submit the transaction to the network using sendrawtransaction.<br />
'''You must be careful to include an appropriate transaction fee''', or the sendrawtransaction method is likely to fail (either immediately or, worse, the transaction will never confirm).<br />
=== Debugging/testing ===<br />
These lower-level routines will be useful for debugging and testing; listunspent gives a detailed list of the state of the wallet, and sendrawtx might be used to test double-spend-handling.<br />
<br />
=== Input selection control ===<br />
You want fine-grained control over exactly what coins in the wallet are spent.<br />
<br />
* Get a list of not-yet-spent outputs with listunspent<br />
* Create a transaction using createrawtransaction<br />
* Apply signatures using signrawtransaction<br />
* Submit it using sendrawtransaction<br />
Note that you are responsible for preventing accidental double-spends.<br />
<br />
=== Control over payment of fees and/or transaction re-transmission ===<br />
You want to specify, on a per-transaction basis, how much to pay in fees. Or you want to implement your own policy for how often transactions that are not immediately included in blocks are re-broadcast to the network.<br />
<br />
* Maintain a list of not-yet-spent, confirmed outputs with listunspent (refreshed every time a new block is found, using the -blocknotify feature).<br />
* Create a transaction with exactly the amount of fees you wish with createrawtransaction<br />
* Apply signatures using signrawtransaction<br />
* Submit it with sendrawtransaction<br />
* Re-submit it periodicially with sendrawtransaction if it does not get into a block.<br />
<br />
== Other, non-obvious use cases ==<br />
=== Re-broadcast a transaction ===<br />
If you want to re-broadcast a transaction right away, you can use the getrawtransaction and sendrawtransaction API calls to do that. As a bash shell-script one-liner it would be:<br />
* sendrawtransaction $(getrawtransaction $TXID)<br />
(note that Bitcoin-Qt/bitcoind automatically re-transmit wallet transactions periodically until they are accepted into a block).<br />
<br />
=== Validate a transaction without broadcasting it ===<br />
If you have a raw transaction and want to make sure all of its signatures are correct, you can use the signrawtransaction API call. Pass in the hex-encoded raw transaction, any inputs that bitcoind doesn't yet know about, and an empty array of private keys to use to sign the transaction. Passing an empty array of private keys will prevent signrawtransaction from doing any signing; if it returns "complete":1 then all of the existing signatures are valid and there are no signatures missing.<br />
[[Category:Technical]]<br />
[[Category:Developer]]</div>Trilhttps://tests.bitcoin.it/w/index.php?title=Fallback_Nodes&diff=25091Fallback Nodes2012-04-05T06:09:00Z<p>Tril: /* Tor nodes */ adding node and updating status of a few</p>
<hr />
<div>This is a list of nodes which are considered reliable. Nodes from this list which are down for more than 24 hours will be automatically removed and status of each node is displayed and updated every hour by [[User:WikiBot|WikiBot]].<br />
<br />
== How to use this list ==<br />
<br />
=== Connect to nodes ===<br />
<br />
You can connect to these nodes with the ''-addnode=ip'' switch instead of the usual node harvesting process (through IRC or via the embedded nodelist). You can connect to more than one node by using ''-addnode=ip'' more than once. It is usually a good idea to connect to more than one of these nodes.<br />
<br />
==== Nodes without a fixed ip ====<br />
<br />
If the node IP is not fixed (see "Fixed" column), you will have to resolve the node's name (first column) each time the IP changes. Some nodes may have their ip change once a day, some others once a month, and some others may stay on the same IP for years. Still, as long as the IP is not fixed, there is no guarantee it will stay the same.<br />
<br />
In order to enable hostname lookups for the ''-addnode'' and ''-connect'' parameters, you must additionally provide the ''-dns'' parameter. Example:<br />
bitcoind -dns -addnode=bitcoin.es<br />
<br />
Versions prior to 0.3.22 do not support hostnames to the ''-addnode'' parameter, so you must do the resolving part for it. For example on linux:<br />
bitcoind -addnode=$(dig +short bitcoin.es)<br />
<br />
=== IP Transactions ===<br />
<br />
You can also send [[IP Transactions]] to these nodes. If you include your bitcoin address in the "message" field, you may have your coins back.<br />
<br />
=== Tor network ===<br />
<br />
To use tor .onion addresses ([[Fallback_Nodes#Tor_nodes|listed below]]), you will need to map virtual ips via the ''torrc'' file:<br />
<br />
mapaddress 192.0.2.2 ijzt2eeizty3p5xe.onion<br />
mapaddress 192.0.2.3 j43z65b6r2usg3vk.onion<br />
mapaddress 192.0.2.4 pvuif6nonbhj3o3r.onion<br />
<br />
And then put these IPs in your bitcoin.conf (or run bitcoin with -connect)<br />
<br />
connect=192.0.2.2<br />
connect=192.0.2.3<br />
connect=192.0.2.4<br />
<br />
You can use any arbitrary IP addresses with MapAddress, though some of the common non-routable ranges (10.*, 192.168.*) will not work due to a Bitcoin bug (reference?). 192.0.2.1-192.0.2.255 is the recommended range because it is both non-routable and compatible with Bitcoin.<br />
<br />
It is highly recommended that you use "connect" instead of "addnode" so that all of your communications are kept within the tor network.<br />
<br />
<span style="color:red">Since Bitcoin 0.5, the client enables nolisten when the proxy setting is enabled, which in effect prevents the client from becoming a peer node. So the only way to operate a hidden bitcoin seed node would be to revert to an earlier version, or see phantomcircuit's [https://github.com/phantomcircuit/bitcoin-alt bitcoin-alt].</span><br />
<br />
== Nodes list ==<br />
<br />
=== IPv4 Nodes ===<br />
<br />
{|class="wikitable sortable"<br />
! Hostname !! Owner !! IP !! Fixed !! Status !! Last Seen (GMT) !! Accepts IP transactions<br />
|-<br />
<!-- BEGIN NODELIST --><br />
| 66.158.72.2 || imsaguy || 66.158.72.2 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || ?<br />
<!-- END NODELIST --><br />
|}<br />
<br />
=== Tor nodes ===<br />
<br />
{|class="wikitable sortable"<br />
! Hostname !! Owner !! Status !! Last Seen (GMT) !! Accepts IP transactions<br />
|-<br />
| bitcoin2bkgm3fke.onion || ? || up || 2012-01-16 || Yes<br />
|-<br />
| ijzt2eeizty3p5xe.onion || ? || ? || 2011-02-11 || Yes<br />
|-<br />
| j43z65b6r2usg3vk.onion || Dybbuk || ? || 2011-02-11 || Yes<br />
|-<br />
| pvuif6nonbhj3o3r.onion || ? || ? || 2011-02-11 || Yes<br />
|-<br />
| c5qvugpewwyyy5oz.onion || ? || ? || 2011-02-11 || Yes<br />
|-<br />
| vso3r6cmjoomhhgg.onion || echelon || ? || 2011-02-11 || Yes<br />
|-<br />
| sjdntqu5roj4q6lo.onion || torservers || up || 2012-04-04 || ?<br />
|-<br />
| bitcoinbudtoeks7.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| iy6ni3wkqazp4ytu.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| h4kklwodpcmo6cbq.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| vv6kcfscuntybrzm.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| nlnsivjku4x4lu5n.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| xqzfakpeuvrobvpj.onion || ? || ? || 2010-11-13 || No<br />
|-<br />
| 4lmduyac3svgrrav.onion || ? || ? || 2011-02-11 || No<br />
|-<br />
| usasx4urod3yj4az.onion || ? || ? || 2011-02-11 || No<br />
|-<br />
| sh4ep6zb6vnoa2h5.onion || Gmaxwell || ? || 2011-10-29 || No<br />
|-<br />
| e3tn727fywnioxrc.onion || ? || ? || 2011-11-01 || No<br />
|-<br />
| p2hwc26zdsrqxiix.onion || redemerald || up || 2012-04-04 || No<br />
|-<br />
| bxfna6fhddpzduck.onion || ? || ? || ? || ?<br />
|-<br />
| esvua6k2gzjj64ad.onion || redemerald || ? || 2011-12-28 || No<br />
|-<br />
| 7hxvg2lvr2ashzli.onion || Tuxavant || up || 2012-04-04 || ?<br />
|-<br />
| siqdznszjf4e6v5j.onion || Tuxavant || up || 2012-04-04 || ?<br />
|-<br />
| fpt6orohw2nuf2kn.onion || Tril || up || 2012-04-04 || No<br />
|}<br />
<br />
== Adding a node ==<br />
<br />
Before adding yourself as a fallback node, you should be sure your node will stay online for a long time. If a node is offline for more than 24 hours it will be removed from the list. To accept IP transactions you will have to add the ''-allowreceivebyip'' flag to your command line parameters.<br />
<br />
To add a node in this list, you just need the ip/hostname and your name, the other fields will be filled automatically. Insert the following lines before the <tt>END NODELIST</tt> line:<br />
<br />
<nowiki>|-<br />
| ip || your name</nowiki><br />
<br />
Please note that a bot is supposed to connect to your node every hour to check its status and version. Sadly, this bot appears to be offline.</div>Trilhttps://tests.bitcoin.it/w/index.php?title=Pycoin&diff=24097Pycoin2012-02-19T18:46:40Z<p>Tril: fix forum link</p>
<hr />
<div>A Bitcoin [[:Category:Clients|client]] built using Python 3 and implements the Bitcoin network protocol.<br />
<br />
The project was announce on March 3rd, 2011<ref>[https://bitcointalk.org/index.php?topic=4084.0 Announcing Pycoin, a (partial) bitcoin protocol implementation in python3]</ref><br />
<br />
==See Also==<br />
* [[Original Bitcoin client]]<br />
* [[Protocol specification|Bitcoin Network Protocol]]<br />
<br />
==External Links==<br />
<br />
* [http://gitorious.org/pycoin pycoin] project page on Gitorious<br />
<br />
==References==<br />
<references/><br />
<br />
[[Category:Nodes]]<br />
[[Category:Wallets]]<br />
[[Category:Open Source]]<br />
[[Category:Clients]]</div>Trilhttps://tests.bitcoin.it/w/index.php?title=BIP_0001&diff=20633BIP 00012011-12-09T18:00:25Z<p>Tril: fix typo: "validity"</p>
<hr />
<div><pre><br />
BIP: 1<br />
Title: BIP Purpose and Guidelines<br />
Author: Amir Taaki <genjix@riseup.net><br />
Status: Active<br />
Type: Standards Track<br />
Created: 19-08-2011<br />
</pre><br />
<br />
==What is a BIP?==<br />
<br />
BIP stands for Bitcoin Improvement Proposal. A BIP is a design document providing information to the Bitcoin community, or describing a new feature for Bitcoin or its processes or environment. The BIP should provide a concise technical specification of the feature and a rationale for the feature.<br />
<br />
We intend BIPs to be the primary mechanisms for proposing new features, for collecting community input on an issue, and for documenting the design decisions that have gone into Bitcoin. The BIP author is responsible for building consensus within the community and documenting dissenting opinions.<br />
<br />
Because the BIPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal<br />
.<br />
==BIP Types==<br />
<br />
There are three kinds of BIP:<br />
<br />
* A Standards Track BIP describes any change that affects most or all Bitcoin implementations, such as a change to the network protocol, a change in block or transaction validity rules, or any change or addition that affects the interoperability of applications using Bitcoin.<br />
* An Informational BIP describes a Bitcoin design issue, or provides general guidelines or information to the Bitcoin community, but does not propose a new feature. Informational BIPs do not necessarily represent a Bitcoin community consensus or recommendation, so users and implementors are free to ignore Informational BIPs or follow their advice.<br />
* A Process BIP describes a process surrounding Bitcoin, or proposes a change to (or an event in) a process. Process BIPs are like Standards Track BIPs but apply to areas other than the Bitcoin protocol itself. They may propose an implementation, but not to Bitcoin's codebase; they often require community consensus; unlike Informational BIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Bitcoin development. Any meta-BIP is also considered a Process BIP.<br />
<br />
==BIP Work Flow==<br />
<br />
The BIP editors assign BIP numbers and change their status. Please send all BIP-related email to <BIPs@Bitcoin.org> (no cross-posting please). Also see BIP Editor Responsibilities & Workflow below.<br />
<br />
The BIP process begins with a new idea for Bitcoin. It is highly recommended that a single BIP contain a single key proposal or new idea. Small enhancements or patches often don't need a BIP and can be injected into the Bitcoin development work flow with a patch submission to the Bitcoin issue tracker. The more focussed the BIP, the more successful it tends to be. The BIP editor reserves the right to reject BIP proposals if they appear too unfocussed or too broad. If in doubt, split your BIP into several well-focussed ones.<br />
<br />
Each BIP must have a champion -- someone who writes the BIP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The BIP champion (a.k.a. Author) should first attempt to ascertain whether the idea is BIP-able. Posting to the [https://bitcointalk.org/index.php?board=6.0 Development&Technical Discussion] forum or the [http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development bitcoin-development@lists.sourceforge.net] mailing list is the best way to go about this.<br />
<br />
Vetting an idea publicly before going as far as writing a BIP is meant to save the potential author time. Many ideas have been brought forward for changing Bitcoin that have been rejected for various reasons. Asking the Bitcoin community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Bitcoin is used.<br />
<br />
Once the champion has asked the Bitcoin community as to whether an idea has any chance of acceptance, a draft BIP should be presented to [http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development bitcoin-development@lists.sourceforge.net]. This gives the author a chance to flesh out the draft BIP to make properly formatted, of high quality, and to address initial concerns about the proposal.<br />
<br />
Following a discussion, the proposal should be sent to the Bitcoin-dev list with the draft BIP and the BIP editors <BIPs@Bitcoin.org>. This draft must be written in BIP style as described below, else it will be sent back without further regard until proper formatting rules are followed.<br />
<br />
If the BIP editor approves, he will assign the BIP a number, label it as Standards Track, Informational, or Process, give it status "Draft", and create and create a page for it on the [[Bitcoin_Improvement_Proposals|Bitcoin Wiki]]. The BIP editor will not unreasonably deny a BIP. Reasons for denying BIP status include duplication of effort, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the Bitcoin philosophy.<br />
<br />
The BIP author may update the Draft as necessary on the wiki.<br />
<br />
Standards Track BIPs consist of two parts, a design document and a reference implementation. The BIP should be reviewed and accepted before a reference implementation is begun, unless a reference implementation will aid people in studying the BIP. Standards Track BIPs must include an implementation -- in the form of code, a patch, or a URL to same -- before it can be considered Final.<br />
<br />
BIP authors are responsible for collecting community feedback on a BIP before submitting it for review. However, wherever possible, long open-ended discussions on public mailing lists should be avoided. Strategies to keep the discussions efficient include: setting up a separate SIG mailing list for the topic, having the BIP author accept private comments in the early design phases, setting up a wiki page, etc. BIP authors should use their discretion here.<br />
<br />
For a BIP to be accepted it must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly.<br />
<br />
Once a BIP has been accepted, the reference implementation must be completed. When the reference implementation is complete and accepted by the community, the status will be changed to "Final".<br />
<br />
A BIP can also be assigned status "Deferred". The BIP author or editor can assign the BIP this status when no progress is being made on the BIP. Once a BIP is deferred, the BIP editor can re-assign it to draft status.<br />
<br />
A BIP can also be "Rejected". Perhaps after all is said and done it was not a good idea. It is still important to have a record of this fact.<br />
<br />
BIPs can also be superseded by a different BIP, rendering the original obsolete. This is intended for Informational BIPs, where version 2 of an API can replace version 1.<br />
<br />
The possible paths of the status of BIPs are as follows:<br />
<br />
[[File:BIP-0001-Process.png]]<br />
<br />
Some Informational and Process BIPs may also have a status of "Active" if they are never meant to be completed. E.g. BIP 1 (this BIP).<br />
<br />
==What belongs in a successful BIP?==<br />
<br />
Each BIP should have the following parts:<br />
<br />
* Preamble -- RFC 822 style headers containing meta-data about the BIP, including the BIP number, a short descriptive title (limited to a maximum of 44 characters), the names, and optionally the contact info for each author, etc.<br />
<br />
* Abstract -- a short (~200 word) description of the technical issue being addressed.<br />
<br />
* Copyright/public domain -- Each BIP must either be explicitly labelled as placed in the public domain (see this BIP as an example) or licensed under the Open Publication License [7].<br />
<br />
* Specification -- The technical specification should describe the syntax and semantics of any new language feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Bitcoin platforms (Satoshi, BitcoinJ, bitcoin-js, libbitcoin).<br />
<br />
* Motivation -- The motivation is critical for BIPs that want to change the Bitcoin protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the BIP solves. BIP submissions without sufficient motivation may be rejected outright.<br />
<br />
* Rationale -- The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages.<br />
<br />
* The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion.<br />
<br />
* Backwards Compatibility -- All BIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The BIP must explain how the author proposes to deal with these incompatibilities. BIP submissions without a sufficient backwards compatibility treatise may be rejected outright.<br />
<br />
* Reference Implementation -- The reference implementation must be completed before any BIP is given status "Final", but it need not be completed before the BIP is accepted. It is better to finish the specification and rationale first and reach consensus on it before writing code.<br />
<br />
* The final implementation must include test code and documentation appropriate for the Bitcoin protocol.<br />
<br />
==BIP Formats and Templates==<br />
<br />
BIPs should be written in mediawiki wiki syntax. Image files should be included in the current subdirectory for that BIP.<br />
<br />
==BIP Header Preamble==<br />
<br />
Each BIP must begin with an RFC 822 style header preamble. The headers must appear in the following order. Headers marked with "*" are optional and are described below. All other headers are required.<br />
<br />
<pre><br />
BIP: <BIP number><br />
Title: <BIP title><br />
Author: <list of authors' real names and optionally, email addrs><br />
* Discussions-To: <email address><br />
Status: <Draft | Active | Accepted | Deferred | Rejected |<br />
Withdrawn | Final | Superseded><br />
Type: <Standards Track | Informational | Process><br />
Created: <date created on, in dd-mm-yyyy format><br />
* Post-History: <dates of postings to bitcoin mailing list><br />
* Replaces: <BIP number><br />
* Superseded-By: <BIP number><br />
* Resolution: <url><br />
</pre><br />
<br />
The Author header lists the names, and optionally the email addresses of all the authors/owners of the BIP. The format of the Author header value must be<br />
<br />
Random J. User <address@dom.ain><br />
<br />
if the email address is included, and just<br />
<br />
Random J. User<br />
<br />
if the address is not given.<br />
<br />
If there are multiple authors, each should be on a separate line following RFC 2822 continuation line conventions.<br />
<br />
Note: The Resolution header is required for Standards Track BIPs only. It contains a URL that should point to an email message or other web resource where the pronouncement about the BIP is made.<br />
<br />
While a BIP is in private discussions (usually during the initial Draft phase), a Discussions-To header will indicate the mailing list or URL where the BIP is being discussed. No Discussions-To header is necessary if the BIP is being discussed privately with the author, or on the bitcoin email mailing lists.<br />
<br />
The Type header specifies the type of BIP: Standards Track, Informational, or Process.<br />
<br />
The Created header records the date that the BIP was assigned a number, while Post-History is used to record the dates of when new versions of the BIP are posted to bitcoin mailing lists. Both headers should be in dd-mmm-yyyy format, e.g. 14-Aug-2001.<br />
<br />
BIPs may have a Requires header, indicating the BIP numbers that this BIP depends on.<br />
<br />
BIPs may also have a Superseded-By header indicating that a BIP has been rendered obsolete by a later document; the value is the number of the BIP that replaces the current document. The newer BIP must have a Replaces header containing the number of the BIP that it rendered obsolete.<br />
Auxiliary Files<br />
<br />
BIPs may include auxiliary files such as diagrams. Such files must be named BIP-XXXX-Y.ext, where "XXXX" is the BIP number, "Y" is a serial number (starting at 1), and "ext" is replaced by the actual file extension (e.g. "png").<br />
<br />
==Transferring BIP Ownership==<br />
<br />
It occasionally becomes necessary to transfer ownership of BIPs to a new champion. In general, we'd like to retain the original author as a co-author of the transferred BIP, but that's really up to the original author. A good reason to transfer ownership is because the original author no longer has the time or interest in updating it or following through with the BIP process, or has fallen off the face of the 'net (i.e. is unreachable or not responding to email). A bad reason to transfer ownership is because you don't agree with the direction of the BIP. We try to build consensus around a BIP, but if that's not possible, you can always submit a competing BIP.<br />
<br />
If you are interested in assuming ownership of a BIP, send a message asking to take over, addressed to both the original author and the BIP editor <BIPs@bitcoin.org>. If the original author doesn't respond to email in a timely manner, the BIP editor will make a unilateral decision (it's not like such decisions can't be reversed :).<br />
BIP Editor Responsibilities & Workflow<br />
<br />
A BIP editor must subscribe to the <BIPs@bitcoin.org> list. All BIP-related correspondence should be sent (or CC'd) to <BIPs@bitcoin.org> (but please do not cross-post!).<br />
<br />
For each new BIP that comes in an editor does the following:<br />
<br />
* Read the BIP to check if it is ready: sound and complete. The ideas must make technical sense, even if they don't seem likely to be accepted.<br />
* The title should accurately describe the content.<br />
* Edit the BIP for language (spelling, grammar, sentence structure, etc.), markup (for reST BIPs), code style (examples should match BIP 8 & 7).<br />
<br />
If the BIP isn't ready, the editor will send it back to the author for revision, with specific instructions.<br />
<br />
Once the BIP is ready for the repository, the BIP editor will:<br />
<br />
* Assign a BIP number (almost always just the next available number, but sometimes it's a special/joke number, like 666 or 3141).<br />
<br />
* List the BIP in BIP 0 (in two places: the categorized list, and the numeric list).<br />
<br />
* Add the BIP to the wiki.<br />
<br />
* Send email back to the BIP author with next steps (post to bitcoin mailing list).<br />
<br />
Many BIPs are written and maintained by developers with write access to the Bitcoin codebase. The BIP editors monitor BIP changes, and correct any structure, grammar, spelling, or markup mistakes we see.<br />
<br />
The editors don't pass judgement on BIPs. We merely do the administrative & editorial part. Except for times like this, there's relatively low volume.<br />
<br />
==History==<br />
<br />
This document was derived heavily from Python's PEP-0001. In many places text was simply copied and modified. Although the PEP-0001 text was written by Barry Warsaw, Jeremy Hylton, and David Goodger, they are not responsible for its use in the Bitcoin Improvement Process, and should not be bothered with technical questions specific to Bitcoin or the BIP process. Please direct all comments to the Bitcoin editors or the forums at bitcointalk.org.</div>Trilhttps://tests.bitcoin.it/w/index.php?title=BT_Feature&diff=20542BT Feature2011-12-07T17:41:22Z<p>Tril: fix forum link</p>
<hr />
<div>A feature request / bounty and donation pool service.<br />
<br />
The site was announced on March 22, 2011<ref>[https://www.bitcointalk.org/index.php?topic=4761.0 New bitcoin features]</ref>. Around June, 2011 the site now longer shows individual bounties and instead directs to the [[Bitcoin Consultancy]] service.<br />
<br />
==External Links==<br />
<br />
* [http://bitcoin.cz.cc BT Feature] web site<br />
* [http://gitorious.org/btfeature btfeature] project on Gitorious<br />
<br />
==References==<br />
<references /><br />
<br />
[[Category:Open Source]]</div>Trilhttps://tests.bitcoin.it/w/index.php?title=Bitcoin2Cash&diff=13858Bitcoin2Cash2011-07-30T07:41:41Z<p>Tril: update forum link</p>
<hr />
<div>A market exchange where bitcoins can be bought and sold. Funds may be deposited by mailing in cash. Funds may be withdrawn as cash mailed to you.<br />
<br />
Bitcoin2cash, LLC is an entity registered in the State of Alabama<ref>[http://arc-sos.state.al.us/cgi/corpdetail.mbr/detail?corp=300237 Bitcoin2cash, LLC Business Entity Details]</ref>.<br />
<br />
The site matches bids and asks periodically (every 5 minutes).<br />
<br />
==History==<br />
<br />
The site was originally announced on July 13th, 2010<ref>[http://www.bitcoin.org/smf/index.php?topic=30.msg2452#msg2452 http://bitcoin2cash.com]</ref>. The site was subsequently redesigned and the new availability was announced on April 2nd, 2011<ref>[http://forum.bitcoin.org/index.php?topic=5307.0 Bitcoin2Cash.com - Cash-Only Marketplace]</ref>.<br />
<br />
==See Also==<br />
<br />
* [[Selling bitcoins]]<br />
* [[Buying bitcoins]]<br />
<br />
==External Links==<br />
<br />
* [http://www.bitcoin2cash.com Bitcoin2Cash] website<br />
<br />
==References==<br />
<references /><br />
<br />
[[Category:Exchanges]]<br />
[[Category:EWallets]]</div>Trilhttps://tests.bitcoin.it/w/index.php?title=Deflationary_spiral&diff=8624Deflationary spiral2011-05-20T17:39:31Z<p>Tril: A lack of currency available in the market causes the price of goods to further *decrease* (not increase)</p>
<hr />
<div>'''Deflationary spiral''' is an economic argument that proposes that runaway deflation can eventually lead to the collapse of the currency given certain conditions and constraints. It is a common criticism made against the viability of [[Bitcoin]].<br />
The ‘deflationary spiral’ is a real condition that affects the fiat fractional reserve backing system. Bitcoin is not affected by this because it is fundamentally different from fiat currency.<br /> See below for a dissenting argument on this topic. <br />
<br />
Deflation is a decline in the general price level. Deflation occurs when the price of goods and services, relative to a specific measure, decline. It is not necessarily that the value of the goods and services themselves declined, but can be because the value of the currency itself increased. <br />
<br />
For example, let us consider an economy comprised entirely of beef and oranges where the medium of exchange is gold. Both beef and oranges can decay and are not consistent, and therefore cannot be used as a currency. In order to trade, people exchange gold for either beef or oranges. They see gold as a store of value that they can use to purchase beef or oranges in the future. What happens when the economy grows and we can produce more beef and more oranges? The price of both beef and oranges will decline. To the extent our productive capacity for both beef and oranges increased at the same pace, the exchange value between the two (the amount of beef for a given number of oranges) will likely stay the same; however, those who held gold as a store of value would now be able to purchase more beef and more oranges for a given amount of gold. <br />
<br />
A deflationary spiral occurs when the value of a currency, relative to the goods in an economy, increases continually as a result of hoarding. As the value of the currency relative to the goods in the economy increase, people have the incentive to hoard the currency, because by merely holding it, they hope to be able to purchase more goods for less money in the future. A lack of currency available in the market causes the price of goods to further decrease, resulting in more hoarding. <br />
<br />
In our economy of beef and oranges it is easy to see how this could occur. First, people see a significant gain in productivity on the horizon; we will be able to produce more beef and oranges for the same effort in the future. The supply of gold, however, is fixed. As a result, people desire to hold gold, because they will be able to purchase more beef and oranges with their gold in the future than they can now. This will lead to a decline in the price of beef and oranges as measured by gold (an increase in the value of gold). Limiting the amount of currency in the market available for exchange can also make transactions more difficult. In a complex system where we do not only have beef, oranges and gold, this can result in a deflationary spiral where no one wishes to spend their currency and the economy itself slows as a result of the limited number of transactions. Limited demand with fixed output results in a decline in prices, which further exacerbates the problem. <br />
<br />
Alternative explanation:<br />
A deflationary spiral occurs when the price of a traded article increases at some given rate, which causes people to hoard it. As people hoard the commodity, less and less of it is available thus causing the price to go up even more. In turn, even more people hoard the commodity. Thus a feedback loop or spiral of deflation occurs.<br /><br />
<br />
In practice, there is only a limited amount of 'value' that can be placed upon a good before it becomes too attractive to trade for other goods (thus ending the spiral). The only time that the 'Deflationary Spiral' can happen (to it's conclusion) is when people can foresee a time where they are forced to use that particular traded article. See below for a dissenting argument on this topic. <br />
<br />
==In The Fiat Fractional Reserve Banking System==<br />
The fiat money that we trade consists of the principal of the loans of other people. All this money must be someday 'repaid.' When people save (pay back their loans), the total monetary supply contracts. When people spend (take out loans), the total monetary supply is increasing.<br />
<br />
If you have people who are hoarding money, the principal still needs to be repaid. Hoarding will make it harder for other people in the economy to pay back their loans.<br />
<br />
Because people foresee a time where they need to pay back their loans (a future fixed expense), when the value of the money starts to increase (deflation), those with loans will endeavour to pay back the loans quicker. This causes the monetary supply to reduce, reducing the total amount of money available for repayment of loans, again making it harder for people to pay back what they owe.<br />
<br />
This Deflationary spiral diverts funds away from the legitimate economy, to the repayment of debt. Causing the economy to stagnates and stop.<br />
<br />
==Bitcoin==<br />
The key difference is that people don't foresee a fixed cost (unit amount) that they must pay with Bitcoin. If the value of the Bitcoins that they own increases, then any future cost will take a proportionally smaller amount of Bitcoins. There isn't any fixed incentive to holding Bitcoin other than speculation.<br />
<br />
If the economy that uses Bitcoin grows, the per-unit value of Bitcoin proportionally increases also.<br />
<br />
Everything is the opposite to the fiat fractional reserve banking system (because Bitcoin isn't a debt but an asset). Bitcoins '''only''' deflate in value when the Bitcoin Economy is '''growing'''.<br />
<br />
Because the Deflationary spiral is a real problem in the traditional monetary system, doesn't necessarily mean that it will also be a problem in the Bitcoin economy.<br />
<br />
==Alternative Viewpoint==<br />
A deflationary spiral occurs when there is an incentive to hoard because of declining prices, which results in even less available currency on the market, further perpetuating declining prices. <br />
<br />
How could this occur in the Bitcoin market? First, we see massive deflation occurring in the market right now, as the value of a Bitcoin relative to other currencies, and as a result goods and services as well, increases. To the extent there is value in a Bitcoin because there will be a limited number of them in the future and they are one of the few untraceable mediums of exchange that cannot be subjected to expropriation (at the moment), it is easy to see why their value is currently increasing. Already, however, this is creating the incentive for hoarding. Given there is a known limit on the future amount of Bitcoins in existence, the market expects that the "price" of Bitcoins as measured in other currencies will increase.<br />
<br />
While this will not necessarily lead to a deflationary spiral, it will likely cause serious problems for Bitcoin which could ultimately trigger Bitcoin's demise, as outlined below. <br />
<br />
1. Currently, with knowledge that there will be a limited number of Bitcoins in the future, the price of Bitcoins is increasingly rapidly. The result is limited price stability. Limited price stability has a negative impact on the acceptance of a currency. Vendors do not wish to speculate on the price of currency when selling goods or services.<br />
<br />
2. Once prices do stabilize in the future, there will always be the knowledge that the number of Bitcoins in the market is limited. As a result, to the extent the GDP of the Bitcoin economy increases (the total value of all Bitcoin transactions completed increases in "real" terms), there will continue to be price deflation. Price deflation rewards the holders of the existing currency and provides an incentive to hoard the currency. The value held by the existing holders of the currency, and the resulting reward that they receive for future deflation, can be eliminated by a competing system. As a result, to the extent there is an expectation for inflation because demand for the currency itself is greater than the supply of Bitcoins, a competing system will emerge. <br />
<br />
Fundamentally, the growth of Bitcoin will be limited because of the knowledge that there is a limited supply of coins. The fact that there is a limited supply of coins means that there is an expectation of deflation if the economy grows. The "cost" of that deflation, borne by new users, can be avoided if an alternative system is used. <br />
<br />
While this is not a traditional deflationary spiral, the constraint on the actual money supply can produce the same result, which is a limit on the value of goods and services transacted using Bitcoins.<br />
<br />
What can be done to deal with this issue?<br />
<br />
There is a simple solution to this problem. For Bitcoins to avoid being supplanted by an alternative electronic currency in the future, the supply of Bitcoins must grow in proportion to the total value of transactions undertaken using the system. This will lead to price stability and will eliminate the benefit that accrues to existing holders of the currency. This is fundamentally necessary to protect the existing value of Bitcoins. If this does not occur then an alternative system that does recognize the risk of deflation and price instability will present itself which will achieve a greater level of acceptance, destroying Bitcoin in the process. <br />
<br />
==See Also==<br />
<br />
* [[Controlled inflation]]<br />
<br />
[[Category:Economics]]</div>Trilhttps://tests.bitcoin.it/w/index.php?title=Myths&diff=8565Myths2011-05-19T15:40:34Z<p>Tril: update link for new forum</p>
<hr />
<div>Lets clear up common Bitcoin misconceptions.<br />
<br />
== Bitcoin is just like all the other virtual currencies, nothing new ==<br />
<br />
All other virtual currencies are centrally controlled. This means that:<br />
* they can be printed at the subjective whims of the controllers<br />
* they can be destroyed by attacking the central point of control<br />
* arbitrary rules can be imposed upon their users by the controllers<br />
<br />
Being decentralized, bitcoin solves all of these problems.<br />
<br />
== Bitcoins don't solve any problems that fiat and/or gold doesn't solve ==<br />
<br />
Unlike gold, bitcoins are:<br />
* easy to transfer and store<br />
* easy to verify authenticity<br />
<br />
Unlike fiat currencies, bitcoins are:<br />
* predictable, and decreasing, as far as the rate of monetary inflation<br />
* not controlled by a central authority<br />
<br />
Unlike electronic fiat currency systems, bitcoins are:<br />
* potentially anonymous<br />
* assets cannot be frozen<br />
<br />
== Bitcoin is backed by CPU cycles ==<br />
<br />
It is not correct to say that Bitcoin is backed by CPU power. A currency being "backed" by something means that it is pegged to something else via a central party at a certain exchange rate. You cannot exchange bitcoins for the computing power that was used to create them. Bitcoin is in this sense not backed by anything. It is a commodity in its own right. Similar to gold - is gold backed by anything? No! It's just gold. Same thing with bitcoin. <br />
<br />
The Bitcoin currency is ''created'' via processing power, and the integrity of the block chain is ''protected'' by the existence of a large network of computing nodes from certain possible [[Weaknesses#Attacker_has_a_lot_of_computing_power|attacks]]. And that is all.<br />
<br />
== Bitcoins are worthless because they aren't backed by anything ==<br />
<br />
Gold isn't backed by anything either. Bitcoins have properties inherent to its design that are subjectively valued by individuals. This valuation is demonstrated when individuals freely exchange for or with Bitcoins. Please refer to the [http://en.wikipedia.org/wiki/Subjective_theory_of_value Subjective Theory of Value]. See also myth [https://en.bitcoin.it/wiki/Myths#Bitcoin_is_backed_by_CPU_cycles Bitcoin is backed by CPU cycles].<br />
<br />
== Bitcoins value is based on how much electricity and computing power it takes to mine them ==<br />
<br />
This statement is an attempt to apply to bitcoin the [http://en.wikipedia.org/wiki/Labor_theory_of_value labor theory of value], which is generally accepted as false. Just because something takes X resources to create does not mean that the resulting product will be worth X. It can be worth more, or less, depending on the utility thereof to its users. <br />
<br />
In fact the causality is the reverse of that (this applies to the labor theory of value in general). The cost to mine bitcoins is based on how much they are worth. If bitcoins go up in value, more people will mine (because mining is profitable), thus [difficulty] will go up, thus the cost of mining will go up. The inverse happens if bitcoins go down in value. These effects balance out to cause mining to always cost the amount of bitcoins it produces.<br />
<br />
== Bitcoins have no intrinsic value (unlike some other things) ==<br />
<br />
It is true that bitcoins have no intrinsic value, in the [http://en.wikipedia.org/wiki/Intrinsic_value_%28numismatics%29 numismatic sense], in other words, value in any realm outside of being used as a medium of exchange.<br />
<br />
However, while some tangible commodities do have intrinsic value, that value is generally much less than its trading price. Consider for example that gold, if it were not used as an inflation-proof store of value, but rather only for its industrial uses, would certainly not be worth what it is today, since the industrial requirements for gold are far smaller than the available supply thereof.<br />
<br />
While historically intrinsic value, as well as other attributes like divisibility, fungibility, scarcity, durability, helped establish certain commodities as mediums of exchange, it is certainly not a prerequisite. While bitcoins lack 'intrinsic value' in this sense, they make up for it in spades by possessing the other qualities necessary to make it a good medium of exchange, equal to or better than [http://en.wikipedia.org/wiki/Commodity_money commodity money].<br />
<br />
Value is ultimately determined by what people are willing to trade for - by supply and demand.<br />
<br />
== Bitcoins are illegal because it's not legal tender ==<br />
<br />
Short answer: chickens aren't legal tender either, but bartering with chickens is not illegal.<br />
<br />
There are a [http://en.wikipedia.org/wiki/Local_currency number of currencies] in existence that are not official government-backed currencies. A currency is, after all, nothing more than a convenient unit of account. While national laws may vary from country to country, and you should certainly check the laws of your jurisdiction, in general trading in any commodity, including digital commodities like bitcoin, game currencies like WoW gold or Linden dollars, is not illegal.<br />
<br />
== Bitcoin is a form of domestic terrorism because it only harms the economic stability of the USA and its currency ==<br />
<br />
http://en.wikipedia.org/wiki/Definitions_of_terrorism#United_States according to this, you need to do violent activities to be considered a terrorist for legal purposes. This has no bearing on politicians and idiotic US attorney's public remarks.<br />
<br />
Also bitcoin isn't domestic. It's a worldwide community. See this map of bitcoin nodes <br />
http://forum.bitcoin.org/?topic=2346.0<br />
<br />
== Bitcoin will only enable tax evaders which will lead to the eventual downfall of civilization ==<br />
<br />
It's up to you to follow the applicable state laws in your home country, or face the consequences.<br />
<br />
== Bitcoins can be printed/minted by anyone and are therefore worthless ==<br />
<br />
Bitcoins are not printed/minted. Instead, [[Blocks]] are computed by miners and for their efforts they are awarded a specific amount of bitcoins + transaction fees. See [[Blocks]] for more information on how this process works.<br />
<br />
== Bitcoins are worthless because it's based on unproven cryptography ==<br />
<br />
SHA256 and ECDSA which are used in Bitcoin are well-known industry standard algorithms.<br />
<br />
== Early adopters are unfairly rewarded ==<br />
<br />
Early adopters are rewarded for taking the higher risk with their time and money. <br />
<br />
In more pragmatic terms, "fairness" is an arbitrary concept that is improbable to be agreed upon by a large population. Establishing "fairness" is no goal of Bitcoin, as this would be impossible.<br />
<br />
The vast majority of the 21 million Bitcoins still have not been distributed. By starting to mine or acquire Bitcoins today, you too can become an early adopter.<br />
<br />
== 21 million coins isn't enough, doesn't scale ==<br />
<br />
There are really 2,099,999,997,690,000 (just over 2 quadrillion) maximum possible atomic units in the bitcoin design.<br />
<br />
The value of "1 BTC" represents 100,000,000 of these. In other words, each is divisible by up to 10^8. <br />
<br />
As the value of the unit of 1 BTC grows too large to be useful for day to day transactions, people can start dealing in smaller [[Units|units]], such as milli-bitcoins (mBTC) or micro-bitcoins (μBTC).<br />
<br />
== Bitcoins are stored in wallet files, just copy the wallet file to get more coins! ==<br />
<br />
No, your wallet contains your secret keys, giving you the rights to spend your bitcoins. Think of it like having bank details stored in a file. If you give your bank details (or bitcoin wallet) to someone else, that doesn't double the amount of money in your account. You can spend your money or they can spend your money, but not both.<br />
<br />
== Lost coins can't be replaced and this is bad ==<br />
<br />
Bitcoins are divisible to 0.00000001, so this is not a problem. If you lose your coins, all other coins will go up in value a little. Consider it a donation to all other bitcoin users.<br />
<br />
A related question is: Why don't we have a mechanism to replace lost coins? The answer is that it is impossible to distinguish between a 'lost' coin and one that is simply sitting unused in someone's safe.<br />
<br />
== It's a giant ponzi scheme ==<br />
In a Ponzi Scheme, the founders persuade investors that they’ll profit. Bitcoin does not make such a guarantee. There is no central entity, just individuals building an economy.<br />
<br />
A ponzi scheme is a zero sum game. Early adopters can only profit at the expense of late adopters. Bitcoin has possible win-win outcomes. Early adopters profit from the rise in value. Late adopters profit from the usefulness of a stable and widely accepted p2p currency. <br />
<br />
Not to be confused with the [[Bitcoin randomizer|Bitcoin Randomizer]] which is a game that really is self-described as a Ponzi scheme.<br />
<br />
== Finite coins plus lost coins means deflationary spiral ==<br />
As deflationary forces may apply, economic factors such as hoarding are offset by human factors that may lessen the chances that a [[Deflationary spiral]] will occur.<br />
<br />
== Bitcoin can't work because there is no way to control inflation ==<br />
<br />
Inflation is simply a rise of prices over time, which is generally the result of the devaluing of a currency. This is a function of supply and demand. Given the fact that the supply of Bitcoins is fixed at a certain amount, unlike fiat money, the only way for inflation to get out of control is for demand to disappear.<br />
<br />
Given the fact that Bitcoin is a distributed system of currency, if demand were to decrease to almost nothing, the currency would be doomed anyway.<br />
<br />
The key point here is that Bitcoin as a currency can't be inflated by any single person or entity, like a government, as there's no way to increase supply past a certain amount.<br />
<br />
Indeed, the most likely scenario, as Bitcoin becomes more popular and demand increases, is for the currency to increase in value, or deflate, until demand stabilizes.<br />
<br />
== Bitcoin community are anarchist/conspiracy theorist/gold standard weenies ==<br />
<br />
CONFIRMED<br />
<br />
== Anyone with enough computing power can take over the network ==<br />
<br />
CONFIRMED, see [[Weaknesses]].<br />
<br />
That said, as the network grows, it becomes harder and harder for a single entity to do so. Already the bitcoin network's computing power is on par with some of the world's fastest supercomputers.<br />
<br />
What an attacker can do once the network is taken over is quite limited. Under no circumstances could an attacker take anybody else's money. An attacker's capabilities are limited to taking back their own money that they very recently spent, and preventing other people's transactions from receiving confirmations. Such an attack would be very costly in resources, and for such meager benefits there is little rational economic incentive to do such a thing.<br />
<br />
== Bitcoin violates some sort of government regulations ==<br />
<br />
Name them if you can.<br />
<br />
See also the [[Myths#Bitcoins_are_illegal_because_it_s_not_legal_tender|legal tender]] question.<br />
<br />
== Fractional reserve banking is not possible ==<br />
<br />
Yes, it is ''possible''. <br />
<br />
1. Start Bitcoin Bank.<br />
<br />
2. Accept deposits from customers<br />
<br />
3. Make loans, using part of the funds deposited by customers, keeping a '''fraction''' thereof in '''reserve'''.<br />
<br />
4. Ask for your money to be returned, plus interest.<br />
<br />
5. PROFIT! <br />
<br />
See [http://en.wikipedia.org/wiki/Fractional-reserve_banking Fractional reserve banking].<br />
<br />
Peanut Gallery: But how does the bank guarantee that account holders can withdraw 100% of their bitcoins?<br />
<br />
Same way non-bitcoin banks do it - they don't. They rely on the government's [http://en.wikipedia.org/wiki/Federal_Deposit_Insurance_Corporation FDIC] program to insure depositors up to a certain amount (currently $250K USD per depositor). The FDIC is widely known to have reserves sufficient to cover only a very small fraction of the total deposits it insures.<br />
<br />
Given the inability of governments to manipulate and monopolize the Bitcoin system, however, Bitcoin fractional-reserve banking may not be ''sustainable''.<br />
<br />
== Point of sale with bitcoins isn't possible because of the 10 minute wait for confirmation ==<br />
<br />
Transactions '''can''' take tens of minutes to become ''confirmed'', and this won't change for the forseeable future. Even after the computing power of the network is orders of magnitude larger than today, the difficulty of generating a block will self-adjust to maintain a target of 6 blocks per hour. Three potential solutions to allow POS transactions are:<br />
<br />
1) For small transactions, simply assume the customer isn't ripping you off. Give the customer his latte immediately after the transaction posts to the network. The transaction should propagate through the network almost instantly, allowing the seller to see the transaction within seconds (albeit with zero confirmations.) The cost of a double-spend attack should make small-scale fraud not worthwhile.<br />
<br />
2) Utilize a [http://www.bitcoin.org/smf/index.php?topic=423.msg3819#msg3819 'listening' period] prior to rendering the service or good. This has yet to be formally implemented in the standard bitcoin client, but would allow a vendor to receive the transaction and then monitor the bitcoin network for a certain period of time (maybe 10 seconds) for possible double spends. Vendors might utilize specialized payment processors with multiple well-connected nodes for this purpose. As explained by Satoshi, the network nodes only accept the first version of a transaction they receive to incorporate into the block they're trying to generate. When you broadcast a transaction, if someone else broadcasts a double-spend at the same time, it's a race to propagate to the most nodes first. If one has a slight head start, it'll geometrically spread through the network faster and get most of the nodes. Therefore, the longer the listening period goes without a double spend attempt, the far less likely a double-spend attempt will actually succeed. If a double-spend is detected, the vendor is notified: no latte.<br />
<br />
3) Create a network of transaction hubs. These entities would communicate using a common API. They would float short-term loans between each other to facilitate instant transactions. <br />
<br />
Imagine that Alice uses Carol's Clearinghouse as her hub, and Bob uses Dave's Anonymous Exchange. Both Alice and Bob have accounts with their respective hubs, and have already deposited some Bitcoins in their accounts. When Alice wants to buy a latte from Bob at a point of sale, Alice tells Carol "I want to send Bob ''x'' Bitcoins. He uses Dave's Anonymous Exchange." After checking that Alice's account does contain at least ''x'' Bitcoins, Carol sends a message to Dave, saying "Credit Bob's account with ''x'' bitcoins immediately; I'll send you the real Bitcoins in the next block." Bob instantly sees his balance increase, and gives Alice her latte.<br />
<br />
As always, trust is required - Alice has to trust Carol, and the hubs have to trust each other. Due to competition, various hubs could develop with vastly different fee structures, membership requirements, trustability, etc.<br />
<br />
(But the point of bitcoin is you don't need trust to execute the transaction, in the above description of option 3 you replaced the bitcoins with a trust-based centralized authority.)<br />
<br />
== After 21 million coins are mined, no one will generate new blocks ==<br />
<br />
When operating costs can't be covered by the block creation bounty, which will happen some time before the total amount of BTC is reached, miners are expected to earn profit from [[transaction fees]].<br />
<br />
== Bitcoin has no built-in chargeback mechanism, and this is bad ==<br />
<br />
'''Why some people think this is bad''': Chargebacks are useful for limiting fraud. The person handling your money has a responsibility to prevent fraud. If you buy something on Ebay and the seller never ships it, PayPal takes funds from the seller's account and gives you back the money. This strengthens the Ebay economy, because people recognize that their risk is limited and are more willing to purchase items from risky sellers.<br />
<br />
'''Why it's actually a good thing''': Bitcoin is designed such that your money is yours and yours alone. Allowing chargebacks implies that it is possible for another entity to take your money from you. You can have either total ownership rights of your money, or fraud protection, but not both. That said, nothing prevents the creation of services overlayed on top of Bitcoin that provide fraud protection services.<br />
<br />
The statement "The person handling your money has a responsibility to prevent fraud" is still true; the power has been shifted into your own hands. Fraud will always exist. It's up to you to only send bitcoins to trusted entities. It is possible to trust an online identity without ever knowing their physical identity; see the [http://wiki.bitcoin-otc.com/wiki/OTC_Rating_System OTC Web of Trust].<br />
<br />
== Quantum computers would break bitcoin's security ==<br />
<br />
Yes, but quantum computers don't yet exist and probably won't for a while. Bitcoin's security can be [http://en.wikipedia.org/wiki/Post-quantum_cryptography upgraded] if this were considered an imminent threat.<br />
<br />
See the implications of quantum computers on public key cryptography here http://en.wikipedia.org/wiki/Quantum_computer#Potential<br />
<br />
The ''risk'' of quantum computers is also there for financial institutions, like banks, because they heavily rely on cryptography when doing transactions.<br />
<br />
== Bitcoin mining is a waste of energy and harmful for ecology ==<br />
<br />
No more so than the the wastefulness of mining gold out of the ground, melting it down and shaping it into bars, and then putting it back underground again. Not to mention the building of big fancy buildings, the waste of energy printing and minting all the various fiat currencies, the transportation thereof in armored cars by no less than two security guards for each who could probably be doing something more productive, etc. <br />
<br />
As far as mediums of exchange go, bitcoin is actually quite economical of resources, compared to others.<br />
<br />
== Shopkeepers can't seriously set prices in bitcoins because of the volatile exchange rate ==<br />
<br />
The assumption is that bitcoins must be sold immediately to cover operating expenses. This might not be the case for various reasons, make sure you need to do that.<br />
<br />
It's true that due to the small size of the bitcoin market, there's relatively high volatility. In the future volatility is expected to decrease, as the size and depth of the market grows. <br />
<br />
In the meantime, many merchants simply regularly pull the latest market rates from the exchanges and automatically update the prices on their websites. Also you might be able to buy a put option in order to sell at a fixed rate for a given amount of time. This would protect you from drops in price and simplify your operations for that time period.<br />
<br />
== Like Flooz and e-gold, bitcoins are great for criminals and so will be shut down ==<br />
<br />
* Hopefully bitcoin will grow to the point where no single organization can disrupt the network, or would be better served by helping it.<br />
* Terrorists fly aircrafts into buildings, but the governments have not yet abolished consumer air travel. Obviously the public good outweighs the possible bad in their opinion.<br />
* Criminal law differs between jurisdictions.<br />
<br />
== Bitcoins will be shut down by the government just like Liberty Dollars were ==<br />
<br />
Liberty Dollars consisted of a commercial venture to establish alternative US currency, including physical banknotes and coins, backed by precious metals. They were officially shut down for counterfeiting and intent to fraud. Bitcoins aren't commercial, physical, or backed by something. Different animals entirely.<br />
<br />
Of course, actually 'shutting down' the decentralized Bitcoin network is rife with its own set of difficult considerations.<br />
<br />
==Bitcoin is not decentralized because the developers can dictate the software's behaviour==<br />
<br />
The Bitcoin protocol was originally defined by Bitcoin's inventor, Satoshi Nakamoto, and this protocol has now been widely accepted as the standard by the community of miners and users. <br />
<br />
Though the developers of the official Bitcoin client still exert influence over the Bitcoin community, their power to arbitrarily modify the protocol is very limited. Since the release of Bitcoin v0.3, changes to the protocol have been minor and always in agreement with community consensus.<br />
<br />
Protocol modifications, such as increasing the block award from 50 to 100 BTC, are not compatible with clients already running in the network. If the developers were to release a new client that the majority of miners perceives as corrupt, or in violation of the project’s aims, that client would simply not catch on, and the few users who do try to use it would find that their transactions get rejected by the network.<br />
<br />
Apart from the “official” Bitcoin client, other clients are available (and currently in development) from other groups of developers. As long as these clients adhere to the Bitcoin protocol, it is impossible for the developers of the official client to stop them from competing for blocks, because the network cannot tell them apart from official clients.</div>Trilhttps://tests.bitcoin.it/w/index.php?title=Development_process&diff=4970Development process2011-03-06T01:24:36Z<p>Tril: /* Bitcoin Open Source Development Process */ link to subversion repo on sourceforge</p>
<hr />
<div>== Bitcoin Open Source Development Process ==<br />
<br />
Bitcoin is transitioning from what was essentially a one-person software project, with Satoshi functioning as the primary developer and gatekeeper for all changes, to a more distributed, free software model of development. The Linux Kernel development process is being used as the model for how changes flow into the official Bitcoin application:<br />
# Developers work in their own source code trees, sharing and testing patches with each other. git using github is the preferred source control system for development.<br />
# When a developer thinks a patch is ready, they submit a pull request for the [https://github.com/bitcoin/bitcoin bitcoin github repository] and post a message on the [http://www.bitcoin.org/smf/index.php?board=6.0 Development and Technical Forum].<br />
# Pull requests are discussed on the forums and if there is consensus they're safe, tested, useful, well written, match coding style, etc. then they're merged into the 'master' branch.<br />
# The master github branch is regularly built and tested, and periodically pushed to the [http://sourceforge.net/projects/bitcoin/develop subversion repository] to become a "release candidate" and then the official, stable, released bitcoin.<br />
<br />
Please read and follow [https://github.com/bitcoin/bitcoin/blob/master/coding.txt coding.txt] for a description of the bitcoin coding style.<br />
<br />
[[Category:Developer]]</div>Tril