Bitcoin Wiki - User contributions [en]

Scalability FAQ

2016-01-26T10:43:33Z

Luzius: More detailed explanation of the fee market, clarifying note on validation effort

Answers to commonly-asked questions and concerns about scaling Bitcoin, including “level 1” solutions such as increasing the block size and “level 2” solutions such as the proposed Lightning network.

== Background ==

Questions about how Bitcoin currently works (related to scaling) as well as questions about the technical terminology related to the scaling discussion.

=== What is the short history of the block size limit? ===

''Note: the software now called Bitcoin Core was previously simply called “Bitcoin”.<ref>[https://bitcoin.org/en/release/v0.9.0#rebranding-to-bitcoin-core Bitcoin Core 0.9.0 release notes], Bitcoin.org, 19 March 2014</ref> To avoid confusion with the Bitcoin system, we’ll use the Bitcoin Core name.''

Bitcoin Core was initially released without an explicit block size limit. However, the code did limit network messages to a maximum of 32 MiB, setting an effective upper bound on block size.<ref>[https://bitcointalk.org/index.php?topic=68121 Earliest known Bitcoin code], <code>src/main.h:17</code></ref>

Around 15 July 2010, Satoshi Nakamoto changed Bitcoin Core’s mining code so that it wouldn’t create any blocks larger than 990,000 bytes.<ref>[https://github.com/bitcoin/bitcoin/commit/a30b56ebe76ffff9f9cc8a6667186179413c6349 Bitcoin Core commit a30b56e], Satoshi Nakamoto, 15 July 2010</ref>

Two months later on 7 September 2010, Nakamoto changed Bitcoin Core’s consensus rules to reject blocks larger than 1,000,000 bytes (1 megabyte) if their block height was higher than 79,400.<ref>[https://github.com/bitcoin/bitcoin/commit/8c9479c6bbbc38b897dc97de9d04e4d5a5a36730 Bitcoin Core commit 8c9479c], Satoshi Nakamoto, 7 September 2010</ref> (Block 79,400 was later produced on 12 September 2010.<ref>[https://www.biteasy.com/blockchain/blocks/000000000021d821ec06be7173f413690bc5c4bc648dfa70b3b6763236f055b7 Block height 79400], dated 12 September 2010</ref>)

Neither the July nor the September commit message explains the reason for the limit, although the careful attempt to prevent a fork may indicate Nakamoto didn’t consider it an emergency.

Nakamoto’s subsequent statements supported raising the block size at a later time<ref>[https://bitcointalk.org/index.php?topic=1347.msg15139#msg15139 Increasing the block size when needed], Satoshi Nakamoto, 3 October 2010</ref>, but he never publicly specified a date or set of conditions for the raise.

=== What is this Transactions Per Second (TPS) limit? ===

The current block size limit is 1,000,000 bytes (1 megabyte)<ref>[https://github.com/bitcoin/bitcoin/blob/41076aad0cbdfa4c4cf376e345114a5c29086f81/src/consensus/consensus.h#L10 <code>MAX_BLOCK_SIZE</code>], retrieved 2 July 2015</ref>, although a small amount of that space (such as the block header) is not available to store transactions.<ref>[https://bitcoin.org/en/developer-reference#serialized-blocks Block serialization description], Bitcoin.org Developer Reference</ref>

Bitcoin transactions vary in size depending on multiple factors, such as whether they’re spending single-signature inputs or a multiple signature inputs, and how many inputs and outputs they have.

The simple way to calculate the number of Transactions Per Second (TPS) Bitcoin can handle is to divide the block size limit by the expected average size of transactions, divided by the average number of seconds between blocks (600). For example, if you assume average transactions are 250 bytes,

<pre>6.6 TPS = 1,000,000 / 250 / 600</pre>

There seems to be general agreement that Bitcoin in 2015 can handle about 3 TPS with the current average size of transactions.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/007986.html Max TPS based on current average transaction size], Mike Hearn, 8 May 2015</ref><ref name="maxwell_not_proposing">[https://www.reddit.com/r/Bitcoin/comments/39yaod/bitcoinorg_position_on_hard_forks/cs7qz5c "No one proposing 3 TPS forever"], Gregory Maxwell, 15 June 2015</ref>

Both old estimates<ref>[[Scalability]], Bitcoin Wiki, retrieved 7 July
2015</ref> and new estimates<ref name="garzik_bip" /> place the
theoretical maximum at 7 TPS with current Bitcoin consensus rules
(including the 1MB block size limit).

=== What do devs mean by the scaling expressions O(1), O(n), O(n2), etc…? ===

[https://en.wikipedia.org/wiki/Big_O_notation Big O notation] is a shorthand used by computer scientists to describe how well a system scales. Such descriptions are rough approximations meant to help predict potential problems and evaluate potential solutions; they are not usually expected to fully capture all variables.

* '''O(1)''' means a system has roughly the same properties no matter how big it gets.
* '''O(n)''' means that a system scales linearly: doubling the number of things (users, transactions, etc.) doubles the amount of work.
* '''O(n2)''' means that a system scales quadratically : doubling (2x) the number of things quadruples (4x) the amount of work. Often written O(n^2) is places without convenient superscripts.
* Additional examples may be found in the [https://en.wikipedia.org/wiki/Big_O_notation#Orders_of_common_functions Wikipedia article]

The following subsections show cases where big O notation has been applied to the scaling Bitcoin transaction volume.

==== O(1) block propagation ====

Bitcoin Core currently relays unconfirmed transactions and then later relays blocks containing many of the same transactions. This redundant relay can be eliminated to allow miners to propagate large blocks very quickly to active network nodes, and would also significantly reduce miner need for peak bandwidth. Currently most miners use a network<ref name="block_relay_net">[http://bitcoinrelaynetwork.org/ Matt Corallo's block relay network]</ref> that is about 25x more efficient than stock Bitcoin Core<ref>[https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2#i-know-that-you-know IBLT design document], Gavin Andresen, 11 August 2014</ref> and almost equally as effective as O(1) block propagation for current block sizes.

==== O(n2) network total validation resource requirements ====

[[File:On2_scaling_illustrated.png|thumb|right|visualization of O(n2) scaling]]

Each on-chain Bitcoin transaction needs to be processed by each full node. If we assume that a certain percentage of users run full nodes (''n'') and that each user creates a certain number of transactions on average (''n'' again), then the network’s total resource requirements are <code>n2 = n * n</code>. In short, this means that the aggregate cost of keeping all transactions on-chain quadruples each time the number of users doubles.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009199.html Total system cost], Dr. Adam Back, 28 June 2015</ref> For example,

* Imagine a network starts with 100 users and 2 total nodes (a 2% ratio).
* The network doubles in users to 200. The number of nodes also doubles to 4 (maintaining a 2% ratio of decentralized low-trust security). However, double the number of users means double the number of transactions, and each node needs to process ''every'' transaction---so each node now does double work with its bandwidth and its CPU. With double the number of nodes and double the amount of work per node, total work increases by four times.
* The network doubles again: 400 users, 8 nodes (still 2% of total), and 4 times the original workload per node for a total of 16 times as much aggregate work as the original.
* Another doubling: 800 users, 16 nodes (still 2%), and 8 times the original workload per node for a total of 64 times aggregate work as the original.
* Another doubling: 1,600 users—sixteen times the original---with 32 nodes (still 2%), and 16 times the original workload per node. The aggregate total work done by nodes is 256 times higher than it was originally.

Note that the validation effort required per full node simply grows in O(n). For a single node, it takes twice as many resources to process twice as many transactions.

=== What’s the difference between on-chain and off-chain transactions? ===

On-chain Bitcoin transactions are those that appear in the Bitcoin block chain. Off-chain transactions are those that transfer ownership of bitcoins without putting a transaction on the block chain.

Common and proposed off-chain transactions include:

* '''Exchange transactions:''' when you buy or sell bitcoins, the exchange tracks ownership in a database without putting data in the block chain. Only when you deposit or withdraw bitcoins does the transaction appear on the block chain.
* '''Web wallet internal payments:''' many web wallets allow users of the service to pay other users of the same service using off-chain payments. For example, when one Coinbase user pays another Coinbase user.
* '''Tipping services:''' most tipping services today, such as ChangeTip, use off-chain transactions for everything except deposits and withdrawals.<ref>[https://www.changetip.com/fees ChangeTip fees], retrieved 3 July 2015</ref>
* '''Payment channels:''' channels are started using one on-chain transaction and ended using a second on-chain transaction.<ref>[https://bitcoin.org/en/developer-guide#micropayment-channel Micropayment channels], Bitcoin.org Developer Guide</ref> In between can be an essentially unlimited number of off-chain transactions as small as a single satoshi (1/100,000,000th of a bitcoin). Payment channels include those that [https://bitcoinj.github.io/working-with-micropayments exist today] as well as proposed hub-and-spoke channels and the more advanced [http://lightning.network/ Lightning network].

Approximately 90% to 99% of all bitcoin-denominated payments today are made off-chain.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008844.html Pure off-chain is a weak form of layer 2], Dr. Adam Back, 19 June 2015</ref>

=== What is a fee market? ===

When you create a Bitcoin transaction, you have the option to pay a [[transaction fee]]. If your software is flexible, you can pay anything from zero fees (a free transaction) to 100% of the value of the transaction (spend-to-fees). This fee is comparable to a tip. The higher it is, the bigger the incentive of the miners to incorporate your transaction into the next block.

When miners assemble a block, they are free to include whatever transactions they wish. They usually include as many as possible up to the maximum block size and then prioritize the transactions that pay the most fees per kilobyte of data.<ref name="fee_pri">[https://bitcointalk.org/index.php?topic=95837.0 Fee prioritization patch], Gavin Andresen, 26 July 2012</ref> This confirms higher-fee transactions before lower-fee transactions. If blocks become full on a regular basis, users who pay a fee that's too small will have to wait a longer and longer time for their transactions to confirm. At this point, a demand-driven fee market may arise where transactions that pay higher fees get confirmed significantly faster than transactions that pay low fees.<ref name="todd_coinwallet">[https://gist.github.com/petertodd/8e87c782bdf342ef18fb Comments on the CoinWallet.eu tx-flood stress-test], Peter Todd, 22 June 2015</ref><ref name="garzik_bip" />

In a competitive market, prices are driven by supply and demand and the emerging equilibrium price asymptotically approaches marginal costs over time. However, the current version of Bitcoin limits the supply to 1 MB per block, only allowing demand to adjust. To establish a free market, one would need to come up with a mechanism that allows the number of included transactions per block to adjust dynamically as well. The design of such a mechanism, however, is not trivial. Simply allowing individual miners to include as many transactions as they want is problematic due to the externalities<ref name="exernality">[https://en.wikipedia.org/wiki/Externality Definition of externality], Wikipedia, 26 January 2016</ref> of including additional blocks and explained further in section [[#Should miners be allowed to decide the block size?|'should miners be allowed to decide the block size?']] .

=== What is the most efficient way to scale Bitcoin? ===

Remove its decentralization properties, specifically decentralized mining and decentralized full nodes. Mining wastes enormous amounts of electricity to provide a decentralized ledger and full nodes waste an enormous amount of bandwidth and CPU time keeping miners honest.

If users instead decided to hand authority over to someone they trusted, mining and keeping miners honest wouldn’t be needed. This is how Visa, MasterCard, PayPal, and the rest of the centralized payment systems works—users trust them, and they have no special difficulty scaling to [[scalability|millions of transactions an hour]]. It’s very efficient; it isn’t decentralized.

=== What is a hard fork, and how does it differ from other types of forks? ===

The word fork is badly overloaded in Bitcoin development.

* '''[[hardfork|Hard fork]]:''' a change to the system which is not backwards compatible. Everyone needs to upgrade or things can go wrong.
* '''[[softfork|Soft fork]]:''' a change to the system which is backwards compatible as long as a majority of miners enforce it. Full nodes that don’t upgrade have their security reduced.
* '''Chain fork:''' when there are two are more blocks at the same height on a block chain. This typically happens a few times a week by accident, but it can also indicate more severe problems.
* '''[https://en.wikipedia.org/wiki/Fork_%28software_development%29 Software fork]:''' using the code from an open source project to create a different project.
* '''[https://help.github.com/articles/fork-a-repo/ Git/GitHub fork]:''' a way for developers to write and test new features before contributing them to a project.

(There are other types of software-related forks, but they don’t tend to cause as much confusion.)

=== What are the block size soft limits? ===

Bitcoin Core has historically come pre-configured to limit blocks it mines to certain sizes.<ref name="fee_pri" /> These “limits” aren’t restrictions placed on miners by other miners or nodes, but rather configuration options that help miners produce reasonably-sized blocks.

Miners can change their soft limit size (up to 1 MB) using <code>-blockmaxsize=<size></code>

Default soft limits at various times:

* '''July 2012:''' <code>-blockmaxsize</code> option created and set to default 250 KB soft limit<ref>[https://github.com/bitcoin/bitcoin/commit/c555400ca134991e39d5e3a565fcd2215abe56f6 Bitcoin Core commit c555400], Gavin Andresen, 12 July 2012</ref>
* '''November 2013:''' Raised to 750KB<ref>[https://github.com/bitcoin/bitcoin/commit/ad898b40aaf06c1cc7ac12e953805720fc9217c0 Bitcoin Core commit ad898b40], Gavin Andresen, 27 November 2013</ref>
* '''June 2015:''' Raise to 1 MB suggested<ref>[https://github.com/bitcoin/bitcoin/pull/6231 Bitcoin Core pull #6231], Chris Wheeler, 4 June 2015</ref>

== General Block Size Increase Theory ==

Questions about increasing the block size in general, not related to any
specific proposal.

==== Why are some people in favor of keeping the block size at 1 MB forever? ====

It is commonly claimed<ref name="garzik_bip" /><ref>[https://epicenterbitcoin.com/podcast/082/ Epicenter Bitcoin podcast #82], Mike Hearn (interviewed), 8 June 2015</ref> that there are people opposed to ever raising the maximum block size limit, but no Bitcoin developers have suggested keeping the maximum block size at one megabyte forever.<ref name="maxwell_not_proposing" />

All developers support raising the maximum size at some point<ref>[https://www.reddit.com/r/Bitcoin/comments/39kqzs/how_about_a_softfork_optin_blocksize_increase/cs5hj8l Nothing magic about 1MB], Dr. Adam Back, 13 June 2015</ref><ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008328.html Regarding size-independent new block propagation], Pieter Wuille, 28 May 2015</ref>—they just disagree about whether now is the correct time.

==== Should miners be allowed to decide the block size? ====

A block may include as little as a single transaction, so miners can always restrict block size. Letting miners choose the maximum block size is more problematic for several reasons:

# '''Miners profit, others pay the cost:''' bigger blocks earn miners more fees, but miners don’t need to store those blocks for more than a few days.<ref>[https://github.com/bitcoin/bitcoin/pull/5863 Bitcoin Core pull #5863 adding pruning functionality], Suhas Daftuar et al., 6 March 2015</ref> Other users who want full validation security, or who provide services to lightweight wallets, pay the costs of downloading and storing those larger blocks.
# '''Bigger miners can afford more bandwidth:''' each miner needs to download every transaction that will be included in block,<ref name="maxwell_correcting_assumptions" /> which means that they all need to pay for high-speed connections. However, a miner with 8.3% of total hash rate can take that cost out of the about 300 BTC they make a day, while a miner with only 0.7% of total hash rate has to take that cost out of only 25 BTC a day. This means bigger miners may logically choose to make bigger blocks even though it may further centralize mining.
# '''Centralized hardware production:''' only a few companies in the world produce efficient mining equipment, and many of them have chosen to stop selling to the public.<ref>[http://blogs.wsj.com/venturecapital/2014/09/05/for-kncminer-time-to-forget-selling-bitcoin-machines-to-at-home-miners/ KnCMiner to stop selling to home miners], Wall Street Journal, Yuliya Chernova, 5 September 2014</ref> This prevents ordinary Bitcoin users from participating in the process even if they were willing to pay for mining equipment.
# '''Voting by hash rate favors larger miners:''' voting based on hash rate allows the current hash rate majority (or super-majority) to enforce conditions on the minority. This is similar to a lobby of large businesses being able to get laws passed that may hurt smaller businesses.<ref>[https://www.reddit.com/r/Bitcoin/comments/39kzyt/draft_bip_100_soft_fork_block_size_increase/cs5gvak Miners choosing the block size limit is ill-advised], Meni Rosenfeld, 13 June 2015</ref>
# '''Miners may not care about users:''' this was demonstrated during the [[July 2015 Forks]] where even after miners lost over $50,000 USD in income from mining invalid chains, and even after they were told that long forks harm users, they continued to mine improperly.<ref>[https://bitcointalk.org/index.php?topic=700411.msg11790734#msg11790734 Intention to continue SPV mining], Wang Chun, 4 July 2015</ref>

However, there are also possible justifications for letting miners choose the block size:

# '''Authenticated participants:''' miners are active participants in Bitcoin, and they can prove it by adding data to the blocks they create.<ref>[https://bitcoin.org/en/developer-reference#term-coinbase-field Coinbase field], Bitcoin.org Developer Reference</ref> It is much harder to prove people on Reddit, BitcoinTalk, and elsewhere are real people with an active stake in Bitcoin.
# '''Bigger blocks may cost miners:''' small miners and poorly-connected miners are at a disadvantage if larger blocks are produced<ref name="wuille_centralization" />, and even large and well-connected miners may find that large blocks reduce their profit percentage if the cost of bandwidth rises too high or their stale rate increases.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008355.html F2Pool block size concerns], Chun Wang, 29 May 2015</ref>

==== How could a block size increase affect user security? ====

Bitcoin’s security is highly dependent on the number of active users who protect their bitcoins with a full node like Bitcoin Core. The more active users of full nodes, the harder it is for miners to trick users into accepting fake bitcoins or other frauds.<ref>[https://medium.com/@lopp/bitcoin-nodes-how-many-is-enough-9b8e8f6fd2cf Bitcoin nodes: how many is enough?], Jameson Lopp, 7 June 2015</ref>

Full nodes need to download and verify every block, and most nodes also store blocks plus relay transactions, full blocks, and filtered blocks to other users on the network. The bigger blocks become, the more difficult it becomes to do all this, so it is expected that bigger blocks will both reduce the number of users who currently run full nodes and suppress the number of users who decide to start running a full node later.<ref>[https://www.reddit.com/r/Bitcoin/comments/3bae2d/amir_taaki_on_raising_the_block_size_a_lot_of/cslcgmw Block size increases-only will create problems], Dr. Adam Back, 28 June 2015</ref>

In addition, full blocks may increase mining centralization<ref name="wuille_centralization" /> at a time when mining is already so centralized that it makes it easy to reverse transactions which have been confirmed multiple times.<ref>[http://bitcoin.stackexchange.com/questions/32562/when-to-worry-about-1-confirmation-payments/32564#32564 When to worry about one-confirmation payments], David A. Harding, 17 November 2014</ref>

==== How could larger blocks affect proof-of-work (POW) security? ====

Proof of work security is dependent on how much money miners spend on mining equipment. However, to effectively mine blocks, miners also need to spend money on bandwidth to receive new transactions and blocks created by other miners; CPUs to validate received transactions and blocks; and bandwidth to upload new blocks. These additional costs don’t directly contribute to POW security.<ref name="maxwell_correcting_assumptions">[https://www.reddit.com/r/Bitcoin/comments/39tgno/letting_miners_vote_on_the_maximum_block_size_is/cs6rek5 Correcting wrong assumptions about mining], Gregory Maxwell, 15 June 2015</ref>

As block sizes increase, the amount of bandwidth and CPU required also increases. If block sizes increase faster than the costs of bandwidth and CPU decrease, miners will have less money for POW security relative to the gross income they earn.

In addition, larger blocks have a higher risk of becoming stale (orphaned)<ref name="rusty_dsl" />, which directly correlates to lost POW security. For example, if the network average stale rate is 10%, then 10% of POW performed isn't protecting transactions on the block chain.

=== What happens if blocks aren't big enough to include all pending transactions? ===

This is already the case more often than not<ref>[http://statoshi.info/dashboard/db/transactions?from=1433297061121&to=1435889061123 Statoshi.info mempool queue June to July 2015]</ref>, so we know that miners will simply queue transactions. The transactions eligible for block inclusion that pay the highest fee per kilobyte will be confirmed earlier than transactions that pay comparatively lower fees.<ref name="fee_pri" />

What happens from there is debated:

* BitcoinJ lead developer Mike Hearn believes there would be “crashing nodes, a swelling transaction backlog, a sudden spike in double spending, [and] skyrocketing fees.”<ref>[https://medium.com/@octskyward/crash-landing-f5cc19908e32 Crash Landing], Mike Hearn, 7 May 2015</ref>
* Bitcoin Foundation chief scientist Gavin Andresen believes that the “average transaction fee paid will rise, people or applications unwilling or unable to pay the rising fees will stop submitting transactions, [and] people and businesses will shelve plans to use Bitcoin, stunting growth and adoption.” <ref>[https://github.com/bitcoin/bitcoin/pull/6341 Bitcoin Core pull #6341], Gavin Andresen, 26 June 2015</ref>
* Bitcoin Core developer Pieter Wuille replies to Andresen’s comment above: “Is it fair to summarize this as ‘Some use cases won’t fit any more, people will decide to no longer use the blockchain for these purposes, and the fees will adapt.’? I think that is already happening […] I don’t think we should be afraid of this change or try to stop it.” <ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009098.html The need for larger blocks], Pieter Wuille, 26 June 2015</ref>
* Bitcoin Core developer Jeff Garzik writes, "as blocks get full and the bidding war ensues, the bitcoin user experience rapidly degrades to poor. In part due to bitcoin wallet software’s relative immaturity, and in part due to bitcoin’s settlement based design, the end user experience of their transaction competing for block size results in erratic, and unpredictably extended validation times."<ref name="garzik_bip" />

== Specific Scaling Proposals ==

=== Andresen-Hearn Block Size Increase Proposals ===

Questions about the series of related proposals by Gavin Andresen and Mike Hearn to use a hard fork to raise the maximum block size, thereby allowing miners to include more on-chain transactions. As of July 2015, the current focus is [https://github.com/bitcoin/bips/pull/163 BIP101].

==== What is the major advantage of this proposal? ====

''Bitcoin can support many more users.'' Assuming earliest possible adoption, 250 bytes per on-chain transaction, 144 blocks per day, and 2 transaction a day per user, Bitcoin can support about,

* 288,000 users in 2015
* 2,304,000 users in 2016 (800% increase)
* 4,608,000 in 2018 (1,600%)
* 9,216,000 in 2020 (3,200%)
* 18,432,000 in 2022 (6,400%)
* 36,864,000 in 2024 (12,800%)
* 73,728,000 in 2026 (25,600%)
* 147,456,000 in 2028 (51,200%)
* 294,912,000 in 2030 (102,400%)
* 589,824,000 in 2032 (204,800%)
* 1,179,648,000 in 2034 (409,600%
* 2,359,296,000 in 2036 (819,200%)

==== What is the major disadvantage of this proposal? ====

''The total cost of remaining decentralized will be high.'' Assuming earliest possible adoption and that the ratio of total users to full node operators remains the same as today, the total estimated amount of work necessary to maintain the decentralized system under the [[#O.28n2.29_network_total_validation_resource_requirements|O(2) scaling model]] will be,

* 100% of today’s work in 2015
* 6,400% in 2016
* 25,600% in 2018
* 102,400% in 2020
* 409,600% in 2022
* 1,638,400% in 2024
* 6,553,600% in 2026
* 26,214,400% in 2028
* 104,857,600% in 2030
* 419,430,400% in 2032
* 1,677,721,600% in 2034
* 6,710,886,400% in 2036

For example, if the total amount spent on running full nodes today (not counting mining) is $100 thousand per year, the estimated cost for the same level of decentralization in 2036 will be $6.7 trillion per year if validation costs stay the same. (They'll certainly go down, but algorithmic and hardware improvements probably won't eliminate an approximate 6,710,886,400% cost increase.)

==== What are the dangers of the proposed hard fork? ====

Under the current proposal, 75% of miners must indicate that they agree to accept blocks up to 8 MB in size.<ref name="bip101">[https://github.com/bitcoin/bips/pull/163 BIP101], Gavin Andresen, 24 June 2016</ref> After the change goes into effect, if any miner creates a block larger than 1 MB, all nodes which have not upgraded yet will reject the block.<ref>[https://bitcoin.org/en/developer-guide#consensus-rule-changes Consensus rule changes], Bitcoin.org Developer Guide</ref>

If all full nodes have upgraded, or very close to all nodes, there should be no practical effect. If a significant number of full nodes have not upgraded, they will continue using a different block chain than the upgraded users, with the following consequences:

* Bitcoins received from before the fork can be spent twice, once on both sides of the fork. This creates a high double spend risk.
* Bitcoins received after the fork are only guaranteed to be spendable on the side of the fork they were received on. This means some users will have to lose money to restore Bitcoin to a single chain.

Users of hosted wallets (Coinbase, BlockChain.info, etc.) will use whatever block chain their host chooses. Users of lightweight P2P SPV wallets will use the [[Thin Client Security|longest chain they know of]], which may not be the actual longest chain if they only connect to nodes on the shorter chain. Users of non-P2P SPV wallets, like Electrum, will use whatever chain is used by the server they connect to.

If a bad hard fork like this happens, it will likely cause large-scale confusion and make Bitcoin very hard to use until the situation is resolved.

==== What is the deployment schedule for BIP 101? ====

* The patch needs to be accepted into Bitcoin Core, Bitcoin XT, or both.
* If accepted into Bitcoin Core, miners using that software will need to upgrade (this probably requires a new released version of Bitcoin Core). If accepted only into Bitcoin XT, miners will need to switch to using XT.
* After 75% of miners have upgraded, 8MB blocks will become allowed at the the latest of (1) 11 January 2016 or (2) two weeks after the 75% upgrade threshold.<ref name="bip101" />
* After the effective date has passed, any miner may create a block larger than 8MB. When a miner does this, upgraded full nodes will accept that block and non-upgraded full nodes will reject it, forking the network.<ref name="bip101" /> See [[#What_are_the_dangers_of_the_proposed_hard_fork.3F|hard fork dangers]] for what his might mean.

==== Will miners go straight from 1 MB blocks to 8 MB blocks? ====

That would be highly unlikely. Uploading an 8 MB block currently takes significantly more time than uploading a 1 MB block<ref name="rusty_dsl">[http://rusty.ozlabs.org/?p=509 Mining on a home DSL connection test results], Rusty Russell, 19 June 2015</ref>, even with the roughly 25x reduction in size available from use of Matt Corallo’s block relay network.<ref name="block_relay_net" />

The longer it takes to upload a block, the higher the risk it will become a stale block—meaning the miner who created it will not receive the block subsidy or transaction fees (currently about 25 BTC per block).

However, if technology like Invertible Bloom Lookup Tables (IBLTs) is deployed and found to work as expected<ref name="iblt">[https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2 O(1) block propagation], Gavin Andresen, 8 August 2014</ref>, or if mining [[#What_is_the_most_efficient_way_to_scale_Bitcoin.3F|centralizes further]], adding additional transactions may not have a significant enough cost to discourage miners from creating full blocks. In that case, blocks will be filled as soon as there are enough people wanting to make transactions paying the default relay fee<ref>[https://github.com/bitcoin/bitcoin/pull/3305 Bitcoin Core pull #3305 dropping default fees], Mike Hearn, 22 November 2013</ref> of 0.00001000 BTC/kilobyte.

==== What tests have been performed related to this proposal? ====

* '''20MB block processing''' (Gavin Andresen) “if we increased the maximum block size to 20 megabytes tomorrow, and every single miner decided to start creating 20MB blocks and there was a sudden increase in the number of transactions on the network to fill up those blocks… the 0.10.0 version of [Bitcoin Core] would run just fine.”<ref>[http://gavintech.blogspot.com/2015/01/twenty-megabytes-testing-results.html Twenty megabyte block testing], Gavin Andresen, 20 January 2015</ref> (ellipses in original)
* '''Mining & relay simulation''' (Gavin Andresen) “if blocks take 20 seconds to propagate, a network with a miner that has 30% of the hashing power will get 30.3% of the blocks.”<ref>[http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners Are bigger blocks better for bigger miners?], Gavin Andresen, 22 May 2015</ref>
* '''Mining on a home DSL connection''' (Rusty Russell) “Using the rough formula of 1-exp(-t/600), I would expect orphan rates of 10.5% generating 1MB blocks, and 56.6% with 8MB blocks; that’s a huge cut in expected profits.”<ref name="rusty_dsl" />
* '''Mining centralization pressure''' (Pieter Wuille) “[This] does very clearly show the effects of larger blocks on centralization pressure of the system.”<ref name="wuille_centralization">[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008581.html Mining centralization pressure from non-uniform propagation speed], Pieter Wuille, 12 June 2015</ref>

=== Garzik Miner Block Size Voting Proposal (AKA BIP100) ===

''Note, BIP 100 is the marketing name for this proposal. No BIP number
has yet been publicly requested, and the number assigned is unlikely to
be 100.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-May/005756.html
Prenumbered BIP naming], Gregory Maxwell, 12 May 2014</ref>''

Questions related to Jeff Garzik's proposal<ref name="garzik_bip">[http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf Draft BIP: decentralized economic policy], Jeff Garzik, 12 June 2015 (revised 15 June 2015)</ref> to allow miners to vote on raising and lowering the maximum block size.

==== What does this proposal do? ====

# It creates a one-time hard fork that does not automatically change the maximum block size.

# It allows miners to vote to increase or decrease the maximum block size within the range of 1MB to 32MB. These changes are neither hard forks nor soft forks, but simply rules that all nodes should know about after the initial hard fork.

==== Does it reduce the risk of a hard fork? ====

Hard forks are most dangerous when they're done without strong
consensus.<ref name="garzik_bip" /><ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008779.html Consensus changes are not about making a change to the software],
Pieter Wuille, 18 June 2015</ref>

If Garzik's proposal gains strong consensus, it will be as safe as possible
for a hard fork and it will allow increasing the block size up to 32 MB
without any additional risk of a fork.

==== Why is it limited to 32 megabytes? ====

According to the draft BIP, "the 32 MB hard fork is largely coincidental -- a whole network upgrade at 32 MB was likely needed anyway."

=== Lightning Network ===

Questions related to using the proposed [http://lightning.network/ Lightning network] as a way to scale the number of users Bitcoin can support.

==== How does transaction security differ from that of Bitcoin? ====

Transactions on the proposed Lightning network use Bitcoin transactions exclusively to transfer bitcoins<ref name="russell_lightning1">[http://rusty.ozlabs.org/?p=450 Lightning Networks: Part I], Rusty Russell, 30 March 2015</ref>, and so the same security as regular Bitcoin transactions is provided when both a Lightning hub and client are cooperating.

When a Lightning hub or client refuses to cooperate with the other (maybe because they accidentally went offline), the other party can still receive their full 100% bitcoin balance by closing the payment channel—but they must first wait for a defined amount of time mutually chosen by both the hub and client.<ref>[http://rusty.ozlabs.org/?p=462 Lightning Networks: Part II], Rusty Russell, 1 April 2015</ref>

If one party waits too long to close the payment channel, the other party may be able to steal bitcoins. However, it is possible to delegate the task of closing the channel in an emergency to an unlimited number of hubs around the Internet, so closing the channel on time should be easy.<ref name="russell_lightning4">[http://rusty.ozlabs.org/?p=477 Lightning Networks: Part IV], Rusty Russell, 8 April 2015</ref>

In summary, provided that payment channels are closed on time, the worst that can happen to users is that they may have to wait a few weeks for a channel to fully close before spending the bitcoins they received from it. Their security is otherwise the same as with regular Bitcoin.

For Lightning hubs, security is slightly worse in the sense that they need to keep a potentially-large amount of funds in a hot wallet<ref name="lightning_paper">[http://lightning.network/lightning-network-paper-DRAFT-0.5.pdf Lightning Network (Draft 0.5)], Section 6.3: Coin Theft via Hacking, Joseph Poon and Thaddeus Dryja</ref>, so they can’t take advantage of the anti-hacking protection offered by cold wallets. Otherwise, Lightning hubs have the same security as clients.

==== When will Lightning be ready for use? ====

Lightning requires a basic test implementation (work underway<ref>[https://lists.blockstream.com/pipermail/lightning-dev/2015-June/000018.html Lightning first steps], Rusty Russell, 13 June 2015</ref>), several soft-fork changes to the Bitcoin protocol (work underway<ref>[https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65: CheckLockTimeVerify], Peter Todd, 1 October 2014</ref><ref>[https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68: Consensus-enforced transaction replacement], Mark Friedenbach, 28 May 2015</ref>, and wallets need to be updated to support the Lightning network protocol.<ref name="russell_lightning4" />

Dr. Adam Back has said, "I expect we can get something running inside a year."<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009242.html Reply to Andresen regarding Lightning], Dr. Adam Back, 28 June 2015</ref>

==== Doesn’t Lightning require bigger blocks anyway? ====

Lightning is block-size neutral. It requires one on-chain transaction to open a channel between a hub and a client, and one on-chain transaction to close a channel.<ref name="russell_lightning1" /> In between it can support an unlimited number of transactions between anyone on the Lightning network.<ref name="lightning_paper" />

Using the numbers from the Lightning presentation<ref name="lightning_slides">[http://lightning.network/lightning-network.pdf Lightning presentation], Joseph Poon, 23 February 2015</ref>, if people open and close a plausible two channels a year, Lightning can support about 52 million users with the current one-megabyte limit—and each user can make an unlimited number of transactions. Currently, assuming people make an average of only two Bitcoin transactions a day, basic Bitcoin can support only 288,000 users.

Under these assumptions, Lightning is 180 times (17,900%) more efficient than basic Bitcoin.

Presumably, if around 30 million people are using Bitcoin via Lightning so that capacity is called into question, it will not be difficult to find consensus to double the block size to two megabytes and bring user capacity up to 105 million. The same goes for later increases to 200 million (4MB), 400 million (8MB), 800 million (16MB), 1.6 billion (32 MB), 3.2 billion (64MB), and all 7 billion living humans (133MB). In each case, all Lightning network participants get unlimited transactions to the other participants.

For basic Bitcoin to scale to just 2 transactions a day for 7 billion people would require 24-gigabyte blocks.<ref name="lightning_slides" />

=== Sidechains ===

==== Real quick, what are sidechains? ====

Block chains that are separate from Bitcoin’s block chain, but which allow you to receive and spend bitcoins using a two-way peg (2WP).<ref name="sidechains_paper">[https://www.blockstream.com/sidechains.pdf Sidechains paper], Adam Back et al., 22 October 2014</ref> (Although a sidechain can never be more secure than the Bitcoin block chain.<ref>[https://www.reddit.com/r/Bitcoin/comments/39r85g/sidechain_hate/cs5spbg Security limitations of pegged chains], Gregory Maxwell, 14 June 2015</ref>)

==== Are sidechains a scaling option? ====

No. Sidechains have the same fundamental scaling problems as Bitcoin does. Moving some transactions to sidechains simply moves some problems elsewhere on the network—the total difficulty of the problem remains the same.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008617.html Sidechains not a direct means for solving any of the scaling problems Bitcoin has], Pieter Wuille, 13 June 2015</ref>

==== But couldn’t I create a sidechain that had 100 GB blocks? ====

Certainly, sidechain code is open source<ref>[https://github.com/ElementsProject/elements Elements Project]</ref>—so you can create your own sidechain. But you’d still have the difficulty of finding people who are willing to validate 100 GB blocks with their own full nodes.

==== Do sidechains require a hard fork? ====

No. Federated sidechains, such as have already been implemented<ref>[https://github.com/ElementsProject/elements/tree/alpha Elements Alpha]</ref>, don’t require any changes to the Bitcoin consensus rules. Merged-mined sidechains, which have not been implemented yet, do require a backwards-compatible soft fork in order to transfer funds between Bitcoin and the sidechain.<ref name="sidechains_paper" />

== References ==
<references />

Transaction

2014-07-21T07:59:02Z

Luzius: /* Input */ Even more precise wording: output script only gives hash of public key

[[File:TxBinaryMap.png|thumb|right|Byte-map of Transaction with each type of TxIn and TxOut]]
A '''transaction''' is a signed section of data that is broadcast to the [[network]] and collected into [[block|blocks]]. It typically references previous transaction(s) and dedicates a certain number of bitcoins from it to one or more new public key(s) (Bitcoin address). It is not encrypted (nothing in Bitcoin is encrypted).

A [[block chain browser]] is a site where every transaction included within the block chain can be viewed. This is useful for seeing the technical details of transaction in action, and for payment verification purposes.

=== general format of a Bitcoin transaction (inside a block) ===
{| class="wikitable"
|-
! Field
! Description
! Size
|-
|Version no
|currently 1
|4 bytes
|-
|In-counter
| positive integer [[ Protocol_specification#Variable_length_integer|VI = VarInt]]
| 1 - 9 bytes
|-
|list of inputs
|[[Transactions#general_format_.28inside_a_block.29_of_each_input_of_a_transaction_-_Txin|the first input of the first transaction is also called "coinbase" (its content was ignored in earlier versions)]]
|<in-counter>-many inputs
|-
|Out-counter
| positive integer [[ Protocol_specification#Variable_length_integer|VI = VarInt]]
| 1 - 9 bytes
|-
|list of outputs
|[[Transactions#general_format_.28inside_a_block.29_of_each_output_of_a_transaction_-_Txout|the outputs of the first transaction spend the mined bitcoins for the block]]
|<out-counter>-many outputs
|-
|lock_time
|if non-zero and sequence numbers are < 0xFFFFFFFF: block height or timestamp when transaction is final
|4 bytes
|}

=== Principle example of a Bitcoin transaction with 1 input and 1 output only ===

==== Data ====

<pre>Input:
Previous tx: f5d8ee39a430901c91a5917b9f2dc19d6d1a0e9cea205b009ca73dd04470b9a6
Index: 0
scriptSig: 304502206e21798a42fae0e854281abd38bacd1aeed3ee3738d9e1446618c4571d10
90db022100e2ac980643b0b82c0e88ffdfec6b64e3e6ba35e7ba5fdd7d5d6cc8d25c6b241501

Output:
Value: 5000000000
scriptPubKey: OP_DUP OP_HASH160 404371705fa9bd789a2fcd52d2c580b65d35549d
OP_EQUALVERIFY OP_CHECKSIG</pre>

==== Explanation ====

The input in this transaction imports 50 BTC from output #0 in transaction f5d8... Then the output sends 50 BTC to a Bitcoin address (expressed here in hexadecimal 4043... instead of the normal base58). When the recipient wants to spend this money, he will reference output #0 of this transaction in an input of his own transaction.

===== Input =====

An '''input''' is a reference to an output in a different transaction. Multiple inputs are often listed in a transaction. The values of the referenced outputs are added up, and the total is usable in the outputs of this transaction. '''Previous tx''' is a [[hash]] of a previous transaction. '''Index''' is the specific output in the referenced transaction. '''ScriptSig''' is the first half of a [[script]] (discussed in more detail later).

The script contains two components, a signature and a public key. The public key must match the hash given in the script of the redeemed output. The public key is used to verify the redeemers signature, which is the second component. More precisely, the second component is an ECDSA signature over a hash of a simplified version of the transaction. It, combined with the public key, proves the transaction was created by the real owner of the address in question. Various flags define how the transaction is simplified and can be used to create different types of payment.

===== Output =====

An '''output''' contains instructions for sending bitcoins. '''Value''' is the number of Satoshi (1 BTC = 100,000,000 Satoshi) that this output will be worth when claimed. '''ScriptPubKey''' is the second half of a script (discussed later). There can be more than one output, and they share the combined value of the inputs. Because each output from one transaction can only ever be referenced once by an input of a subsequent transaction, the entire combined input value needs to be sent in an output if you don't want to lose it. If the input is worth 50 BTC but you only want to send 25 BTC, Bitcoin will create two outputs worth 25 BTC: one to the destination, and one back to you (known as "[[change]]", though you send it to yourself). Any input bitcoins not redeemed in an output is considered a [[transaction fee]]; whoever generates the block will get it.
[[File:transaction.png|thumb|A sends 100 BTC to C and C generates 50 BTC. C sends 101 BTC to D, and he needs to send himself some change. D sends the 101 BTC to someone else, but they haven't redeemed it yet. Only D's output and C's change are capable of being spent in the current state.]]

===== Verification =====

To verify that inputs are authorized to collect the values of referenced outputs, Bitcoin uses a custom Forth-like [[script|scripting]] system. The input's scriptSig and the ''referenced'' output's scriptPubKey are evaluated (in that order), with scriptPubKey using the values left on the stack by scriptSig. The input is authorized if scriptPubKey returns true. Through the scripting system, the sender can create very complex conditions that people have to meet in order to claim the output's value. For example, it's possible to create an output that can be claimed by anyone without any authorization. It's also possible to require that an input be signed by ten different keys, or be redeemable with a password instead of a key.

=== Types of Transaction ===
Bitcoin currently creates two different scriptSig/scriptPubKey pairs. These are described below.

It is possible to design more complex types of transactions, and link them together into cryptographically enforced agreements. These are known as [[Contracts]].

==== Pay-to-PubkeyHash ====

scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <sig> <pubKey>
A Bitcoin [[address]] is only a hash, so the sender can't provide a full public key in scriptPubKey. When redeeming coins that have been sent to a Bitcoin address, the recipient provides both the signature and the public key. The script verifies that the provided public key does hash to the hash in scriptPubKey, and then it also checks the signature against the public key.

Checking process:
{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
| <sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| scriptSig and scriptPubKey are combined.
|-
|<sig> <pubKey>
| OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Constants are added to the stack.
|-
|<sig> <pubKey> <pubKey>
| OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Top stack item is duplicated.
|-
|<sig> <pubKey> <pubHashA>
|<pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Top stack item is hashed.
|-
|<sig> <pubKey> <pubHashA> <pubKeyHash>
|OP_EQUALVERIFY OP_CHECKSIG
| Constant added.
|-
|<sig> <pubKey>
|OP_CHECKSIG
| Equality is checked between the top two stack items.
|-
|true
|Empty.
|Signature is checked for top two stack items.
|}

==== Pay-to-Script-Hash ====

scriptPubKey: OP_HASH160 <scriptHash> OP_EQUAL
scriptSig: ..signatures... <serialized script>

m-of-n multi-signature transaction:
scriptSig: 0 <sig1> ... <script>
script: OP_m <pubKey1> ... OP_n OP_CHECKMULTISIG

P2SH addresses were created with the motivation of moving "the responsibility for supplying the conditions to redeem a transaction from the sender of the funds to the redeemer. They allow the sender to fund an arbitrary transaction, no matter how complicated, using a 20-byte hash"[https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki#motivation 1]. Pay-to-Pubkey-hash addresses are similarly a 20-byte hash of the public key.

Pay-to-script-hash provides a means for complicated transactions, unlike the Pay-to-pubkey-hash, which has a specific definition for scriptPubKey, and scriptSig. The specification places no limitations on the script, and hence absolutely any contract can be funded using these addresses.

The scriptPubKey in the funding transaction is script which ensures that the script supplied in the redeeming transaction hashes to the script used to create the address.

In the scriptSig above, 'signatures' refers to any script which is sufficient to satisfy the following serialized script.

Checking process:
{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
| 0 <sig1> <sig2> OP_2 <pubKey1> <pubKey2> <pubKey3> OP_3 OP_CHECKMULTISIG
| Only the scriptSig is used.
|-
| 0 <sig1> <sig2> OP_2 <pubKey1> <pubKey2> <pubKey3> OP_3
| OP_CHECKMULTISIG
| Constants are added to the stack.
|-
| true
| Empty
| Signatures validated in the order of the keys in the script.
|}

See also [[BIP 0016]]

==== Generation ====

Generations have a single input, and this input has a "coinbase" parameter instead of a scriptSig. The data in "coinbase" can be anything; it isn't used. Bitcoin puts the current compact-format [[target]] and the arbitrary-precision "extraNonce" number there, which increments every time the Nonce field in the [[block_hashing_algorithm|block header]] overflows. Outputs can be anything, but Bitcoin creates one exactly like an IP address transaction.
The extranonce contributes to enlarge the domain for the proof of work function. Miners can easily modify nonce (4byte), timestamp and extranonce (2 to 100bytes).

=== general format (inside a block) of each input of a transaction - Txin ===
{| class="wikitable"
|-
! Field
! Description
! Size
|-
|Previous Transaction hash
| doubled [[Wikipedia:SHA-256|SHA256]]-[[hash|hashed]] of a (previous) to-be-used transaction
|32 bytes
|-
|Previous Txout-index
| non negative integer indexing an output of the to-be-used transaction
|4 bytes
|-
|Txin-script length
|non negative integer [[ Protocol_specification#Variable_length_integer|VI = VarInt]]
|1 - 9 bytes
|-
|Txin-script / scriptSig
|[[Script]]
|<in-script length>-many bytes
|-
|sequence_no
|normally 0xFFFFFFFF; irrelevant unless transaction's lock_time is > 0
|4 bytes
|}

The input sufficiently describes where and how to get the bitcoin amout to be redeemed.
If it is the (only) input of the first transaction of a block, it is called the generation transaction input and its content completely ignored. (Historically the Previous Transaction hash is 0 and the Previous Txout-index is -1.)

=== general format (inside a block) of each output of a transaction - Txout ===
{| class="wikitable"
|-
! Field
! Description
! Size
|-
|value
|non negative integer giving the number of [[FAQ#What_do_I_call_the_various_denominations_of_bitcoins.3F|Satoshis(BTC/10^8)]] to be transfered
|8 bytes
|-
|Txout-script length
|non negative integer
|1 - 9 bytes [[ Protocol_specification#Variable_length_integer|VI = VarInt]]
|-
|Txout-script / scriptPubKey
|[[Script]]
|<out-script length>-many bytes
|}
The output sets the conditions to release this bitcoin amount later. The sum of the output values of the first transaction is the value of the mined bitcoins for the block plus possible transactions fees of the other transactions in the block.

==See Also==

* [[Script]]
* [[BTC Sender]] Transmit raw, hand-crafted transactions
* [[Raw Transactions]]
* [[Transaction Malleability]]

[[Category:Technical]]
[[Category:Vocabulary]]
[[de:Transaktion]]
[[es:Transacción]]
[[pl:Transakcje]]

Transaction

2014-07-21T07:57:02Z

Luzius: improved wording. the public key itself does not prove anything

[[File:TxBinaryMap.png|thumb|right|Byte-map of Transaction with each type of TxIn and TxOut]]
A '''transaction''' is a signed section of data that is broadcast to the [[network]] and collected into [[block|blocks]]. It typically references previous transaction(s) and dedicates a certain number of bitcoins from it to one or more new public key(s) (Bitcoin address). It is not encrypted (nothing in Bitcoin is encrypted).

A [[block chain browser]] is a site where every transaction included within the block chain can be viewed. This is useful for seeing the technical details of transaction in action, and for payment verification purposes.

=== general format of a Bitcoin transaction (inside a block) ===
{| class="wikitable"
|-
! Field
! Description
! Size
|-
|Version no
|currently 1
|4 bytes
|-
|In-counter
| positive integer [[ Protocol_specification#Variable_length_integer|VI = VarInt]]
| 1 - 9 bytes
|-
|list of inputs
|[[Transactions#general_format_.28inside_a_block.29_of_each_input_of_a_transaction_-_Txin|the first input of the first transaction is also called "coinbase" (its content was ignored in earlier versions)]]
|<in-counter>-many inputs
|-
|Out-counter
| positive integer [[ Protocol_specification#Variable_length_integer|VI = VarInt]]
| 1 - 9 bytes
|-
|list of outputs
|[[Transactions#general_format_.28inside_a_block.29_of_each_output_of_a_transaction_-_Txout|the outputs of the first transaction spend the mined bitcoins for the block]]
|<out-counter>-many outputs
|-
|lock_time
|if non-zero and sequence numbers are < 0xFFFFFFFF: block height or timestamp when transaction is final
|4 bytes
|}

=== Principle example of a Bitcoin transaction with 1 input and 1 output only ===

==== Data ====

<pre>Input:
Previous tx: f5d8ee39a430901c91a5917b9f2dc19d6d1a0e9cea205b009ca73dd04470b9a6
Index: 0
scriptSig: 304502206e21798a42fae0e854281abd38bacd1aeed3ee3738d9e1446618c4571d10
90db022100e2ac980643b0b82c0e88ffdfec6b64e3e6ba35e7ba5fdd7d5d6cc8d25c6b241501

Output:
Value: 5000000000
scriptPubKey: OP_DUP OP_HASH160 404371705fa9bd789a2fcd52d2c580b65d35549d
OP_EQUALVERIFY OP_CHECKSIG</pre>

==== Explanation ====

The input in this transaction imports 50 BTC from output #0 in transaction f5d8... Then the output sends 50 BTC to a Bitcoin address (expressed here in hexadecimal 4043... instead of the normal base58). When the recipient wants to spend this money, he will reference output #0 of this transaction in an input of his own transaction.

===== Input =====

An '''input''' is a reference to an output in a different transaction. Multiple inputs are often listed in a transaction. The values of the referenced outputs are added up, and the total is usable in the outputs of this transaction. '''Previous tx''' is a [[hash]] of a previous transaction. '''Index''' is the specific output in the referenced transaction. '''ScriptSig''' is the first half of a [[script]] (discussed in more detail later).

The script contains two components, a signature and a public key. The public key must match the one specified in the script of the redeemed output. The public key is used to verify the redeemers signature, which is the second component. More precisely, the second component is an ECDSA signature over a hash of a simplified version of the transaction. It, combined with the public key, proves the transaction was created by the real owner of the address in question. Various flags define how the transaction is simplified and can be used to create different types of payment.

===== Output =====

An '''output''' contains instructions for sending bitcoins. '''Value''' is the number of Satoshi (1 BTC = 100,000,000 Satoshi) that this output will be worth when claimed. '''ScriptPubKey''' is the second half of a script (discussed later). There can be more than one output, and they share the combined value of the inputs. Because each output from one transaction can only ever be referenced once by an input of a subsequent transaction, the entire combined input value needs to be sent in an output if you don't want to lose it. If the input is worth 50 BTC but you only want to send 25 BTC, Bitcoin will create two outputs worth 25 BTC: one to the destination, and one back to you (known as "[[change]]", though you send it to yourself). Any input bitcoins not redeemed in an output is considered a [[transaction fee]]; whoever generates the block will get it.
[[File:transaction.png|thumb|A sends 100 BTC to C and C generates 50 BTC. C sends 101 BTC to D, and he needs to send himself some change. D sends the 101 BTC to someone else, but they haven't redeemed it yet. Only D's output and C's change are capable of being spent in the current state.]]

===== Verification =====

To verify that inputs are authorized to collect the values of referenced outputs, Bitcoin uses a custom Forth-like [[script|scripting]] system. The input's scriptSig and the ''referenced'' output's scriptPubKey are evaluated (in that order), with scriptPubKey using the values left on the stack by scriptSig. The input is authorized if scriptPubKey returns true. Through the scripting system, the sender can create very complex conditions that people have to meet in order to claim the output's value. For example, it's possible to create an output that can be claimed by anyone without any authorization. It's also possible to require that an input be signed by ten different keys, or be redeemable with a password instead of a key.

=== Types of Transaction ===
Bitcoin currently creates two different scriptSig/scriptPubKey pairs. These are described below.

It is possible to design more complex types of transactions, and link them together into cryptographically enforced agreements. These are known as [[Contracts]].

==== Pay-to-PubkeyHash ====

scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <sig> <pubKey>
A Bitcoin [[address]] is only a hash, so the sender can't provide a full public key in scriptPubKey. When redeeming coins that have been sent to a Bitcoin address, the recipient provides both the signature and the public key. The script verifies that the provided public key does hash to the hash in scriptPubKey, and then it also checks the signature against the public key.

Checking process:
{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
| <sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| scriptSig and scriptPubKey are combined.
|-
|<sig> <pubKey>
| OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Constants are added to the stack.
|-
|<sig> <pubKey> <pubKey>
| OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Top stack item is duplicated.
|-
|<sig> <pubKey> <pubHashA>
|<pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Top stack item is hashed.
|-
|<sig> <pubKey> <pubHashA> <pubKeyHash>
|OP_EQUALVERIFY OP_CHECKSIG
| Constant added.
|-
|<sig> <pubKey>
|OP_CHECKSIG
| Equality is checked between the top two stack items.
|-
|true
|Empty.
|Signature is checked for top two stack items.
|}

==== Pay-to-Script-Hash ====

scriptPubKey: OP_HASH160 <scriptHash> OP_EQUAL
scriptSig: ..signatures... <serialized script>

m-of-n multi-signature transaction:
scriptSig: 0 <sig1> ... <script>
script: OP_m <pubKey1> ... OP_n OP_CHECKMULTISIG

P2SH addresses were created with the motivation of moving "the responsibility for supplying the conditions to redeem a transaction from the sender of the funds to the redeemer. They allow the sender to fund an arbitrary transaction, no matter how complicated, using a 20-byte hash"[https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki#motivation 1]. Pay-to-Pubkey-hash addresses are similarly a 20-byte hash of the public key.

Pay-to-script-hash provides a means for complicated transactions, unlike the Pay-to-pubkey-hash, which has a specific definition for scriptPubKey, and scriptSig. The specification places no limitations on the script, and hence absolutely any contract can be funded using these addresses.

The scriptPubKey in the funding transaction is script which ensures that the script supplied in the redeeming transaction hashes to the script used to create the address.

In the scriptSig above, 'signatures' refers to any script which is sufficient to satisfy the following serialized script.

Checking process:
{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
| 0 <sig1> <sig2> OP_2 <pubKey1> <pubKey2> <pubKey3> OP_3 OP_CHECKMULTISIG
| Only the scriptSig is used.
|-
| 0 <sig1> <sig2> OP_2 <pubKey1> <pubKey2> <pubKey3> OP_3
| OP_CHECKMULTISIG
| Constants are added to the stack.
|-
| true
| Empty
| Signatures validated in the order of the keys in the script.
|}

See also [[BIP 0016]]

==== Generation ====

Generations have a single input, and this input has a "coinbase" parameter instead of a scriptSig. The data in "coinbase" can be anything; it isn't used. Bitcoin puts the current compact-format [[target]] and the arbitrary-precision "extraNonce" number there, which increments every time the Nonce field in the [[block_hashing_algorithm|block header]] overflows. Outputs can be anything, but Bitcoin creates one exactly like an IP address transaction.
The extranonce contributes to enlarge the domain for the proof of work function. Miners can easily modify nonce (4byte), timestamp and extranonce (2 to 100bytes).

=== general format (inside a block) of each input of a transaction - Txin ===
{| class="wikitable"
|-
! Field
! Description
! Size
|-
|Previous Transaction hash
| doubled [[Wikipedia:SHA-256|SHA256]]-[[hash|hashed]] of a (previous) to-be-used transaction
|32 bytes
|-
|Previous Txout-index
| non negative integer indexing an output of the to-be-used transaction
|4 bytes
|-
|Txin-script length
|non negative integer [[ Protocol_specification#Variable_length_integer|VI = VarInt]]
|1 - 9 bytes
|-
|Txin-script / scriptSig
|[[Script]]
|<in-script length>-many bytes
|-
|sequence_no
|normally 0xFFFFFFFF; irrelevant unless transaction's lock_time is > 0
|4 bytes
|}

The input sufficiently describes where and how to get the bitcoin amout to be redeemed.
If it is the (only) input of the first transaction of a block, it is called the generation transaction input and its content completely ignored. (Historically the Previous Transaction hash is 0 and the Previous Txout-index is -1.)

=== general format (inside a block) of each output of a transaction - Txout ===
{| class="wikitable"
|-
! Field
! Description
! Size
|-
|value
|non negative integer giving the number of [[FAQ#What_do_I_call_the_various_denominations_of_bitcoins.3F|Satoshis(BTC/10^8)]] to be transfered
|8 bytes
|-
|Txout-script length
|non negative integer
|1 - 9 bytes [[ Protocol_specification#Variable_length_integer|VI = VarInt]]
|-
|Txout-script / scriptPubKey
|[[Script]]
|<out-script length>-many bytes
|}
The output sets the conditions to release this bitcoin amount later. The sum of the output values of the first transaction is the value of the mined bitcoins for the block plus possible transactions fees of the other transactions in the block.

==See Also==

* [[Script]]
* [[BTC Sender]] Transmit raw, hand-crafted transactions
* [[Raw Transactions]]
* [[Transaction Malleability]]

[[Category:Technical]]
[[Category:Vocabulary]]
[[de:Transaktion]]
[[es:Transacción]]
[[pl:Transakcje]]

Bitcoin Wiki:Community portal

2013-11-22T17:10:09Z

Luzius: /* Non-profit Organizations */

== Bitcoin Community Forums on various platforms ==

* [http://bitcointalk.org/ Bitcointalk]
* [http://www.reddit.com/r/Bitcoin/ /r/Bitcoin]
* [http://bitcoin.org.uk/forums Bitcoin Forums]
* [http://bitcoin.stackexchange.com/ The Bitcoin StackExchange]
* [http://www.quora.com/Bitcoin/ Bitcoin group on Quora]
* [http://bitcointrading.com Bitcoin Trading Forum]
* [http://tweetforum.com/bitcoin TweetForum Bitcoin Community]
* [http://www.bitcoin-board.com/ Bitcoin-Board Forum]
* [http://www.bitcoinforums.net BitcoinForums.Net]
* [http://groups.google.com/group/bitcoin-discussion Bitcoin google group]
* [http://goo.gl/2PncY Bitcoin Portal p2p (on Osiris platform)]
* [http://www.btclog.com btc::log]
* [http://www.facebook.com/bitcoins Facebook page]
* [http://www.facebook.com/groups/136003253120130 Facebook Group]
* [https://plus.google.com/107581642674912229828/ Bitcoin Google+]
* [http://www.bitcointribe.com Bitcoin Tribe Social Network]

===Regions / Languages===

* [https://www.bitcoin-italia.org Bitcoin Italia]
* [http://forum.bitcoin.com.au/ Bitcoin Australia Forum]
* [http://www.bitcoin.org.il Isreali Bitcoin community forum]
* [http://bitcoin.pl/forum/ Polish Bitcoin community forum]
* [http://btcsec.com/ BTCsec.com] Russian website about Bitcoin
* [https://forum.btcsec.com/ BTCsec.com Bitcoin community forum (Russian)]
* [http://rubitcoin.com/ Russian bitcoin community forum]

== Bitcoin Community Groups on Bitcoin Wiki platform ==

=== Special interests ===
* [[Bitcoin Wiki]]-group

=== Geographically ===
* [[Espagna]] / [[Spain]] (E.)
* [[France]] / [[France]] (F.)
* [[Germany]] / [[Deutschland]] (D.)
* [[Netherlands]] (NL) and [[Belgium]] (B.)
* [[United Kingdom]] of Great Brittain (GB) and Northern Ireland
* [[United States]] of America (USA)

====Clusters====
There are various temporary and permanent clusters where bitcoin-friendly communities form. Temporary clusters are listed in [[Bitcoin:Community_portal#Events|events]]. Permanent communities include:

* [http://bitcointalk.org/index.php?topic=66832.0 Free State Project] New Hampshire
* [http://www.thebitcointrader.com/2012/05/bitcoins-hogwarts-san-francisco-tech.html 20 Mission] San Francisco, CA
* [http://bitcoinmagazine.net/bitcoin-kiez-rollout-3-new-btc-accepting-stores-and-restaurants-in-berlin-more-to-come Bitcoin Kiez] Berlin, Germany

== IRC Chat ==

* See [[IRC_channels|IRC channels]]

==Wiki Users==

* [http://en.bitcoin.it/wiki/Special:ListUsers List of Users] registered on the Bitcoin wiki.

== Events ==
Periodic events where Bitcoin community meets include PorcFest, Chaos Computer Camp, Burning Man, Bitcoin conferences and more.

* [[Meetups]]
* [http://bitcointalk.org/index.php?topic=4526.0 Events, conferences and other events]

==Bitcoin Related Publications==

* [http://bitcoinmagazine.net Bitcoin Magazine] periodical printed publication
* [http://twitter.com/bitcoinnews/bitcoin @BitcoinNews/bitcoin] Twitter list
* [[Bitcoin Weekly]] weekly newspaper by [[User:Kiba|Kiba]]
* See [[:Category:Blogs|Blogs]] category
* See [[:Category:Directories|Directories]] category
* See [[Press]]

==Education==

* [[:Category:Educational|Educational category]]

== Maps ==
* [http://bitcoinyellowpages.com Bitcoin Yellow Pages], A fast growing Bitcoin search directory showing all Bitcoin business locations on a world map. Search by keyword, location, or category to find the Bitcoin business that fits your needs.
* [http://coinmap.org/ CoinMap], collaborative map based on OpenStreetMap data and rendering
* [[Bitcoin.local]] Local exchanges
* The [[Bitcoin Map (Collaborative map)|Bitcoin Map]] collaborative map
* [[Bitcoin Users Worldwide]] - Find nearby Bitcoin users • Engage in local trade • Add your own offers • Get notifications

== Monitoring ==
* [http://bitcoincharts.com/markets/ Bitcoin Charts] displays an overview of Bitcoin exchange markets.
* The [http://www.bitcoinmonitor.com/ Bitcoin Monitor] visualizes transactions, new blocks and trades on markets as they are happening.
* [http://www.bitcoinwatch.com/ Bitcoin Watch] has various statistics on things like the size of the economy or the number of transactions.

== Portfolio ==
* [http://my-btc.info MY-BTC.INFO] A free profit/loss portfolio manager for Bitcoins and other digital currencies.
* [http://myBitWorth.com myBitWorth] - allows you to track your bitcoin holdings over multiple addresses and portfolios on the bitcoin securities exchanges.

== Bitcoin Project ==
* [http://www.bitcoin.org Bitcoin.org] Official project site
* [[:Category:Developer|Developer]] pages

== Non-profit Organizations ==

* [[List_of_Bitcoin_non-profits_around_the_world|List of Bitcoin non-profits around the world]]

== External Communities ==
* [http://www.etsy.com/teams/10366/bitcoin Bitcoin team on Etsy]
* [http://weacceptbitcoins.deviantart.com #WeAcceptBitcoins group on DeviantArt]
* [https://www.couchsurfing.org/group.html?gid=38717 Bitcoin group on Couchsurfing.org]
* [http://steamcommunity.com/groups/bitcoin Bitcoin group on Steam] platform by Valve
* [http://forums.somethingawful.com/showthread.php?threadid=3413928 Bitcoin on SomethingAwful]
* [http://AnonCoin.org AnonCoin.org]
* [http://forum.guildminers.com/ Guildminers Forum]
* [http://www.Ogrr.com Ogrr]
* [http://www.coinconnect.org/ CoinConnect] bitcoin social network
* [http://www.rugatu.com/ Rugatu] Q&A Community

List of Bitcoin non-profits around the world

2013-11-22T16:05:44Z

Luzius: Fixing Swiss link

This page will list all the known Bitcoin and crypto-currency non-profits around the world. The criterias for being on this list are:

# A focus on Bitcoin or crypto-currency (merely accepting Bitcoin donations is not enough)
# Being a non-profit
# The organization needs to be either a registered non-profit or in the process of active registration.

= List of organizations (by country of residence)=
== Australia: The Bitcoin Association of Australia ==
* Board members:
** [[Martin Bajalan]]
** [[Max Kaye]] Treasurer
** [[Adam Poulton]] Secretary
** [[Pantelis Roussakis]] Vice-President
** [[Bret Treasure]]
** [[Jason Williams]] President
** [[Tristan Winters]]

== Austria: Bitcoin Austria ==
* [http://bitcoin-austria.at/ Website]

== Belgium: Belgian Bitcoin Association ==
* Directors:
** [[Arne Brutschy]]
** [[Chris D'Costa]]
** [[Jérémie Dubois-Lacoste]]
** [[Filip Roose]]
** [[Thomas Spaas]]
** [[Jean Wallemacq]]

== Canada: The Bitcoin Embassy ==
* [http://bitcoinembassy.ca website]
A non-profit organization seeking to promote the adoption of Bitcoin and related crypto-technologies, as well as facilitating networking throughout the Bitcoin community in Canada and worldwide.

== Germany: Bundesverband Bitcoin e.V. ==
* [http://www.bundesverband-bitcoin.de/ Website]
* Board members:
** [[Radoslav Albrecht]]
** [[Dennis Daiber]]
** [[Oliver Flaskämper]]
** [[JF Gallas]] Chairman
** [[Timo Hanke]]
** [[Jörg von Minckwitz]]
** [[Jörg Platzer]] Vice Chairman

== Israel: איגוד הביטקוין הישראלי ==
See [[The Israeli Bitcoin Association]].

== Italy: Bitcoin Foundation Italia ==
* [https://www.bitcoin-italia.org/ Website]
* Board members:
** [[Andrea Medri]]
** [[Davide Barbieri]]
** [[Franco Cimatti]]

== Netherlands: Stichting Bitcoin Nederland ==
* [http://stichtingbitcoin.nl/ Website]
* [http://stichtingbitcoin.nl/index.php/de-stichting/het-bestuur/ Board members]:
** [[Mark van Cuijk]]
** [[Jouke Hofman]]
** [[Richard Kohl]]
** [[Carl Kuntze]]
** [[Sicco Steenhuisen]] Chairman

== Switzerland: Bitcoin Association Switzerland ==
* [http://www.bitcoinassociation.ch/ Website]
* Board members:
** [[Johann Gevers]] - Treasurer
** [[Stefan Greiner]] - Secretary
** [[Luzius Meisser]] - President

== United Kingdom: UK Bitcoin Foundation ==
* [[Adam Cleary]]
* [[Paul Gordon]]
* [[Eitan Jankelewitz]]
* [[Tom Robinson]]
* [[James Smith]]
* [[Lee Welham]]

== United States / International: Bitcoin Foundation ==
* [http://bitcoinfoundation.org/ website]
* [https://bitcoinfoundation.org/about/board Board members (alphabetically)]:
** [[Gavin Andresen]] - Chief Scientist
** [[Mark Karpeles]] - Board Member
** [[Jon Matonis]] - Executive Director and Board Member
** [[Patrick Murck]] - General Counsel
** [[Charlie Shrem]] - Vice Chairman
** [[Peter Vessenes]] - Chairman of the Board

= Other =
== Bitcoin100 ==
[http://bitcoin100.org/ Bitcoin100] is a charity organization that exists specifically to convince new charities to start accepting bitcoin donations.

== The Mastercoin Foundation ==
See [http://wiki.mastercoin.org/index.php/The_Mastercoin_Foundation the Mastercoin wiki].

== PikaPay Foundation ==

The [https://PikaPay.com PikaPay Foundation] is a nonprofit dedicated to innovation in today’s financial systems and is focussed on developing the Bitcoin ecosystem.

PikaPay's Mission: To explore trends in science, technology, community and culture; To overcome limitations of traditional financial services; To improve lives, empower groups and individuals; and To make greater social contributions to the world.

= See Also =
# [https://bitcointalk.org/index.php?topic=288677.0 bitcointalk thread]
# [https://docs.google.com/document/d/1TnTCcT7fiNr5nt-oApr_7DwXAypFoJpZ6lk_w_ykwcc/edit google doc].
# [[:Category:nonprofit]]

List of Bitcoin non-profits around the world

2013-11-22T16:04:43Z

Luzius: Ordering organizations by country and using actual name in title, adding link to German association, added Swiss association, added Austria

This page will list all the known Bitcoin and crypto-currency non-profits around the world. The criterias for being on this list are:

# A focus on Bitcoin or crypto-currency (merely accepting Bitcoin donations is not enough)
# Being a non-profit
# The organization needs to be either a registered non-profit or in the process of active registration.

= List of organizations (by country of residence)=
== Australia: The Bitcoin Association of Australia ==
* Board members:
** [[Martin Bajalan]]
** [[Max Kaye]] Treasurer
** [[Adam Poulton]] Secretary
** [[Pantelis Roussakis]] Vice-President
** [[Bret Treasure]]
** [[Jason Williams]] President
** [[Tristan Winters]]

== Austria: Bitcoin Austria ==
* [http://bitcoin-austria.at/ Website]

== Belgium: Belgian Bitcoin Association ==
* Directors:
** [[Arne Brutschy]]
** [[Chris D'Costa]]
** [[Jérémie Dubois-Lacoste]]
** [[Filip Roose]]
** [[Thomas Spaas]]
** [[Jean Wallemacq]]

== Canada: The Bitcoin Embassy ==
* [http://bitcoinembassy.ca website]
A non-profit organization seeking to promote the adoption of Bitcoin and related crypto-technologies, as well as facilitating networking throughout the Bitcoin community in Canada and worldwide.

== Germany: Bundesverband Bitcoin e.V. ==
* [http://www.bundesverband-bitcoin.de/ Website]
* Board members:
** [[Radoslav Albrecht]]
** [[Dennis Daiber]]
** [[Oliver Flaskämper]]
** [[JF Gallas]] Chairman
** [[Timo Hanke]]
** [[Jörg von Minckwitz]]
** [[Jörg Platzer]] Vice Chairman

== Israel: איגוד הביטקוין הישראלי ==
See [[The Israeli Bitcoin Association]].

== Italy: Bitcoin Foundation Italia ==
* [https://www.bitcoin-italia.org/ Website]
* Board members:
** [[Andrea Medri]]
** [[Davide Barbieri]]
** [[Franco Cimatti]]

== Netherlands: Stichting Bitcoin Nederland ==
* [http://stichtingbitcoin.nl/ Website]
* [http://stichtingbitcoin.nl/index.php/de-stichting/het-bestuur/ Board members]:
** [[Mark van Cuijk]]
** [[Jouke Hofman]]
** [[Richard Kohl]]
** [[Carl Kuntze]]
** [[Sicco Steenhuisen]] Chairman

== Switzerland: Bitcoin Association Switzerland ==
* [https://www.bitcoinassociation.ch/ Website]
* Board members:
** [[Johann Gevers]] - Treasurer
** [[Stefan Greiner]] - Secretary
** [[Luzius Meisser]] - President

== United Kingdom: UK Bitcoin Foundation ==
* [[Adam Cleary]]
* [[Paul Gordon]]
* [[Eitan Jankelewitz]]
* [[Tom Robinson]]
* [[James Smith]]
* [[Lee Welham]]

== United States / International: Bitcoin Foundation ==
* [http://bitcoinfoundation.org/ website]
* [https://bitcoinfoundation.org/about/board Board members (alphabetically)]:
** [[Gavin Andresen]] - Chief Scientist
** [[Mark Karpeles]] - Board Member
** [[Jon Matonis]] - Executive Director and Board Member
** [[Patrick Murck]] - General Counsel
** [[Charlie Shrem]] - Vice Chairman
** [[Peter Vessenes]] - Chairman of the Board

= Other =
== Bitcoin100 ==
[http://bitcoin100.org/ Bitcoin100] is a charity organization that exists specifically to convince new charities to start accepting bitcoin donations.

== The Mastercoin Foundation ==
See [http://wiki.mastercoin.org/index.php/The_Mastercoin_Foundation the Mastercoin wiki].

== PikaPay Foundation ==

The [https://PikaPay.com PikaPay Foundation] is a nonprofit dedicated to innovation in today’s financial systems and is focussed on developing the Bitcoin ecosystem.

PikaPay's Mission: To explore trends in science, technology, community and culture; To overcome limitations of traditional financial services; To improve lives, empower groups and individuals; and To make greater social contributions to the world.

= See Also =
# [https://bitcointalk.org/index.php?topic=288677.0 bitcointalk thread]
# [https://docs.google.com/document/d/1TnTCcT7fiNr5nt-oApr_7DwXAypFoJpZ6lk_w_ykwcc/edit google doc].
# [[:Category:nonprofit]]