Bitcoin Wiki - User contributions [en]

User:Gmaxwell/derandomized nonce notes

2021-03-08T02:41:18Z

Gmaxwell: /* Shouldn't Bitcoin use ed25519 because it has derandomized nonces? */

==Shouldn't Bitcoin use ed25519 because it has derandomized nonces?==

Nonce generation in all conventional DL signature systems is purely an implementation function. The ed25519 specific had the foresight to specify a specific reasonable nonce generation scheme but unfortunately it's not possible to enforce that any particular scheme is used. As a result people have still managed to create implementations of ed25519 with insecure nonce generation, and worse<ref>some parties have have falsely assumed that the deterministic nonces were mandatory with ed25519 and made the signatures unique resulting in serious vulnerabilities in some cryptocurrencies.</ref>.

RFC6979 specifies a nonce scheme that any DL signature system (such as ECDSA with secp256k1) can use. It's been in common use in Bitcoin since 2015 and is now nearly ubiquitous.

Both standard RFC6979 and the ed25519 scheme have demonstrated some minor weaknesses in the fact of differential power analysis (power/emi side-channels) and as a result the state of the art these days is "synthetic nonces" which combine most of the advantages of de-randomization with by hashing secret values with the message and a counter or random input to make it so a DPA attacker can't get multiple recordings of the same trace.

Both RFC6979 and ed25519 also lack a clear an unambiguous domain separation in their hashing. If you use the same nonce scheme in different protocols (potentially even w/ different curves) you may inadvertently reuse a nonce and compromise your security. This issue can be avoided through the use of tagged hashes and/or synthetic nonces.

Bitcoin's BIP340 learns from ed25519 and incorporates a recommended secure nonce scheme in the BIP to reduce the risk that implementer will get it wrong. The recommended scheme also learns from the limitations of the ed25519 spec by using tagged hashes and supporting (optionally) synthetic nonces.

It isn't technically possible to mandate any particular scheme for any of these cryptosystems, and it's just as well: People have also constructed specialized nonce schemes for BIP340 which achieve other useful properties such as provability eliminating signing devices using the nonce as a cover sidechannel, and also generating nonces in a way which is provably deterministic (using a large additional zero knowledge proof) which is potentially useful in some multiparty protocols.

<references/>

User:Gmaxwell/derandomized nonce notes

2021-03-08T02:38:50Z

Gmaxwell:

==Shouldn't Bitcoin use ed25519 because it has derandomized nonces?==

Nonce generation in all conventional DL signature systems is purely an implementation function. The ed25519 specific had the foresight to specify a specific reasonable nonce generation scheme but unfortunately it's not possible to enforce that any particular scheme is used. As a result people have still managed to create implementations of ed25519 with insecure nonce generation, and worse<ref>some parties have have falsely assumed that the deterministic nonces were mandatory with ed25519 and made the signatures unique resulting in serious vulnerabilities in some cryptocurrencies.</ref>.

RFC6979 specifies a nonce scheme that any DL signature system (such as ECDSA with secp256k1) can use. It's been in common use in Bitcoin since 2015 and is now nearly ubiquitous.

Both standard RFC6979 and the ed25519 scheme have demonstrated some minor weaknesses in the fact of differential power analysis (power/emi sidechannels) and as a result the state of the art these days is "synthetic nonces" which combine most of the advantages of de-randomization with by hashing secret values with the message and a counter or random input to make it so a DPA attacker can't get multiple recordings of the same trace.

Both RFC6979 and ed25519 also lack a clear an unambiguous domain separation in their hashing. If you use the same nonce scheme in different protocols (potentially even w/ different curves) you may inadvertently reuse a nonce and compromise your security. This issue can be avoided through the use of tagged hashes and/or synthetic nonces.

Bitcoin's BIP340 learns from ed25519 and incorporates a recommended secure nonce scheme in the BIP to reduce the risk that implementer will get it wrong. The recommended scheme also learns from its shortcomings by using tagged hashes and supporting (optionally) synthetic nonces.

It isn't technically possible to mandate any particular scheme for any of these cryptosystems, and it's just as well: People have also constructed specialized nonce schemes for BIP340 which achieve other useful properties such as provability eliminating signing devices using the nonce as a cover sidechannel, and also generating nonces in a way which is provably determinstic (using a large additional zero knowedlge proof) which is potentially useful in some multiparty protocols.

<references/>

User:Gmaxwell/derandomized nonce notes

2021-03-08T02:38:12Z

Gmaxwell: Created page with " ==Shouldn't Bitcoin use ed25519 because it has derandomized nonces?== Nonce generation in all conventional DL signature systems is purely an implementation function. The ed..."

==Shouldn't Bitcoin use ed25519 because it has derandomized nonces?==

Nonce generation in all conventional DL signature systems is purely an implementation function. The ed25519 specific had the foresight to specify a specific reasonable nonce generation scheme but unfortunately it's not possible to enforce that any particular scheme is used. As a result people have still managed to create implementations of ed25519 with insecure nonce generation, and worse<ref>some parties have have falsely assumed that the deterministic nonces were mandatory and made the signatures unique resulting in vulnerabilities.</ref>.

RFC6979 specifies a nonce scheme that any DL signature system (such as ECDSA with secp256k1) can use. It's been in common use in Bitcoin since 2015 and is now nearly ubiquitous.

Both standard RFC6979 and the ed25519 scheme have demonstrated some minor weaknesses in the fact of differential power analysis (power/emi sidechannels) and as a result the state of the art these days is "synthetic nonces" which combine most of the advantages of de-randomization with by hashing secret values with the message and a counter or random input to make it so a DPA attacker can't get multiple recordings of the same trace.

Both RFC6979 and ed25519 also lack a clear an unambiguous domain separation in their hashing. If you use the same nonce scheme in different protocols (potentially even w/ different curves) you may inadvertently reuse a nonce and compromise your security. This issue can be avoided through the use of tagged hashes and/or synthetic nonces.

Bitcoin's BIP340 learns from ed25519 and incorporates a recommended secure nonce scheme in the BIP to reduce the risk that implementer will get it wrong. The recommended scheme also learns from its shortcomings by using tagged hashes and supporting (optionally) synthetic nonces.

It isn't technically possible to mandate any particular scheme for any of these cryptosystems, and it's just as well: People have also constructed specialized nonce schemes for BIP340 which achieve other useful properties such as provability eliminating signing devices using the nonce as a cover sidechannel, and also generating nonces in a way which is provably determinstic (using a large additional zero knowedlge proof) which is potentially useful in some multiparty protocols.

<references/>

Softfork wishlist

2021-03-08T02:20:09Z

Gmaxwell: No longer attractive, with optimized implementations and the GLV patent expired

The '''Softfork Wishlist''' is to record changes to Bitcoin that might be desirable, but that will require a [[Softfork|"soft" block-chain split]] (consensus of the miners). These changes are implemented by convincing a majority of the miners to reject or [[Discouraged_block|discourage]] blocks that were previously considered valid. This is often combined with a special form of pay-to-anybody transaction, which is declared to have a new meaning. Old clients will see the new transaction types as a pay-to-anybody, but attempts to "steal" these pay-to-anybody outputs without using the new transaction type will be refused by the miners and all upgraded clients.

This page is ''not'' for changes that require a [[Hardfork|"hard" block-chain split]] (everybody must upgrade, old software will not accept blocks/transactions created with the new [[Protocol rules|rules]], considering them to be [[Invalid block|invalid blocks]]). See [[Hardfork_Wishlist]].

== Block format ==
* Require a [https://en.bitcoin.it/wiki/Thin_Client_Security#Unused_Output_Tree_in_the_Blockchain_.28UOT.29 UTXO tree] in every block

== New Transaction Types ==
* Pay-to-[http://eprint.iacr.org/2013/507.pdf SNARK] (aka [https://bitcointalk.org/index.php?topic=277389.0 CoinWitness]). This allows payment to a user who can produce cryptographic evidence that they ran a certain (time-bounded) program on a certain input argument. The size of the cryptographic evidence is linear in the input argument but constant with respect to the size and running time of the program, so bounding the size of the input argument bounds the size of the data that needs to be put into the blockchain. Unfortunately the time+space constant factors are, with current algorithms, rather large.

== Cryptographic changes==
* Pervasive ECC public key-recovery to reduce transaction sizes (can be done partially without breaking compatibility completely)
* Support for more than one public-key cryptosystem (ECDSA-k1) and key size (256bits) as a hedge against future cryptanalysis or designed-in flaws in any one algorithm. Every node must support validation of signatures with every cryptosystem, but a small number of very-cryptograpically-diverse options is still better than just one. Additional signature types could be kludged into the existing system with script extensions but would be better supported natively.
* Support for a [http://en.wikipedia.org/wiki/Post-quantum_cryptography post-quantum] signature scheme. [http://en.wikipedia.org/wiki/Lamport_signature Lamport signatures] have nice intuitive security properties, but it has extreme space requirements that would require structural changes to the blockchain to accommodate, (e.g. flip-chain+paytoscripthash+extensive pruning). However other post-quantum schemes like [http://en.wikipedia.org/wiki/NTRU IEEE1363.1] (patent expires in 2016) do not. See the [http://pqcrypto.org/www.springer.com/cda/content/document/cda_downloaddocument/9783540887010-c1.pdf introductory chapter of DJB's book] and the [http://pqcrypto.org PQCrypto conference webpage] for full details.

Talk:Scalability

2020-12-29T04:00:44Z

Gmaxwell: /* Removal of the word ripple */

== Response to Dan Kaminskys presentation ==

[http://www.slideshare.net/dakami/bitcoin-8776098 Dans slides] were presented at Blackhat 2011.

=== Response from Mike Hearn (original author) ===

Mike responded [https://bitcointalk.org/index.php?topic=34597.0 in this forum thread].

== Other discussion ==

There is one major point that the page overlooks: the limitation on block
creation.

Block creation is limited to an average of one block every ten minutes.
Furthermore, block size (which includes the transactions in the block) is limited to 1,000,000 bytes.

Each transaction requires 10 bytes, plus approximately 106 bytes for every
input and approximately 69 bytes for every output. The exact size depends
on the size of the public key, which I have not been able to confirm, but
the keys in my wallet.dat seem to be about 65 bytes each.

If we assume that transactions average two inputs and two outputs, then
the average transaction size will be about 350 bytes ''(note that the main page assumes an average of 1KB per transaction)''. If we further assume
that the block size will, in practice, be limited to 500,000 bytes because
the transaction fees increase as the block size increases, then that means
there will be, on average, approximately 1430 transactions per block. That
works out to an average of 2.5 transactions per second - '''well''' below
the stated goal of at least 4,000 transactions per second.

Even if we assume only one input and one output per transaction, and that
each block will contain the full 1,000,000 bytes, that still works out to only 5,405
transactions per block, or 9 transactions per second.

Unfortunately, this is '''not''' a limitation that can be overcome by
simply increasing memory, or switching to a different ISP with more
bandwidth. It is a built-in limitation, designed to '''deliberately'''
slow down block creation. One solution is to somehow allow blocks to be freely created, while still keeping the rate of coin creation constant.

The bottom line is that, ''as it sits'', this system is not scalable.
:MAX_BLOCK_SIZE has always been planned to increase as needed. That limitation should be ignored. [[User:Theymos|theymos]] 17:15, 4 March 2011 (GMT)
:What Theymos said. Increasing MAX_BLOCK_SIZE will be done when "lightweight, header-only" client mode is done. Until then, block size has to be kept under control.--[[User:Gavinandresen|Gavin Andresen]] 00:19, 5 March 2011 (GMT)
:I've updated the page with more discussion of this topic. --[[User:Mike|Mike]] March 5 2011

The thing with VISA or and credit card company is that there wouldn't be that many actual transactions. When I buy stuff with my credit card the vender doesn't get paid instantly. I pay my bill once a month and the vender gets all his transactions lumped into one payment from VISA (once a week, I think). Someone correct me if I'm wrong, but the number of real transfers of money would be much smaller. --[[User:Randomproof|Randomproof]] 17:29, 1 April 2011 (GMT)

Would also be nice to get some kind of an estimate on how much the crypto-operations could be accelerated with a GPU.
[[User:Jojkaart|Jojkaart]] 20:48, 13 June 2011 (GMT)

Shouldn't this (under Opimizations -> Network Structure): "''Switching to DNS would give dramatically faster startup times that do not scale with the size of the network.''" read: "''Switching to DNS would give dramatically faster startup times that do scale with the size of the network.''"? ie Remove the "not".
--[[User:Tokoin|Tokoin]] 09:24, 21 July 2011 (GMT)

== Moore's law ==

I think Moore's law should be mentioned.

Even though now the comparison to Visa produces requirements for processing power, data storage or network capacity appear overwhelming for a casual user, the cost/performance ratio decreases all the time. My calculations based on data from wikipedia projected for 2020:

=== Disk space ===

Wikipedia quotes a research article that estimates that "in 2020 a two-platter, 2.5-inch disk drive will be capable of storing more than 14 terabytes(TB) and will cost about $40". This can hold about 85 days of data (~3 months) at "visa-speed". This is a bit pricey, but within the scope of a normal user, and definitely enough for enthusiasts.

=== Network capacity ===

Wikipedia references articles that estimate the "moore's law" equivalent for network to be 50% increase / year. For 9 years (2011-2020), this makes an increase of approximately 38 times. In order to achieve the speed of 1GB/s, this is the equivalent of someone having 27MB/s at the moment, i.e. 215Mbit/s. I think this exceeds a normal user and most enthusiasts. Assuming a casual user has 2Mbit/s at the moment, he'll scale to "visa-speed" in about 16 years, i.e. 2027.

=== CPU performance ===

Moore's law is approximated as "doubling every 18 months". For 9 years this makes 34 times if I'm calculating right. 50/34 = 1.47 cores. A dual-core computer in 2020 should therefore be sufficient to handle relaying/verifying Bitcoin transactions at visa-speed. I'm ignoring mining. So why someone is proposing that double tx check should be removed from the protocol ? We would surely leave the door open to some nasty attacks if strange transactions or double spends slip into blocks from attacking miners.

=== Summary ===

I only made very rough estimates. Feel free to recalculate with more accurate data. My conclusion is that CPU would be a no-brainer, disk space would be an annoyance, however network speed would indeed appear to be a problem.

== satoshiDICE ==

I believe the implications of [[SatoshiDice]] and similar schemes that stress the network should be mentioned, since as of March 2013, SatoshiDice transactions occupy 80% of the [[block chain]]. --[[User:Alvox|Alvox]] ([[User talk:Alvox|talk]]) 23:09, 29 March 2013 (GMT)

: So mention them? Note that SatoshiDice just abuses the network, not so much merely stressing it.. but clarifications can always be edited in after we have something to start from. --[[User:Luke-jr|Luke-jr]] ([[User talk:Luke-jr|talk]]) 23:28, 29 March 2013 (GMT)

: Is SatoshiDice relevant to scalability? If there is a solution to SatoshiDice spam then we probably should mention it, but I don't know of any solutions that can't be worked around by them --[[User:Lapp0|Lapp0]] ([[User talk:Lapp0|talk]]) 17:50, 20 December 2014 (UTC)

== passively running a full node and other scalability options ==

This page makes no distinction between passively running a full node and actively using 90% of your CPU power, 90% of your bandwidth and a ton of disk space. Clearly if it takes significant effort to run a full node, arguably unlike right now, then the number of full nodes will drop significantly.

I propose collapsing this whole article into one section titled "Increasing the Block size (Hardfork)" and include the problems with hardforking along with the problems of expensive full nodes.

Along with this section there should be other sections on other scalability improvements and their problems including sidechains, opentransactions, and others. --[[User:Lapp0|Lapp0]] ([[User talk:Lapp0|talk]]) 17:47, 20 December 2014 (UTC)

== Removal of the word ripple ==

I originally added the [https://en.bitcoin.it/w/index.php?title=Scalability&action=historysubmit&type=revision&diff=14273&oldid=14112 mention of ripple] back in 2011. At the time that was before OpenCoin (now called Ripple Labs) purchased the ripple name and stuck it on an entirely unrelated centralized system. Instead, what ripple referred to back then was a network of pairwise trust that allowed payments to ripple from person to person very similar to how Lightning actually works except ripple depended on trust while lightning is made cryptographically secure with smart contracting.

When opencoin bought the name and applied it to something different [https://bitcointalk.org/index.php?topic=144471.msg1547843#msg1547843 I protested against the ethics of that move and went through and edited all my comments referring to ripple, where they could be edited], but the text here had been removed by Hearn's edit-warring at the time so it didn't get fixed. I noticed today that Furunodo rightfully added an edit a few months back to indicate that Ripple's decentralization was bullshit-- it was right to change the text, but his change was the wrong one: The text was written long before centralised-bullshit-"ripple" was created in 2013. When it was written it referred to a system which we'd now recognize as a primordial lightning. Had the text been in the article in 2013 I would have fixed it then (and probably said "payment channels"), but it wasn't. I've corrected it now. Cheers. --[[User:Gmaxwell|Gmaxwell]] ([[User talk:Gmaxwell|talk]]) 03:59, 29 December 2020 (UTC)

Talk:Scalability

2020-12-29T03:59:54Z

Gmaxwell: on my most recent edit

== Response to Dan Kaminskys presentation ==

[http://www.slideshare.net/dakami/bitcoin-8776098 Dans slides] were presented at Blackhat 2011.

=== Response from Mike Hearn (original author) ===

Mike responded [https://bitcointalk.org/index.php?topic=34597.0 in this forum thread].

== Other discussion ==

There is one major point that the page overlooks: the limitation on block
creation.

Block creation is limited to an average of one block every ten minutes.
Furthermore, block size (which includes the transactions in the block) is limited to 1,000,000 bytes.

Each transaction requires 10 bytes, plus approximately 106 bytes for every
input and approximately 69 bytes for every output. The exact size depends
on the size of the public key, which I have not been able to confirm, but
the keys in my wallet.dat seem to be about 65 bytes each.

If we assume that transactions average two inputs and two outputs, then
the average transaction size will be about 350 bytes ''(note that the main page assumes an average of 1KB per transaction)''. If we further assume
that the block size will, in practice, be limited to 500,000 bytes because
the transaction fees increase as the block size increases, then that means
there will be, on average, approximately 1430 transactions per block. That
works out to an average of 2.5 transactions per second - '''well''' below
the stated goal of at least 4,000 transactions per second.

Even if we assume only one input and one output per transaction, and that
each block will contain the full 1,000,000 bytes, that still works out to only 5,405
transactions per block, or 9 transactions per second.

Unfortunately, this is '''not''' a limitation that can be overcome by
simply increasing memory, or switching to a different ISP with more
bandwidth. It is a built-in limitation, designed to '''deliberately'''
slow down block creation. One solution is to somehow allow blocks to be freely created, while still keeping the rate of coin creation constant.

The bottom line is that, ''as it sits'', this system is not scalable.
:MAX_BLOCK_SIZE has always been planned to increase as needed. That limitation should be ignored. [[User:Theymos|theymos]] 17:15, 4 March 2011 (GMT)
:What Theymos said. Increasing MAX_BLOCK_SIZE will be done when "lightweight, header-only" client mode is done. Until then, block size has to be kept under control.--[[User:Gavinandresen|Gavin Andresen]] 00:19, 5 March 2011 (GMT)
:I've updated the page with more discussion of this topic. --[[User:Mike|Mike]] March 5 2011

The thing with VISA or and credit card company is that there wouldn't be that many actual transactions. When I buy stuff with my credit card the vender doesn't get paid instantly. I pay my bill once a month and the vender gets all his transactions lumped into one payment from VISA (once a week, I think). Someone correct me if I'm wrong, but the number of real transfers of money would be much smaller. --[[User:Randomproof|Randomproof]] 17:29, 1 April 2011 (GMT)

Would also be nice to get some kind of an estimate on how much the crypto-operations could be accelerated with a GPU.
[[User:Jojkaart|Jojkaart]] 20:48, 13 June 2011 (GMT)

Shouldn't this (under Opimizations -> Network Structure): "''Switching to DNS would give dramatically faster startup times that do not scale with the size of the network.''" read: "''Switching to DNS would give dramatically faster startup times that do scale with the size of the network.''"? ie Remove the "not".
--[[User:Tokoin|Tokoin]] 09:24, 21 July 2011 (GMT)

== Moore's law ==

I think Moore's law should be mentioned.

Even though now the comparison to Visa produces requirements for processing power, data storage or network capacity appear overwhelming for a casual user, the cost/performance ratio decreases all the time. My calculations based on data from wikipedia projected for 2020:

=== Disk space ===

Wikipedia quotes a research article that estimates that "in 2020 a two-platter, 2.5-inch disk drive will be capable of storing more than 14 terabytes(TB) and will cost about $40". This can hold about 85 days of data (~3 months) at "visa-speed". This is a bit pricey, but within the scope of a normal user, and definitely enough for enthusiasts.

=== Network capacity ===

Wikipedia references articles that estimate the "moore's law" equivalent for network to be 50% increase / year. For 9 years (2011-2020), this makes an increase of approximately 38 times. In order to achieve the speed of 1GB/s, this is the equivalent of someone having 27MB/s at the moment, i.e. 215Mbit/s. I think this exceeds a normal user and most enthusiasts. Assuming a casual user has 2Mbit/s at the moment, he'll scale to "visa-speed" in about 16 years, i.e. 2027.

=== CPU performance ===

Moore's law is approximated as "doubling every 18 months". For 9 years this makes 34 times if I'm calculating right. 50/34 = 1.47 cores. A dual-core computer in 2020 should therefore be sufficient to handle relaying/verifying Bitcoin transactions at visa-speed. I'm ignoring mining. So why someone is proposing that double tx check should be removed from the protocol ? We would surely leave the door open to some nasty attacks if strange transactions or double spends slip into blocks from attacking miners.

=== Summary ===

I only made very rough estimates. Feel free to recalculate with more accurate data. My conclusion is that CPU would be a no-brainer, disk space would be an annoyance, however network speed would indeed appear to be a problem.

== satoshiDICE ==

I believe the implications of [[SatoshiDice]] and similar schemes that stress the network should be mentioned, since as of March 2013, SatoshiDice transactions occupy 80% of the [[block chain]]. --[[User:Alvox|Alvox]] ([[User talk:Alvox|talk]]) 23:09, 29 March 2013 (GMT)

: So mention them? Note that SatoshiDice just abuses the network, not so much merely stressing it.. but clarifications can always be edited in after we have something to start from. --[[User:Luke-jr|Luke-jr]] ([[User talk:Luke-jr|talk]]) 23:28, 29 March 2013 (GMT)

: Is SatoshiDice relevant to scalability? If there is a solution to SatoshiDice spam then we probably should mention it, but I don't know of any solutions that can't be worked around by them --[[User:Lapp0|Lapp0]] ([[User talk:Lapp0|talk]]) 17:50, 20 December 2014 (UTC)

== passively running a full node and other scalability options ==

This page makes no distinction between passively running a full node and actively using 90% of your CPU power, 90% of your bandwidth and a ton of disk space. Clearly if it takes significant effort to run a full node, arguably unlike right now, then the number of full nodes will drop significantly.

I propose collapsing this whole article into one section titled "Increasing the Block size (Hardfork)" and include the problems with hardforking along with the problems of expensive full nodes.

Along with this section there should be other sections on other scalability improvements and their problems including sidechains, opentransactions, and others. --[[User:Lapp0|Lapp0]] ([[User talk:Lapp0|talk]]) 17:47, 20 December 2014 (UTC)

== Removal of the word ripple ==

I originally added the [https://en.bitcoin.it/w/index.php?title=Scalability&action=historysubmit&type=revision&diff=14273&oldid=14112 mention of ripple] back in 2011. At the time that was before OpenCoin (now called Ripple Labs) purchased the ripple name and stuck it on an entirely unrelated centralized system. Instead, what ripple referred to back then was a network of pairwise trust that allowed payments to ripple from person to person very similar to how Lightning actually works except ripple depended on trust while lightning is made cryptographically secure with smart contracting.

When opencoin bought the name and applied it to something different [https://bitcointalk.org/index.php?topic=144471.msg1547843#msg1547843 I protested against the ethics of that move and went through and edited all my comments referring to ripple, where they could be edited], but the text here had been removed by Hearn's edit-warring at the time so it didn't get fixed. I noticed today that Furunodo rightfully added an edit a few months back to indicate that Ripple's decentralization was bullshit-- it was right to change the text, but his change was the wrong one: The text was written long before centralised-bullshit-"ripple" was created in 2013 and referred to a system which we'd now recognize as a primordial lightning. Had the text been in the article in 2013 I would have fixed it then (and probably said "payment channels"), but it wasn't. I've corrected it now. Cheers. --[[User:Gmaxwell|Gmaxwell]] ([[User talk:Gmaxwell|talk]]) 03:59, 29 December 2020 (UTC)

Scalability

2020-12-29T03:50:41Z

Gmaxwell: This text was written before opencoin unethically bought the name "ripple" and stuck it on an unrelated centeralized system. Lightning is the moral successor to the ripple idea applied to Bitcoin..

'''''Note: This page is seriously outdated and largely unmaintained; due to past incidents of edit-warring it has not been subject to much peer review.'''''

A Bitcoin [[full node]] could be modified to scale to much higher transaction rates than are seen today, assuming that said node is running on a high end servers rather than a desktop. Bitcoin was designed to support lightweight clients that only process small parts of the block chain (see ''simplified payment verification'' below for more details on this).

''Please note that this page exists to give calculations about the scalability of a Bitcoin full node and transactions on the block chain without regards to network security and decentralization. It is not intended to discuss the scalability of alternative protocols or try and summarise philosophical debates. Create alternative pages if you want to do that.''

==Note to Readers==

When techies hear about how bitcoin works they frequently stop at the word "flooding" and say "Oh-my-god! that can't scale!". The purpose of this article is to take an extreme example, the peak transaction rate of Visa, and show that bitcoin ''could'' technically reach that kind of rate without any kind of questionable reasoning, changes in the core design, or non-existent overlays. As such, it's merely an extreme example— not a plan for how bitcoin will grow to address wider needs (as a decentralized system it is the bitcoin using public who will decide how bitcoin grows)— it's just an argument that shows that bitcoin's core design can scale much better than an intelligent person might guess at first.

Dan rightly criticizes the analysis presented here— pointing out that operating at this scale would significantly reduce the decentralized nature of bitcoin: If you have to have many terabytes of disk space to run a "full validating" node then fewer people will do it, and everyone who doesn't will have to trust the ones who do to be honest. Dan appears (from his slides) to have gone too far with that argument: he seems to suggest that this means bitcoins will be controlled by the kind of central banks that are common today. His analysis fails for two reasons (and the second is the fault of this page being a bit misleading):

First, even at the astronomic scale presented here the required capacity is well within the realm of (wealthy) private individuals, and certainly would be at some future time when that kind of capacity was required. A system which puts private individuals, or at least small groups of private parties, on equal footing with central banks could hardly be called a centralized one, though it would be less decentralized than the bitcoin we have today. The system could also not get to this kind of scale without bitcoin users agreeing collectively to increase the maximum block size, so it's not an outcome that can happen without the consent of bitcoin users.

Second, and most importantly, the assumed scaling described here deals with Bitcoin replacing visa. This is a poor comparison because bitcoin alone is not a perfect replacement for visa for reasons completely unrelated to scaling: Bitcoin does not offer instant transactions, credit, or various anti-fraud mechanisms (which some people want, even if not everyone does), for example. Bitcoin is a more complete replacement for checks, wire transfers, money orders, gold coins, CDs, savings accounts, etc. and if widely adopted probably replace the uses of credit cards which would be better served by these other things if they worked better online.

Bitcoin users sometimes gloss over this fact too quickly because people are too quick to call it a flaw but this is unfair. No one system is ideal for all usage and Bitcoin has a broader spectrum of qualities than most monetary instruments. If the bitcoin community isn't willing to point out some things would better be done by other systems then it becomes easy to make strawman arguments: If we admit that bitcoin could be used as a floor wax and desert topping, someone will always point out that it's not the best floorwax or best desert topping.

It's trivial to build payment processing and credit systems _on top_ of bitcoin, both classic ones (like Visa itself!) as well as "decentralized" ones like Lightning. These systems could handle higher transaction volumes with lower costs, and settle frequently to the bitcoin that backs them. These could use other techniques with different tradeoffs than bitcoin, but still be backed and denominated by bitcoin so still enjoy its lack of central control. We see the beginnings of this today with bitcoin exchange and wallet services allowing instant payments between members.

These services would gain the benefit of the stable inflation resistant bitcoin currency, users would gain the benefits of instant transactions, credit, and anti-fraud, bitcoin overall would enjoy improved scaling from offloaded transaction volume without compromising its decentralized nature. In a world where bitcoin was widely used payment processing systems would probably have lower prices because they would need to compete with raw-bitcoin transactions, they also could be afford lower price because frequent bitcoin settling (and zero trust bitcoin escrow transactions) would reduce their risk. This is doubly true because bitcoin could conceivably scale to replace them entirely, even if that wouldn't be the best idea due to the resulting reduction in decentralization.

==Scalability targets==

VISA handles on average around 2,000 transactions per second (tps), so call it a daily peak rate of 4,000 tps. It has a peak capacity of around 56,000 transactions per second, [https://usa.visa.com/dam/VCOM/download/corporate/media/visa-fact-sheet-Jun2015.pdf] however they never actually use more than about a third of this even during peak shopping periods. [http://www.visa.com/blogarchives/us/2013/10/10/stress-test-prepares-visanet-for-the-most-wonderful-time-of-the-year/index.html]

PayPal, in contrast, handled around 10 million transactions per day for an average of 115 tps in late 2014. [https://web.archive.org/web/20141226073503/https://www.paypal-media.com/about]

Let's take 4,000 tps as starting goal. Obviously if we want Bitcoin to scale to all economic transactions worldwide, including cash, it'd be a lot higher than that, perhaps more in the region of a few hundred thousand tps. And the need to be able to withstand DoS attacks (which VISA does not have to deal with) implies we would want to scale far beyond the standard peak rates. Still, picking a target let us do some basic calculations even if it's a little arbitrary.

Today the Bitcoin network is restricted to a sustained rate of 7 tps due to the bitcoin protocol restricting block sizes to 1MB.

===CPU===

The protocol has two parts. Nodes send "inv" messages to other nodes telling them they have a new transaction. If the receiving node doesn't have that transaction it requests it with a getdata.

The big cost is the crypto and block chain lookups involved with verifying the transaction. Verifying a transaction means some hashing and some [[ECDSA]] signature verifications. RIPEMD-160 runs at 106 megabytes/sec (call it 100 for simplicity) and SHA256 is about the same. So hashing 1 megabyte should take around 10 milliseconds and hashing 1 kilobyte would take 0.01 milliseconds - fast enough that we can ignore it.

Bitcoin is currently able (with a couple of simple optimizations that are prototyped but not merged yet) to perform around 8000 signature verifications per second on an quad core [http://ark.intel.com/products/53469 Intel Core i7-2670QM 2.2Ghz processor]. The average number of inputs per transaction is around 2, so we must halve the rate. This means 4000 tps is easily achievable CPU-wise with a single fairly mainstream CPU.

As we can see, this means as long as Bitcoin nodes are allowed to max out at least 4 cores of the machines they run on, we will not run out of CPU capacity for signature checking unless Bitcoin is handling 100 times as much traffic as PayPal. As of late 2015 the network is handling 1.5 transactions/second, so even assuming enormous growth in popularity we will not reach this level for a long time.

Of course Bitcoin does other things beyond signature checking, most obviously, managing the database. We use LevelDB which does the bulk of the heavy lifting on a separate thread, and is capable of very high read/write loads. Overall Bitcoin's CPU usage is dominated by ECDSA.

===Network===

Let's assume an average rate of 2000tps, so just VISA. Transactions vary in size from about 0.2 kilobytes to over 1 kilobyte, but it's averaging half a kilobyte today.

That means that you need to keep up with around 8 megabits/second of transaction data (2000tps * 512 bytes) / 1024 bytes in a kilobyte / 1024 kilobytes in a megabyte = 0.97 megabytes per second * 8 = 7.8 megabits/second.

This sort of bandwidth is already common for even residential connections today, and is certainly at the low end of what colocation providers would expect to provide you with.

When blocks are solved, the current protocol will send the transactions again, even if a peer has already seen it at broadcast time. Fixing this to make blocks just list of hashes would resolve the issue and make the bandwidth needed for block broadcast negligable. So whilst this optimization isn't fully implemented today, we do not consider block transmission bandwidth here.

===Storage===

At very high transaction rates each block can be over half a gigabyte in size.

It is not required for most fully validating nodes to store the entire chain. In Satoshi's paper he describes "pruning", a way to delete unnecessary data about transactions that are fully spent. This reduces the amount of data that is needed for a fully validating node to be only the size of the current unspent output size, plus some additional data that is needed to handle re-orgs. As of October 2012 (block 203258) there have been 7,979,231 transactions, however the size of the unspent output set is less than 100MiB, which is small enough to easily fit in RAM for even quite old computers.

Only a small number of archival nodes need to store the full chain going back to the genesis block. These nodes can be used to bootstrap new fully validating nodes from scratch but are otherwise unnecessary.

The primary limiting factor in Bitcoin's performance is disk seeks once the unspent transaction output set stops fitting in memory. Once hard disks are phased out in favour of SSDs, it is quite possible that access to the [[UTXO]] set never becomes a serious bottleneck.

==Optimizations==

The description above applies to the current software with only minor optimizations assumed (the type that can and have been done by one man in a few weeks).

However there is potential for even greater optimizations to be made in future, at the cost of some additional complexity.

===CPU===

Algorithms exist to accelerate batch verification over elliptic curve signatures. It's possible to check their signatures simultaneously for a 2x speedup. This is a somewhat more complex implementation.

===Simplified payment verification===


It's possible to build a Bitcoin implementation that does not verify everything, but instead relies on either connecting to a trusted node, or puts its faith in high difficulty as a proxy for proof of validity. [[bitcoinj]] is an implementation of this mode.

In Simplified Payment Verification (SPV) mode, named after the section of Satoshi's paper that describes it, clients connect to an arbitrary full node and download only the block headers. They verify the chain headers connect together correctly and that the difficulty is high enough. They then request transactions matching particular patterns from the remote node (ie, payments to your addresses), which provides copies of those transactions along with a Merkle branch linking them to the block in which they appeared. This exploits the Merkle tree structure to allow proof of inclusion without needing the full contents of the block.

As a further optimization, block headers that are buried sufficiently deep can be thrown away after some time (eg. you only really need to store as low as 2016 headers).

The level of difficulty required to obtain confidence the remote node is not feeding you fictional transactions depends on your threat model. If you are connecting to a node that is known to be reliable, the difficulty doesn't matter. If you want to pick a random node, the cost for an attacker to mine a block sequence containing a bogus transaction should be higher than the value to be obtained by defrauding you. By changing how deeply buried the block must be, you can trade off confirmation time vs cost of an attack.

Programs implementing this approach can have fixed storage/network overhead in the null case of no usage, and resource usage proportional to received/sent transactions.

See also: [[Thin Client Security]].

== Related work ==
There are a few proposals for optimizing Bitcoin's scalability. Some of these require an alt-chain / hard fork.

* [https://bitcointalk.org/index.php?topic=88208.0 Ultimate blockchain compression] - the idea that the blockchain can be compressed to achieve "trust-free lite nodes"
* [http://cryptonite.info/files/mbc-scheme-rev2.pdf The Finite Blockchain] paper that describes splitting the blockchain into three data structures, each better suited for its purpose. The three data structures are a finite blockchain (keep N blocks into the past), an "account tree" which keeps account balance for every address with a non-zero balance, and a "proof chain" which is an (ever growing) slimmed down version of the blockchain.
* [https://lightning.network/ Lightning Network], an alternative protocol for transaction clearance in which nodes set up micropayment channels between each other and settle up on the block chain occasionally. Ordinary users interact primarily or only with payment channels and only use the blockchain for large transfers and cold storage.

[[Category:Technical]]
[[Category:Scalability]]

Bech32 adoption

2020-05-26T17:08:07Z

Gmaxwell: /* Exchanges */ some additions

[[Bech32]] is a new bitcoin [[address]] format specified by [[BIP 0173]]. This page tracks the adoption of [[Bech32]].

Ideally wallets and services would first support ''sending to'' bech32 addresses. After almost everything can send to, then people may be willing to adopt bech32 widely for receiving.

The amount of bech32 addresses on the blockchain is tracked on this website: https://p2sh.info/dashboard/db/bech32-statistics?orgId=1

{| class="wikitable"
|-
| {{No}} ||
|-
| {{Evaluating|??}} || Maybe / Haven't checked / placeholder
|-
| {{Planned}} || The developers said they plan to
|-
| {{Acceptable|PR Merged}} || In the case of software, code has been written and merged, and it will be in next release.
|-
| {{Yes}} || Feature has been released
|}

=== Software Wallets ===
{| class="wikitable sortable"
|-
! Name !! Send to !! Create/receive !! Notes
|-
| Bitcoin Core || {{Yes}} || {{Yes}} ||
|-
| Bitcoin Knots || {{Yes}} || {{Yes}} ||
|-
| bcoin || {{Yes}} || {{Yes}} ||
|-
| Electrum || {{Yes}} || {{Yes}} ||
|-
| Armory || {{Yes}} || {{No}} ||
|-
| JoinMarket || {{Yes}} || {{No}} ||
|-
| GreenAddress || {{Yes}} || {{Yes}} ||
|-
| Breadwallet || {{Yes}} || {{No}} || https://twitter.com/udiWertheimer/status/975810157941796864
|-
| Samourai Wallet || {{Yes}} || {{Yes}} ||
|-
| Coinomi || {{Yes}} || {{Yes}} || [https://www.reddit.com/r/Bitcoin/comments/865qn1/coinomi_wallet_beta_has_segwit_support/ reddit source]
|-
| BTC.com || {{Yes}} || {{No}} ||
|-
| Casa || {{Yes}} || {{No}} ||
|-
| Mycelium || {{Yes}} || {{Yes}} ||
|-
| [https://play.google.com/store/apps/details?id=de.schildbach.wallet Bitcoin Wallet for Android] || {{Yes}} || {{Yes}} ||
|-
| Wasabi Wallet || {{Yes}} || {{Yes}} ||
|-
| Trust Wallet || {{Yes}} || {{Yes}} || [https://trustwallet.com/blog/trust-wallet-adds-support-for-btc-ltc-bch official blog]
|-
| Guarda Wallet || {{Yes}} || {{No}} || [https://twitter.com/GuardaWallet/status/1194270398730448896 twitter announcement]
|-
|}

=== Hardware Wallets ===

Hardware wallet manufacturers typically publish a web wallet or browser add-on wallet for use with their hardware. Users can also sometimes connect their hardware wallet to a software wallet like [[Electrum]].

{| class="wikitable sortable"
|-
! Name !! Send to !! Create/receive !! Notes
|-
| Trezor web wallet || {{Acceptable|PR Merged}} || {{No}} ||
|-
| Ledger chrome app || {{No}} || {{No}} ||
|-
| Ledger Live (desktop app) || {{Yes}} || {{Yes}} || Experimental feature
|-
| KeepKey chrome app || {{No}} || {{No}} ||
|-
| BitBox Desktop app || {{Yes}} || {{Yes}} ||
|-
| Trezor + Electrum || {{Yes}} || {{Yes}} ||
|-
| Ledger + Electrum || {{Yes}} || {{Yes}} ||
|-
| BitBox + Electrum || {{Yes}} || {{Yes}} ||
|-
| KeepKey + Electrum || {{Yes}} || {{Yes}} ||
|-
| Archos + Electrum || {{Yes}} || {{Yes}} ||
|-
| Coldcard + Electrum || {{Yes}} || {{Yes}} ||
|-
| Ballet + app|| {{Yes}} || {{Yes}} ||
|}

=== Web Wallets ===

{| class="wikitable sortable"
|-
! Name !! Send to !! Create/receive !! Notes
|-
| Coinapult || {{Evaluating|??}} || {{No}} ||
|-
| Coin.Space || {{Evaluating|??}} || {{No}} ||
|-
| BitGo || {{Yes}} || {{Yes}} || Full support on v2 platform, no plans to add support on v1 platform. Also see: https://blog.bitgo.com/native-segwit-addresses-via-bitgos-api-4946f2007be9
|-
| blockchain.info web|| {{Yes}} || {{No}} || https://twitter.com/provoost/status/1037802325874761728
|-
| HolyTransaction || {{Yes}} || {{No}} ||
|-
| [https://coinb.in Coinb.in] || {{Yes}} || {{Yes}} || open source JavaScript implementation
|-
| Guarda Wallet || {{Yes}} || {{No}} || https://twitter.com/GuardaWallet/status/1194270398730448896
|}

=== Exchanges ===



{| class="wikitable sortable"
|-
! Name !! Send to !! Create/receive !! Notes
|-
| 1Fox || {{Yes}} || {{No}} || https://1fox.com/?c=en/content/blog&id=12
|-
| [[AgoraDesk]] || {{Yes}} || {{No}} ||
|-
| Anycoin Direct || {{Yes}} || {{No}} || https://anycoindirect.eu/en/news/details/segwit-activated
|-
| BitBargain.co.uk || {{Yes}} || {{No}} ||
|-
| Bitcoin.de || {{Yes}} || {{No}} || https://bitcoinblog.de/2018/08/10/bitcoin-de-aktiviert-segwit-kunden-sparen-gebuehren/
|-
| Bitfinex || {{Yes}} || {{No}} || https://twitter.com/bitfinex/status/1189164144789983234
|-
| BitMEX || {{yes}} || {{No}} || https://blog.bitmex.com/bitmex-enables-bech32-sending-support/
|-
| Bittrex || {{No}} || {{No}} || https://www.reddit.com/r/Bitcoin/comments/gqt1m6/bittrex_does_not_even_support_withdrawals_to/
|-
| Bittylicious || {{Yes}} || {{No}} || https://twitter.com/Bittylicious_/status/998881327347888128
|-
| Bitstamp || {{Yes}} || {{Yes}} || https://www.bitstamp.net/article/weve-added-support-bech32-bitcoin-addresses-bitsta/
|-
| Bitso || {{Yes}} || {{No}} || https://twitter.com/Bitso/status/1203784055340314624?s=20
|-
| Bitwage || {{Evaluating|??}} || {{No}} ||
|-
| Bisq || {{No}} || {{No}} || https://github.com/bisq-network/bisq-desktop/issues/1139 https://bisq.community/t/bech32-address-support/6521
|-
| Coinbase.com || {{Yes}} || {{No}} || https://twitter.com/diogorsergio/status/983052769262292992 (Note that Coinbase commerce does not support sending to bech32)
|-
| CoinFalcon || {{Yes}} || {{No}} ||
|-
| Coinfloor || {{Evaluating|??}} || {{No}} ||
|-
| Coinsbank.com || {{Yes}} || {{Yes}} ||
|-
| Flyp.me || {{Yes}} || {{No}} ||
|-
| GDax || {{Yes}} || {{No}} || https://www.reddit.com/r/Bitcoin/comments/8c738k/coinbase_gdax_already_allows_sending_to_bc1/
|-
| Gemini || {{Yes}} || {{Yes}} || https://np.reddit.com/r/Bitcoin/comments/b66n0v/psa_gemini_is_full_on_with_native_segwit_and_uses/
|-
| Genesis || {{Evaluating|??}} || {{No}} ||
|-
| Globitex || {{No}} || {{No}} ||
|-
| HitBTC || {{Yes}} || {{No}} ||
|-
| Hodl Hodl || {{Yes}} || {{Yes}} || https://medium.com/@hodlhodl/hodl-hodl-segwit-compatible-exchange-a2231968ac56
|-
| Independent Reserve|| {{Yes}} || {{No}} || https://www.independentreserve.com/bitcoin/investing
|-
| Itbit || {{Evaluating|??}} || {{No}} ||
|-
| Kraken || {{Yes}} || {{No}} || https://twitter.com/krakenfx/status/1060306827848470528
|-
| LedgerX || {{No}} || {{No}} ||
|-
| Liberalcoins || {{Yes}} || {{Yes}} || https://liberalcoins.com
|-
| Localbitcoins.com || {{No}} || {{No}} ||
|-
| Paxful.com || {{Evaluating|??}} || {{No}} ||
|-
| Poloniex.com || {{Yes}} || {{No}} || https://www.reddit.com/r/Bitcoin/comments/a3jhcf/you_can_now_withdraw_from_poloniex_to_bech32/
|-
| TheRockTrading.com || {{Yes}} || {{Yes}} || https://twitter.com/TheRockTrading/status/976787499648512003
|-
| Walltime || {{Yes}} || {{Yes}} || https://walltime.info
|-
| Purse.io || {{Yes}} || {{Yes}} ||
|-
| www.bitwala.com || {{Yes}} || {{Yes}} ||
|-
| Xapo || {{Yes}} || {{No}} ||
|}

=== Bitcoin ATM Models ===

Hopefully when a model updates then all its ATMs everywhere will gain that feature. See https://coinatmradar.com/shop/buy-bitcoin-atm/

{| class="wikitable sortable"
|-
! Name !! Send to !! Create/receive !! Notes
|-
| GenesisCoin || {{No}} || {{No}} ||
|-
| General Bytes || {{Yes}} || {{Yes}} || Depending on configuration. Since version 20190613 https://www.generalbytes.com/en/support/changelog
|-
| Lamassu Douro || {{Yes}} || {{No}} || https://medium.com/@LamassuSupport/announcing-crafty-chnemu-v7-3-9522fe2868
|}

=== Blockchain Explorers ===

For trying these out you can use mainnet TXIDs <code>4ef47f6eb681d5d9fa2f7e16336cd629303c635e8da51e425b76088be9c8744c</code> and <code>514a33f1d46179b89e1fea7bbb07b682ab14083a276979f91038369d1a8d689b</code>. And addresses <code>bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq</code> and <code>bc1qc7slrfxkknqcq2jevvvkdgvrt8080852dfjewde450xdlk4ugp7szw5tk9</code>.

Some blockchain explorers can only parse the bech32 address and display it, they don't build an index so users cannot search for bech32 addresses.

See also: https://en.bitcoin.it/wiki/Category:Block_chain_browsers

{| class="wikitable sortable"
|-
! Name !! Display !! Index !! Notes
|-
| Apirone.com || {{Yes}} || {{Yes}} || https://apirone.com
|-
| bitaps.com || {{Yes}} || {{Yes}} || https://bitaps.com
|-
| Bitflyer || {{Yes}} || {{Yes}} || https://chainflyer.bitflyer.jp/
|-
| Bitupper Explorer || {{Yes}} || {{Yes}} || https://bitupper.com/en/explorer/bitcoin
|-
| blockchain.info || {{Yes}} || {{No}} ||
|-
| Blockchair || {{Yes}} || {{Yes}} || https://blockchair.com/
|-
| Blockcypher || {{Yes}} || {{Yes}} || https://live.blockcypher.com/btc
|-
| Blockonomics || {{Yes}} || {{Yes}} || https://www.blockonomics.co
|-
| Blockpath || {{Yes}} || {{Yes}} || https://blockpath.com
|-
| BTC.com || {{Yes}} || {{Yes}} || https://BTC.com
|-
| Esplora || {{Yes}} || {{Yes}} || Open source explorer, instances are https://blockstream.info/ and https://www.localbitcoinschain.com/
|-
| chaindex || {{Yes}} || {{Yes}} || https://chaindex.com/blockchain/
|-
| Insight || {{No}} || {{No}} || Open source explorer, instances include https://insight.bitpay.com/
|-
| OXT || {{Yes}} || {{Yes}} || https://oxt.me/
|-
| Tradeblock || {{No}} || {{No}} || https://tradeblock.com/bitcoin
|}

=== Payment Processors ===



{| class="wikitable sortable"
|-
! Name !! Invoice addresses !! Withdrawal addresses !! Notes
|-
| [https://apirone.com Apirone] || {{Yes}} || {{Yes}} || Payment notifications, merchant dashboard, plugins for Magento, WooCommerce, OpenCart 2, Opencart 3.x, Virtuemart
|-
| [https://bitaps.com Bitaps] || {{Yes}} || {{Yes}} || Payment forwarding API, Wallet API, fault tolerance callback.
|-
| [https://coingate.com CoinGate] || {{No}} || {{Yes}} ||
|-
| [https://cryptochill.com CryptoChill] || {{Yes}} || {{Yes}} || Highly customizable Bitcoin and Lightning Network payment gateway. Multi-sig, HD wallets, API, SDK.
|}

=== Mining Pools ===

{| class="wikitable sortable"
|-
! Name !! Payout !! Notes
|-
| [https://pool.btc.com/ BTC.com Pool] || {{No}} ||
|-
| [http://ckpool.org/ Ckpool] || {{Yes}} ||
|-
| [https://kano.is/ KanoPool] || {{Yes}} || [https://bitcointalk.org/index.php?topic=789369.msg53374508#msg53374508 bitcointalk source]
|-
| [http://poolin.com/ Poolin] || {{Yes}} || [https://bitcointalk.org/index.php?topic=5169994.msg52184844#msg52184844 bitcointalk source]
|-
| [https://slushpool.com/ Slush Pool] || {{Yes}} ||
|-
| [https://ukrpool.com/ Ukr Pool] || {{Yes}} || [https://bitcointalk.org/index.php?topic=5124825.msg51358033#msg51358033 bitcointalk source]
|-
| [https://pool.viabtc.com/ ViaBTC Pool] || {{No}} ||
|}

=== Other Services ===

Casinos, marketplaces, etc that let users withdraw money

{| class="wikitable sortable"
|-
! Name !! Withdrawals !! Notes
|-
| 1Broker || {{Yes}} ||
|-
| Crypto-Games.net || {{Yes}} || [https://bitcointalk.org/index.php?topic=750760.msg31421151#msg31421151 bitcointalk source]
|-
| YOLOdice || {{Yes}} ||
|}

=== References ===

[[Category:Software]]

Talk:Shamir Secret Snakeoil

2019-11-27T18:09:59Z

Gmaxwell:

This article should be cleaned up to remove bias. I understand Greg Maxwell is well respected in terms of his cryptography knowledge, but its clear that this article is written in a way that includes many [https://en.wikipedia.org/wiki/Weasel_word weasel words], including in the title itself. Shamir's secret sharing algorithm is, even by Greg Maxwell's own admission here, a perfectly valid and secure algorithm. The fact that many programmers have botched the implementation is not an indictment of the algorithm itself. This page should be upgraded to be a bit more professional and unbiased, noting the pitfalls as well as the downsides in comparison to multisig alternatives, but also being clear that it is a secure tool people can use as long as they find well vetted implementations (like anything in cryptography). [[User:Fresheneesz|Fresheneesz]] ([[User talk:Fresheneesz|talk]]) 00:20, 25 November 2019 (UTC)
::Note that the article [[Shamir Secret Sharing]] redirects to this article. I'm guessing the author added that for effect so that if someone searches Shamir Secret Sharing they can immediately see it be called snakeoil. The title isn't weasal words (which is using anonymous authority) but [https://en.wikipedia.org/wiki/Name_calling name calling] which is legitimately useful in rhetoric (in our ecosystem see "shitcoin", "fedcoin", "scamcoin", etc). In this case the namecalling is useful to help the idea stick in people's heads (see rule 1 of [https://en.wikipedia.org/wiki/Made_to_Stick#Overview how to make ideas sticky]). The article does not use the argument that some programmers have botched the implementation therefore the algorithm is bad, instead the argument is that SSS itself is not a useful algorithm for storing bitcoins. Being unbiased is not an ideal to aim for; we should never be unbiased about educating people so they can avoid harming themselves. If you believe SSS is valuable you should respond to some of gmaxwell's points, such as the argument about SSS requiring the private keys to be restored in one machine, and if you have access to a secure machine you may as well just use store keys there without resorting to SSS. A multisig vs SSS section could be useful but multisig still wins hands-down, especially after schnorr gets adds to bitcoin, and even without schnorr a huge number of UTXOs today are in 2-of-3 multisig so the privacy issue isn't even that bad. [[User:Belcher|Belcher]] ([[User talk:Belcher|talk]]) 17:06, 27 November 2019 (UTC)
:::In fact, re about it not being about botched implementations... it even states "Errors in SSS implementations are not usually the fault of an unusual incompetence in their developers." SSS is unusually brittle, which is unsurprising when you realize that it's just a generalization of the one-time-pad from 2 of 2 (ciphertext+key) to N of M. Consider how frequently OTP is described as highly brittle and prone to errors, useful in few circumstances, and generally recommended against: E.g. [https://freedom-to-tinker.com/2015/03/25/be-wary-of-one-time-pads-and-other-crypto-unicorns/ 1] [https://crypto.stackexchange.com/questions/26124/is-the-one-time-pad-a-secure-system-according-to-modern-definitions 2] [https://www.schneier.com/blog/archives/2014/09/terrible_articl.html 3]. One can also state that correctly used OTP is a "valid" and "secure" system, but that doesn't make it useful. Most experts would immediately flag any product bragging about one time pads as likely outright insecure, or at a minimum over-hyped. This article is intending to make the same case for SSS. And as the examples show, someone who followed this heuristic would have successfully avoided several widely used insecure systems.
:::Other kinds of cryptography are also brittle (though not usually as bad as OTP/SSS) but they seldom have the unique combination of extremely low practical value, brittleness, and innate appeal to non-experts that result in a broad ecosystem of practically broken tools. "Snakeoil" in the traditional description is a product that is promoted as being a miracle cure to various ills to an unsophisticated consumer but which doesn't actually cure any ill that they're likely to have. And I think the article makes the case that SSS is usually snakeoil in just that sense. Implemented perfectly it is still usually pointless or nearly pointless: it doesn't cure an ill that the user has. Worse, it's usually not implemented perfectly so it has often made user's security much worse in practice. These three factors (uselessness, brittleness, and naieve-appeal) aren't independent, but feed off each other: Expert practitioners who would be more likely to implement correctly don't bother because it's low value and not worth the effort, while people paying casual attention can easily get seduced by the ritual aspects and fail to pay attention to the brittleness and as a result feel a lot more secure than they actually are.
:::In security it's not just important to have the right amount of security but it's also important that you feel exactly as secure as you are, no more no less. In Bitcoin in particular, multisig actually offers essentially all of the security advantages commonly ascribed to SSS but without the usability flaws that make SSS so often useless, while also being generally less brittle (at least for ordinary CMS multisig). If people were going around promoting securing your keys with "the power of multiplication", I'd advise against that too and describe that promotion as snakeoil: While multiplication is a perfectly valid building block for secure systems, it's not a useful security tool for end users to directly apply to secure their secrets.--[[User:Gmaxwell|Gmaxwell]] ([[User talk:Gmaxwell|talk]]) 18:03, 27 November 2019 (UTC)

Talk:Shamir Secret Snakeoil

2019-11-27T18:06:11Z

Gmaxwell: minor additions

This article should be cleaned up to remove bias. I understand Greg Maxwell is well respected in terms of his cryptography knowledge, but its clear that this article is written in a way that includes many [https://en.wikipedia.org/wiki/Weasel_word weasel words], including in the title itself. Shamir's secret sharing algorithm is, even by Greg Maxwell's own admission here, a perfectly valid and secure algorithm. The fact that many programmers have botched the implementation is not an indictment of the algorithm itself. This page should be upgraded to be a bit more professional and unbiased, noting the pitfalls as well as the downsides in comparison to multisig alternatives, but also being clear that it is a secure tool people can use as long as they find well vetted implementations (like anything in cryptography). [[User:Fresheneesz|Fresheneesz]] ([[User talk:Fresheneesz|talk]]) 00:20, 25 November 2019 (UTC)
::Note that the article [[Shamir Secret Sharing]] redirects to this article. I'm guessing the author added that for effect so that if someone searches Shamir Secret Sharing they can immediately see it be called snakeoil. The title isn't weasal words (which is using anonymous authority) but [https://en.wikipedia.org/wiki/Name_calling name calling] which is legitimately useful in rhetoric (in our ecosystem see "shitcoin", "fedcoin", "scamcoin", etc). In this case the namecalling is useful to help the idea stick in people's heads (see rule 1 of [https://en.wikipedia.org/wiki/Made_to_Stick#Overview how to make ideas sticky]). The article does not use the argument that some programmers have botched the implementation therefore the algorithm is bad, instead the argument is that SSS itself is not a useful algorithm for storing bitcoins. Being unbiased is not an ideal to aim for; we should never be unbiased about educating people so they can avoid harming themselves. If you believe SSS is valuable you should respond to some of gmaxwell's points, such as the argument about SSS requiring the private keys to be restored in one machine, and if you have access to a secure machine you may as well just use store keys there without resorting to SSS. A multisig vs SSS section could be useful but multisig still wins hands-down, especially after schnorr gets adds to bitcoin, and even without schnorr a huge number of UTXOs today are in 2-of-3 multisig so the privacy issue isn't even that bad. [[User:Belcher|Belcher]] ([[User talk:Belcher|talk]]) 17:06, 27 November 2019 (UTC)
:::In fact, re about it not being about botched implementations... it even states "Errors in SSS implementations are not usually the fault of an unusual incompetence in their developers." SSS is unusually brittle, which is unsurprising when you realize that it's just a generalization of the one-time-pad from 2 of 2 (ciphertext+key) to N of M. Consider how frequently OTP is described as highly brittle and prone to errors, useful in few circumstances, and generally recommended against: E.g. [https://freedom-to-tinker.com/2015/03/25/be-wary-of-one-time-pads-and-other-crypto-unicorns/ 1] [https://crypto.stackexchange.com/questions/26124/is-the-one-time-pad-a-secure-system-according-to-modern-definitions 2] [https://www.schneier.com/blog/archives/2014/09/terrible_articl.html 3]. One can also state that correctly used OTP is a "valid" and "secure" system, but that doesn't make it useful. Most experts would immediately flag any product bragging about one time pads as likely outright insecure, or at a minimum over-hyped. This article is intending to make the same case for SSS. And as the examples show, someone who followed this heuristic would have successfully avoided several widely used insecure systems.
:::Other kinds of cryptography are also brittle (though not usually as bad as OTP/SSS) but they seldom have the unique combination of extremely low practical value, brittleness, and innate appeal to non-experts that result in a broad ecosystem of practically broken tools. "Snakeoil" in the traditional description is a product that is promoted as being a miracle cure to various ills to an unsophisticated consumer but which doesn't actually cure any ill that they're likely to have. And I think the article makes the case that SSS is usually snakeoil in just that sense. Implemented perfectly it is still usually pointless or nearly pointless: it doesn't cure an ill that the user has. Worse, it's usually not implemented perfectly so it has often made user's security much worse in practice. These three factors (uselessness, brittleness, and naieve-appeal) aren't independent, but feed off each other: Expert practitioners who would be more likely to implement correctly don't bother because it's low value and not worth the effort, while people paying casual attention can easily get seduced by the ritual aspects and fail to pay attention to the brittleness and as a result feel a lot more secure than they actually are. In security it's not just important to have the right amount of security but it's also important that you feel exactly as secure as you are, no more no less. In Bitcoin in particular, multisig actually offers essentially all of the security advantages commonly ascribed to SSS but without the usability flaws that make SSS so often useless, while also being generally less brittle (at least for ordinary CMS multisig).--[[User:Gmaxwell|Gmaxwell]] ([[User talk:Gmaxwell|talk]]) 18:03, 27 November 2019 (UTC)

Talk:Shamir Secret Snakeoil

2019-11-27T18:03:59Z

Gmaxwell: re

This article should be cleaned up to remove bias. I understand Greg Maxwell is well respected in terms of his cryptography knowledge, but its clear that this article is written in a way that includes many [https://en.wikipedia.org/wiki/Weasel_word weasel words], including in the title itself. Shamir's secret sharing algorithm is, even by Greg Maxwell's own admission here, a perfectly valid and secure algorithm. The fact that many programmers have botched the implementation is not an indictment of the algorithm itself. This page should be upgraded to be a bit more professional and unbiased, noting the pitfalls as well as the downsides in comparison to multisig alternatives, but also being clear that it is a secure tool people can use as long as they find well vetted implementations (like anything in cryptography). [[User:Fresheneesz|Fresheneesz]] ([[User talk:Fresheneesz|talk]]) 00:20, 25 November 2019 (UTC)
::Note that the article [[Shamir Secret Sharing]] redirects to this article. I'm guessing the author added that for effect so that if someone searches Shamir Secret Sharing they can immediately see it be called snakeoil. The title isn't weasal words (which is using anonymous authority) but [https://en.wikipedia.org/wiki/Name_calling name calling] which is legitimately useful in rhetoric (in our ecosystem see "shitcoin", "fedcoin", "scamcoin", etc). In this case the namecalling is useful to help the idea stick in people's heads (see rule 1 of [https://en.wikipedia.org/wiki/Made_to_Stick#Overview how to make ideas sticky]). The article does not use the argument that some programmers have botched the implementation therefore the algorithm is bad, instead the argument is that SSS itself is not a useful algorithm for storing bitcoins. Being unbiased is not an ideal to aim for; we should never be unbiased about educating people so they can avoid harming themselves. If you believe SSS is valuable you should respond to some of gmaxwell's points, such as the argument about SSS requiring the private keys to be restored in one machine, and if you have access to a secure machine you may as well just use store keys there without resorting to SSS. A multisig vs SSS section could be useful but multisig still wins hands-down, especially after schnorr gets adds to bitcoin, and even without schnorr a huge number of UTXOs today are in 2-of-3 multisig so the privacy issue isn't even that bad. [[User:Belcher|Belcher]] ([[User talk:Belcher|talk]]) 17:06, 27 November 2019 (UTC)
:::In fact, re about it not being about botched implementations... it even states "Errors in SSS implementations are not usually the fault of an unusual incompetence in their developers." SSS is unusually brittle, which is unsurprising when you realize that it's just a generalization of the one-time-pad from 2 of 2 (ciphertext+key) to N of M. Consider how frequently OTP is described as highly brittle and prone to errors, useful in few circumstances, and generally recommended against: E.g. [https://freedom-to-tinker.com/2015/03/25/be-wary-of-one-time-pads-and-other-crypto-unicorns/ 1] [https://crypto.stackexchange.com/questions/26124/is-the-one-time-pad-a-secure-system-according-to-modern-definitions 2] [https://www.schneier.com/blog/archives/2014/09/terrible_articl.html 3]. One can also state that correctly used OTP is a "valid" and "secure" system, but that doesn't make it useful. Most experts would immediately flag any product bragging about one time pads as likely outright insecure, or at a minimum over-hyped. This article is intending to make the same case for SSS.
:::Other kinds of cryptography are also brittle (though not usually as bad as OTP/SSS) but they seldom have the unique combination of extremely low practical value, brittleness, and innate appeal to non-experts that result in a broad ecosystem of practically broken tools. "Snakeoil" in the traditional description is a product that is promoted as being a miracle cure to various ills to an unsophisticated consumer but which doesn't actually cure any ill that they're likely to have. And I think the article makes the case that SSS is usually snakeoil in just that sense. Implemented perfectly it is still usually pointless or nearly pointless: it doesn't cure an ill that the user has. Worse, it's usually not implemented perfectly so it has often made user's security much worse in practice. These three factors (uselessness, brittleness, and naieve-appeal) aren't independent, but feed off each other: Expert practitioners who would be more likely to implement correctly don't bother because it's low value and not worth the effort, while people paying casual attention can easily get seduced by the ritual aspects and fail to pay attention to the brittleness and as a result feel a lot more secure than they actually are. In security it's not just important to have the right amount of security but it's also important that you feel exactly as secure as you are, no more no less. In Bitcoin in particular, multisig actually offers essentially all of the security advantages commonly ascribed to SSS but without the usability flaws that make SSS so often useless, while also being generally less brittle (at least for ordinary CMS multisig).--[[User:Gmaxwell|Gmaxwell]] ([[User talk:Gmaxwell|talk]]) 18:03, 27 November 2019 (UTC)

Shamir Secret Snakeoil

2019-11-04T06:46:40Z

Gmaxwell: copyedits

Shamir Secret Sharing seems to be mysteriously attractive to people: The idea of splitting up a secret into multiple parts and having a ritual to recombine them seems have an instinctive appeal to many.

Shamir's scheme is clever enough that programmers feel smart for being able to understand and implement it but it is not so clever that they give up before getting something working. Unfortunately, the difference between implementing it and implementing it correctly is substantial. Like all cryptographic techniques small errors can have devastating consequences. As a result many, perhaps the vast majority, of SSS implementations are flawed. In some cases the flaws are merely theoretical, compromising properties of SSS that don't matter in practice, but others have been flawed in ways that completely destroy the security. The user's reliance on false security then goes on to cause them to do things that can make them actually lose their funds.

As a generalization of the one time pad SSS, if implemented perfectly, has the unusual property of achieving information theoretic security: it's strong against attackers with unbounded computational power. This kind of "perfect security" adds to the mysterious appeal but this property is of essentially no practical use and seems to distract people from the fact that many attempts at SSS have been so weak a child's speak-n-spell could crack them. Like the one-time-pad and most other cryptosystems, the security of SSS is fairly brittle.

In Bitcoin, Shamir Secret Sharing by itself has almost no valid use: Most threat models that could be defended using SSS are _much_ better defended by multisig particularly because recombining shares of a private key on a device leave the key exposed to malware or a malicious user of the device which are usually the most important threats to protect against. If you have a device which is guaranteed to be free of malware operated by a user guaranteed to be uncorrupt, you could just leave the private key there and dispense with the SSS ritual-security-theatre. Bitcoin products that advertise SSS are often snake-oil and the same thoughtlessness that caused the marketing of SSS probably signals poor security.

Most the time safe bitcoin key material can be backed up more safely by simply making multiple copies. Vulnerability of any one backup to theft can be protected against using multisig.

== Examples of Shamir Secret Snakeoil ==

Errors in SSS implementations are not usually the fault of an unusual incompetence in their developers. Correctly implementing cryptographic functions is *hard* but SSS is in a particular sweet spot where-- like most crypto functions-- it is hard enough to implement correctly that it's interesting to try but also easy enough to implement at all.

Simply avoiding the mistakes listed here will not make an implementation secure. A secure implementation of any cryptosystem starts with a careful analysis of the costs and benefits assuming it worked perfectly and often SSS does not make the cut, meaning that most implementations that exist were made by people who didn't carefully consider if it was even worth doing.

=== Armory ===

Bitcoin Armory, a previously popular Bitcoin wallet used a N of M secret sharing for backing up users private keys. The implementation used repeated hashing of data instead of a random number generator and that combined with other errors completely breaks the scheme. [https://bitcointalk.org/index.php?topic=2199659.0 The result] is that regardless of the requested threshold an attacker with the first share and any other share could recover the secret (or alternatively the N-th share plus any N additional ones).

=== HTC Exodus phone ===

HTC exodus phone backs up users keys by splitting them 3 of 5 to your phone contacts but [http://diyhpl.us/wiki/transcripts/breaking-bitcoin/2019/extracting-seeds-from-hardware-wallets/ totally failed to deliver the advertised security]:

<blockquote>They implemented Shamir secret sharing by sharing the 256 bit seed (32 bytes) with 32 different polynomials of degree 2, and then it evaluates it in 5 points and sends the shares. The coefficient a,b are randomly generated with a PRNG and must be kept secret.

The problem with HTC's implementation is that the PRNG update operation is linear and not updated well. Both a and b are linearly dependent. Instead of ending up with a polynomial that they expected, they end up with a different one which has a linear dependency between the coefficients. [...] You only need to compromise 2 different trusted contacts, then you get their shares and you're able to get the seed. So one trusted contact can collude with another and retrieve the value of the seed. This is really bad.

In firmware v1.54.2401.6, the PRNG is seeded with a fixed value. By reverse engineering the application, we know the value, so it's easy for us to calculate a and b polynomials. So only one share is enough to compute the seed. This means a malicious application can extract YOUR seed from the phone of *any* of your trusted contacts.</blockquote>

=== Sidechannels ===

Virtual all (all?) existing SSS implementations are completely unhardened against EMI/DPA side-channels, many are unhardened against simple timing sidechannels. Competent key generation and signing software goes through significant efforts to avoid leaking private keys to observers who can monitor your timing or RF emissions, but SSS software will just go ahead and leak this information. In particular, any scheme that implements sharing with a general bignum library will end up with timing side-channels.

=== Unique benefits against fantasy threat models ===

SSS's unusual information theoretic properties also makes it possible to "deny shares". Imagine you have a N of M split secret and some attacker finds N-1 of the shares and using a $5 wrench they demand that you provide an additional share so they could get the secret. In theory, with SSS you could compute another share to forge any outcome, so instead of the real secret they get a fake one of your choice! However you can only compute a specific forgery if you know the shares they already possess. It would be difficult for even Hollywood scriptwriters to come up with a situation where you'd have both access to those shares and an opportunity to compute something. Without the shares the best you could do would be to give them a fake value which would decode to something random, and almost all SSS implementations add some kind of error detection to detect false decodes which would reveal your games. Moreover, many SSS implementations don't use actual randomness-- e.g. they hash the secret to generate the random values, so that multiple runs produce the same shares-- which can allow detection any kind of share forging, even if the gods of implausible movie scripts smiled on you and gave you a copy of their shares. And finally, SSS implementations never actually provide a usable forging tool and so using forgery or even an argument that someone could have plausibly forged a share as a defence is simply fantasy.

== What could SSS sensibly be used for? ==

SSS sometimes shows up as an internal building block inside other cryptographic protocols for multiparty computation. In these cases the user isn't directly exposed to the SSS and it's much more likely to have been implemented correctly because the complexity of the overall protocol set a higher bar for implementations. In these cases it's a perfectly fine construct, but also in these cases the user will almost certainly never hear the words shamir secret sharing.

Shamir Secret Snakeoil

2019-11-04T06:42:18Z

Gmaxwell: on why implementations often don't generate their randomness randomly.

Shamir Secret Sharing seems to be mysteriously attractive to people: The idea of splitting up a secret into multiple parts and having a ritual to recombine them seems have an instinctive appeal to many.

Shamir's scheme is clever enough that programmers feel smart for being able to understand and implement it but it is not so clever that they give up before getting something working. Unfortunately, the difference between implementing it and implementing it correctly is substantial. Like all cryptographic techniques small errors can have devastating consequences. As a result many, perhaps the vast majority, of SSS implementations are flawed. In some cases the flaws are merely theoretical, compromising properties of SSS that don't matter in practice, but others have been flawed in ways that completely destroy the security. The user's reliance on false security then goes on to cause them to do things that can make them actually lose their funds.

As a generalization of the one time pad SSS, if implemented perfectly, has the unusual property of achieving information theoretic security: it's strong against attackers with unbounded computational power. This kind of "perfect security" adds to the mysterious appeal but this property is of essentially no practical use and seems to distract people from the fact that many attempts at SSS have been so weak a child's speak-n-spell could crack them. Like the one-time-pad and most other cryptosystems, the security of SSS is fairly brittle.

In Bitcoin, Shamir Secret Sharing by itself has almost no valid use: Most threat models that could be defended using SSS are _much_ better defended by multisig particularly because recombining shares of a private on a device leave the key exposed to malware or a malicious user of the device which are usually the most important threats to protect against. If you have a device which is guaranteed to be free of malware operated by a user guarenteed to be uncorrupt, you could just leave the private key there and dispense with the SSS ritual-security-theatre. Bitcoin products that advertise SSS are often snake-oil and the same thoughtlessness that caused the marketing of SSS probably signals poor security.

Most the time safe bitcoin key material can be backed up more safely by simply making multiple copies. Vulnerability of any one backup to theft can be protected against using multisig.

== Examples of Shamir Secret Snakeoil ==

Errors in SSS implementations are not usually the fault of an unusual incompetence in their developers. Correctly implementing cryptographic functions is *hard* but SSS is in a particular sweet spot where-- like most crypto functions-- it is hard to implement correctly that it's interesting to try but also easy enough to implement at all.

Simply avoiding the mistakes listed here will not make an implementation secure. A secure implementation of any cryptosystem starts with a careful analysis of the costs and benefits and often SSS does not make the cut.

=== Armory ===

Bitcoin Armory, a previously popular Bitcoin wallet used a N of M secret sharing for backing up users private keys. The implementation used repeated hashing of data instead of a random number generator and that combined with other errors completely breaks the scheme. [https://bitcointalk.org/index.php?topic=2199659.0 The result] is that regardless of the requested threshold an attacker with the first share and any other share could recover the secret (or alternatively the N-th share plus any N additional ones).

=== HTC Exodus phone ===

HTC exodus phone backs up users keys by splitting them 3 of 5 to your phone contacts but [http://diyhpl.us/wiki/transcripts/breaking-bitcoin/2019/extracting-seeds-from-hardware-wallets/ totally failed to deliver the advertised security]:

<blockquote>They implemented Shamir secret sharing by sharing the 256 bit seed (32 bytes) with 32 different polynomials of degree 2, and then it evaluates it in 5 points and sends the shares. The coefficient a,b are randomly generated with a PRNG and must be kept secret.

The problem with HTC's implementation is that the PRNG update operation is linear and not updated well. Both a and b are linearly dependent. Instead of ending up with a polynomial that they expected, they end up with a different one which has a linear dependency between the coefficients. [...] You only need to compromise 2 different trusted contacts, then you get their shares and you're able to get the seed. So one trusted contact can collude with another and retrieve the value of the seed. This is really bad.

In firmware v1.54.2401.6, the PRNG is seeded with a fixed value. By reverse engineering the application, we know the value, so it's easy for us to calculate a and b polynomials. So only one share is enough to compute the seed. This means a malicious application can extract YOUR seed from the phone of *any* of your trusted contacts.</blockquote>

=== Sidechannels ===

Virtual all (all?) existing SSS implementations are completely unhardened against EMI/DPA side-channels, many are unhardened against simple timing sidechannels. Competent key generation and signing software goes through significant efforts to avoid leaking private keys to observers who can monitor your timing or RF emissions, but SSS software will just go ahead and leak this information. In particular, any scheme that implements sharing with a general bignum library will end up with timing side-channels.

=== Unique benefits against fantasy threat models ===

SSS's unusual information theoretic properties also makes it possible to "deny shares". Imagine you have a N of M split secret and some attacker finds N-1 of the shares and using a $5 wrench they demand that you provide an additional share so they could get the secret. In theory, with SSS you could compute another share to forge any outcome, so instead of the real secret they get a fake one of your choice! However you can only compute a specific forgery if you know the shares they already possess. It would be difficult for even Hollywood scriptwriters to come up with a situation where you'd have both access to those shares and an opportunity to compute something. Without the shares the best you could do would be to give them a fake value which would decode to something random, and almost all SSS implementations add some kind of error detection to detect false decodes which would reveal your games. Moreover, many SSS implementations don't use actual randomness-- e.g. they hash the secret to generate the random values, so that multiple runs produce the same shares-- which can allow detection any kind of share forging, even if the gods of implausible movie scripts smiled on you and gave you a copy of their shares. And finally, SSS implementations never actually provide a usable forging tool and so using forgery or even an argument that someone could have plausibly forged a share as a defence is simply fantasy.

== What could SSS sensibly be used for? ==

SSS sometimes shows up as an internal building block inside other cryptographic protocols for multiparty computation. In these cases the user isn't directly exposed to the SSS and it's much more likely to have been implemented correctly because the complexity of the overall protocol set a higher bar for implementations. In these cases it's a perfectly fine construct, but also in these cases the user will almost certainly never hear the words shamir secret sharing.

BTCMine

2019-06-10T02:15:08Z

Gmaxwell: fix links

A [[Pooled mining|mining pool]] which offers shared block payout as well as pay per share payout.

The service was first available for alpha testing starting March 08, 2011<ref>[http://bitcointalk.org/?topic=4251.0 BTCMine - new shared mining pool]</ref>.

==See Also==

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

==External Links==

* [http://btcmine.com BTCMine] web site

==References==
<references />

[[Category:Pool Operators]]

ToyTrader

2019-06-10T02:10:28Z

Gmaxwell: fix links

{{infobox software
|author=toyotasupra
|released=May 19, 2011
|language=PHP
|github=toyotasupra/ToyTrader
}}'''ToyTrader''' was an open source command line trading tool for [[Mt. Gox]] first released on May 19, 2011.<ref name="op">[http://bitcointalk.org/index.php?topic=8968.0 ToyTrader - a daytrading command line tool for mtgox]</ref> There was never a subsequent release<ref name="op"/> and it ceased functioning after the closure of Mt. Gox.

==External Links==

* [http://github.com/toyotasupra/ToyTrader ToyTrader on Github]

==References==
<references />

[[Category:Mt. Gox]]
[[Category:Barely notable subjects]]
{{article}}
{{stub}}

GPU overclocking tools

2019-06-10T02:09:52Z

Gmaxwell: fix links

[[Category:Mining]]

With these tools it is possible to change the clock speeds of Radeon graphic cards to increase hashrate and thus mining profitability.

Usually core clock is increased and memory clock is decreased to lower temperatures and save power.

==Windows==
* '''AMD GPU clock tool''' - GUI / command line, http://www.techpowerup.com/downloads/1128/AMD_GPU_Clock_Tool_v0.9.8.html
* '''AMD / ATI Tray Tools''' - GUI, http://www.guru3d.com/article/ati-tray-tools-/
* '''ClockTweak''' - Command line, not free, multiple cards, http://bitcointalk.org/index.php?topic=9982.0
* '''EVGA Precision''' - Nice GUI, multiple cards supported (can use others than EVGA cards), supports multi-CPU setups, change clock settings for memory and other setting, new integrated GPU Voltage Tuner, http://www.evga.com/precision/
* '''MSI Afterburner''' - Fancy GUI, multiple cards, needs to be unlocked, some problems with multi GPU setups http://event.msi.com/vga/afterburner/
* '''RBE Radeon BIOS editor''' - GUI, can also be used to overclock, http://www.techpowerup.com/rbe/
* '''Sapphire TriXX''' - GUI, Works very well for multi GPU setups with or with or without crossfire. http://www.sapphiretech.com/ssc/TriXX/

==Linux==
* '''AMDOverdriveCtrl''' - GUI, http://sourceforge.net/projects/amdovdrvctrl/

==MacOS==
...

Mining Team Reddit

2019-06-10T02:09:43Z

Gmaxwell: fix links

'''Mining Team Reddit''', shortened to '''MtRed''' or '''Mt. Red''', was a [[Pooled mining|mining pool]] for [[/r/Bitcoin]] users. This pool paid out using a proportional share reward system (your shares / total shares for the round) = % share of the rewards.

The pool was opened in May 2011<ref>[http://bitcointalk.org/index.php?topic=9911.0 Eu.MtRed.com - Beta Testing my Hacks on PushPool]</ref> and was later reorganized into a [[BTC Guild]] team as mining became more competitive.

==See Also==

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

==Exernal Links==

* [http://mtred.com/index.php?r=site/page&view=about Mining Team Reddit] pool

==References==
<references />
{{Pools}}
[[Category:Pool Operators]]

Work For Bitcoin

2019-06-10T02:09:37Z

Gmaxwell: fix links

A job board that includes full time, part time, temporary and freelancer opportunities.

This service was launched on May 25, 2011<ref>[http://bitcointalk.org/index.php?topic=9803.0 Work for bitcoin!]</ref>.

==See Also==

* [[:Category:Freelancers|Freelancers]]
* [[For Bitcoin]]
* [[BitGigs]]
* [[Bitcoiners]]
* [[BTCworkers]] Bitcoin freelancing board with payment escrow.
* [[XBTFreelancer]] A bitcoin freelancers site - get paid bitcoin for doing freelance jobs

==External Links==

* [http://workforbitcoin.com Work For Bitcoin] web site

==References==
<references />

[[Category:For Hire]]

Bitcoin Cashout

2019-06-10T02:09:32Z

Gmaxwell: fix links

Formerly a fixed-rate exchange operated by [[Bitcoin Solutions]] allowing you to trade bitcoins for virtual prepaid cards.

==History==

This site was announced on May 02, 2011<ref>[http://www.bitcoin.org/smf/index.php?topic=7067.0 Announcing: BitcoinCashout.com]</ref>. The service was acquired by [[Bitcoin Solutions| Bitcoin Solutions LLC]] on May 24th, 2011<ref>[http://bitcointalk.org/index.php?topic=9665.0 Big Moves - Great Changes - Outstanding Service - Bitcoin Solutions LLC]</ref>. The service showed "sold out" for many month and as-of April 16, 2012 the site is offline.

==See Also==

* [[Buying bitcoins]]
* [[Selling bitcoins]]
* [[Bitcoin Solutions]]

==References==
<references />

TheBitcoin.us

2019-06-10T02:09:28Z

Gmaxwell: fix links

Provides a general overview of Bitcoin with links to the more popular components in several categories (e.g., mining, exchanges, etc.) related to Bitcoin.

The site was launched on May 23rd, 2011<ref>[http://bitcointalk.org/index.php?topic=9520.0 http://thebitcoin.us another generic information site]</ref>

==See also==

* [[:Category:Introduction|Introduction]]
* [[BitcoinMe]]

==External Links==

* [http://thebitcoin.us TheBitcoin.us] web site.

==References==
<references />

[[Category:Introduction]]

Open Source FPGA Bitcoin Miner

2019-06-10T02:09:23Z

Gmaxwell: fix links

A miner that makes use of a compatible FPGA Board. The miner works either in a [[Pooled Mining|mining pool]] or solo.

This is the first open source FPGA Bitcoin miner. It was released on May 20, 2011<ref>[http://bitcointalk.org/index.php?topic=9047.0 Official Open Source FPGA Bitcoin Miner (Just Released!)]</ref>.

== Software needed ==

Currently programming and running the FPGAminer code requires Quartus II for Altera devices and Xilinx ISE Webpack for Xilinx devices. Quartus is 32bit only. The free ISE Webpack does not work on devices larger then Spartan6 LX75.

== Compiling ==

=== Altera ===

The compile the code on an different Altera device then DE2-115, you need to set the Device to be the correct one. Find the correct fpga package number and add it, for the DE0-Nano this is EP4CE22F17C6. Be sure to select the correct one, because the hardware effects the location of your pins, which you will need in the clock pin step.

To get the provided code to compile on a smaller device, you need to set CONFIG_LOOP_LOG2 to a value between 0-5. Higher values shrink the size in so that 4 does approx. 12000 LUTs large program, while 0 is around 90000 LUTs. CONFIG_LOOP_LOG2 is set in the file fpgaminer.qsf. The fpgaminer_top.v file also has a similar setting, but it is an ifdef/it does not get set from there if the setting exists in the qsf.

To make the code compile properly on an different device (not a DE2-115), you need to set the osc_clk pin to the clock pin of your device. ''This can be read from the device manual''! On an DE0-Nano this pin is PIN_R8. This pin location varies between devices and you ''must'' look it up in your device manual. To set the pin location, open the assignment editor add new osc_clk and set its location to the pin ''specified in your manual'', ie. for DE0-nano this is R8. For the DE2-115 this is PIN_Y2.

=== Changing the clock speed ===

NOTE: You can fry your FPGA doing this!

Edit main_pll.v and find the line:
altpll_component.clk0_multiply_by = 5,

The way the Mhz is calculated is 50Mhz*multply_by/divide_by. Setting of 10 with default clk0_divide_by gives Mhz of 100, 8 is 80Mhz.

Compile the code.

Watch for critical warnings from synthesis.

Run Powerplay power analyzer tool and set it with the cooling system you have. If there are no errors, you may at your own risk program the FPGA with the higher Mhz bitfile.

== Programming the FPGA ==

On linux you need to set udev rules for the UsbBlaster cable to work. Under arch these are under /etc/udev/rules.d/ add a file called 51-altera.rules.

#####altera usb blaster
BUS=="usb", SYSFS{idVendor}=="09fb", SYSFS{idProduct}=="6001", MODE="0666", SYMLINK+="usbblaster"

=== Altera ===
Copy the .sof file from the quartus output directory under your project directory to the scripts/program directory and execute <path>/quartus_stp -t program.tcl, then select the device you want programmed and then the sof file you moved to the directory.

=== Using urjtag ===

(unconfirmed to work, lights blink though)

$ sudo jtag

> cable UsbBlaster

> bsdl path /usr/share/urjtag/bsdl/EP4CE22F17C6_pre.bsd

> detect

> svf fpgaminer.svf

== Mining ==

=== Altera ===

The new mining and programming scripts find the connected devices now. Just edit the config.tcl to have your details.

==See Also==

* [[Pooled Mining|Mining Pool]]

==External Links==

* [http://github.com/progranism/Open-Source-FPGA-Bitcoin-Miner Open-Source-FPGA-Bitcoin-Miner] project on GitHub
* [http://www.bitcoinmining.com/bitcoin-mining-software/ Bitcoin Mining Software]

==References==
<references />

[[Category:Miners]]
[[Category:Open Source]]

RPCminer.app

2019-06-10T02:09:18Z

Gmaxwell: fix links

A application-packaged frontend for [[RPC Miner]] that can be run on Mac OS 10.6 or higher.

Double-click on the icon to start mining. Yields 1100–1400 khash/s on a recent MacBook Air and Mac Mini (2011 models).

Features integration with Mac OS APIs and systems such as user defaults for storing configuration, LaunchAgents, and more.

The project was announced on May 19, 2011<ref>[http://bitcointalk.org/index.php?topic=8994.0 ‘GUI’ miners for Mac (Diablo GPU and RPCminer CPU)]</ref> The project’s goal is to provide a self-contained binary download in a standard Mac packaging that is ready for use by the end-user.

==Download==
* [http://ul.to/kxr9ydrj DiaboloMiner.app] (MD5 SUM: 98bdbbbcec9c094769c308cbd146e65e)
* [http://ul.to/49dw65r3 RPCminer.app (64bit binary)] (MD5 SUM: eb7bdf83dcbf18c5b3fe7c6853ce6293)

==See Also==

* [http://github.com/codykrieger/gfxCardStatus gfxCardStatus] utility

==External Links==

* [http://bitcointalk.org/index.php?topic=8994.0 Official forum thread] with links to download files
* [http://maccoinminer.wordpress.com/2011/05/20/rpcminer-for-mac/ Walk-through] for setting up [[pooled mining]]
* [http://www.bitcoinmining.com/bitcoin-mining-software/ Bitcoin Mining Software]

==References==
<references />

[[Category:Miners]]
[[Category:Open Source]]

DiabloMiner.app

2019-06-10T02:09:10Z

Gmaxwell: fix links

A application-packaged frontend for [[DiabloMiner]] that can be run on Mac OS 10.6 or higher.

Double-click on the icon to start mining. Yields 5800–7200 khash/s on a recent MacBook Air and Mac Mini (2011 models).

Features integration with Mac OS APIs and systems such as user defaults for storing configuration, LaunchAgents, and more.

The project was announced on May 19, 2011<ref>[http://bitcointalk.org/index.php?topic=8994.0 ‘GUI’ miners for Mac (Diablo GPU and RPCminer CPU)]</ref> The project’s goal is to provide a self-contained binary download in a standard Mac packaging that is ready for use by the end-user.

==See Also==

* [[RPCminer.app]]
* [http://github.com/codykrieger/gfxCardStatus gfxCardStatus] utility

==External Links==

* [http://bitcointalk.org/index.php?topic=8994.0 Official forum thread] with links to download files
* [http://maccoinminer.wordpress.com/2011/05/20/diablominer-for-mac/ Walk-through] for setting up [[pooled mining]]

==References==
<references />

[[Category:Miners]]
[[Category:Open Source]]

Magento Payment Gateway Plugin

2019-06-10T02:07:42Z

Gmaxwell: fix links

The Magento Payment Gateway Plugin for Bitcoin [[API reference (JSON-RPC)|RPC API]] provides the ability for eCommerce sites running Magento to be able to accept bitcoins for payment.

This open source project was released on June 11, 2011<ref>[http://bitcointalk.org/index.php?topic=8880.msg203426#msg203426 Bitcoin Payment Module for Magento]</ref>.

==External Links==

* [http://github.com/jalder/Magento-Bitcoin-Payment-Module Magento-Bitcoin-Payment-Module] project on GitHub
* [https://github.com/BitPagos/bitpagos-magento Magento Bitcoin Payment Module] for [https://www.bitpagos.net BitPagos]
* [https://www.btcmerch.com/help/magento Bitcoin/Altcoins Plugin for Magento] developed by BTCMerch.
* [https://coingate.com/plugins/magento CoinGate Magento Bitcoin Plugin] enables any Magento website to accept Bitcoin payments and receive payouts not only in Bitcoin, but also in Euros or U.S. Dollars straight to your bank account or PayPal without risk of price volatility. [https://blog.coingate.com/2017/05/install-magento-bitcoin-altcoins-plugin/ Visual guide for setup].

==References==
<references />

[[Category:Shopping_Cart_Interfaces]]

Spend Bitcoins

2019-06-10T02:07:35Z

Gmaxwell: fix links

A service that provides exchange allowing bitcoins to be purchased or to be spent through a variety of methods to cash out.

==Buy==

===AUD===

* Cash deposit at NAB, Commonwealth Bank, Westpac and ANZ.

==Sell==

* Online Payments Service (You provide the URL, Spend Bitcoins will make the payment)
* Bank transfer (AUD) to NAB, Commonwealth Bank, Westpac and ANZ.
* International bank wire transfer
* AustPost reloadable VISA (AUD)
* Bill Payment (Australian bill payment services)

===Gift cards===

====eCode Card====

* Fishpond (AUD)

====Physical Card====

* Coles Myer Group (redeemable at Coles Myer stores and others, in AUDs)

==History==

The service was launched on May 18, 2011<ref>[http://bitcointalk.org/index.php?topic=8864.0 Spend your bitcoins on amazon with no transaction fees]</ref>. Also sometimes referenced as SpendBitcoins.

On August 7th, 2012, the service stopped support for U.S. retailers, citing the costs due to regulatory obstacles<ref>[https://spendbitcoins.zendesk.com/entries/21806042-spend-bitcoins-out-of-the-us-market Spend Bitcoins out of the US market - Australia only for now]</ref>.

==See Also==

* [[Selling bitcoins]]
* [[Buying bitcoins]]

==External Links==

* [http://spendbitcoins.com SpendBitcoins.com] web site

==References==
<references />

[[Category:Services]]
[[Category:Exchanges]]

BTC Network

2019-06-10T02:07:29Z

Gmaxwell: fix links

An informational site.

The site had announced plans to sell Vanilla VISA prepaid gift cards in exchange for Bitcoins on May 18, 2011<ref>[http://bitcointalk.org/index.php?topic=8857.0 NEW - BTC - Vanilla Visa(c) Service]</ref>.

The BTC Network is an informational site for bitcoin mining and trading. There are links to find information on bit coin mining pools, mining software and hardware.

==External Links==

* [http://www.btcnetwork.com BTC Network] web site

==References==
<references />

Browser Bitcoin Miner

2019-06-10T02:07:25Z

Gmaxwell: fix links

Browser based mining is the practice of utilizing web browsers as bitcoin miners through means of plugins or scripts.

== Introduction ==

This concept was first reached by Bitcoin Plus, a [[cpu-miner|cpu miner]] that is launched from the browser, requires no installation, and runs as a Java application.

==[[Bitcoin Plus|Bitcoin Plus]] Implementation==

The miner connects to a pool and the payout method is pay-per-share. The pool's fee is 3%.

Requires Java 1.5 or higher. This miner app is not open source.

This software was announced on May 18, 2011<ref>[http://bitcointalk.org/index.php?topic=8780.0 Browser Bitcoin Miner (No setup, no download, no configuration)]</ref>.

* [[Why a GPU mines faster than a CPU]]

==External Links==

* [http://www.bitcoinplus.com http://bitcoinplus.com] web site

==References==
<references />

[[Category:Distributed Miners]]

Continuum

2019-06-10T02:07:17Z

Gmaxwell: fix links

A [[Pooled mining|mining pool]].

This pool pays out using a proportional share reward system (your shares / total shares for the round) = % share of the rewards. There is also an optional pay per share.

The service was first available on May 17, 2011<ref>[http://bitcointalk.org/index.php?topic=8660.0 Continuum Mining Pool: No fees; Optional PPS; Client uptime monitoring]</ref>.

PPS was discontinued on June 21, 2011 <ref>[http://bitcointalk.org/index.php?topic=8660.msg254208#msg254208 Operator announces PPS is discontinued]</ref>. Pay per share fee was 5%.

==Reward distribution==

* Proportional: 0% fee.

==See Also==

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

==External Links==

* [http://www.continuumpool.com Continuum] web site

==References==
<references />

[[Category:Pool Operators]]

Swepool

2019-06-10T02:07:11Z

Gmaxwell: fix links

a [[Pooled mining|mining pool]].

The service was first available on May 14, 2011<ref>[http://bitcointalk.org/index.php?topic=8288.0 Swepool.net Pay-Per-Share, LP, JSON-API, SSL, Email Notify, Super Low Variance!]</ref>.

This pool was paying out using a pay per share reward system, but it switched to proportional system<ref>[https://swepool.net/news Swepool switching to propotional]</ref>.

This pool is now a p2pool.

==Reward distribution==

* Proportional, 1% fee.

==See Also==

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

==External Links==

* [http://swepool.net Swepool] web site

==References==
<references />

[[Category:Pool Operators]]

Millibit

2019-06-10T02:07:05Z

Gmaxwell: fix links

'''MilliBit''' was name chosen by popular vote in poll on the Bitcoin forum to represent the SI unit of 0.001 bitcoins (BTCs). The poll was announced on May 14, 2011 to come to an agreement of the most commonly used name.<ref>[http://bitcointalk.org/index.php?topic=8282.0 What to call 0.001 BTC?]</ref> With the market exchange rate nearing $10 USD per BTC, a name for the sub-BTC unit was needed. The subunit later steered toward simply '''millibit'''. Other commonly used names are '''millibitcoin''', '''millicoin''', and '''millie'''.

A milli is the International System of Units (SI) prefix representing one thousandth (1/1000th)<ref>[http://en.wikipedia.org/wiki/SI_prefix#List_of_SI_prefixes SI prefix]</ref>.

==Examples==

* One thousand millibits refers to 1 bitcoin or 1 BTC.
* Twenty seven millibits refers to 0.027 BTC.
* 1.375 BTC may be referred to as one bitcoin and three hundred seventy-five millibits, or in more common notation, simply one thousand three hundred seventy-five millibits..

==Criticism==

"Millibit" does not follow the SI standard verbatim, so at best this is an ad-hoc naming convention.

The poll was concluded without participation by a majority of the Bitcoin community nor even was there a statistically significant sample of votes from the community.

==See Also==

* [[Units]]
* [[Bit]]

==References==
<references />

BitTicker

2019-06-10T02:06:56Z

Gmaxwell: fix links

{{offline}}
An open source stock ticker app for Mac OS X.

The software was announced on May 14, 2011<ref>[http://bitcointalk.org/index.php?topic=8220.0 BitTicker: A Mt. Gox "stock ticker" for Mac, and soon also iPhone and iPad]</ref>. The author plans to make the tool available on iPhone and iPad as well.

==See Also==

* [[MtGox#Data_Services|Mt. Gox Data Services]]

==External Links==

* [http://github.com/mrsteveman1/BitTicker-Mac BitTicker-Mac] project on GitHub
* [https://github.com/downloads/mrsteveman1/BitTicker-Mac/BitTicker.zip BitTicker] download

==References==
<references />

[[Category:Open Source]]

BTC Guild

2019-06-10T02:06:49Z

Gmaxwell: fix links

{{infobox company|name=BTC Guild|image=[[File:BTCGuild.png|256px]]
|trading_name=BTC Guild
|industry=[[Mining pool]]
|founder=[[Eleuthria]]
|foundation=May 9, 2011
|hashrate=15.2 PHash/s
|website=http://www.btcguild.com
}}'''BTC Guild''' is a [[Pooled mining|mining pool]] which offers proportional ([[PPLNS]]) based rewards, where your reward is equal to the block value, multiplied by your valid shares submitted during the round. The pool does not take a fee from each block solved, and calculates rewards to the full 8 decimal points supported by the Bitcoin protocol. The pool is run off the donations of users, and is offering premium services at different donation levels to encourage users to donate a small percentage of their rewards. Donations are taken from the individual user's reward when a block is calculated.

2.5% donators (calculated on a per block basis) are able to claim their rewards without waiting for 120 confirmations of the block. This also acts as invalid protection, similar to [[DeepBit]], where a user can claim rewards even if the block is later invalidated/orphaned by the network.

The [[coinbase]] signature for this pool is: "Mined by BTC Guild"<ref>[https://blockchain.info/tx/0a04176e074d1bc651e969929b866b8d04104a964332c96fb6913ab863e2dac0 Example of decoded coinbase]</ref>.

BTC Guild first opened up on May 9th, 2011.<ref>[http://bitcointalk.org/index.php?topic=7760.0 BTC Guild - 0% Fee Pool, Long polling, JSON API, invalid insurance]</ref> It is currently for sale and a possible buyer has been found. There is a 90 day notice period. If the sale does not go through, another 90 day notice period will be announced. 30 days for the pool to stop operation and an additional 60 days for users to withdraw their mining proceeds<ref>https://bitcointalk.org/index.php?topic=49417.msg9395478#msg9395478</ref>.

== Closure ==
On June 15th, 2015, it was announced<ref>https://bitcointalk.org/index.php?topic=49417.msg11628010#msg11628010</ref> that BTC Guild will be shutting down on June 30th, 2015. Its operator - Eleuthria - cited concerns over low percentage of network hashrate vs funds in a hot wallet, the [[New York Bitlicense]] and possible but difficult to prove gaming of the pool by miners.

==See Also==

* [[Pooled Mining]]

==External Links==

* [http://www.btcguild.com BTCGuild] web site

==References==
<references />

[[Category:Pool Operators]]
{{Pools}}

WHMCS-Bitcoin-Payment-Module

2019-06-10T02:06:39Z

Gmaxwell: fix links

A script that adds functionality comparable to a shopping cart interface to WHMCS, a billing solution for online businesses.

This open source software was released May 08, 2011<ref>[http://bitcointalk.org/index.php?topic=7612.0 WHMCS Bitcoin Payment Gateway]</ref>.

Requires a bitcoind rpc server to be running remotely or locally.

==External Links==

* [https://github.com/jalder/WHMCS-Bitcoin-Payment-Module WHMCS-Bitcoin-Payment-Module] project on GitHub

==References==
<references />

[[Category:Shopping Cart Interfaces]]

Bitcoin Days Destroyed

2019-06-10T02:06:33Z

Gmaxwell: fix links

Bitcoin Days Destroyed is a measure of the transaction volume of Bitcoin. <ref>[http://bitcointalk.org/index.php?topic=6172.msg90789#msg90789 ByteCoin's Proposal to use Bitcoin Days Destroyed as a measure of transaction volume]</ref> A bounty for a script to compute the Bitcoin Days Destroyed by the transactions in a block has been awarded. <ref>[http://bitcointalk.org/index.php?topic=9300.0 Bounty Award to develop a script to compute the BitcoinDays Destroyed by the transactions in a block.]</ref> [[Abe]] is a [[block chain browser]] that computes this statistic in real time.

==Calculation==

Bitcoin days destroyed for any given transaction is calculated by taking the number of Bitcoins in a transaction and multiplying it by the number of days it has been since those coins were last spent.

===Example===

If someone has 100BTC that they received a week ago and they spend it then 700 bitcoin days have been destroyed. If they take those 100BTC and send them to several addresses and then spend them then although the total transaction volume could be arbitrarily large the number of bitcoindays destroyed is still 700.

==Graph of Percentage of Bitcoin Days Destroyed==

Percentage of Bitcoin Days destroyed vs block number, as of June 17th 2011.
[[File:June-17th-days-destroyed.png]]

==See Also==

* [[Abe]] Alternate Block Explorer

==References==
<references/>

[[Category:Economics]]

BitcoinExchange Services

2019-06-10T02:06:19Z

Gmaxwell: fix links

A former fixed-rate exchange providing cashout services.

Note - multiple forum posts are reporting that delivery of bitcoins or sale proceeds from this exchange are not being received.<ref>[http://bitcointalk.org/index.php?topic=36789.0 New member here. Worried i got scammed.]</ref>, <ref>[http://bitcointalk.org/index.php?topic=6223.msg433997#msg433997 www.BitcoinExchange.cc - Western Union, MoneyGram, MoneyPak, ACH/Wire, Dwolla]</ref>.

The operator stated that offices are in Florida<ref>[http://bitcointalk.org/index.php?topic=6125.msg91752#msg91752 Ethical Hacking & Security Consultation Services]</ref>.

==History==

The exchange has been in operation since April 2011<ref>[http://bitcointalk.org/index.php?topic=6223.0 BitcoinExchange Services]</ref>. The operator had continued to solicit new orders though customer complaints continued to be the result<ref>[http://bitcointalk.org/index.php?topic=6223.msg831280#msg831280 www.BitcoinExchange.cc - Western Union, MoneyGram, MoneyPak, ACH/Wire, Dwolla]</ref>

==References==

<references />

[[Category:Defunct exchanges]]

Wallet

2019-06-10T02:06:12Z

Gmaxwell: fix links

A Bitcoin '''wallet''' is a collection of private keys but may also refer to [[Clients|client software]] used to manage those keys and to make transactions on the Bitcoin network.

This page covers various wallet formats in use.

=== [[Bitcoin Core]] ===

The original Bitcoin client stores private key information in a file named '''wallet.dat''' following the so called [https://bitcointalk.org/index.php?topic=4448.0 "bitkeys"] format.

It contains:

* keypairs for each of your [[address|addresses]]
* transactions done from/to your addresses
* user preferences
* default key
* reserve keys
* [[Accounts_explained|accounts]]
* a version number
* [[Key pool]]
* Since 0.3.21: information about the current best chain, to be able to rescan automatically when restoring from a backup.

The wallet.dat file is located in the [[data directory|Bitcoin data directory]] and may be [[Wallet_encryption|encrypted with a password]].

It is intended that a wallet file be used on only one installation of Bitcoin at a time. Attempting to clone a wallet file for use on multiple computers will result in "weird behavior"<ref>[http://bitcointalk.org/index.php?topic=5324.msg77896#msg77896 Multiple instance of bitcoin with the same wallet]</ref>.

The format of this file is Berkeley DB. Tools that can manipulate wallet files include [[pywallet]].

=== [[Armory]] ===

The Armory client uses a custom [[Deterministic wallet]] format [https://www.bitcoinarmory.com/wallet-format/ described here] and runs on top of [[Bitcoin Core]].

=== [[Bitcoin Wallet]] ===

[[File:bitcoin_wallet.png|192px]] Bitcoin Wallet uses the bitcoinj [http://code.google.com/p/protobuf/ protobuf] format for its wallet file. However, due to Android isolation of applications, it is impossible to access the wallet file as a non-root user.

=== [[Blockchain.info#Wallet|Blockchain.info]] ===

Blockchain.info offers a [[Browser-based_wallet#Hybrid_e-wallets|hybrid eWallet]] called "My Wallet". It use a plain text [https://blockchain.info/wallet/wallet-format JSON wallet format]. Private keys Keys are stored in base58.

=== [[Denarium.com]] ===

Denarium is Physical Bitcoin coin manufacturer. Denarium produces easy, handy and secure wallets in a coin form. The private key is stored under a security seal without password protection. Denarium also offers a trustless multisignature coins, which eliminates the need to trust the manufacturer.

=== [[Ledger Wallet]] ===

Ledger Wallet manufactures various hardware wallets.

=== [[Multibit]] ===

Multibit HD (the current version) uses a [[BIP 0032]] (type 2) [[Deterministic wallet]] with the [https://www.multibit.org/en/help/hd0.1/files.html format described here]. The "Classic" version used the bitcoinj [https://github.com/google/protobuf protobuf] wallet file.

=== [[Blocktrail]] ===

Blocktrail offers a [[BIP 0032]] (type 2) [[Deterministic wallet]] and for added security also implements [[Multisignature]] wallet technology.

=== [[TREZOR]] ===

TREZOR is an isolated hardware environment for offline transaction signing and using a small display you can visually verify the transaction contents.

=== [https://opendime.com Opendime] ===

Opendime is a small USB stick that allows you to spend Bitcoin like a dollar bill. Pass it along multiple times. Connect to any USB to check balance. Unseal anytime to spend online. Trust no one.

==See Also==

* [[Transaction fees]]
* [[Securing your wallet]]
* [[EWallet]]
* [[Deterministic Wallet]]
* [https://bitcoin.org/en/choose-your-wallet Choose your wallet]

==References==
<references />

What is Bitcoin?

2019-06-10T02:06:05Z

Gmaxwell: fix links

The most-widely known video that introduces Bitcoin.

The video was created following a bounty offer for an animated movie.<ref>[http://bitcointalk.org/index.php?topic=697.0 Bounty for Bitcoin Animated Movie]</ref> The video was posted on YouTube on March 22, 2011.<ref>[http://www.youtube.com/watch?v=Um63OQz3bjo What is Bitcoin?] </ref> The bounty was awarded to JustMoon and the 8,511.96 BTC award was distributed on April 05, 2011.<ref>[http://bitcointalk.org/index.php?topic=5140.msg79199#msg79199 Does WeUseCoins Deserves the Full Bounty?]</ref>

The award recipient created the [[Bitcoin Marketing Fund]] and donated most of the bounty award proceeds to the fund.

==External Links==

* [http://www.youtube.com/watch?v=Um63OQz3bjo What is Bitcoin?] video on YouTube
* [http://www.youtube.com/watch?v=2kPNz0tdlj0 What is Bitcoin? (German)] video on YouTube
* [http://www.youtube.com/watch?v=QSUJqb33Sd8 What is Bitcoin? (Italian)] video on YouTube
* [http://www.youtube.com/watch?v=IdWgvOxjYi8 What is Bitcoin? (Russian)] video on YouTube

==References==
<references />

[[Category:Introduction]]
[[Category:Marketing]]
{{italicTitle}}

MyBitcoin

2019-06-10T02:03:57Z

Gmaxwell: fix links

'''MyBitcoin''' was one of the earliest [[eWallet]] providers for Bitcoin. It shut down near the end of July 2011. It was available at the URL http://www.mybitcoin.com, as well as via Tor but it has since been replaced with a statement explaining its shutdown.

==Shutdown==
[[File:MyBitCoin08042011.png|thumb|MyBitcoin shutdown notice]]
The site became inaccessible starting July 29, 2011<ref>[http://bitcointalk.org/index.php?topic=32900.0 mybitcoin down or just me?]</ref>.

The site has become accessible starting August 4th, 2011 but only to state that their shopping cart interface has been compromised and so they are having to go in to receivership. Soon afterwards, MyBitcoin issued a statement that it had been compromised and that 51% of its total bitcoin holdings had been stolen. It began a process to return the remaining 49% of each customer's balance.

==Criticism==
This service showed the name MyBitcoin LLC and a mailing address in Nevis. It is not known if this truly is an LLC and if so, where the organization was located. There has been no member of the Bitcoin community who has claimed any affiliation with MyBitcoin.

There has never been a way to verify the claim that all bitcoins from account balances are available. The [http://www.mybitcoin.com/legal/terms.php Terms of Service] do state:
:: <tt>6. OBLIGATIONS OF MYBITCOIN LLC 6.1 MYBITCOIN LLC will ensure that for all Bitcoins in circulation in the MyBitcoin System there is at all times an identical quantity of unencumbered Bitcoins held in MYBITCOIN LLC's master Bitcoin wallet.</tt>

==See Also==

* [[eWallet]]

==References==
<references />

SecureCoin

2019-06-10T02:03:29Z

Gmaxwell: fix links

Formerly an escrow-like service that allows safer payment by securely holding a buyer's coins in escrow until the terms of the sale are met and as a result the buyer releases payment to the seller. Furthermore there is an id verification service. Users can confirm their identity and share them with other users about so-called public IDs.

==History==

The site was launched on July 2011<ref>[http://bitcointalk.org/index.php?topic=32121.0]</ref>. On September 2011 the site merged with the Bitcoin trading portal & auction house [http://www.bitmit.net Bitmit].

==See Also==

* [[Secure Trading]]

==References==
<references />

My.bit.safe

2019-06-10T02:03:23Z

Gmaxwell: fix links

Formerly an escrow-like service that allows safer payment by securely holding a buyer's coins in escrow until the coins are released by the buyer.

If the coins are not released, they are donated to the [[Bitcoin Faucet]] after thirty days have passed. MyBitSafe provides no other dispute resolution services.

==History==

The site was launched on July 10th, 2011<ref>[http://bitcointalk.org/index.php?topic=27673.0 New Escrow Service - mybitsafe.com]</ref>. The service is defunct, as-of at least March 18th, 2012.

==See Also==

* [[Secure Trading]]

==References==
<references />

Bitcoin-android

2019-06-10T02:03:17Z

Gmaxwell: fix links

This app is not being maintained any more, and it doesn't implement the current Bitcoin p2p protocol. It requires a rooted phone and a lot of manual work to retrieve your coins from this app.

A client and wallet application for Android mobiles that allows bitcoins to be sent and received.

A message on the app's project page warns:
This app is still under development and may lose your coins! Test it with small amounts.

This app implements the Bitcoin protocol natively and does not require service from an RPC host or [[eWallet]]. This app is based on the [[BitCoinJ]] library.

==History==

This project was launched on July 6, 2011<ref>[http://bitcointalk.org/index.php?topic=26684.0 Bitcoin Android Released! ]</ref>.

==See Also==

* [[BitPay]]
* [[Bitcoin-js-remote]]
* [[BitcoinJS]]
* [[:Category:Mobile|Mobile]]

==External Links==

* [https://github.com/barmstrong/bitcoin-android Bitcoin-android] project page on GitHub

==References==
<references />

[[Category:Mobile]]
[[Category:Clients]]
[[Category:Frontends]]
[[Category:Open Source]]
[[Category:Android]]

Intersango

2019-06-10T02:03:11Z

Gmaxwell: fix links

'''Intersango''' was an [[currency exchange|exchange]] offering multiple trading markets for trading bitcoins against multiple currencies.

The service was launched on July 6, 2011<ref>[http://bitcointalk.org/index.php?topic=26543.0 Intersango.com EUR exchange is now live]</ref>. The Intersango [[:Category:Open Source|open source]] software that the exchange runs on was announced on March 17, 2011<ref>[https://bitcointalk.org/index.php?topic=4579.0 Free Bitcoin exchange software- Intersango]</ref>. In September, 2011 the exchange began using a new version of the Intersango open source exchange project with two currency markets (BTC/EUR, BTC/USD) live under the Intersango brand and plans made for the third (BTC/GBP) when [[Britcoin]] accounts are migrated at a future date.

On October 9, 2012, the exchange announced imminent plans to shutter its BTC/USD market. On December 19, 2012, the exchange closed its BTC/GBP market after being unable to re-establish a UK banking relationship<ref>[http://bitcointalk.org/index.php?topic=63877.msg1409989#msg1409989 Intersango Exchange (Closed BTC/GBP)]</ref>.

==See Also==

* [[Buying bitcoins]]
* [[Selling bitcoins]]

==External Links==

* [https://intersango.com Intersango] EUR exchange website
* [http://gitorious.org/intersango Intersango] exchange project on Gitorious

==References==
<references/>

[[Category:Defunct exchanges]]
[[Category:eWallets]]
[[Category:Offline]]

BitPiggy

2019-06-10T02:03:06Z

Gmaxwell: fix links

A fixed-rate [[currency exchange|exchange]] site serving those trading between bitcoins and Australian dollars (AUD).

The exchange rates offered are derived from the current market rates at [[MtGox]].

==Buying Bitcoins==

After receiving a confirmation e-mail an order size can be specified and sufficient bitcoins at that rate will be reserved. A bank transfer, in the amount specified for the order, must then be sent to the account specified by BitPiggy and once received the reserved bitcoins will be released.

==Selling Bitcoins==

After receiving a confirmation e-mail an order size can be specified. Upon receipt of confirmed bitcoin funds, a bank transfer to the account provided will be sent.

==History==

The service was announced May 8, 2011<ref>[http://bitcointalk.org/index.php?topic=7568.0 BitPiggy.com - new Australian Dollar <-> BitCoin exchange]</ref>. On July 1, 2011 the exchange announced plans to offer a Twitter-based payment system<ref>[http://bitcointalk.org/index.php?topic=7568.msg309339#msg309339 Re: BitPiggy.com - new Australian Dollar <-> BitCoin exchange]</ref>, <ref>[http://bitcointalk.org/index.php?topic=26493.0 Mobile payments + basic banking coming to BitPiggy.com]</ref>.

==See Also==

* [[Buying bitcoins]]
* [[Selling bitcoins]]

==External Links==

* [http://platform.bitpiggy.com/ BitPiggy] web site

==References==
<References />

[[Category:Exchanges]]

CampBX

2019-06-10T02:03:00Z

Gmaxwell: fix links

A bitcoin [[currency exchange]]/trading platform site headquartered in USA - Atlanta, GA.

[https://CampBX.com/ CampBX] is a platform where you can buy and sell Bitcoins for US Dollars in real-time using advanced order-matching algorithms. Any buy or sell order that you place is matched against a database of other orders. If a perfect match is found, a Bitcoin-to-USD trade is executed instantly. If there are no matching orders at the price you specified, then your order can remain open for up to 31 days. To maintain fairness in trading, CampBX have taken a purely-platform approach and they are never a counter-party to any trade.

This platform was designed from the ground up with stability and security as top priorities, and became the first Bitcoin website to obtain Payment Card Industry (PCI) certification and the McAfee Secure seal of confidence on June 28th, 2011 <ref>[https://bitcointalk.org/index.php?topic=23938.0 CampBX Hacker / Security Audit: Results]</ref>.

CampBX is also the first Bitcoin platform to bring advanced features like Margin Trading and Short-selling, and have several more innovative features in pipeline.

There are no fees required to open a CampBX account.

==Headquarter and Offices==
This platform is operated by BulBul Investments LLC, which is a corporate entity registered with the State of Georgia, and is headquartered in Atlanta at 2002 Summit Blvd #300, Atlanta, GA 30319. At launch time CampBX maintained a 4-people development office for a 3-month period; however as the development-phase ended they have switched to a Flex-office plan to save costs.

==Major Features==
CampBX aims to be the feature leader, and this vision is reflected in a comprehensive list of features:

<ul>
<li> Security certification from McAfee</li>
<li> Advanced trading options with AON/FOK/Market</li>
<li> STOPLOSS and Short-Selling available soon </li>
<li> Trading API available</li>
<li> Wallet API available </li>
<li> CBX Instant Bitcoin Transfers Feature </li>
<li> Stoploss / Custom Order Expiry Date/Time </li>
<li> SMS (Text Message) Notifications </li>
<li> Two-Factor Authentication </li>
<li> Based in USA - Atlanta </li>
</ul>

==Adding Funds==
Funds deposited with the exchange for escrow towards placing a buy order include the following.

===BTC===

* Adding bitcoins to the account balance incurs no fees.

===USD===

* [[Dwolla]] (instant). There is a $1,000 per-day transfer limit regardless of deposit or withdrawal.
* P2P bank transfer (available through Chase, Bank of America, Wells Fargo and ING, credited after 3 business days)
* Personal Check
* USPS Postal Money Order (No fee to receive, costs only $1.55 to send $1,000)
* Canada Post Money Order (USD)

==Withdrawing Funds==

===BTC===

* CampBX does not have any fees for Bitcoin withdrawals. The default withdrawal limit is 500 Bitcoins per-day; this limit can be increased by submitting a ticket to the help-desk. Account-to-account (A2A) transfers to another Camp BX account can be made. In the accountholder's profile is the CBX Instant Transfer which the sender needs to know.

===USD===

* [[Dwolla]] (instant). There is a $1,000 per-day transfer limit regardless of deposit or withdrawal.
* ACH Withdrawal (Direct deposit)
* Bank transfer (Domestic wire)
* International Bank transfer (International wire)
* USPS Postal Money Order

==Trading==

CampBX is the only Bitcoin exchanges to offer both market orders as well as limit orders. Market orders get filled regardless of the price.
Additional Advanced Trading options include Fill-or-Kill and All-or-Nothing fills. Fill-or-Kill means that if the order cannot immediately be matched, it will be canceled automatically. All-or-Nothing means that the order will match only when the entire quantity in the order can be traded. One option is to set a custom expiry date for each order, which allows setting up advanced trading strategies.
The trading algorithms implement trading functionality described in the following SEC Investor Bulletin as closely as possible:
http://www.sec.gov/investor/alerts/trading101basics.pdf

CampBX also provides Quick Trades for casual Bitcoin users, where you enter the quantity and the desired price for buying or selling Bitcoins, and execute the trade. All prices entered are "Limit" prices, where the platform will find a matching trade at given price or better.

Additionally, though currently disabled, the exchange's trading site refers to margin trading (buying on margin and shorting) -- something that no other exchange has offered yet.

===Fees===

Trades on the exchange incur a commission (fee) of 0.55%. (Volume discounts available)

==Data Services==
===Linux===
* [https://github.com/3M3RY/Dojima Dojima] market client

==History==

A story of firsts:

CampBX was the first Bitcoin trading platform to launch on Testnet <ref>[https://bitcointalk.org/index.php?topic=20777.0 CampBX Platform in Beta: Margin Trading, Short Selling, and Advanced Orders]</ref>. This allowed Bitcoin users to try out CampBX without risking their Bitcoins on an unknown website. Following a major CBX Testnet opened for public trial on June 21st, and in the following 15 days handled trading of ~90,000 testnet coins.
CampBX trade engine supported multiple advanced trading features like Margin Trading, Short Selling, Advanced Order Execution like FOK (Fill-or-Kill), (AON) All-or-Nothing orders, Stoploss, and custom expiry dates for orders.

On June 28th, we went through a rigorous third-party security audit by McAfee Hacker Safe (McAfee Secure) and two more white-hat auditors. As our commitment to transparency, we shared the results of the audit in a public forum <ref>[https://bitcointalk.org/index.php?topic=23938.0 CampBX Hacker / Security Audit: Results]</ref>. CampBX obtained compliance with 7 security standards including PCI (Payment Card Industry) compliance, another major first in the Bitcoin world.

We ended the testnet phase and opened for trading following the Independence Day on July 5th, 2011 <ref>[http://bitcointalk.org/index.php?topic=26202.0 CampBX Launch - Free Trades for All Bxlievers!]</ref>. As we grow, we are determined to continue this tradition of security, transparency, and customer service.

==See Also==

* [[Buying bitcoins]]
* [[Selling bitcoins]]

==External Links==

* [https://CampBX.com/ CampBX Home Page]
* [https://twitter.com/CampBX [[Twitter]] Feed for CampBX]
* [https://facebook.com/CampBX [[Facebook]] page for CampBX]
* [https://campbx.com/api.php API Reference]
* [https://campbx.com/faq.php Office Location and FAQ]
* [https://campbx.com/contact.php Helpdesk for CampBX]
* [https://CampBX.com/ CampBX Terms of Use (User Agreement)]

==References==
<References />

[[Category:Exchanges]]
[[Category:EWallets]]

Dark Exchange

2019-06-10T02:02:55Z

Gmaxwell: fix links

A 100% decentralized p2p exchange.

Running the Dark-Exchange open source software on the i2p network lets a market participant buy and sell bitcoins or other items. There is no master node(s) and there is no intermediary in the trades.

The project was launched as beta on July 5, 2011<ref>[http://bitcointalk.org/index.php?topic=26063.0 Dark Exchange: a 100% decentralized p2p exchange]</ref>.

==External Links==

* [https://github.com/macourtney/Dark-Exchange Dark-Exchange] project on GitHub

==References==
<references />

[[Category:Exchange software]]
[[Category:Local]]

GetBitcoin

2019-06-10T02:02:48Z

Gmaxwell: fix links

Formerly an [[currency exchange|exchange]] service operating from July 2011 to September 2012.

==History==

The service was launched July 3, 2011<ref>[http://bitcointalk.org/index.php?topic=25528.0 GetBitcoin - New Site For Exchanging Bitcoin/USD]</ref>. The company GetBitcoin LLC is (?) registered entity in the State of Delaware (File# 4997818). Complaints began in September 2012 and the website has been down since then.

The service is not to be confused with the Australian web site [https://www.getbitcoin.com.au getbitcoin.com.au], which offers a [https://en.bitcoin.it/wiki/Buying_bitcoins#Fixed_Rate_Exchanges_.26_Others fixed price exchange] service for bitcoins in Australia. The Australian business has nothing to do with the US company.

==See Also==

* [[Buying bitcoins]]
* [[Selling bitcoins]]

==References==
<References />

Bitcoiny.cz

2019-06-10T02:02:41Z

Gmaxwell: fix links

A [[currency exchange]] site serving those trading between bitcoins and the Czech crown (CZK).

The exchange operates as an information service that matches buyer and seller. The exchange does not perform escrow and is not a party in any transactions that occur.

The service was announced July 2, 2011<ref>[http://bitcointalk.org/index.php?topic=25474.0 new bitcoin trading server for Czech republic, CZK]</ref>.

==See Also==

* [[Buying bitcoins]]
* [[Selling bitcoins]]

==External Links==

* [http://www.Bitcoiny.cz Bitcoiny.cz] web site

==References==
<References />

[[Category:Exchanges]]
[[Category:Local]]

CaVirtEx

2019-06-10T02:02:36Z

Gmaxwell: fix links

A [[currency exchange|exchange]] allowing trade between bitcoins and CAD (Canadian Dollar). It is publicly known as CaVirtEx, as it is a Canadian (Ca) exchange.

==Deposits==

* Cash deposit at Bank of Montreal or ScotiaBank (same business day)
* Online bill payment
* Wire transfer

==Withdrawals==

* Canada Xpress Post Bank Draft (send by mail)
* Payza (formerly AlertPay) (withdrawn as CAD)
* Direct Deposit

==Problems==

After a full year of operation, the exchange is still unable to to get their trading API working.

==History==
The exchange was opened on July 2, 2011 after weeks of Beta mode<ref>[http://bitcointalk.org/index.php?topic=25312.0 cavirtex.com - Canadian Bitcoin Exchange now LIVE]</ref>. The exchange discontinued support for adding and withdrawing funds using Interac e-Transfers (EMTs) in August, 2011.

==See Also==

* [[Buying bitcoins]]
* [[Selling bitcoins]]

==External Links==

* [http://cavirtex.com CaVirtEx] exchange website
* [https://play.google.com/store/apps/details?id=com.veken0m.cavirtex Bitcoinium] for Android on Google Play

==References==
<references/>

[[Category:Defunct exchanges]]
[[Category:EWallets]]

GoldMoney

2019-06-10T02:02:30Z

Gmaxwell: fix links

GoldMoney is a payment network for [[digital currency|digital currencies]] each backed by a precious metal.

The company holds the precious metal in reserve and issues currency units denominated in units of the metal.

The currencies and units offered are:
* Gold - Goldgrams
* Silver - Silver ounces
* Platinum - Platinum grams
* Palladium - Palladium grams

Transactions made to a merchant or sent to another GoldMoney member clear instantly. Only customers with "full holding" accounts are able to make payments using the currency. Payment are non-repudiable<ref>[http://www.goldmoney.com/glossary.html GoldMoney Glossary]</ref>.

With GoldMoney payments being irrevocable (i.e., no charge-backs) it is a method embraced by Bitcoin traders as bitcoin payments are irrevocable as well. These traders may be found on the [[Bitcoin-otc|bitcoin-otc marketplace]], for instance.

==Fees==

There are fees when buying the currency, for demurrage (storage), and when making payments or withdrawing funds. The rates are disclosed on the GoldMoney site.

==History==

GoldMoney was started in 2001 and by 2011 it had $2 billion USD of customer assets in storage<ref>[http://www.goldmoney.com/history.html History of GoldMoney]</ref> Though offers to trade bitcoins for GoldMoney and vice-versa were discussed as early as October 2010, the first bitcoin to GoldMoney trade appears to have occurred in July, 2011<ref>[http://bitcointalk.org/index.php?topic=24714.0 Bitcoin <--> GoldMoney]</ref>.

The GoldMoney P2P digital currency was restricted to accounts domiciled in Jersey in 2011 because of regulatory concerns and eventually discontinued by the company. However in an ironic twist GoldMoney created a Bitcoin-to-gold exchange company called Netagio in 2014 and in 2015 Goldmoney was acquired by BitGold<ref>[http://www.businesswire.com/news/home/20150720006453/en/BitGold-Completes-59.4MM-Acquisition-GoldMoney-Building-Global BitGold acquires GoldMOney for $59M]</ref>

==See Also==

* [[Ruxum]]
* [[e-gold]]

==External Links==

* [http://www.goldmoney.com GoldMoney] web site

==References==
<references />

[[Category:Digital currencies]]

Bitcoin Wallet Balance

2019-06-10T02:02:25Z

Gmaxwell: fix links

'''Bitcoin Wallet Balance''' is an Android App to allow you to view the balance in your wallet on your Android device. It works by reading your public key hashes (addresses) and obtaining your transactions from blockexplorer.com. Keys are exported once, saved in cloud storage, and allow the user to view their balance in real time on their device. The code is open sourced so it can be freely inspected (since it has to touch the wallet.dat)

This app was announced on June 24, 2011<ref>[http://bitcointalk.org/index.php?topic=21969.0 Android wallet balance viewer]</ref>.

==External Links==

* [http://code.google.com/p/bitcoinwallet/ homepage] on Google code hosting.

==References==
<references />

[[Category:Mobile]]
[[Category:Android]]