Bitcoin Forum
November 06, 2024, 05:27:02 PM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 »  All
  Print  
Author Topic: Permanently keeping the 1MB (anti-spam) restriction is a great idea ...  (Read 105071 times)
DeathAndTaxes (OP)
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1079


Gerald Davis


View Profile
February 05, 2015, 01:31:00 AM
Last edit: March 13, 2015, 04:10:44 AM by DeathAndTaxes
 #1

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.

Quote
Bitcoin ... A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution.
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.

Code:
       P2PkH:   131 bytes per script round trip (25 byte scriptPubKey +   106 byte scriptSig)
  2-of-3 P2SH:   253 bytes per script round trip (22 byte scriptPubKey +   231 byte scriptSig)  
  3-of-5 P2SH:   383 bytes per script round trip (22 byte scriptPubKey +   361 byte scriptSig)
15-of-15 P2SH: 1,481 bytes per script round trip (22 byte scriptPubKey + 1,459 byte scriptSig)

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.
Code:
Txn Size  Upper Bound   Example  
373       4.4 tps       (2in, 2out, P2PkH)
416       4.0 tps
520       3.3 tps       Average of the last 1,000,000 transactions
555       3.0 tps
616       2.7 tps       (2in, 2out, 2-of-3 P2SH)
833       2.0 tps

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.

Code:
Maximum supported users based on transaction frequency.
Assumptions: 1MB block, 821 bytes per txn
Throughput:  2.03 tps, 64,000,000 transactions annually

Total #        Transactions per  Transaction
direct users     user annually    Frequency
       <8,000       8760          Once an hour
      178,000        365          Once a day
      500,000        128          A few (2.4) times a week
    1,200,000         52          Once a week
    2,600,000         24  Twice a month
    5,300,000         12  Once a month
   16,000,000          4  Once a quarter
   64,000,000          1          Once a year
  200,000,000          0.3        Less than once every few years
1,000,000,000          0.06       Less than once a decade

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.

Code:
Bitcoin block size to reach comparable network volume based on average txn size
Network    txn volume        Average transaction size
           annually (mil)    373 bytes   560 bytes   833 bytes
FedWire       150               1.1 MB      1.7 MB      2.3 MB
Remittance  2,000              14.2 MB     21.3 MB     31.7 MB
SWIFT       5,000              35.5 MB     53.3 MB     79.3 MB
ACH        19,000             134.8 MB    202.4 MB    301.0 MB

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.
MrGreenHat
Full Member
***
Offline Offline

Activity: 173
Merit: 104


View Profile
February 05, 2015, 01:51:31 AM
 #2

I approve this message!
juju
Sr. Member
****
Offline Offline

Activity: 381
Merit: 250



View Profile
February 05, 2015, 02:13:11 AM
 #3

-snip- 

This makes me a bit scared, I had always figured in the future we would be allowed to use the blockchain and create transactions as we take for granted today. If we don't raise the block size, the competitiveness for transactions would be insane, I had always figured this but never had I imagined a scenario that we would never be able to move any coins.
zimmah
Legendary
*
Offline Offline

Activity: 1106
Merit: 1005



View Profile
February 05, 2015, 02:21:12 AM
 #4

Yes, and it doesn't stop at 20MB either, I just hope people will stop crying about progress.

Did you cry as much about the upgrade from 32bit to 64bit operating systems?

Or from 1.44 MB floppy disks to 200 MB CDs?

I mean you can fit the current blocks on a floppy disk, maybe even two blocks if you're lucky.

If Bitcoin really catches on we will need block sizes of a gigabyte or even more.

20 mb is nice for a start, it will last as a year or two, three maybe, but it will need to be upgraded eventually as well. We are dangerously close to our limit with 1 my and we can't stay at 1 mb.
zimmah
Legendary
*
Offline Offline

Activity: 1106
Merit: 1005



View Profile
February 05, 2015, 02:25:19 AM
 #5

I lol at your post, it shows how self-serving people are, ever tried to ask the miners?? You know the ones that keep the network alive in this competitive environment (not so much now) a market for fees would strenght the network even in the scenario of a total price collapse because you are creating more incentives for mining, and not keeping the vulture industry that dominates it today.

Miners can choose to include or exclude transactions regardless of block size.

A miner can decide for himself if a no-fee transaction is worth including, or a low-fee transaction for that matter.

If a lot of miners agree a low fee or no fee transaction should be excluded, it will take a long time before a transaction will be picked up by a small mining pool.

Miners also need to consider that excluding low fees will mean that the miner pools that do include the low fees will process more transactions (because all the low fee transactions will stack up) and it could be thousands upon thousands of transactions and thousand times a small fee can become quite a large sum.

It's better to sell 1 billion screws and make 0,01 cent profit on each of them than to sell 1 Lamborghini and make $100000 in profit.
MrTeal
Legendary
*
Offline Offline

Activity: 1274
Merit: 1004


View Profile
February 05, 2015, 02:30:16 AM
 #6

Very nice post, D&T. I think it's the most clear argument I've seen presented in favor of larger block size.
zimmah
Legendary
*
Offline Offline

Activity: 1106
Merit: 1005



View Profile
February 05, 2015, 02:37:37 AM
 #7

I lol at your post, it shows how self-serving people are, ever tried to ask the miners?? You know the ones that keep the network alive in this competitive environment (not so much now) a market for fees would strenght the network even in the scenario of a total price collapse because you are creating more incentives for mining, and not keeping the vulture industry that dominates it today.

Miners can choose to include or exclude transactions regardless of block size.

A miner can decide for himself if a no-fee transaction is worth including, or a low-fee transaction for that matter.

If a lot of miners agree a low fee or no fee transaction should be excluded, it will take a long time before a transaction will be picked up by a small mining pool.

Miners also need to consider that excluding low fees will mean that the miner pools that do include the low fees will process more transactions (because all the low fee transactions will stack up) and it could be thousands upon thousands of transactions and thousand times a small fee can become quite a large sum.

It's better to sell 1 billion screws and make 0,01 cent profit on each of them than to sell 1 Lamborghini and make $100000 in profit.

You still dont get it, you think they mine because they like BTC, its about the money, no miner will keep on with a loss, so besides the centralization in storage to run the nodes you are centralizing the mining process even further! The USG must be proud.

You don't get it, there won't be any Bitcoin to mine if we limit the system to 2tps.

Also, people don't pay for taxis because taxis are limited, people pay for taxis because they need a taxi. And the taxi price is decided by the taxi drivers themselves.

Based on gas prices, wages, wear of the car, etc. it's not so high that competition will eat away their profits by offering the same service cheaper, but not so low that they can't make a living.

Same with miners, their fees (which they can decide themselves) can be very high, but then very few transactions will be solved by that miner because very few people will want to pay a lot to make sure their transaction is included within the next block for 100% certainty. But if you put it too low than you can't make a profit anymore. So each miner and mining poo, should decide for themselves how the a fee should be before they include it in a block.

It's better to make 0,01 Bitcoin per transaction on fees on 5 million transactions per block than to make 1 Bitcoin in fees on 2400 transactions in 10 minutes (because more transactions will not fit)

If you don't even understand this simple fact I'm done arguing with you.

Btw I used to be a miner and I would still be one, except black arrow never delivered. So I am done buying miners becaus they either arrive late or never arrive. And besides the cost of electricity in Europe is ridiculously high so I wouldn't be able to compete anyway.
Foxpup
Legendary
*
Online Online

Activity: 4531
Merit: 3183


Vile Vixen and Miss Bitcointalk 2021-2023


View Profile
February 05, 2015, 02:45:14 AM
 #8

Thank you for reminding me that there are still a few sane individuals on this forum.


Will pretend to do unspeakable things (while actually eating a taco) for bitcoins: 1K6d1EviQKX3SVKjPYmJGyWBb1avbmCFM4
I am not on the scammers' paradise known as Telegram! Do not believe anyone claiming to be me off-forum without a signed message from the above address! Accept no excuses and make no exceptions!
acoindr
Legendary
*
Offline Offline

Activity: 1050
Merit: 1002


View Profile
February 05, 2015, 03:16:32 AM
 #9

A great detailed post as usual D&T.

Yes, I think the 7tps was meant as a technical maximum assuming 1 input and 2 outputs (1 to destination, and 1 back for change) for 225 bytes.

I agree 1MB blocks unnecessarily hinder Bitcoin, and although I don't see much difference in the potential for global value between 10tps and 20tps, seeing as VISA alone does 2,000 tps on average, I've revised my signature advertisement down from 7tps Wink
marcus_of_augustus
Legendary
*
Offline Offline

Activity: 3920
Merit: 2349


Eadem mutata resurgo


View Profile
February 05, 2015, 03:21:11 AM
 #10

There needs to be a consideration of chilling effects, or otherwise, upon ancillary technological development that is directed towards the current rules, when even merely discussing changing the rules.

R2D221
Hero Member
*****
Offline Offline

Activity: 658
Merit: 500



View Profile
February 05, 2015, 03:36:50 AM
 #11

Did you cry as much about the upgrade from 32bit to 64bit operating systems?

Or from 1.44 MB floppy disks to 200 MB CDs?

I'm still using floppies, I don't know why anyone would think they are obsolete.

But I still need to upgrade my operating system, so I think this will be a long night.


An economy based on endless growth is unsustainable.
knight22
Legendary
*
Offline Offline

Activity: 1372
Merit: 1000


--------------->¿?


View Profile
February 05, 2015, 03:45:24 AM
 #12

Thanks for this. Bitcoin needs to scale and increasing the block size limit should part of that roadmap.

runpaint
Sr. Member
****
Offline Offline

Activity: 518
Merit: 250



View Profile
February 05, 2015, 03:48:36 AM
 #13

Did you cry as much about the upgrade from 32bit to 64bit operating systems?

Or from 1.44 MB floppy disks to 200 MB CDs?

I'm still using floppies, I don't know why anyone would think they are obsolete.

But I still need to upgrade my operating system, so I think this will be a long night.






That is not true, Windows 8.1 is not officially offered on the medium of floppy discs.  Those discs are not genuine.

GoldenCryptoCommod.com
MrTeal
Legendary
*
Offline Offline

Activity: 1274
Merit: 1004


View Profile
February 05, 2015, 03:50:07 AM
 #14

That is not true, Windows 8.1 is not officially offered on the medium of floppy discs.  Those discs are not genuine.
You must be the toast of every party. Tongue
R2D221
Hero Member
*****
Offline Offline

Activity: 658
Merit: 500



View Profile
February 05, 2015, 03:51:12 AM
 #15

That is not true, Windows 8.1 is not officially offered on the medium of floppy discs.  Those discs are not genuine.

Are you telling me I just got scammed? </sarcasm>

An economy based on endless growth is unsustainable.
RoadStress
Legendary
*
Offline Offline

Activity: 1904
Merit: 1007


View Profile
February 05, 2015, 03:59:06 AM
 #16

Great post D&T. As a miner raising the block limit is the next best thing that can happen after a moonish exchange rate.

amspir
Member
**
Offline Offline

Activity: 112
Merit: 10


View Profile
February 05, 2015, 04:16:57 AM
 #17

Great post.

Perhaps the best way to deal with the transaction limit, so it does not continue to be a problem, is to quadruple the block limit size at each block reward halving every 4 years.  This should put in in line with Moore's Law, such that running a full node won't be out of reach of the average user.

BusyBeaverHP
Full Member
***
Offline Offline

Activity: 209
Merit: 100


View Profile
February 05, 2015, 04:21:39 AM
 #18

Thank you for expressing what many of us knows intuitively, but lack the technical articulation to bring the argument to full fidelity. Wonderful stuff.
zimmah
Legendary
*
Offline Offline

Activity: 1106
Merit: 1005



View Profile
February 05, 2015, 04:23:44 AM
 #19

Did you cry as much about the upgrade from 32bit to 64bit operating systems?

Or from 1.44 MB floppy disks to 200 MB CDs?

I'm still using floppies, I don't know why anyone would think they are obsolete.

But I still need to upgrade my operating system, so I think this will be a long night.






That is not true, Windows 8.1 is not officially offered on the medium of floppy discs.  Those discs are not genuine.

the sad thing is, you're probably not even the most stupid person i have met on these forums.

marcus_of_augustus
Legendary
*
Offline Offline

Activity: 3920
Merit: 2349


Eadem mutata resurgo


View Profile
February 05, 2015, 04:53:03 AM
Last edit: February 05, 2015, 05:11:46 AM by marcus_of_augustus
 #20

Great post.

Perhaps the best way to deal with the transaction limit, so it does not continue to be a problem, is to quadruple the block limit size at each block reward halving every 4 years.  This should put in in line with Moore's Law, such that running a full node won't be out of reach of the average user.


I like the simplicity of this strategy and it has grounding in practical limitations for physical hardware.

Although I would suggest to have it at the midway points between halvings so as to smooth out any lumpiness in the response to fees/reward when changing the halving and max_block_size increase together. Analogous to presidential and mid-term election cycles.

So quadruple max_block_size at 315k, 525k, 735k, 945k, thereafter every 210k blocks. But need to begin with a one-off quadruple increase to 4 MByte ASAP (to account for previous increase that would have ideally happened at 315k).

Edit: on further thought maybe doubling every 105k blocks is less disruptive again, instead of banging the limit every so often. So a one-off quadruple to 4 MB ASAP then double to 8 MB at next halving (420k blocks) and double every 105k blocks thereafter, i.e. double approx. every 2 years, more or less, depending on hashrate, which is a rough proxy for network demand via price.

Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!