Well I would suggest a lot more reading as there are concepts far more complex than this.  The answer is that they don't.  Bitcoin and other blockchain based networks are 'gossip networks'.  A node with new information (new txn, new block, new alert) notifies its direct peers.  Those peers verify/authenticate the new information and then notify their direct peers who verify it and forward it to their peers.  This process continues until all nodes are aware of the new information.

This.  2FA doesn't apply to backups.   Did you have a backup emailed to yourself?  Stored on your computer?  Sent to dropbox?

Bitcoin will be the Bitcoin 2.0. 

No.  To the Bitcoin network anything in the OP_RETURN output has no meaning or significance.  It is third party systems which use OP_RETURN for some specific meaning.  Without that third party the message means nothing.

For example imagine an OP_RETURN message which says "I D&T transfer 250 bingbings to onkkill (signature)".  There is no such concept of a bingbings in the Bitcoin network.  In fact the entire OP_RETURN is just treated as "junk".  However imagine there was a bingbings network and it could verify that I have 250 bingbings eligible for transfer and also to transfer and that the message is authentic (created by me).  The bitcoin network (nodes and miners) have no idea what that means, they don't care.  It is only in this hypothetical bingbings network (which is piggybacking on Bitcoin) that the message has any meaning or relevance.  Under this scenario now in the future YOU could create a new OP_RETURN transfering some number of bingbings to someone else.  Once again the bitcoin network won't be validating it, hell it won't even be reading it.  OP_RETURN is just a way for your to piggyback your third party message onto the Bitcoin network.

Why would bingbings piggyback on Bitcoin instead of using their own network?  Bitcoin is incredibly secure, many magnitudes more secure than a bingbings network could ever hope to be.  What if I didn't have any bingbings and created the message anyways would the OP_RETURN output be valid? Of course it was.  Any data in an OP_RETURN output (subject to size and number limitations) is valid.  The Bitcoin network has no idea what the actual message is, doesn't care, and has no way or reason to try and validate it.  So it would eventually be included in a block.  However clients on the bingbings network parse the Bitcoin blockchain and would see by OP_RETURN message but they (BingBings nodes) would discard it as invalid because it is not valid for THEIR network.

Today most (all?) miners accept some zero fee transactions.  Yet fees have not gone down to zero.  They is a balance between cost and convenience.  If there wasn't then ATMs, convenience stores, and overnight mail wouldn't exist as services.

If 100% of miners will accept your txn for $0.05 in fees and 10% will accept your txn for free most rational users will still pick $0.05 in fees on many transactions.  Saving $0.05 usually doesn't make sense and in many cases ends up being the more expensive option (due to volatility risk).  We see this dynamic right now in every block.  There are plenty of "high priority" transactions which include a fee despite it not being required by the full nodes.  Unlike low priority transactions which will not be relayed by full nodes unless they include a fee, high priority transactions will be relayed without a fee so they are guaranteed to end up in the memory pool of miners.  At that point it is only a matter of time before they are included in a block.  The amount of space devoted to high priority transactions is however limited and that means transaction times for unpaid transactions are both long and unpredictable.  For many users the short and predictable confirmation times are worth more than the fee.

If someday 10% of the hashrate decided to include free transactions I think the rest of the miners would love that and probably reduce or eliminate the space they currently give away for free to include more paying transactions.

Hard forks are not trivial.  This is going to be a six month process.  The goal would be that when the fork occurs a super majority of users, merchants, service providers, exchanges, and miners are already proactively ready.  Despite the gnashing of teeth, doomsday claims, and threats of a bitcoin war when the fork happens it will be a wimper.  We saw the same thing with P2SH.  The reason we are talking about it now is because it is a long process and talking about it after the transactions are backing up due to insufficient capacity would put everyone behind the eight ball.

Nope.  You don't have to do anything.  If there is a fork you would need to upgrade your client if/when you decide to spend coins.  That is about it.  Seeing how Gavin and the other developers moved forward with P2SH it won't happen until there is a super majority of support.

It does work out of the box.  There is something blocking the user's internet connection (at least on the port used by bitcoind).  This fact was seemingly missed by 99% of the responses.  If Bitcoind can't connect to any peers it can't sync.  This is a connectivity issue.   Some possibilities would include:
* over restrictive firewall (most firewalls by default on block incoming ports but some may block outgoing traffic as well)
* ISP filtering (ISP is dropping all traffic on port 8333).
* another application using the same port (would be uncommon).

5JmdXtN7fDwaD8ZH2a1ksEeotDaw6­WKahgCCArLZmCV8RLBAiDW

can not even be decoded.  It is not proper base58 encoding of anything.

There is no need for Satoshi to chime in (although if he did reappear I have a list of questions).   The first version of the client had no block size limit.   The second version of the client had no block size limit.  The next 146 commits to the repo had no block size limit.  The source code is the proof.   The block size limit wasn't added as an anti-spam mechanism until more than 21 months after the genesis block.

You don't.

1) The version indicates the version of the client running.   If you can't figure this out then you obviously are not running a customized client.
2) It is about the stupidest form of "advertising".  Something which is only available in logs or debug panel. 

Just because someone else does something idiotic to spoof the network doesn't mean you need to follow them.

Please show me the commit where Satoshi added the 1MB block limit.  What about it makes you believe it was either permanent or intended to be more than an anti-spam rule?

Satoshi had no limit on block sizes at all.   From block 1 it was legal to have a 2MB, 20MB, even 33MB block.   There was a 33.5MB limit on message length and since blocks are transmitted as a single message it would have limited blocks to only 33.5MB but even this wasn't a hard limit as new message type could have been added which transmitted blocks in other ways (i.e. header & txn hashes vs full transactions).

The 1MB "limit" was added as a temporary anti-spam measure 18 months later.   There was no voting, no significant discussion, and the commit wasn't made by Satoshi.  It actually was combined with a bunch of other unrelated changes and not even well documented at the time.  There is nothing which indicates this was a core design decision that Bitcoin would perpetually be limited to 1MB.

I agree.  I didn't have the time to respond in your thread but I don't believe there is "one blockchain to rule them all" however even for those who believe Bitcoin can exists as an interchange between a diverse ecosystem of networks the block size will need to be raised.  1MB blocks prevent even infrequent access by users between the Bitcoin network and side networks without "trusted" intermediaries.  If the backbone is centrally controlled then the supporting ecosystem is built on a foundation of sand.

We may see most of the overall transaction data occurring on side networks or way may see sidechains only used in niche applications where they provide a tangible benefit over Bitcoin "core".  I don't know how it is going to play out there are advantages and disadvantages either way.   How, when, by what method, and to what ultimate end the transaction capacity will be increased are all good questions.

Probably and it may be infeasible to raise the cap further in the future even if that would be optimal.  However with a 20MB or 33.6 MB* (2^25) block size Bitcoin at least has the potential to exist as a backbone of sorts and it does provide us breathing room.  Once again I am not advocating any particular size limit, timeline, or method to raise the cap just that the idea of permanently keeping a 1MB block size just fails basic math and reasoning.   If the post convinces some people to go from "never raise the limit" to "I have concerns how can be raise the limit in a way which addresses them" then it served its purpose.


* The only "limit" definitively set by Satoshi.

It certainly could be.   The point of the post wasn't to arrogantly state what we must do or even that we must do something now.   I would point out that planning a hard fork is no trivial manner so the discussion needs to start now even if the final switch to new block version won't actually occur for 9-12 months.   The point was just to show that a permanent 1MB cap is simply a non-starter.  It allows roughly 1 million direct users to make less than 1 transaction per month.  That isn't a backbone it is a technological dead end.

For the record I disagree with Gavin on if Bitcoin can (or even should) scale to VISA levels.   It is not optimal that someone in Africa needs transaction data on the daily coffee habit of a guy in San Francisco they will never meet.   I do believe that Bitcoin can be used as a core backbone to link a variety of other more specialized (maybe even localized) systems via the use of sidechains and other technologies.  The point of the post was that whatever the future of Bitcoin ends up being it won't happen with a permanent 1 MB cap.

https://gist.github.com/gavinandresen/5044482

I am not sure the numbers are completely sound so I am not saying rely on them like gospel but more as a thought exercise.  I think the underlying study that Gavin relied on has some pretty worst case assumptions backed in and the average miner is probably going to be better connected than the average non-miner.  Still even assuming they estimate is 10x actual cost the idea that there is no cost is simply not supported.   A 1 satoshi fee (or even 100 satoshi fee) for all intents and purposes is a no fee transaction.

As for fees making up the difference of the subsidy cut ... they won't.  However at the current time the network is probably overprotected relative to the actual economic value of the transactions occurring on it.  Subsidies tend to do that in any market.   So over the next five years the difference caused by the two halvings will be compensated by a combination of a) some reduction in overall security, b)the rise in the exchange rate as miners costs are mostly in fiat terms, and c)rise in overall block fees.

You keep saying this but the cost is not zero.  The cost of orphaned blocks is very real.   If you increase propagation time by six seconds then the probability that your block will be orphaned increased by 1%.  Those transactions have to be paying more than the estimated loss due to increased propagation delay or the miner takes a net loss.  As margins squeeze and the subsidy declines, miners that are bad at math will quickly become bankrupt miners that will be replaced by miners less bad at math.

Another way to look at it is if you double the size of a block you double the chance of your block being orphaned however since miners include highest fee transactions first doubling the size of the block does not double your gross revenue.  At some point there is that marginal transaction where despite it having a fee it will result in a net loss to include it.  A rational miner will draw the minimum fee policy just above that line.

Permanently keeping the 1MB (anti-spam) restriction is a great idea, if you are a bank. Those favoring a permanent 1MB cap, whilst asserting that Bitcoin can still be a financial backbone of sorts, don't know how right they are. The problem isn't a limit in general but that 1MB provides so little transaction capacity that, under any meaningful adoption scenario, it will push all individual users off the blockchain to rely on trusted third parties. 1MB is insufficient for end to end direct user access, but it is sufficient for a robust inter-‘bank’ settlement network.

If the cap is not raised to some higher limit; allowing a larger number of users to maintain direct access, then individuals will be priced out of the blockchain. When that happens Bitcoin becomes yet another network with no direct (peer) access; like FedWire, SWIFT, and other private closed transfer networks.  There is no realistic scenario where a network capped permanently at 1MB can have meaningful adoption whilst still maintaining direct access to the blockchain by individuals. To be clear, by ‘direct access’ I mean both parties transacting directly on-chain without relying on an intermediary or trusted third party.

Satoshi Nakamoto - Bitcoin Whitepaper

Finding a balance
If the transaction capacity of a peer to peer network is very low then the resource requirements of running a full node will also be low but the cost of a transactions will be high.  A network that keeps computing requirements low but which has priced direct access to that network out of the hands of individuals doesn't help decentralization. Likewise if the transaction capacity of the network is very high then the cost of transactions will be low but the resource requirements for running a full node will be high.  A network that has sufficient transaction capacity for every possible transaction but which requires resources that put operation of a full node beyond the capabilities of individuals also doesn't help decentralization.

There is no "perfect" transaction rate.  It is a compromise between two different centralization risks.  Lowering the risk of transaction centralization raises the risk of node centralization and the reverse is also true.  A robust network means minimizing overall risk not minimizing one risk at the expense of the other.  This means that neither extreme is optimal.  What level of transaction capacity (in terms of block size) provides the optimum balance will be saved for future discussions. Having a discussion on how to change the network first requires an acceptance that the network needs to change.  So lets start with why the network must change.


Can we stop talking about a cup of coffee please?
If you have been following the discussion you may have heard a claim such as "Every $5 coffee doesn't need to be on the blockchain so there is no need to raise the limit".   The implied meaning is that while the cost of permanently keeping the limit will exclude 'trivial' transactions you will still have direct access to the blockchain for everything else.   This is misleading as the 1MB restriction is so restrictive that larger more meaningful transactions will eventually become uneconomical as well.  

I don't really care if my morning coffee is paid for using a centralized service.  Centralization and trusted third parties aren't always bad. <gasp>.  Context matters so try to read the rest before freaking out.  Have you ever given or received a gift card?   Can't get more centralized than that.  If I put $100 in Bitcoins under the control of a third party say in a ewallet or bitcoin debit card service, the risk and scope of that centralization are limited and manageable.  As long as direct access to the network remains economical I can securely store and transfer my wealth using on-chain transactions and use centralized solutions where the risk is low such as day to day purchases.  On the other hand if the imbalance between transaction demand and capacity makes individual transactions uneconomical I will lose direct access all together and that risk is more severe and the consequences more significant.

Sidechains, payment channels, and cross-chain atomic transactions are decentralized system that can move some of the transaction volume off the primary chain.  In essence like centralized solutions they can act as a multiplier allowing a higher number of total transactions than the number of direct on-chain transactions.   It is important to realize they still rely on the primary chain having sufficient transaction capacity or they aren't trustless.  As an example a payment channel could allow hundreds or even thousands of off chain transactions but it requires periodic on-chain transactions to create, adjust, and takedown.  If the individual user loses direct access to the primary chain they also lose trust free solutions like payment channels.  If direct access becomes prohibitively expensive then only alternative which provides sufficient scale is using trusted third parties.

When demand significantly exceeds capacity it increases the utility and value of centralized solutions
If the transaction demand exceeds capacity by a magnitude or more it will lead to direct users being replaced by trusted third parties acting as aggregators.   There are a lot of disadvantages to centralized services but they are more efficient and if the artificial limit is kept it will play right into the advantages of centralized services.  A third party can facilitate instant off-chain transactions.  If demand outstrips the very limited capacity it will force transactions off-chain using trusted third parties which I will call processors.  

Today these processors would include online wallet providers, exchanges, merchant payment service providers, and services where the user maintains a balance under the control of the merchant (casino, poker room).  In time even traditional financial companies and banks could be processors.  The one thing they all have in common is that customers of these services do not have direct control over private keys and do not directly make transactions on the network.  The processor has control over the private keys, keeps the Bitcoins in reserve and maintains an internal ledger of user transactions and balances.   Processors can trivially facilitate transactions between two customers of their service.   Since they control the private keys they simply update the ledger balances of the two customers and many of them do this today.  

However transactions can still occur off-chain even if they involve customers of different processors.  The process is not trustless but risk can be managed.  Two processors would aggregate all the transactions which occur between their customers and then periodically settle the difference.  When a payment from a customer of one processor is made to a customer of another processor the sending processor will notify the receiving processor.  Both processors will update their internal ledgers.  Over time this will result in an accumulated balanced owed by one processor to the other which can be settled with a single on-chain transaction.  The key thing is that there is a one to many relationship between the settlement transactions and underlying customer transactions.   While the 1MB block limit does not provide sufficient capacity for a large number of direct user transactions, third party processors can facilitate a very large number of off-chain transactions using a smaller number of on-chain settlements.  Blocks of a finite size can support a nearly unlimited amount of off-chain transaction capacity with the limitation that it involves the use of trusted third parties.

You can't competing with a 'bank'
You might be considering the point above but dismissing it because you still 'could' submit a transaction to the network.  The processors described above don't have the ability to close the network but a network that you have technical access to but which is uneconomical is effectively no access at all.  The current block size realistically limits capacity to no more than two to four transactions per second.  Two transactions per second is roughly 64 million transactions per year.  A finite number of transactions can't support an infinite number of direct users.  Say at some point there are ten million users and they wish to make two transactions per month.  That is 240 million transactions but only 64 million will fit in the blocks.  What happens to the excess.  If third party processors are attractive the difference will be handled by them. When you consider a settlement network would allows these third party processors to offer instant, 'no risk' transactions at significantly lower fees than on chain transactions the excess demand will be processed off-chain.   If the network continues to grow the profitability of these companies will grow and that will lead to more third party companies.   Those settlement transactions allow more off-chain transactions but at the same time compete with direct user transactions for the limited on-chain capacity.  In a settlement network the upper limit on the number of settlements required grows exponentially with the number of trusted peers.  Just two hundred trusted peers (crypto banks) performing hourly settlements would fill the blocks, all the blocks perpetually.  There may be billions of 'Bitcoin' transactions but they would be nothing more than updates on centralized ledgers.  The blockchain would just handle the settlement between massive financial service providers.  As these entities are collecting fees, and on chain transactions are a necessity of doing business, they can and will pay far more than you to ensure timely inclusion in a block.   When you as an individual have been reduced to a position where you must outbid a 'bank' for space in the blockchain then you have effectively lost access to the blockchain.

Wait I don't get how off blockchain transactions could occur across entities
Imagine two large financial service providers where thousands of customers make payments to customers of the other entity.  These may not be banks in the traditional sense, they can be any entity which acts as a third party to manage the bitcoins and transactions of customer.  Today it could be major exchanges, payment processors, and ewallet providers but tomorrow it could include traditional financial service companies or even banks.   For this example lets call the two entities Chase and HSBC.   Chase and HSBC can notify each other when one of their customers makes a payment to a customer of the other entity.  Both would update their internal ledgers and the payments would appear to occur instantly.  Most importantly none of them would require an on-chain transaction.  It is just updating numbers in a ledger.  If you are a Coinbase customer and pay another coinbase customer this happens today.  We are only taking it a step further and handling cross entity transactions.  Now the entities have no real cost to perform these payments.  They are just sharing a few bytes of information with their counterparty and updating numbers in a database.  However over time, the net amount of the thousands of transactions will result in one entity accumulating a balanced owed to the other.  This is why settlement networks require some level of trust.   It requires trusted peers to extend mutual lines of credit to each other.  The more they trust each other, the larger the lines of credit and the less frequently they need to settle.  It is also why you will never be a peer on this network.  The entities would enter into a legally binding agreements which set up the conditions of the settlement.  The amount of funds the entities are risking is limited.  The entities will limit the amount of credit they will extend and the terms are usually very short.  These aren't long term loans, in the traditional banking world settlement might occur the next business day.  The efficiency of the blockchain allows for lower capital requirements and lower risk by settling more frequently maybe even hourly.

Imagine that in a particular hour HSBC customers make thousands of payments to Chase customers totalling 10,000 BTC and Chase customers make thousands of payments to HSBC customers totalling 3,000 BTC.  In total transaction volume is worth 13,000 BTC.   As these payments occur Chase and HSBC notify the other party.  This allows both to update their ledgers.  A customer making a payment would see their balance be reduced 'instantly' and the customer receiving a payment would see their balance increase 'instantly'.  The net flows however are not balanced.  Chase has increased their customer balances 10,000 BTC and only reduced their customer balances 3,000 BTC.  On the books both entities have a liability called 'Customer Deposits'.  They keep reserves (hopefully >=100% to cover those liabilities).  However Chase has seen its liability increase by 7,000 BTC and HSBC has seen its liability decrease by the same amount.  To reconcile this HSBC will make a single on-chain transaction to Chase for 7,000 BTC.  This will increase Chase's reserves by 7,000 BTC and decrease HSBC's reserves by 7,000 BTC.  Everything is balanced again.   Yes it did require a limited amount of trust between settlement peers and a single on-chain transaction but it facilitated thousands of off chain transactions.  As soon as the next cross entity transaction happens a balance is owed by one entity and the net amount owed will increase and decrease until the next settlement which balances the books again and the cycle perpetually continues.

Now when demand for transactions exceeds what is possible who do you think can pay more in fees?  You or a bank?  If transaction demand exceeds capacity then some transactions will not make it into a block.  Those paying the highest fee will be the ones who retain access to the blockchain and those unable or unwilling to will be excluded.  It is delusional to think it will be the 'banks' that suffer in a situation like that.

The reported 7tps transaction capacity does not exist.
There is a myth that without raising the limit the network could handle 7tps.  It can't.  The limit is 1MB per block the actual transaction capacity depends on the average transaction size and realistically that provides no more than 2 to 4 tps. To achieve 7 tps using one block of 1 MB every 600 seconds means that the average transaction size must be 240 bytes (1,000,000 bytes / 600 seconds / 7tps = 240 bytes).  If you have a Bitcoin wallet handy take a look at your last dozen transactions and if you don't have a wallet handy use a website to lookup the transactions in the most recent block.  How many of the transactions were under 240 bytes? Not very many.  I am going to say the majority of your transactions were probably between 300 and 700 bytes.  

Can you form a 240 byte transaction?  Sure as long as you only have only a single input.  A transaction input is requires at least 147 bytes so an average of 240 bytes per transaction is not possible unless the average number of inputs is less than 2.  While some transactions may have one input on average they are going to have more.   The total number of inputs in the blockchain will roughly equal the the total number of outputs.  As the number of blocks approaches infinity the ratio of inputs to outputs in a well functioning blockchain will approach 1:1.

Since most outputs will eventually become inputs it makes more sense to look at block capacity using a balanced transactions as a template for transaction size.  A balanced transaction is one where the number of inputs equals the number of outputs.  Single input, single output exceptions are both rare and have limited use.   A 2 input, 2 output transaction using all compressed keys and P2PKH scripts is typical and weighs in at 373 bytes.  At 373 bytes per transaction and 1MB per block the network will not exceed 4.4 tps..  This is already 37% less than claimed but it is still unrealistic as it represents the smallest possible balanced transaction.

Most transactions are going to be larger than 373 bytes due to the use of uncompressed keys being used, more complex scripts, and more inputs and outputs per transaction.  Looking at the last million transactions in the blockchain I found the average txn size was 560 bytes.  At 560 bytes per transaction and 1MB per block the network will not exceed 3.0 tps.  So we have already lost over half of this claimed capacity but this is very likely to decrease over time as transaction sizes creep higher.  Multisig and other more complex scripts are being used more frequently and that trend will continue.  A good estimate for the network throughput when limited to 1MB blocks would be 2 to 4 tps depending on how optimistic you want to be.

Here is a direct comparison of the combined script size for some different types of scripts.  The scriptPubKey is encoded in a transaction output and the scriptSig is encoded in the transaction that "spends" that output.  Since outputs eventually become inputs in new transactions the combined size of the scriptPubKey and scriptSig represents the "roundtrip" script cost of a transaction.


How many transactions are possible per megabyte of block capacity?  Below is a the maximum capacity of the network at various average transaction sizes.  Realistically 2 to 4 tps is all that is supported by a 1MB block and the lower end of that range is a far more likely.

This same metric also applies to larger blocks.  Advocates of larger blocks will often overestimate the capacity of larger blocks.  It is realistic to estimate getting 2 to 4 tps per MB of block space regardless of the block size. If all blocks were 20MB that would provide a realistic throughput of 40 to 80 tps not 140 tps.  Still 40 to 80 tps would be sufficient for 100 million users to make one or two transactions per month.

1MB can not support a sufficient number of direct users even if transaction frequency is very low
One argument made by those favoring the cap is that Bitcoin doesn't need to be used as a transactional currency to be successful.  Users could primarily acquire Bitcoins as a way to secure store of value (savings) and continue to use other currencies for routine purchases.  Bullion and other stores of value have a much lower velocity than transactional currencies.  This means a block of the same size could support more more users.  While the user of a non-transaction currency may not make dozens of transactions a day, meaningful access would at least require access on the order of dozens of transactions per year.  If your savings or brokerage account restricted you to only one deposit per quarter and one withdrawal per year I don't think you would find that acceptable.  Future users of Bitcoin will not find it any more acceptable if they are forced to transaction as infrequently.


As you can see even with an average transaction frequency of just once a week or once a month the network can't support more than a token number of users.  When someone advocates a permanent cap of 1MB what they are saying is I think Bitcoin will be great if it is never used by more than a couple million users making less than one transaction per month.  Such a system will never flourish as a store of value as it is eclipsed by alternatives which are more inclusive.  To support even 100 million direct users making an average of one transaction every two weeks would require a throughput of 82 tps and an average block size of 20 to 40 Megabytes.

1MB doesn't can't even keep up with existing non-retail payment networks.
Going back to that coffee meme, the implied message is that 1MB is fine unless for everything else.  You know substantial stuff like paying your mortgage, business deals, major capital expenditures, or paying a supplier for inventory.  This just isn't the case though.  Do you know anyone who pays for coffee with a bank wire? The FedWire service (run by US federal reserve) processes ~150 million bank wires annually.   The FedWire service only operates in the US.  Internationally the largest clearinghouse is SWIFT and it processes more than 5 billion transfers annually.  The US ACH network is even larger with 19 billion transactions annually (excluding converted checks).  There are also about 2 billion international remittances annually (western union, moneygram, and other networks).  A 1MB restricted Bitcoin network couldn't even keep up with these transfer networks even if you forget about retail sales completely.  The idea keeping the 1MB restriction, only keeps limits the utility of small payments is simply incorrect.


On a transaction fee basis.
Currently the cost of the network is roughly $300 million annually. The users of the network are collectively purchasing $300 mil worth of security each year.  If users paid $400 million the network would be more secure and if they paid $200 million it would be less secure. Today the majority of this cost is paid indirectly (or subsidized) through the creation of new coins but it is important to keep in mind the total unsubsidized security cost.  At 2 tps the network the unsubsidized cost per transaction would be about $5. At 100 tps it would be $0.05.  If Bitcoin was widely adopted, more users purchasing more coins should mean a higher exchange rate and thus the value of potential attacks also rises.  The future cost of the network will need to rise to ensure that attacks are not economical and non-economic attacks are prohibitively expense relative to the benefit for the attacker.   It may not rise linearly but it will need to rise.   If someday one Bitcoin is worth $10,000 and we are still only spending $300 million a year on security we probably are going to have a problem.  Now advocates of keeping the limit may argue that the majority of the network cost won't be paid by fees for many years but the reality is that with a low maximum transaction rate you can choose either much higher fees or much lower security.

Conclusion
Restricting the size of blocks to 1MB permanently is great if you are a major financial services company.   You could co-opt a very robust network, act as a trusted intermediary and force direct users off the chain onto centralized services.  For the same reasons, it is a horrible idea if you even want to keep open the possibility that individuals will be able to participate in that network without using a trusted third party as an intermediary.

On edit: fixed some typos.  Cleaned up some poorly worded statements.  Yeah there are a lot more.  It is a work in progress.

Not really.  Another way to look at it is that the reward halves every ~4 years, so if the USD/BTC exchange rate doubles every 4 years then in USD terms miners will have the same revenue they do now.  A 100% increase in 4 years is only 18% compounded annually.  This isn't to say Bitcoin will rise 18% annually (it could go to zero) but if Bitcoin continues to grow, 18% a year is a pretty low bar.

25 BTC @ $250 = 12.5 BTC @ $500 = 6.25 BTC @ $1,000 = 3.125 BTC @ $2,000

For those thinking ahead yes this does mean the level of security as a ratio of the value of the money supply will decline but the network is probably "overprotected" right now so we have a couple halvings before that becomes an issue.