Bitcoin Wiki - User contributions [en]

BitClockers

2021-03-23T09:42:44Z

Mmortal03: defunct

A [[Pooled mining|mining pool]].

BitClockers.com was created with an emphasis on performance, reliability, and user support.

Features included 24/7 Live Chat, an active forums community, real-time worker statistics tracking and mining hardware giveaways/contests.

The service was first available for beta testing starting May 26, 2011<ref>[http://bitcointalk.org/index.php?topic=10127.0 BitClockers.com Mining Pool LP/SSL/API/SIGs/Multihomed/InstaPay/Support]</ref>.

==Pool Features<ref>[http://bitclockers.com/ BitClockers.com Bitcoin Mining Pool]</ref>==

* Merged Mining: BTC and NMC
* Real-time statistics
* Reward calculator
* SSL Encryption
* JSON API for miner status
* Protocols supported: Stratum, GetBlockTemplate, GetMemoryTemplate, GetWork
* Difficulty: Dynamic - 0.5 to infinity in multiples of 2

==Reward distribution==

* Bitcoin Pay-Per-Share: 5% fee.
* Namecoin Proportional: 5% fee.
* Minimum payout is 0.01 BTC/NMC
* Pool pays for invalid blocks.

==Hosts==

* pool.bitclockers.com:8332 - Load balanced between Denver/Chicago/Zlin
* pool2.bitclockers.com:8332 - Chicago, IL USA
* pool3.bitclockers.com:8332 - Zlin, Czech Republic EU

* testnet.bitclockers.com:8332 - Development pool, only produces testnet coins.

==See Also==

* [[Comparison of mining pools]]
* [[Pooled Mining]]

==External Links==

* [http://bitclockers.com BitClockers] web site

==References==
<references />

[[Category:Pool Operators]]

Coinprism

2018-05-16T07:37:58Z

Mmortal03:

{{infobox company|image=[[Image:Logo_Coinprism.png‎‎|300px]]|name=Coinprism
|founder=Flavien Charlon
|foundation=March 13, 2014
|industry=[[EWallet]]
|website=https://www.coinprism.com
}}[https://www.coinprism.com Coinprism] was a Colored Coins web wallet. Coinprism was similar to other web wallets, except you could store, issue, send and receive [[Colored Coins]] and not only normal Bitcoins.

==Colored Coins==

Colored coins allow you to store assets on the [[Coinprism.info|Bitcoin blockchain]]. There are many interesting applications to colored coins. You could have an IPO on the blockchain by issuing shares as colored coins, and send them to your shareholders. The shares could then be traded almost instantaneously and for free through the Bitcoin blockchain. You could have smart properties represented by colored coins. You could store your house on the blockchain by issuing a single coin, then the ownership of the house can be transferred with a simple Bitcoin transaction.

==Specifications==

Coinprism was an implementation of the [[Colored Coins#Open_Assets|Open Assets protocol]] and it was compatible with the open source Colored Coins wallet [[Colorcore]].

==Features==
* Issue any assets
* Send and receive assets and bitcoins
* [http://www.coinprism.info Full block explorer]
* Two-factor authentication
* Export and backup wallet
* Import private key
* Issue bitcoin and colored coin dividends
* Optional miners' fee
* Offline storage (Armory, TREZOR)
* [https://play.google.com/store/apps/developer?id=Coinprism Android App]

==Coinprism Android App==
<gallery>
Coinprism_Android_App_2.png
Coinprism_Android_App_3.png
Coinprism_Android_App_4.png
</gallery>

==History==

* Coinprism Beta launch: March 13th 2014<ref>[http://www.coindesk.com/holy-bitcoin-trinity-revive-colored-coins/ Could This Holy Bitcoin Trinity Revive Colored Coins?]</ref>
* Coinprism Full launch: May 13th 2014<ref>[https://bitcointalk.org/index.php?topic=517139.0 ANN Coinprism: the first colored coin web wallet]</ref>
* Coinprism launches support for sending dividends: July 12th 2014<ref>[http://blog.coinprism.com/2014/07/12/colored-coins-dividends/ Colored coins now supporting dividends]</ref>
* Coinprism launches a beta [http://docs.coinprism.apiary.io/ Colored Coin API]: August 2nd 2014
* Coinprism launches a [https://www.coinprism.info Colored Coin blockchain explorer], a [https://www.coinprism.info/assets Colored Coin assets directory]: August 2nd 2014 <ref>[http://blog.coinprism.com/2014/08/03/coinprism-info-new-colored-coin-blockchain-explorer-and-assets-directory/ Coinprism.info: New Colored Coin blockchain explorer and Assets directory]</ref>
* Coinprism launches [https://github.com/OpenAssets/colorcore Colorcore], an open source colored coin wallet compatible with open assets and Coinprism: September 2nd 2014 <ref>[http://www.reddit.com/r/Bitcoin/comments/2f9sfy/announcing_colorcore_the_open_source_colored_coin/ Colorcore: the colored coin wallet compatible with open assets]</ref>
* Coinprism launches the [https://github.com/OpenAssets/openassets Open Assets Python Library]: September 2nd 2014
* Coinprism launches an [https://play.google.com/store/apps/developer?id=Coinprism Android App]: October 20th 2014<ref>[http://www.coindesk.com/coinprism-mobile-wallet-colored-coins/ Coinprism Releases Colored Coins Android App for Mobile Asset Transfer]</ref>
* Coinprism adds support for [http://blog.coinprism.com/2014/11/17/colored-coin-denominated-dividends/ colored coin dividends]: November 17th 2014<ref>[http://www.coindesk.com/ethereum-counterparty-fork-colored-coins/ Coinprism debuts dividends feature]</ref>
* Coinprism adds support for [http://blog.coinprism.com/2014/11/17/colored-coin-denominated-dividends/ offline storage with Armory]: November 24th 2014<ref>[http://bravenewcoin.com/news/coinprism-adds-armory-support/ Coinprism Adds Armory Support]</ref>
* New special [http://blog.coinprism.com/2014/12/15/solving-the-issue-of-uncoloring-colored-coins-through-a-new-address-type/ address format] for colored coins: December 15th 2014
* Coinprism adds support for [http://blog.coinprism.com/2015/03/09/trezor-with-coinprism/ offline storage with TREZOR]: March 9th 2015<ref>[http://bitcoinist.net/coinprism-trezor-compatible/ Coinprism is now TREZOR Compatible]</ref>
* Coinprism shut down: March 31st, 2018<ref>[https://www.coindesk.com/blockchain-startup-coinprism-to-shut-down-in-2-days/ 'Colored Coins' Startup Coinprism Is Shutting Down]</ref>

==External Links==

* [https://www.coinprism.com Coinprism] Official website
* [https://www.coinprism.info Coinprism.info] Blockchain explorer & asset directory
* [https://coinprism.desk.com/ Coinprism Support Center] Support Center
* [http://forum.coinprism.com Coinprism Developer Forum] Official Developer Forum
* [http://docs.coinprism.apiary.io/ Coinprism API] Coinprism API documentation
* [https://github.com/OpenAssets/open-assets-protocol Open Assets protocol]
* [https://github.com/OpenAssets/openassets Open Assets Python library]
* [https://github.com/OpenAssets/colorcore Colorcore] Colorcore Open Source wallet
* [http://blog.coinprism.com Coinprism Blog] Official Blog
* [https://bitcointalk.org/index.php?topic=517139.0 Coinprism on BitcoinTalk] BitcoinTalk
* [https://coinprism.desk.com/customer/portal/emails/new Contact the coinprism team] Contact
* [https://twitter.com/Coinprism @Coinprism] Twitter
* [http://www.facebook.com/Coinprism Coinprism on Facebook] Facebook page
* [https://plus.google.com/109866598728356866398/ Coinprism on Google+ ] Google+ page
* [http://reddit.com/r/coinprism Coinprism on Reddit] Coinprism subreddit
* [http://www.crunchbase.com/organization/coinprism/ Crunchbase profile] Crunchbase
* [http://www.bitcoin2comparator.org/ Comparison Bitcoin 2.0 technologogies] Bitcoin2comparator

==References==
<references />

==Screenshots==
<gallery>
Coinprism_wallet.png‎‎|Wallet
Coinprism_blockchain_explorer.png|Chain explorer
Coinprism_asset_directory.png|Asset directory
Coinprism_fund_address.png|Fund Address
</gallery>
[[Category:EWallets]]
[[Category:Wallets]]
[[Category:Services]]
[[Category:Financial]]
[[Category:Clients]]
[[Category:Frontends]]
[[Category:Block chain browsers]]
[[Category:Mobile]]
[[Category:Colored Coins]]

Clearing Up Misconceptions About Full Nodes

2016-07-24T14:45:22Z

Mmortal03: /* Myth: The number of these nodes matters and/or is too low. */

This article was written in March 2016 to clear up misconceptions common in the bitcoin community at the time.

=Myth: There are only about 5500 [[Full node|full nodes]] worldwide=

This number comes from [https://bitnodes.21.co/ sites like this] and it measured by trying to connect to every nodes on their open ports.

Problem is, not all nodes actually have open ports that can be probed. Either because they are behind firewalls or because their users have configured them to not listen for connections.

Nobody knows how many [[full node|full nodes]] there are, since many people don't know how to forward ports behind a firewall, and bandwidth can be costly, its quite likely that the number of nodes with closed ports is at least another several thousand.

Nodes with open ports are able to upload blocks to new full nodes. In all other ways they are the same as nodes with closed ports. But because open-port-nodes can be measured and closed-port-nodes cannot, some members of the [[bitcoin]] community have been mistaken into believing that open-port-nodes represent the full count.

====Very roughly estimating the total node count====

(Original research by theymos on June 6, 2016 18:30 UTC.)

According to getaddr.bitnodes.io, there are 5834 listening full nodes. Assuming they're all using default Bitcoin Core settings, they'll each provide 117 connection slots to the network on net (125 provided minus 8 consumed). SPV nodes typically use 4 connection slots, and full nodes typically use 8. So the network can support a maximum of around 170,644 SPV nodes or 85,322 non-listening full nodes at one time. This is roughly the upper limit for the number of wallets that are online and connected to the Bitcoin network at any one time. (If there were more people online at once than that, people would start seeing various issues.) This doesn't include wallets that don't actually connect to the Bitcoin network, of course.

If I look at my long-running listening full node, I currently have incoming connections from 40 full nodes and 10 SPV nodes via the Internet, and 11 full nodes via my Tor hidden service. So if I ignore the hidden service connections because they are somewhat unusual, and I assume that my node is typical otherwise, it seems reasonable to make a very rough guess that there are at this moment (40*5834)/8 = 29,170 full nodes (5834 listening) and (10*5834)/4 = 14,585 lightweight nodes connected to the network.

=Myth: The number of these nodes matters and/or is too low.=

Nodes with open ports are useful to the [[Network|bitcoin network]] because they help [[Network#Initial_block_download|bootstrap new nodes]] by uploading historical blocks -- they are a measure of the number of redundant copies of the blockchain available for synchronizing with. So far, there has been no shortage of bandwidth capacity for simply syncing wallets from the available nodes, and if there were, bandwidth might be added by renting cloud servers. However, for miners, there ''has'' been a need for higher throughput, something that, thus far, hasn't been realized in a decentralized fashion by way of the average full node. This circumstance will change as further optimizations to the code are introduced, with additions such as compact blocks (BIP152).

Trust, security, and privacy are also important. [[full node|Full nodes]] are able to check that all of bitcoin's rules are being followed. Rules like following the [[Controlled_supply|inflation schedule]], [[Double-spending|no double spending]], no spending of coins that don't belong to the holder of the private key and all the other rules required to make [[bitcoin]] work (e.g. difficulty)

Full nodes are what make [[bitcoin]] trustless. No longer do you have to trust a financial institution like a bank or paypal, you can simply run software on your own computer. ''To put simply, the only node that matters is the one you use''

=Myth: There is no incentive to run nodes, the network relies on altruism=

It is very much in the individual bitcoin's users rational self interest to run a [[full node]] and use it as their [[wallet]].

====Trustless====
Running a full node as your [[wallet]] is the only way to know for sure that none of bitcoin's rules have been broken. Rules like no coins were spent not belonging to the owner, that no coins were spent twice, that no inflation happens outside of the schedule and that all the rules needed to make the system work are followed (e.g. [[Difficulty]].) All other kinds of wallet involve trusting a third party server.

====Security====
All these checks done by full nodes also increase the security. There are many attacks possible against lightweight wallets that do not affect full node wallets.

This is not just mindless paranoia, there have been real world examples where full node users were unaffected by turmoil in the rest of the bitcoin ecosystem. The 4th July 2015 accidental chain fork effected many kinds of wallets. Here is the wiki page on this event [[July_2015_chain_forks#Wallet_Advice]]

Notice how node software updated months ago was completely unaffected by the fork. All other wallets required either extra [[confirmation|confirmations]] or checking that the third-party institution was running the correct version. A bitcoin business, like an exchange, marketplace or online store should always use a full node for security.

====Privacy====
Full nodes wallets are also currently the most private way to use Bitcoin, with nobody else learning which bitcoin [[address|addresses]] belong to you. All other [[Thin_Client_Security|lightweight wallets]] leak information about which [[address|addresses]] are yours because they must query third-party servers. The Electrum servers will know which [[address|addresses]] belong to you and can link them together. Despite [[BIP_0037|bloom filtering]], lightweight wallets based on [[bitcoinj|BitcoinJ]] do not provide much privacy against nodes who connected directly to the wallet or wiretappers.<ref>http://jonasnick.github.io/blog/2015/02/12/privacy-in-bitcoinj/ Privacy in BitcoinJ</ref>

For some use cases, such privacy may not be required. But an important reason to run a full node and use it as a wallet is to get the full privacy benefits.

=Myth: I can just set up a node on a cloud server instance and leave it=

To get the benefits of running a full node, you must use it as your wallet, preferably on hardware you control.

Most people who do this do not use a full node as their wallet. Unfortunately because Bitcoin has a similar name to Bittorrent, some people believe that upload capacity is the most important thing for a healthy network. As I've explained above: bandwidth and connections are not a problem today; trust, security and privacy are.

=Myth: Running a full node is not recommended, most people should use a lightweight client=

This was common advice in 2012, but since then the full node software has vastly improved in terms of user experience.

If you cannot spare the disk space to store the [[blockchain]], you can [https://bitcoin.org/en/release/v0.12.0#wallet-pruning enable pruning]. In Bitcoin Core 0.12, pruning being enabled will leave the wallet enabled. Altogether this should require less than 900MB of hard disk space.

If you cannot spare the bandwidth to upload blocks to other nodes, [https://bitcoin.org/en/full-node#reduce-traffic there are number of options to reduce or eliminate the bandwidth requirement]. These include limiting connections, bandwidth targeting and disabling listening. Bitcoin Core 0.12 has the new option [https://bitcointalk.org/index.php?topic=1377345.0 -blocksonly], where the node will not download unconfirmed transaction and only download new blocks. This more than halves the bandwidth usage at the expense of not seeing unconfirmed transactions.

[[Network#Initial_block_download|Synchronizing the blockchain]] for a new node has improved since 2012 too. Features like [https://bitcoin.org/en/release/v0.10.0#faster-synchronization headers-first] and libsecp256k1 have greatly improved the initial synchronization time.

It can be further improved by setting -dbcache=3000 which keeps more of the [[Data_directory#chainstate_subdirectory|UTXO set]] in memory. It reduces the amount of time reading from disk and therefore speeds up synchronization. Tests showed that the entire [[blockchain]] can now be synchronized in [https://github.com/bitcoin/bitcoin/pull/6954#issuecomment-154993958 less than **3 and a half hours**] (Note that you'll need Bitcoin Core 0.12 or later to get all these efficiency improvements) [https://www.botbot.me/freenode/bitcoin-core-dev/2016-04-13/?msg=64033258&page=1 Another example with 2h 25m]

=How to run a full node as your wallet=

I think every moderate user of bitcoin would benefit by running a full node and using it as their wallet. There are several ways to do this.

* Run a [https://bitcoin.org/en/download bitcoin-qt full node].

* Use wallet software that is backed by a full node (e.g. [[Armory]], [https://github.com/AdamISZ/JMBinary/#jmbinary JoinMarket])

* Use a lightweight wallet that connects only to your full node (e.g. [[Multibit]] connecting only to your node running at home, [[Electrum]] connecting only to your own Electrum server)

So what are you waiting for? The benefits are many, the downsides are not that bad. The more people do this, the more robust and healthy the bitcoin ecosystem is.

=Further Reading=
[http://www.truthcoin.info/blog/measuring-decentralization/ Measuring Decentralization - Truthcoin]

[https://www.reddit.com/r/BitcoinBeginners/comments/3eq3y7/full_node_question/ctk4lnd Pieter Wuille's explaination of full node trustlessness]

[https://bitcoin.org/en/bitcoin-core/features/validation bitcoin.org's article on validation]

[https://www.reddit.com/r/Bitcoin/comments/44rx5k/psa_clearing_up_some_misconceptions_about_full/ Reddit comments]

=References=
<references />

[[Category:Technical]]

Clearing Up Misconceptions About Full Nodes

2016-07-24T14:28:12Z

Mmortal03: /* Trustless */

This article was written in March 2016 to clear up misconceptions common in the bitcoin community at the time.

=Myth: There are only about 5500 [[Full node|full nodes]] worldwide=

This number comes from [https://bitnodes.21.co/ sites like this] and it measured by trying to connect to every nodes on their open ports.

Problem is, not all nodes actually have open ports that can be probed. Either because they are behind firewalls or because their users have configured them to not listen for connections.

Nobody knows how many [[full node|full nodes]] there are, since many people don't know how to forward ports behind a firewall, and bandwidth can be costly, its quite likely that the number of nodes with closed ports is at least another several thousand.

Nodes with open ports are able to upload blocks to new full nodes. In all other ways they are the same as nodes with closed ports. But because open-port-nodes can be measured and closed-port-nodes cannot, some members of the [[bitcoin]] community have been mistaken into believing that open-port-nodes represent the full count.

====Very roughly estimating the total node count====

(Original research by theymos on June 6, 2016 18:30 UTC.)

According to getaddr.bitnodes.io, there are 5834 listening full nodes. Assuming they're all using default Bitcoin Core settings, they'll each provide 117 connection slots to the network on net (125 provided minus 8 consumed). SPV nodes typically use 4 connection slots, and full nodes typically use 8. So the network can support a maximum of around 170,644 SPV nodes or 85,322 non-listening full nodes at one time. This is roughly the upper limit for the number of wallets that are online and connected to the Bitcoin network at any one time. (If there were more people online at once than that, people would start seeing various issues.) This doesn't include wallets that don't actually connect to the Bitcoin network, of course.

If I look at my long-running listening full node, I currently have incoming connections from 40 full nodes and 10 SPV nodes via the Internet, and 11 full nodes via my Tor hidden service. So if I ignore the hidden service connections because they are somewhat unusual, and I assume that my node is typical otherwise, it seems reasonable to make a very rough guess that there are at this moment (40*5834)/8 = 29,170 full nodes (5834 listening) and (10*5834)/4 = 14,585 lightweight nodes connected to the network.

=Myth: The number of these nodes matters and/or is too low.=

Nodes with open ports are useful to the [[Network|bitcoin network]] because they help [[Network#Initial_block_download|bootstrap new nodes]] by uploading historical blocks, they are a measure of bandwidth capacity. Right now there is no shortage of bandwidth capacity, and if there was it could be easily added by renting cloud servers.

The problem is not bandwidth or connections, but trust, security and privacy. Let me explain.

[[full node|Full nodes]] are able to check that all of bitcoin's rules are being followed. Rules like following the [[Controlled_supply|inflation schedule]], [[Double-spending|no double spending]], no spending of coins that don't belong to the holder of the private key and all the other rules required to make [[bitcoin]] work (e.g. difficulty)

Full nodes are what make [[bitcoin]] trustless. No longer do you have to trust a financial institution like a bank or paypal, you can simply run software on your own computer. ''To put simply, the only node that matters is the one you use''

=Myth: There is no incentive to run nodes, the network relies on altruism=

It is very much in the individual bitcoin's users rational self interest to run a [[full node]] and use it as their [[wallet]].

====Trustless====
Running a full node as your [[wallet]] is the only way to know for sure that none of bitcoin's rules have been broken. Rules like no coins were spent not belonging to the owner, that no coins were spent twice, that no inflation happens outside of the schedule and that all the rules needed to make the system work are followed (e.g. [[Difficulty]].) All other kinds of wallet involve trusting a third party server.

====Security====
All these checks done by full nodes also increase the security. There are many attacks possible against lightweight wallets that do not affect full node wallets.

This is not just mindless paranoia, there have been real world examples where full node users were unaffected by turmoil in the rest of the bitcoin ecosystem. The 4th July 2015 accidental chain fork effected many kinds of wallets. Here is the wiki page on this event [[July_2015_chain_forks#Wallet_Advice]]

Notice how node software updated months ago was completely unaffected by the fork. All other wallets required either extra [[confirmation|confirmations]] or checking that the third-party institution was running the correct version. A bitcoin business, like an exchange, marketplace or online store should always use a full node for security.

====Privacy====
Full nodes wallets are also currently the most private way to use Bitcoin, with nobody else learning which bitcoin [[address|addresses]] belong to you. All other [[Thin_Client_Security|lightweight wallets]] leak information about which [[address|addresses]] are yours because they must query third-party servers. The Electrum servers will know which [[address|addresses]] belong to you and can link them together. Despite [[BIP_0037|bloom filtering]], lightweight wallets based on [[bitcoinj|BitcoinJ]] do not provide much privacy against nodes who connected directly to the wallet or wiretappers.<ref>http://jonasnick.github.io/blog/2015/02/12/privacy-in-bitcoinj/ Privacy in BitcoinJ</ref>

For some use cases, such privacy may not be required. But an important reason to run a full node and use it as a wallet is to get the full privacy benefits.

=Myth: I can just set up a node on a cloud server instance and leave it=

To get the benefits of running a full node, you must use it as your wallet, preferably on hardware you control.

Most people who do this do not use a full node as their wallet. Unfortunately because Bitcoin has a similar name to Bittorrent, some people believe that upload capacity is the most important thing for a healthy network. As I've explained above: bandwidth and connections are not a problem today; trust, security and privacy are.

=Myth: Running a full node is not recommended, most people should use a lightweight client=

This was common advice in 2012, but since then the full node software has vastly improved in terms of user experience.

If you cannot spare the disk space to store the [[blockchain]], you can [https://bitcoin.org/en/release/v0.12.0#wallet-pruning enable pruning]. In Bitcoin Core 0.12, pruning being enabled will leave the wallet enabled. Altogether this should require less than 900MB of hard disk space.

If you cannot spare the bandwidth to upload blocks to other nodes, [https://bitcoin.org/en/full-node#reduce-traffic there are number of options to reduce or eliminate the bandwidth requirement]. These include limiting connections, bandwidth targeting and disabling listening. Bitcoin Core 0.12 has the new option [https://bitcointalk.org/index.php?topic=1377345.0 -blocksonly], where the node will not download unconfirmed transaction and only download new blocks. This more than halves the bandwidth usage at the expense of not seeing unconfirmed transactions.

[[Network#Initial_block_download|Synchronizing the blockchain]] for a new node has improved since 2012 too. Features like [https://bitcoin.org/en/release/v0.10.0#faster-synchronization headers-first] and libsecp256k1 have greatly improved the initial synchronization time.

It can be further improved by setting -dbcache=3000 which keeps more of the [[Data_directory#chainstate_subdirectory|UTXO set]] in memory. It reduces the amount of time reading from disk and therefore speeds up synchronization. Tests showed that the entire [[blockchain]] can now be synchronized in [https://github.com/bitcoin/bitcoin/pull/6954#issuecomment-154993958 less than **3 and a half hours**] (Note that you'll need Bitcoin Core 0.12 or later to get all these efficiency improvements) [https://www.botbot.me/freenode/bitcoin-core-dev/2016-04-13/?msg=64033258&page=1 Another example with 2h 25m]

=How to run a full node as your wallet=

I think every moderate user of bitcoin would benefit by running a full node and using it as their wallet. There are several ways to do this.

* Run a [https://bitcoin.org/en/download bitcoin-qt full node].

* Use wallet software that is backed by a full node (e.g. [[Armory]], [https://github.com/AdamISZ/JMBinary/#jmbinary JoinMarket])

* Use a lightweight wallet that connects only to your full node (e.g. [[Multibit]] connecting only to your node running at home, [[Electrum]] connecting only to your own Electrum server)

So what are you waiting for? The benefits are many, the downsides are not that bad. The more people do this, the more robust and healthy the bitcoin ecosystem is.

=Further Reading=
[http://www.truthcoin.info/blog/measuring-decentralization/ Measuring Decentralization - Truthcoin]

[https://www.reddit.com/r/BitcoinBeginners/comments/3eq3y7/full_node_question/ctk4lnd Pieter Wuille's explaination of full node trustlessness]

[https://bitcoin.org/en/bitcoin-core/features/validation bitcoin.org's article on validation]

[https://www.reddit.com/r/Bitcoin/comments/44rx5k/psa_clearing_up_some_misconceptions_about_full/ Reddit comments]

=References=
<references />

[[Category:Technical]]

Clearing Up Misconceptions About Full Nodes

2016-07-24T14:23:22Z

Mmortal03: /* Myth: There are only about 5500 full nodes worldwide */

This article was written in March 2016 to clear up misconceptions common in the bitcoin community at the time.

=Myth: There are only about 5500 [[Full node|full nodes]] worldwide=

This number comes from [https://bitnodes.21.co/ sites like this] and it measured by trying to connect to every nodes on their open ports.

Problem is, not all nodes actually have open ports that can be probed. Either because they are behind firewalls or because their users have configured them to not listen for connections.

Nobody knows how many [[full node|full nodes]] there are, since many people don't know how to forward ports behind a firewall, and bandwidth can be costly, its quite likely that the number of nodes with closed ports is at least another several thousand.

Nodes with open ports are able to upload blocks to new full nodes. In all other ways they are the same as nodes with closed ports. But because open-port-nodes can be measured and closed-port-nodes cannot, some members of the [[bitcoin]] community have been mistaken into believing that open-port-nodes represent the full count.

====Very roughly estimating the total node count====

(Original research by theymos on June 6, 2016 18:30 UTC.)

According to getaddr.bitnodes.io, there are 5834 listening full nodes. Assuming they're all using default Bitcoin Core settings, they'll each provide 117 connection slots to the network on net (125 provided minus 8 consumed). SPV nodes typically use 4 connection slots, and full nodes typically use 8. So the network can support a maximum of around 170,644 SPV nodes or 85,322 non-listening full nodes at one time. This is roughly the upper limit for the number of wallets that are online and connected to the Bitcoin network at any one time. (If there were more people online at once than that, people would start seeing various issues.) This doesn't include wallets that don't actually connect to the Bitcoin network, of course.

If I look at my long-running listening full node, I currently have incoming connections from 40 full nodes and 10 SPV nodes via the Internet, and 11 full nodes via my Tor hidden service. So if I ignore the hidden service connections because they are somewhat unusual, and I assume that my node is typical otherwise, it seems reasonable to make a very rough guess that there are at this moment (40*5834)/8 = 29,170 full nodes (5834 listening) and (10*5834)/4 = 14,585 lightweight nodes connected to the network.

=Myth: The number of these nodes matters and/or is too low.=

Nodes with open ports are useful to the [[Network|bitcoin network]] because they help [[Network#Initial_block_download|bootstrap new nodes]] by uploading historical blocks, they are a measure of bandwidth capacity. Right now there is no shortage of bandwidth capacity, and if there was it could be easily added by renting cloud servers.

The problem is not bandwidth or connections, but trust, security and privacy. Let me explain.

[[full node|Full nodes]] are able to check that all of bitcoin's rules are being followed. Rules like following the [[Controlled_supply|inflation schedule]], [[Double-spending|no double spending]], no spending of coins that don't belong to the holder of the private key and all the other rules required to make [[bitcoin]] work (e.g. difficulty)

Full nodes are what make [[bitcoin]] trustless. No longer do you have to trust a financial institution like a bank or paypal, you can simply run software on your own computer. ''To put simply, the only node that matters is the one you use''

=Myth: There is no incentive to run nodes, the network relies on altruism=

It is very much in the individual bitcoin's users rational self interest to run a [[full node]] and use it as their [[wallet]].

====Trustless====
Using a full node as your [[wallet]] is the only way to know for sure that none of bitcoin's rules have been broken. Rules like no coins were spent not belonging to the owner, that no coins were spent twice, that no inflation happens outside of the schedule and that all the rules needed to make the system work are followed (e.g. [[Difficulty]].) All other kinds of wallet involve trusting a third party server.

====Security====
All these checks done by full nodes also increase the security. There are many attacks possible against lightweight wallets that do not affect full node wallets.

This is not just mindless paranoia, there have been real world examples where full node users were unaffected by turmoil in the rest of the bitcoin ecosystem. The 4th July 2015 accidental chain fork effected many kinds of wallets. Here is the wiki page on this event [[July_2015_chain_forks#Wallet_Advice]]

Notice how node software updated months ago was completely unaffected by the fork. All other wallets required either extra [[confirmation|confirmations]] or checking that the third-party institution was running the correct version. A bitcoin business, like an exchange, marketplace or online store should always use a full node for security.

====Privacy====
Full nodes wallets are also currently the most private way to use Bitcoin, with nobody else learning which bitcoin [[address|addresses]] belong to you. All other [[Thin_Client_Security|lightweight wallets]] leak information about which [[address|addresses]] are yours because they must query third-party servers. The Electrum servers will know which [[address|addresses]] belong to you and can link them together. Despite [[BIP_0037|bloom filtering]], lightweight wallets based on [[bitcoinj|BitcoinJ]] do not provide much privacy against nodes who connected directly to the wallet or wiretappers.<ref>http://jonasnick.github.io/blog/2015/02/12/privacy-in-bitcoinj/ Privacy in BitcoinJ</ref>

For some use cases, such privacy may not be required. But an important reason to run a full node and use it as a wallet is to get the full privacy benefits.

=Myth: I can just set up a node on a cloud server instance and leave it=

To get the benefits of running a full node, you must use it as your wallet, preferably on hardware you control.

Most people who do this do not use a full node as their wallet. Unfortunately because Bitcoin has a similar name to Bittorrent, some people believe that upload capacity is the most important thing for a healthy network. As I've explained above: bandwidth and connections are not a problem today; trust, security and privacy are.

=Myth: Running a full node is not recommended, most people should use a lightweight client=

This was common advice in 2012, but since then the full node software has vastly improved in terms of user experience.

If you cannot spare the disk space to store the [[blockchain]], you can [https://bitcoin.org/en/release/v0.12.0#wallet-pruning enable pruning]. In Bitcoin Core 0.12, pruning being enabled will leave the wallet enabled. Altogether this should require less than 900MB of hard disk space.

If you cannot spare the bandwidth to upload blocks to other nodes, [https://bitcoin.org/en/full-node#reduce-traffic there are number of options to reduce or eliminate the bandwidth requirement]. These include limiting connections, bandwidth targeting and disabling listening. Bitcoin Core 0.12 has the new option [https://bitcointalk.org/index.php?topic=1377345.0 -blocksonly], where the node will not download unconfirmed transaction and only download new blocks. This more than halves the bandwidth usage at the expense of not seeing unconfirmed transactions.

[[Network#Initial_block_download|Synchronizing the blockchain]] for a new node has improved since 2012 too. Features like [https://bitcoin.org/en/release/v0.10.0#faster-synchronization headers-first] and libsecp256k1 have greatly improved the initial synchronization time.

It can be further improved by setting -dbcache=3000 which keeps more of the [[Data_directory#chainstate_subdirectory|UTXO set]] in memory. It reduces the amount of time reading from disk and therefore speeds up synchronization. Tests showed that the entire [[blockchain]] can now be synchronized in [https://github.com/bitcoin/bitcoin/pull/6954#issuecomment-154993958 less than **3 and a half hours**] (Note that you'll need Bitcoin Core 0.12 or later to get all these efficiency improvements) [https://www.botbot.me/freenode/bitcoin-core-dev/2016-04-13/?msg=64033258&page=1 Another example with 2h 25m]

=How to run a full node as your wallet=

I think every moderate user of bitcoin would benefit by running a full node and using it as their wallet. There are several ways to do this.

* Run a [https://bitcoin.org/en/download bitcoin-qt full node].

* Use wallet software that is backed by a full node (e.g. [[Armory]], [https://github.com/AdamISZ/JMBinary/#jmbinary JoinMarket])

* Use a lightweight wallet that connects only to your full node (e.g. [[Multibit]] connecting only to your node running at home, [[Electrum]] connecting only to your own Electrum server)

So what are you waiting for? The benefits are many, the downsides are not that bad. The more people do this, the more robust and healthy the bitcoin ecosystem is.

=Further Reading=
[http://www.truthcoin.info/blog/measuring-decentralization/ Measuring Decentralization - Truthcoin]

[https://www.reddit.com/r/BitcoinBeginners/comments/3eq3y7/full_node_question/ctk4lnd Pieter Wuille's explaination of full node trustlessness]

[https://bitcoin.org/en/bitcoin-core/features/validation bitcoin.org's article on validation]

[https://www.reddit.com/r/Bitcoin/comments/44rx5k/psa_clearing_up_some_misconceptions_about_full/ Reddit comments]

=References=
<references />

[[Category:Technical]]

Atomic swap

2016-03-26T06:49:52Z

Mmortal03: /* Solution using specialized altchain */

The problem of '''atomic cross-chain trading''' is one where (at least) two parties, Alice and Bob, own coins in separate cryptocurrencies, and want to exchange them without having to trust a third party (centralized exchange).

A non-atomic trivial solution would have Alice send her Bitcoins to Bob, and then have Bob send another cryptocurrency to Alice - but Bob has the option of going back on his end of the bargain and simply not following through with the protocol, ending up with both Bitcoins and the altcoin.

== Solution using revealing secrets of contract ==

One solution is [[Contracts#Example_5:_Trading_across_chains|Contracts]] and [[nLockTime]].

=== Algorithm ===
Here is one description of an algorithm that solves this problem, [https://bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949 credit goes to TierNolan] for this specific description (the algorithm was described in other terms by other people including [[Mike Hearn]] above).

<pre>
A picks a random number x

A creates TX1: "Pay w BTC to <B's public key> if (x for H(x) known and signed by B) or (signed by A & B)"

A creates TX2: "Pay w BTC from TX1 to <A's public key>, locked 48 hours in the future, signed by A"

A sends TX2 to B

B signs TX2 and returns to A

1) A submits TX1 to the network

B creates TX3: "Pay v alt-coins to <A-public-key> if (x for H(x) known and signed by A) or (signed by A & B)"

B creates TX4: "Pay v alt-coins from TX3 to <B's public key>, locked 24 hours in the future, signed by B"

B sends TX4 to A

A signs TX4 and sends back to B

2) B submits TX3 to the network

3) A spends TX3 giving x

4) B spends TX1 using x

This is atomic (with timeout). If the process is halted, it can be reversed no matter when it is stopped.

Before 1: Nothing public has been broadcast, so nothing happens
Between 1 & 2: A can use refund transaction after 72 hours to get his money back
Between 2 & 3: B can get refund after 24 hours. A has 24 more hours to get his refund
After 3: Transaction is completed by 2
- A must spend his new coin within 24 hours or B can claim the refund and keep his coins
- B must spend his new coin within 72 hours or A can claim the refund and keep his coins

For safety, both should complete the process with lots of time until the deadlines.
</pre>

== Solution using specialized altchain ==

The previously mentioned approach can be used directly to trade between bitcoin-derived chains without special support on the side of protocol. The obvious disadvantage is nLockTime - if counterparty does not go through the trade, our funds are locked and cannot used in another trade for the duration of timeout. Additionally, it depends on transaction replacement which may, or may not be considered standard under current bitcoin protocol rules.

Another proposal of cross-chain p2ptrade is to use specialized altchain with properties for efficient operation of p2ptrade from bitcoin chain. Additionally, we use only single standard bitcoin transaction which looks exactly the same as normal payment (no nlocktime, no multisig, no special script).

Assuming the altchain has actual economic value to support it, it can even serve as proxy for (relatively) efficient zero-trust p2p market between fe. BTC and LTC thanks to arbitraging market makers.

=== Algorithm ===

Alice=AltChain
Bob=Bitcoin

* Bob create and sign the transaction as usual and compute its txid. He sends txid and the transaction body with input scripts/signature blanked to Alice.
* Alice computes hash of the blanked body, call it blankhash, and constructs transaction with special bitcointxid(blankhash,txid) opcode. Broadcasts the transaction to altchain.
* Bob waits for altchain tx to confirm and verify its outputs are as previously agreed - at that point he sends the "uncensored" Bitcoin tx to Alice who'll broadcast it. Alice is therefore credited the bitcoin funds, which in turn validate altchain transaction at the same time (this is the atomic point).
* Note that bob releases his tx only if he is sufficiently confident the altchain will not reorg its transactions, thus possibly double spend. This might imply that *many* confirmations in altchain should come first, however during that time each of them might decide to cancel the trade with no further consequences.

=== Opcodes and altchain special rules ===

* bitcointxid evaluates to true if txid (and blankhash is equal to tx body) are seen confirmed in the bitcoin blockchain (altchain client must consult bitcoin for that) and it's outputs are spendable (ie verify it's standard tx).
* The transaction is constructed in such a way it is valid to be included in altchain even if there is no matching txid/blankhash in bitcoin
* Its outputs are not spendable and inputs are free to be spent by another tx (i know, ugly!) until bitcoin txid confirmed "freezes" the tx (at which point it consumes inputs, and it's outputs become spendable).
* Optionally there could be bitcoin block# parameter at which point the freeze occurs (effectively dictating number of confirms on bitcoin side).
* It is legal for inputs to be mentioned multiple times, first (in blockheight order) transaction which gets "frozen" wins and other same-input consumers become invalid.

== Other references ==
* [https://bitcointalk.org/index.php?topic=91843.0 P2PTradeX: P2P Trading between cryptocurrencies]
* [https://bitcointalk.org/index.php?topic=193281.0 Alt chains and atomic transfers]

Full node

2016-02-11T04:29:14Z

Mmortal03:

Any computer that connects to the Bitcoin [[network]] is called a '''node'''. Nodes that fully enforce all of the rules of Bitcoin are called '''full nodes'''. Most nodes on the network are [[lightweight node]]s instead of full nodes, but full nodes form the backbone of the network.

==What makes a full node?==

Full nodes download every block and transaction and check them against Bitcoin's core consensus rules. Here are examples of consensus rules, though there are many more:
* Blocks may only create a certain number of bitcoins. (Currently 25 BTC per block.)
* Transactions must have correct signatures for the bitcoins being spent.
* Transactions/blocks must be in the correct data format.
* Within a single [[block chain]], a transaction output cannot be double-spent.

If a transaction or block violates the consensus rules, then it is absolutely rejected, even if every other node on the network thinks that it is valid. This is one of the most important characteristics of full nodes: they do what's right ''no matter what''. For full nodes, miners actually have fairly limited power: they can only reorder or remove transactions, and only by expending a lot of computing power. A powerful miner is able to execute [[Weaknesses#Attacker_has_a_lot_of_computing_power|some serious attacks]], but because full nodes rely on miners only for a few things, miners could not completely change or destroy Bitcoin.

Nodes that have different ''consensus'' rules are actually using two different networks/currencies. Changing any of the consensus rules requires a [[hard fork]], which can be thought of as creating a new currency and having everyone move to it. Consensus rules are different from ''policy'' rules, which specify how a node or miner prioritizes or discourages certain things. Policy rules can be changed freely, and different nodes can have different policy rules. Because all full nodes must use ''exactly'' the same consensus rules in order to remain compatible with each other, even duplicating bugs and oddities in the original consensus rules, creating a full node from scratch is extremely difficult and dangerous. It is therefore recommended that everyone who wishes to run a full node use software based on the [[reference client]], which is the only client guaranteed to behave correctly.

At minimum, a full node must download every transaction that has ever taken place, all new transactions, and all block headers and Merkle trees. Additionally, full nodes must store information about every unspent transaction output until it is spent. Modern-day full nodes are inefficient in that they download each new transaction at least twice, and they store the entire block chain (>30 GB) forever, even though only the unspent transaction outputs (<1 GB) are required.

== Why should you run a full node? ==

==== Summary ====
Running a full node is the only way you can use Bitcoin in a trustless way. You will know for sure that all the rules of Bitcoin are being followed, for example that no bitcoins are spent not belonging to the owner, that no coins were spent twice, that no inflation happens outside of the [[Controlled_supply|schedule]] and that all the rules needed to make the system work (e.g. [[difficulty]]) are followed. Full nodes are currently the most [[Privacy|private]] way to use Bitcoin, with no nobody else learning which bitcoin [[Address|addresses]] belong to you. Full nodes are the most secure way to use Bitcoin, they do not suffer from many attacks that affect lightweight wallets.

=== Economic strength ===

This is by far the most important reason for running a full node, though it is a little difficult to understand.

As explained previously, full nodes enforce the consensus rules no matter what. However, lightweight nodes do not do this. Lightweight nodes do whatever the majority of mining power says. Therefore, if most of the miners got together to increase their block reward, for example, lightweight nodes would blindly go along with it. If this ever happened, the network would split such that lightweight nodes and full nodes would end up on separate networks, using separate currencies. People using lightweight nodes would be unable to transact with people using full nodes. If all businesses and many users are using full nodes, then this network split is not a ''critical'' problem because users of lightweight clients will quickly notice that they can't send or receive bitcoins to/from most of the people who they usually do business with, and so they'll stop using Bitcoin until the evil miners are overcome, which is the appropriate response. ''However'', if almost everyone on the network is using lightweight nodes in this situation, then everyone would continue being able to transact with each other, and so Bitcoin could very well end up "hijacked" by evil miners.

In practice, miners are unlikely to attempt anything like the above scenario as long as full nodes are prevalent because the miners would lose a lot of money. But the incentives completely change if everyone uses lightweight nodes. In that case, miners definitely ''do'' have an incentive to change Bitcoin's rules in their favor. It is only reasonably secure to use a lightweight node ''because'' most of the Bitcoin economy uses full nodes.

Therefore, it is critical for Bitcoin's survival that the great majority of the Bitcoin economy be backed by full nodes, not lightweight nodes. This is especially important for Bitcoin businesses, which have more economic weight. To contribute to Bitcoin's economic strength, you must actually use a full node for your real transactions (or use a lightweight node connected to a full node that you personally control). Just running a full node on a server somewhere does not contribute to Bitcoin's economic strength.

More details https://www.reddit.com/r/BitcoinBeginners/comments/3eq3y7/full_node_question/ctk4lnd

=== Network services ===

Full nodes may provide various services to other network participants (if the software is run with -listen=1 as is default). This is especially important for lightweight nodes.

These services include:
* Filtering transactions and blocks on behalf of lightweight nodes so that lightweight nodes do not need to download every transaction ever made on the network in order to find their own transactions.
* Serving historical full blocks to nodes that have been offline for a while.
* Transmitting new transactions from users to miners.
* Broadcasting new blocks from miners to other nodes.

For the most part, these services are only usefully performed by full nodes that are listening on port 8333. Other full nodes and all lightweight nodes are actually a slight drain on the network's resources in this respect. The more full nodes that accept incoming connections there are, the more users the Bitcoin network can support.

=== Privacy ===

Having the blockchain stored on your hard drive is the most private way to have a wallet. All other lightweight solutions leak information about which addresses are yours because they must query third-party servers. The Electrum servers will know which addresses belong to you and can link them together. Despite bloom filtering, SPV nodes based on BitcoinJ do not provide much privacy against nodes who connected directly to the wallet <ref>[https://jonasnick.github.io/blog/2015/02/12/privacy-in-bitcoinj/ Privacy in BitcoinJ ]</ref>.

For many use cases, such privacy may not be required. But an important reason to run a full node and use it as a wallet is to get the full privacy benefits.

=== Security ===

Lightweight nodes are sometimes able to be temporarily tricked into accepting transactions or blocks that are not actually valid. This could cause serious financial damage, especially for websites that automatically process Bitcoin transactions. Full nodes provide the maximum security possible, and so they should be used by all businesses, and also by regular users whenever doing so is convenient.

=== Some are incentivizing it ===
Bitnodes is incentivizing full node operators "until the end of 2015 or until 10,000 nodes are running."<ref>[https://bitcoinmagazine.com/19620/bitnodes-project-issues-first-incentives-node-operators/ Bitnodes Project Issues First Incentives For Node Operators by Joel Dalas] of [http://bitcoinmagazine.com/ Bitcoin Magazine]; cf. https://blog.bitcoinfoundation.org/bitnodes-project-2015-q1-report-peer-index-and-incentivized-full-nodes/</ref> For rules and how to join the incentives program, visit [https://getaddr.bitnodes.io/nodes/incentive/ Bitnodes Incentive Program].

== How to run a full node ==

If you run the [[Bitcoin Core]]/[[bitcoind]] wallet, you are running a full node. If you open port 8333, you will contribute to the network's capacity. If you actually use the wallet feature, or if you use a lightweight client like [[MultiBit]] but configure it to connect exclusively to your full node, then you will contribute to the network's economic strength and receive protection from some possible attacks against lightweight nodes.

There are a few alternate full node implementations, but they are not recommended for serious use because it is currently difficult to determine whether they implement the consensus rules with 100% accuracy. Even very slight inaccuracies could cause serious problems for the users of these alternate clients.

==References==
<references />

[[Category:Technical]]

{{Bitcoin Core documentation}}

Meetups

2016-01-27T14:57:32Z

Mmortal03:

Don't add everyone who's going in the "Who?" column, just prominent Bitcoin members and organizers. Also see [http://bitcoin.meetup.com bitcoin.meetup.com]. Also see [[Conferences]].

Keep an eye on the [http://bitcointalk.org/index.php?board=86.0 Meetups] forum board on BitcoinTalk for announcements.

{| class="wikitable"
|-
! Group
! When?
! Where?
! Who?
! Other Notes
|-
| [http://www.meetup.com/Bitcoin-in-San-Diego/ Bitcoin in San Diego]
| Bi-Monthly meetups, weekly workshops
| San Diego, CA, United States
| Local and international participants - guest speakers welcome.
| Presentations and workshops, discussion & trade.
|-
| [http://www.meetup.com/Tucson-Bitcoin-Marketplace/ Bitcoin in Tucson]
| short-notice meetups
| Tucson, AZ, United States
| everyone welcome
| breakfast, Bitcoin basics, presentations, cryptocurrencies, blockchains, and economics
|-
| [http://www.meetup.com/blockchaintech/ Blockchain Tech in Phoenix]
| regular and short-notice meetups
| Phoenix, AZ, United States
| everyone welcome
| hack-a-thons and anything directly or indirectly related to blockchain technology!
|-
| [http://bitcoinembassy.ca Bitcoin Embassy]
| Monthly meetups, weekly workshops
| Montreal, QC, Canada
| Local and international participants - guest speakers welcome. Come and visit our hackerspace, startup incubator and soon, Bitcoin store.
| Presentations and workshops, discussion & trade. [http://eepurl.com/GRzAf Register to our mailing list] to receive event invitations. We also post on [https://bitcointalk.org/index.php?board=86.0 BitcoinTalk Meetups], [http://bitcoinembassy.eventbrite.ca/ EventBrite], [https://www.facebook.com/bitcoinembassy Facebook Bitcoin Embassy page], [https://plus.google.com/u/0/100266464273886488866 Google +], etc.
|-
|-
| [http://www.meetup.com/San-Antonio-Bitcoin/ San Antonio Meetup]
| Every Thursday at 7:00 PM
| San Antonio, Texas
Currently at [https://www.google.com/maps/place/17711+Interstate+10+Frontage+Rd,+The+Rim,+San+Antonio,+TX+78257/@29.609714,-98.59871,17z/data=!3m1!4b1!4m2!3m1!1s0x865c6423ecd5d047:0xaa94c89b14a98fc0 Tiago's]
| Miners, entrepreneurs, traders and anyone looking to learn more about Bitcoin and other Cryptocurrencies are welcome.
| [https://bitcointalk.org/index.php?topic=727155.0 Bitcointalk thread]
|-
|-
| [http://www.meetup.com/BitcoinCT/ BitcoinCT Meetup]
| Monthly Meetups
| Stamford, CT
| The Connecticut Bitcoin Meetup brings together Bitcoin users in Connecticut. This meetup is suitable for everyone from Bitcoin newbies to experienced Bitcoiners. You can attend meetups simply to learn more about Bitcoin or to make business connections for entrepreneurs, miners and developers. | We welcome everyone to our meetups even if you're not currently a Bitcoin user, but simply want to find out more about this amazing e-currency.
|-
|-
| [https://bitcash.cz/forum/ Bitcash.cz]
| Ocasionally
| Prague, Brno, Ostrava
| Meetup for Czech and Slovak bitcoin pioneers.
| Discuss and trade with Bitcoin. Events posted also on our [https://www.facebook.com/Bitcash.cz Facebook] profile.
|-
|-
| [http://www.meetup.com/Sydney-Bitcoin-Users-Group/ BitcoinSYD]
| Every Wednesday @ 1800
| [https://goo.gl/maps/okdSm The SG], Downstairs, 32 York St. Look for the guy in the Red Cap.
| Local, National and International peeps looking to Talk and Trade Bitcoin
| We also post our meetups on Reddit and [https://www.facebook.com/pages/Bitcoin-Sydney-Australia/457681220943285 Facebook]
|-
|-
| [https://bitcointalk.org/index.php?topic=27191.0;all Bitcoin Stammtisch]
| each first Thursday of the month
| [http://www.room77.de/ Room 77], Gräfestr. 77, Berlin-Kreuzberg
| Anyone interested in Bitcoin: technically, economically, socially or philosophically.
| If questions contact andreas(at)schildbach.de (founder).
|-
|-
| [http://www.meetup.com/Nashville-Bitcoin-Meetup/ Nashville Bitcoin Meetup]
| weekly and quarterly
| Nashville, TN
| Plenty of room for all!
|
|-
| [http://www.meetup.com/bitcoins/ Bitcoin NYC]
| monthly
| [http://www.xcubicle.com/ xCubicle Hackerspace - New York, NY]
| Any and all Bitcoin aficionados.
|
|-
|-
| [https://en.bitcoin.it/wiki/Bitcoin_Wednesday Bitcoin Wednesday Amsterdam]
| First Wednesday of the Month
| Dutch Bitcoin Users Group of the Netherlands - The country's longest continuously running Bitcoin event.
| [http://www.meetup.com/BitcoinWednesday/ Sign Up - Amsterdam, The Netherlands]
| Open to anyone interested in Bitcoin. Organized by [https://www.PikaPay.com PikaPay.com] @PikaPay or hello-AT-PikaPay.com
|-
|-
| [http://hitspace.org/ HIT Space - Hack it Together]
| monthly
| [http://hitspace.org/where-we-are/ HIT Space - Porto, Portugal]
| Hackerspace members and anyone who want to join us
| send us an email geral[at]hitspace.org
|-
|-
| [http://bitcoin-austria.at Bitcoin Austria]
| monthly - check the [http://bitcoin-austria.at wiki] or subscribe to the [http://lists.bitcoin-austria.at/listinfo/bitcoin mailinglist]
| [https://metalab.at/wiki/Lage Metalab], Vienna hacker space, Rathausstraße 6, 1010 Wien
| Everybody interested in Bitcoin
|
|-
| [http://brmlab.cz brmlab, prague hackerspace]
| 14th Nov 2011
28th Nov 2011
([http://brmlab.cz/event/bitcoin_seminar])
| [http://brmlab.cz/place Brmlab, Bubenska 1]
| brmlab crew, slush, genjix
|
|-
| [http://www.facebook.com/groups/175596065827848/ Bitcoin Boston]
| Every Friday at 4:30 and bi-weekly on Saturday or Sunday ([http://www.facebook.com/groups/175596065827848/ See Facebook page])
| Starbucks in Kendall Square (Ames St & Broadway) and bi-weekly at Starbucks in Harvard Square
| Anyone is welcome!
| Our bi-weekly meetings have been somewhat sporadic but we aim to gain some regularity.
|-
| [http://www.meetup.com/Milwaukee-Area-Bitcoin-Meetup/ Milwaukee Area Bitcoin Meetup]
| Every other Thursday at 6:00pm
| 17025 West Rogers Drive, New Berlin WI
| Open to anyone interested in Bitcoin
| [https://www.facebook.com/groups/BTCMKE Milwaukee Area Bitcoin Meetup Facebook]
|-
| [http://www.meetup.com/bitcoin New York Bitcoin Users]
| 6:00 PM, 3rd Sunday of every month ([http://www.meetup.com/bitcoin/events/past past meetings])
| OnlyOneTV Studios - 290 Fifth Ave New York, NY
| Bruce Wagner (Organizer) and others
|
|-
|-
| [http://www.meetup.com/bitcoin New York Bitcoin Users]
| 6:00 PM, every Wednesday of every month ([http://www.meetup.com/bitcoin/events/past past meetings])
| Just Sweet Dessert House - 83 Third Ave New York, NY
| Yifu Guo (Organizer) and crew
| hosted by Bitsyncom, the people behind [[Bitnavigator]], walk-ins welcome;
|-
|[http://www.meetup.com/MichiganBitcoinMeetup Michigan Bitcoin Meetup]
|
|
|Kinnard Hockenhull (Organizer)
|Sponsored by [[BitBox]]
|-
| [http://www.meetup.com/PhillyBitcoin Philadelphia Bitcoin User Group]
| TBD
| TBD
| Brian Cohen (Organizer) and others
|
|-
| [http://www.meetup.com/BitcoinDC Washington, DC Bitcoin Users]
| 7:00 PM, 1st Monday of every month ([http://www.meetup.com/BitcoinDC/#past past meetings])
| Northside Social, 3211 Wilson Blvd Arlington, VA
| [[User:Dduane|Darrell Duane]] (Organizer) and others
|
|-
| [http://www.meetup.com/Silicon-Valley-Bitcoin-Users Silicon Valley Bitcoin Users]
| 7:00 PM, Tuesday, June 14, 2011 ([http://www.meetup.com/Silicon-Valley-Bitcoin-Users/events/past past meetings])
| 140B S Whisman Road Mountain View, CA
| Brian Mcqueen and others
|
|-
| [http://www.meetup.com/BitcoinChicago Chicago]
| No regular schedule yet ([http://www.meetup.com/BitcoinChicago/events/past past meetings])
| Sunnyvale Art Gallery Cafe, 251 W El Camino Real Sunnyvale, CA
| Igor
|
|-
| [http://www.meetup.com/denver-bitcoin Denver]
| First meeting June 4th, 2011 ([http://www.meetup.com/denver-bitcoin/events/past past meetings])
| Gypsy House Cafe - 1279 Marion St Denver, CO
| bearbones
|
|-
| [http://www.meetup.com/SF-Bitcoin-Devs/ SF Bitcoin Devs]
| About twice a month ([http://www.meetup.com/SF-Bitcoin-Devs/#past past meetings])
| San Francisco, CA
|
| This meetup has a strong technical/engineering focus ([https://www.youtube.com/channel/UCREs0ConyCR2sEFf-DrLRMw see videos of past presentations])
|-
| [http://www.meetup.com/San-Francisco-Bitcoin-Social/ San Francisco Bitcoin Social]
| Every second Thursday and last Tuesday of the month ([http://www.meetup.com/San-Francisco-Bitcoin-Social/#past past meetings])
| San Francisco, CA
|
| More general (less technical) meetup for cryptocurrency aficionados
|-
| [http://www.meetup.com/Los-Angeles-Digital-Currency-Innovators-Group Los Angeles Digital Currency Innovators]
| Thursday July 7th, 2011, 7 PM
| (mt)/Media Temple, Culver City, CA
| [[User:sgornick|Stephen Gornick]] (Interim organizer) and others
| Seeking meetup coordinator
|-
| [http://CryptoParty.vegas/ Las Vegas Crypto Party]
| 1st Thursday 7pm. [http://BitcoinsInVegas.com Weekly Wednesday lunch mobs]
| CoinBus.com, 64 N Pecos, Henderson, NV 89052
| Julian Tosh / Tuxavant
|
|-
| [https://www.facebook.com/groups/195492163844669/ Free State Bitcoin Consortium]
| Every Saturday, at 6:30 PM
| Strange Brew Tavern, Manchester, NH
| ben-abuya (organizer)
| Weekly
|-
| [https://www.facebook.com/groups/195492163844669/ Twin Cities Users]
| Friday, June 10, 2011, 6:30 PM
| Joule - 1200 Washington Ave S Minneapolis, MN
| Mac Manson
|
|-
| [http://www.meetup.com/Portland-Bitcoin-Meetup-Users Portland Bitcoin Users Meetup Group]
| forming
|
| Steven Wagner
|
|-
| [http://www.meetup.com/Bitcoin-of-South-Florida/ Bitcoin of South Florida] and [http://www.meetup.com/Miami-International-Bitcoin-Group/ Miami International Bitcoin]
| Rotated weekly
| Miami, Ft. Lauderdale, and Boca Raton, FL
| All party people are welcome
|-
| [http://www.meetup.com/Bitcoin-Orlando Bitcoin Orlando]
| ([http://www.meetup.com/Bitcoin-Orlando#past past meetings])
| Frank & Steins 150 S. Magnolia Ave, Orlando, FL
| Antonio Gallippi
|
|-
| [http://www.meetup.com/Bitcoin-Enthusiasts/ Bitcoin Tampa]
| Monthly meetings
| Matt Branton -- [https://www.coinlock.com/ Coinlock.com] founder
|
|-
| [http://www.hive13.org/?p=310 Hive13 Hackerspace]
| Bitcoin Exchange, Every Tuesday, 7:30 PM
| Hive13 - 2929 Spring Grove Avenue, Cincinnati, OH
|
|
|-
| [https://www.facebook.com/bitcoinaus Bitcoin Australia]: Melbourne
| [https://www.facebook.com/events/345430765511234/ Wednesday, 23 May 2012, 18:45]
| Melbourne CBD(TBA)
| Facebook, IRC, Bitcointalk Forum...
|
|-
| [[Bitcoin Wiki:Tokyo meetup|Tokyo]]
| Every Thursday
| Shibuya, Roppongi
| Roger Ver (Organizer) and others
| Locations change, check the meetup page
|-
| [http://meetup.com/Bitcoin-Canada Vancouver Canada]
| ([http://www.meetup.com/Bitcoin-Canada/#past past meetings])
| The Brickhouse - 730 Main St.
| humble (and others)
|
|-
| [https://plus.google.com/u/0/communities/113055238568417913658 Zurich / Geneva Switzerland]
| Twice a month
| Kennedy's Irish Pub, Zurich; Lord Nelson Pub, Geneva
| Stefan Thomas (WeUseCoins), Mike Hearn (BitcoinJ), bitdragon, Luzius (Wuala), more ...
|
|-
| Seattle Bitcoin Meetup
| [http://www.meetup.com/SeattleBitCoin/ Semi-regularly].
| [http://maps.google.com/maps?q=cafe+solstice&daddr=4116+University+Way,+Seattle,+WA+98105-6214&hl=en&ll=47.657424,-122.31313&spn=0.007328,0.01929&gl=us&view=map&geocode=CRT9Bdg7zX3vFdcx1wIdWqa1-CFcJ9qrr9CcEQ&t=h&z=16 Solstice Cafe, 2pm]
| [https://bitcointalk.org/index.php?action=profile;u=36217 indolering]
|
|-
| [https://bitcointalk.org/index.php?topic=135723.0 Munich Germany]
| First wednesday of the month, 6:00PM
| [http://www.openstreetmap.org/?minlon=11.5800867080688&minlat=48.1336479187012&maxlon=11.5804319381714&maxlat=48.1338386535645 Nero Pizza], Rumfordstrasse 34, 80469 München
| Bitcoin-users from Munich and around
| [http://www.meetup.com/Bitcoin-Munchen/ @meetup.com]
|-
| [http://www.meetup.com/bitcoin-il/ Israel Bitcoin Meetup Group]
| Occasional
| TBD
| Meni Rosenfeld
|
|-
| [http://www.meetup.com/Dallas-Bitcoin-User-Meetup/ Dallas Bitcoin Meetup Group]
| Biweekly on Saturdays, 6:00PM
| [http://freemandallas.com/ The Free Man Cajun Cafe]
| Justus Ranvier (organizer)
|
|-
| [https://en.bitcoin.it/wiki/Cafe Café Bitcoin Sevilla]
|
| Seville, Spain
| Randy Brito (rdymac / btcven), Eduardo (bitcoin.com.es), Jorge and Alfredo
| http://cafebitcoin.com
|-
| [http://www.meetup.com/BitcoinSingapore/ Bitcoin Singapore Meetup]
|
| Singapore
| Monthly
| [https://www.facebook.com/pages/Bitcoin-Singapore/431452580303555 Bitcoin Singapore Facebook Page]
|-
| [http://www.meetup.com/Lehigh-Valley-Bitcoin-Meetup/ Lehigh Valley (Allentown/Bethlehem PA) Bitcoin]
|
| Westgate Subway; Schoenersville Rd; Bethlehem
| Jim Hoff (organizer)
| http://www.meetup.com/Lehigh-Valley-Bitcoin-Meetup/
|-
| [http://www.meetup.com/LetsUseBitcoin/ Lets Use Bitcoin]
| Monthly
| The Netherlands
| Local and international participants
| Using Bitcoin and having fun! Sponsored by [[Blocktrail]]
|-
| [http://www.meetup.com/Arnhem-Bitcoin-Users Arnhem Bitcoin Users]
| Monthly
| Arnhem Bitcoincity (the Netherlands)
| Beginners and experts
| Spend some time (and bitcoins) in the most Bitcoin-friendly city!
|-
|}

==See Also==

* [http://hackerspaces.org/wiki/List_of_Hacker_Spaces List of Hacker Spaces]
* [http://bitimap.net Bitimap.net - Find local meetups (up-to-date)]

[[Category:Local]]
[[Category:Meetups]]

[[de:Treffen]]

Hardware wallet

2014-09-10T10:58:24Z

Mmortal03: Piper wallet URL changed

A '''hardware wallet''' is a device that stores a part of a user's [[wallet]] securely in mostly-offline hardware. They have major advantages over other wallet types:

* the key is often stored in a protected area of a microcontroller, and cannot be transferred out of the device in plaintext
* immune to computer viruses that steal from software wallets
* can be used securely and interactively, as opposed to a [[paper wallet]] which must be imported to software at some point
* much of the time, the software is open source, allowing a user to validate the entire operation of the device

This page is an attempt to summarize all the known developments of hardware wallets that can use Bitcoin as part of their operation.

== Purchasable hardware wallets ==

=== Piper - Standalone bitcoin paper wallet printer ===
[http://cryptographi.com/ Cryptographi.com]
[[File:piper.jpg|300px|thumb|left|Piper wallet from the front]]
Piper is the easiest way to store bitcoin and other cryptocurrencies securely.

* Easy: Simply press the button to print a new paper wallet. You can choose to have Piper store your keys. Backup is as easy as plugging in a USB drive.
* Secure: Paper wallets are the most secure way to store your Bitcoin. Piper is the only offline wallet to pass all 26 Dieharder tests to ensure secure private key generation.
* Customizable: Plug in a display, mouse, and keyboard and customize Piper to do whatever you want. It's Linux-based, open source, and powered by the Raspberry Pi. You can even use your own printer!

 

=== [[TREZOR]] The Bitcoin Safe ===
[http://bitcointrezor.com BitcoinTrezor.com]

[[File:Trezor-tx.jpg|300px|thumb|left|Confirming the transaction with TREZOR]]

[[TREZOR]] is a secure bitcoin storage and a transaction signing tool. The private keys are generated by the device and never leave it thus they cannot be accessed by a malware.

It uses a deterministic wallet structure which means it can hold an unlimited number of keys (BIP32/BIP44). A recovery seed is generated when the device is initialized. In case TREZOR gets lost or stolen, all its contents can be recovered using this seed (private keys, bitcoin balance and transaction history) into a new device or another BIP39/BIP44 compatible wallet.

TREZOR also introduced a unique way of PIN entering preventing keyloggers from recording it even when entered on a compromised computer. An encryption passphrase can be set on top of the PIN protection. More passphrases can be used for plausible deniability.

[http://BuyTrezor.com E-shop BuyTrezor.com] | [http://doc.satoshilabs.com/ TREZOR Documentation]

 

=== Pi Wallet - cold storage ===
[[File:Piwallet.jpeg|300px|thumb|left|Pi-Wallet]]
[http://www.pi-wallet.com/ Pi-Wallet Shop]

[http://www.pi-wallet.com/pages/what-is-pi-wallet Further informations about Pi-Wallet]

The Pi-Wallet is comparable to an offline Notebook.

However it combines all features of the Armory bitcoin client (e.g. offline transaction signing) with the advantages of a tiny computer.

To sign offline-transaction you will need an (unused) USB stick.

 

=== BTChip HW.1 - USB Smartcard Hardware Wallet ===
[https://www.hardwarewallet.com HW.1 Home Page]

[[File:Btchip_dongle.jpg|220px|thumb|left|HW.1 inserted in a laptop]]

HW.1 is an implementation of a deterministic (BIP 32) Hardware Wallet on a USB smartcard.

It is typically used as a blind secure device for multi signature transactions - holding a set of derived private keys and signing transactions without requiring user confirmation.

Power users can rely on it to confirm all transactions with a second factor scheme turning the dongle into a keyboard typing what the user is supposed to have signed, as a protection against malware.

It is also possible to customize HW.1 for more specfic needs, such as creating a prepaid card without revealing the deterministic seed before it is received by the user, or securing bitcoin transactions on a server.

[https://buy.hardwarewallet.com E-shop] | [https://btchip.github.io/btchip-doc/bitcoin-technical.html Technical Documentation]

 

== Not purchasable hardware wallets ==

=== BitcoinCard Megion Technologies-Card based wallet ===
[[File:Bitcoincard-medley-large.jpg|400px|thumb|left|Bitcoin Card]]
[http://www.bitcoincard.org/ Bitcoincard Home Page]

[http://blog.bitinstant.com/blog/2012/6/19/our-discovery-in-vienna-the-bitcoin-card.html Excellent review by evoorhees]

Incorporates a e-paper display, keypad, and radio (custom ISM band protocol.) Unfortunately it is fairly limited in terms of transaction I/O, requiring a radio gateway or another bitcoincard wherever funds need to be transferred.

 

=== BitSafe - allten/someone42's hardware wallet ===
[[File:Bitsafe-wallet-sizecompare.jpg|200px|thumb|left|Bitsafe wallet]]
[https://bitcointalk.org/index.php?topic=127587.0 BitSafe Hardware Wallet Development - BOM Ready - 50 kits being prepared]

Signing transactions only, requires USB host software for transactions & USB power. Has a OLED display and Confirm/Cancel buttons. Evolved out of someone42's prototype below, and has significant contributions from someone42 as well.
 
=== someone42's original prototype ===
[[File:Someone42-wallet-prototype.jpg|300px|thumb|left|someone42's original prototype]]
[https://bitcointalk.org/index.php?topic=78614.0 Hardware Bitcoin wallet - a minimal Bitcoin wallet for embedded devices]

Signing transactions only, requires USB host software for transactions & USB power. All work is rolled into the above BitSafe wallet currently.
 
=== Other/Defunct but with good discussion: ===
* natman3400's BitClip Jun 2011 [https://bitcointalk.org/index.php?topic=24852.0 https://bitcointalk.org/index.php?topic=24852.0]
:Seems to have gone defunct around Dec 2011. Some good ideas though and seemed to have started on execution.
* jim618 hardware wallet proposal Apr 2012 [https://bitcointalk.org/index.php?topic=77553.0 Dedicated bitcoin devices - dealing with untrusted networks]
:Great discussion and good ideas from jim618. Also linked the following video:
* Prof. Clemens Cap's hardware wallet? (video:)[https://www.youtube.com/watch?v=IavQ-Wc8S1U Clemens Cap about electronic bitcoin wallet at EuroBit]
:Clemens Cap of Uni Rostock explains the Electronic Bitcoin wallet device he's working on. It's based on adafruit microtouch device.
* ripper234's discussion based on Yubikeys Aug 2012 [https://bitcointalk.org/index.php?topic=99492 Having a YUBIKEY as one of the parties for m-of-n signatures]
:The use of Yubikeys. They only support symmetric crypto, so you'd have to trust the host device.
* kalleguld's hardware wallet proposal Oct 2012 [https://bitcointalk.org/index.php?topic=115294.0 Proposal: Hardware wallet (Win 3 BTC)]
* Vaporware: Matthew N Wright's ellet [https://bitcointalk.org/index.php?topic=85931.0 ANN The world's first handheld Bitcoin device, the Ellet!] (Vaporware)

== Smart Card based wallets ==
This type of device requires complete trust in the host device, as there is no method for user input.
See [[Smart card wallet]]

== Related Resources ==
* slush's Hardware wallet wire protocol discussion: [https://bitcointalk.org/index.php?topic=125383.0 Hardware wallet wire protocol]
* kjj's Todo List discussion for client protocol requirements: [https://bitcointalk.org/index.php?topic=19080.msg272348#msg272348 in topic Re: Split private keys]
* paybitcoin's original post: [https://bitcointalk.org/index.php?topic=134277.0 Hardware Wallet Roundup]
* [https://bitcointalk.org/index.php?topic=135090.0 This thread] about editing this very wiki entry.
* Various Hardware Wallets and Reviews: [http://www.offlinewallets.com/hardware-wallets Offline Hardware Wallets]

[[Category:Security]]
[[Category:Wallets]]
[[Category:Hardware]]

Base58Check encoding

2014-08-24T07:26:20Z

Mmortal03: /* Encoding a private key */

A modified Base 58 [http://en.wikipedia.org/wiki/Binary-to-text_encoding binary-to-text encoding] known as '''Base58Check''' is used for encoding [[Bitcoin address|Bitcoin addresses]].

More generically, Base58Check encoding is used for encoding byte arrays in Bitcoin into human-typable strings.

==Background==
The original Bitcoin client source code explains the reasoning behind base58 encoding:

base58.h:
// Why base-58 instead of standard base-64 encoding?
// - Don't want 0OIl characters that look the same in some fonts and
// could be used to create visually identical looking account numbers.
// - A string with non-alphanumeric characters is not as easily accepted as an account number.
// - E-mail usually won't line-break if there's no punctuation to break at.
// - Doubleclicking selects the whole number as one word if it's all alphanumeric.

==Features of Base58Check==
Base58Check has the following features:
* An arbitrarily sized payload.
* A set of 58 alphanumeric symbols consisting of easily distinguished uppercase and lowercase letters (0OIl are not used)
* One byte of version/application information. Bitcoin addresses use 0x00 for this byte (future ones may use 0x05).
* Four bytes (32 bits) of SHA256-based error checking code. This code can be used to automatically detect and possibly correct typographical errors.
* An extra step for preservation of leading zeroes in the data.

==Creating a Base58Check string==
A Base58Check string is created from a version/application byte and payload as follows.
# Take the version byte and payload bytes, and concatenate them together (bytewise).
# Take the first four bytes of SHA256(SHA256(results of step 1))
# Concatenate the results of step 1 and the results of step 2 together (bytewise).
# Treating the results of step 3 - a series of bytes - as a single big-endian bignumber, convert to base-58 using normal mathematical steps (bignumber division) and the base-58 alphabet described below. The result should be normalized to not have any leading base-58 zeroes (character '1').
# The leading character '1', which has a value of zero in base58, is reserved for representing an entire leading zero '''byte''', as when it is in a leading position, has no value as a base-58 symbol. There can be one or more leading '1's when necessary to represent one or more leading zero bytes. Count the number of leading zero bytes that were the result of step 3 (for old Bitcoin addresses, there will always be at least one for the version/application byte; for new addresses, there will never be any). Each leading zero byte shall be represented by its own character '1' in the final result.
# Concatenate the 1's from step 5 with the results of step 4. '''This is the Base58Check result.'''

==Encoding a Bitcoin address==
Bitcoin addresses are implemented using the Base58Check encoding of the hash of either:
* Pay-to-script-hash (p2sh): payload is [[RIPEMD160]]([[SHA256]](redeemScript the wallet knows how to spend)); version 0x05 (these addresses begin with the digit '3')
* Pay-to-pubkey-hash (p2pkh): payload is [[RIPEMD160]]([[SHA256]](ECDSA public key the wallet knows the private key for)); version 0x00 (these addresses begin with the digit '1')

The resulting hash in both of these cases is always exactly 20 bytes.
These are big-endian (most significant byte first). (Beware of [[bignumber]] implementations that clip leading 0x00 bytes, or prepend extra 0x00 bytes to indicate sign - your code must handle these cases properly or else you may generate valid-looking addresses which can be sent to, but cannot be spent from - which would lead to the permanent loss of coins.)

==Encoding a private key==
Base58Check encoding is also used for encoding [[private key|ECDSA private keys]] in the [[wallet import format]].
This is formed exactly the same as a Bitcoin address, except that 0x80 is used for the version/application byte, and the payload is 32 bytes instead of 20 (a private key in Bitcoin is a single 32-byte unsigned big-endian integer).
For private keys associated with an uncompressed public key, such encodings will always yield a 51-character string that starts with '5', or more specifically, either '5H', '5J', or '5K'.

==Base58 symbol chart==
The Base58 symbol chart used in Bitcoin is specific to the Bitcoin project and is not intended to be the same as any other Base58 implementation used outside the context of Bitcoin.
{| class="wikitable"
|-
!Value
!Character
!Value
!Character
!Value
!Character
!Value
!Character
|-
|0
|1
|1
|2
|2
|3
|3
|4
|-
|4
|5
|5
|6
|6
|7
|7
|8
|-
|8
|9
|9
|A
|10
|B
|11
|C
|-
|12
|D
|13
|E
|14
|F
|15
|G
|-
|16
|H
|17
|J
|18
|K
|19
|L
|-
|20
|M
|21
|N
|22
|P
|23
|Q
|-
|24
|R
|25
|S
|26
|T
|27
|U
|-
|28
|V
|29
|W
|30
|X
|31
|Y
|-
|32
|Z
|33
|a
|34
|b
|35
|c
|-
|36
|d
|37
|e
|38
|f
|39
|g
|-
|40
|h
|41
|i
|42
|j
|43
|k
|-
|44
|m
|45
|n
|46
|o
|47
|p
|-
|48
|q
|49
|r
|50
|s
|51
|t
|-
|52
|u
|53
|v
|54
|w
|55
|x
|-
|56
|y
|57
|z
|}

The algorithm for encoding address_byte_string (consisting of 1-byte_version + hash_or_other_data + 4-byte_check_code) is

code_string = "123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz"
x = convert_bytes_to_big_integer(hash_result)

output_string = ""

while(x > 0)
{
(x, remainder) = divide(x, 58)
output_string.append(code_string[remainder])
}

repeat(number_of_leading_zero_bytes_in_hash)
{
output_string.append(code_string[0]);
}

output_string.reverse();

==Version bytes==
Here are some common version bytes:

{| class="wikitable"
|-
!Decimal version
!Leading symbol
!Use
|-
|0
|1
|Bitcoin pubkey hash
|-
|5
|3
|Bitcoin script hash
|-
|21
|4
|Bitcoin (compact) public key (proposed)
|-
|52
|M or N
|Namecoin pubkey hash
|-
|128
|5
|Private key
|-
|111
|m or n
|Bitcoin testnet pubkey hash
|-
|196
|2
|Bitcoin testnet script hash
|}
[[List of address prefixes]] is a more complete list.

== Source code ==
* [https://github.com/bitcoin/bitcoin/blob/master/src/base58.h "Satoshi" C++ codebase (encode/decode using BigNum library)]
* [https://github.com/luke-jr/libbase58 libbase58 C code (decode and encode, no external libraries needed)]
* [https://gitorious.org/bitcoin/libblkmaker/blobs/master/base58.c libblkmaker C code (decode only, no external libraries needed)]

[[Category:Technical]]

[[es:Codificación Base58Check]]