Pages:
Author

Topic: Blocksize needs to be increased now. - page 7. (Read 25112 times)

full member
Activity: 182
Merit: 101
January 16, 2016, 07:16:43 AM
#86

Because raising the blocksize to 8MB out of nowhere is way more risky than staying with 1 while we search for ways to scale Bitcoin properly (raising the blocksize will never properly scale Bitcoin, not without something like LN). We don't want datacenters running nodes, we want to be able to run nodes on a single computer, what's so hard to get about this? That's the real sabotage, centralized nodes.

Dude, the 8 MB limit is not each and ever block. If the cap is 8mb, and the current block size is 0.5 mb , then 0.5 mb blocks will circulate. The 8mb block is only the cap limit, not the default size.


Therefore the block structure won't really be destroyed, it's not like you have to reformat earlier blocks to all have the identical size. Even now block sizes vary so that's not an issue.


But what you are doing here is artificially not letting the block size go up, and when the limit is hit, then people will compete for the empty space, so the TX fee will massively go up, and most people cannot transact and the TX confirm time will go up.

That is the real sabotage.

The blocksize will go up anyway, the question is, will you let it go up naturally, or you plan to make bitcoin a communist centrally planned currency. I hope not.

Having a bunch of "free space" that's unused due the cap being too big brings a lot of problems and possible exploits. What centralizes Bitcoin is not being able to run a node in your computer, not the nonsense you are talking about. Bitcoin will never scale to worldwide levels by raising blocksize.

Honest newbie question: how rising block size prevents from running a node on regular PC?
full member
Activity: 182
Merit: 101
January 16, 2016, 07:05:37 AM
#85
Bitcoin gaining popularity not because its payment function, and it will never be. There are plenty of statistics showing that people are not interested in using bitcoin to purchase coffee, they are more interested in use bitcoin to hedge against inflation and make money

Well then bitcoin will have a much higher fee, and will lose most of it's appeal in the long run.

I already have problems sending transactions at 0.0001 BTC fee, so now I use 0.00025 BTC/kb as set in electrum.

Soon that will double of triple, and bitcoin will lose its fast & cheap transaction appeals. It will be a huge marketing blowback.

Bitcoin might get a higher fee, but it will never lose its most significant appeal in the long run: Long term saving and international remittance

Let's be honest: Bitcoin will never be able to compete with those fast&cheap mobile/3rd party payment solutions that charges 0 transaction fee and instant confirmation (you even get some bonus when using them), and the possibility of refund

For example, Sweden has already over 50% of population use mobile payment. So all of these users will feel angry when they need to pay a fee  to use bitcoin to spend, besides all the hassles about exchange into and out of bitcoin

So, even if you make bitcoin 0 transaction fee + instant confirmation + refund, people would still not use bitcoin to spend, because they gain nothing from switching from existing mobile payment solutions to bitcoin. People who care about bitcoin mostly attracted by its deflative nature for value storage, and they usually buy large amount of coins, so the fee is the least concern for them (I have seen these people paying 5-10% above market price to get 1-2 bitcoin, do you think they really care about the current level of fee?)

If you consider its major advantage against existing financial system, it is clear that the best marketing for bitcoin is either its exchange rate rises (for long term saving), or more and more exchanges are available in each country (for international remittance)

Credit card companies charge merchant for credit card using. Normal charge is about 2%,I believe. So there is a a clear incentive for merchant to accept bitcoin payments over VISA or Master Card for instance. I'm not sure, but I believe accepting mobile payments is not free either for merchant.
legendary
Activity: 994
Merit: 1035
January 15, 2016, 11:01:25 PM
#84
No, Classic is the choice. There is no fallback, if you want to stay relevant.

Can you clarify a technical advantage of classic above core with segwit ?

As Far as I am aware Cores proposal comes with 45 developers, proposal is already further along, written and being tested right now, comes with many other improvements, and has practically the same capacity advantages as Bitcoin Classic/BIP102.

I really don't understand why people would pick Classic unless Segwit is delayed for some reason or for political reasons which I am not interested in as I want to judge each proposal by their technical considerations.

If classic was a 2+4 BIP + Segwit that may be interesting because it would contain all the advantages of segwit and have an effective 3-4MB capacity and than 6-8MB effective capacity with plenty of headroom to put off future forks for a couple years. It may have some centralization tradeoffs , but at least it is different enough to consider and make interesting. I know why Jonathan Toomim is so dissapointed that his proposal was vetoed for such a conservative one now.
hero member
Activity: 546
Merit: 500
Warning: Confrmed Gavinista
January 15, 2016, 09:22:27 PM
#83
source? re-read the slack and you will see that segwit is also-ran for now.  What ill be developed will not necessarily reflect whats in core right now.

So looks like Bitcoin classic will be a fallback for miners if Segwit on core doesn't roll out quick enough.

No, Classic is the choice. There is no fallback, if you want to stay relevant.
legendary
Activity: 889
Merit: 1013
January 15, 2016, 08:08:56 PM
#82
Consensus is soon, I just wish there were more details as to what Bitcoin Classic represents as I cannot give my opinion on the matters until there is.

My best guess is that it is a 2 -4 plan with Segwit hardforked???
https://bitcoinclassic.consider.it/merge-3-v0112-2mb-4mb?results=true

Miners supporting Classic

    Bitmain/Antpool - 27%
    BitFury - 13%
    BW.COM - 4%
    HAOBTC.com -
    KnCMiner - 5%
    Genesis Mining

= over 49%

Companies supporting Classic

    Coinbase
    OKCoin
    Bitstamp
    Foldapp
    Bitcoin.com
    Bread Wallet
    Snapcard.io
    Cubits


Developers

    Jonathan Toomim
    Gavin Andresen
    Ahmed Bodiwala
    Jeff Garzik
    Peter Rizun



Hopefully there will be some reconciliation between Core and Classic and the can find consensus together as there is a lot of support and talent within both groups.

I wish there was more transparency over the consensus forming process, I can't see any clear way to make a meaningful contribution to the discussion.
legendary
Activity: 994
Merit: 1035
January 15, 2016, 07:23:42 PM
#81
source? re-read the slack and you will see that segwit is also-ran for now.  What ill be developed will not necessarily reflect whats in core right now.

Yes, I now see the new Proposal is simply BIP 102
So looks like Bitcoin classic will be a fallback for miners if Segwit on core doesn't roll out quick enough.

Segwit softfork = 1.75-2MB capacity with many additional benefits
Bitcoin Classic hardfork= 2MB capacity

I understand why they prefer the simplicity with a hard fork , but there really isn't much reason to choose classic above core without more of a differentiation in benefits; 0 to .25 isn't going to be overly motivating IMHO.

Sorry to bring this up , and no disrespect to Gavin as I respect his contributions, but when I saw this on slack it freaked me out--



None of the other devs even acknowledged it either. Was this some sort of Joke Gavin was making?
hero member
Activity: 546
Merit: 500
Warning: Confrmed Gavinista
January 15, 2016, 06:55:11 PM
#80

I'm sure with some reasoned discussion there could be reconciliation between Classic and Core

I applaud your efforts towards harmony and union.  There are dscussions going on now, but its not looking good for your hopes re: segwit. Maybe at a more realistic timeframe.

source? From the Classic developers statements on slack and elsewhere I see them favorable to segwit(but perhaps more in favor of a hardfork rollout instead which is fine to do in conjunction of a blocksize increase because most of the problem with hardfork is coordinating everyone ) Cores main problems with a hardfork is the difficulty in coordinating this responsibly. If one is going to perform a hardfork you may as well do 2MB+ Segwit and the appropriate sigop protections being adjusted.

source? re-read the slack and you will see that segwit is also-ran for now.  What ill be developed will not necessarily reflect whats in core right now.
legendary
Activity: 994
Merit: 1035
January 15, 2016, 05:43:52 PM
#79

I'm sure with some reasoned discussion there could be reconciliation between Classic and Core

I applaud your efforts towards harmony and union.  There are dscussions going on now, but its not looking good for your hopes re: segwit. Maybe at a more realistic timeframe.

source? From the Classic developers statements on slack and elsewhere I see them favorable to segwit(but perhaps more in favor of a hardfork rollout instead which is fine to do in conjunction of a blocksize increase because most of the problem with hardfork is coordinating everyone ) Cores main problems with a hardfork is the difficulty in coordinating this responsibly. If one is going to perform a hardfork you may as well do 2MB+ Segwit and the appropriate sigop protections being adjusted.
hero member
Activity: 546
Merit: 500
Warning: Confrmed Gavinista
January 15, 2016, 05:35:49 PM
#78

I'm sure with some reasoned discussion there could be reconciliation between Classic and Core

I applaud your efforts towards harmony and union.  There are dscussions going on now, but its not looking good for your hopes re: segwit. Maybe at a more realistic timeframe.
legendary
Activity: 994
Merit: 1035
January 15, 2016, 02:57:52 PM
#77
What about an dynamic size?
So I would recommend something like the average of the past 50 blocks . With an maximum of 10 MB , to prevent spam or dos,...

I'm not an developer so I'm sure there are a lot of more things thing about it.



I can empathize with Core not wanted to do 2 hard forks and simply preferring to perfect flexcap.... but despite it being a pain in the ass, there needs to be some reconciliation where all parties feel they win and lose equally to move forward.

The Big Blockers have already gone from 20MB to 8MB to 2MB .... and Core has already gone from 1 to ~1.75MB with segwitt for capacity.
I'm sure with some reasoned discussion there could be reconciliation between Classic and Core where SegWit is soft forked in ASAP, and a planned and controlled hardfork of 2-4 MB BIP is rolled out later this year to give a little breathing room to properly test flexcap , and most importantly stop all the politicking so everyone can focus on code and testing.
hero member
Activity: 838
Merit: 534
January 15, 2016, 02:38:29 PM
#76
What about an dynamic size?
So I would recommend something like the average of the past 50 blocks . With an maximum of 10 MB , to prevent spam or dos,...

I'm not an developer so I'm sure there are a lot of more things thing about it.

legendary
Activity: 994
Merit: 1035
January 15, 2016, 02:22:09 PM
#75
Consensus is soon, I just wish there were more details as to what Bitcoin Classic represents as I cannot give my opinion on the matters until there is.

My best guess is that it is a 2 -4 plan with Segwit hardforked???
https://bitcoinclassic.consider.it/merge-3-v0112-2mb-4mb?results=true

Miners supporting Classic

    Bitmain/Antpool - 27%
    BitFury - 13%
    BW.COM - 4%
    HAOBTC.com -
    KnCMiner - 5%
    Genesis Mining

= over 49%

Companies supporting Classic

    Coinbase
    OKCoin
    Bitstamp
    Foldapp
    Bitcoin.com
    Bread Wallet
    Snapcard.io
    Cubits


Developers

    Jonathan Toomim
    Gavin Andresen
    Ahmed Bodiwala
    Jeff Garzik
    Peter Rizun



Hopefully there will be some reconciliation between Core and Classic and the can find consensus together as there is a lot of support and talent within both groups.
copper member
Activity: 1498
Merit: 1528
No I dont escrow anymore.
January 15, 2016, 01:37:39 PM
#74
Would Bitcoin nodes be downloading and upload a lot more?
If the new maximum block size was reached, then yes, nodes would be downloading and uploading more. The blockchain's size would grow faster and it would require even more disk space.

Would we lose a lot of full nodes because of the higher BW and memory requirements?
Probably.

After reading the 0.12 patch notes I see no higher memory requirements. The memory imprint is already small, the biggest part are the transactions, which will be less with bigger blocks as more get confirmed. At least for a while. IF memory was meant as = disk space, then yes.
staff
Activity: 3458
Merit: 6793
Just writing some code
January 15, 2016, 01:05:40 PM
#73
Would Bitcoin nodes be downloading and upload a lot more?
If the new maximum block size was reached, then yes, nodes would be downloading and uploading more. The blockchain's size would grow faster and it would require even more disk space.

Would we lose a lot of full nodes because of the higher BW and memory requirements?
Probably.

Also because of this would there be more control over hash-power which could lead to centralization - need for attaining equilibrium?
Probably not. Since most miners already mine at one of 10 or so mining pools, only the pools have to maintain nodes that can handle the larger blockchain and bandwidth requirements. I'm fairly certain that the pool operators have the money to be able to upgrade, although if the block size limit grows even larger, there are concerns that it would take a while for blocks to reach pools in China due to the Great Firewall of China.
hero member
Activity: 616
Merit: 603
January 15, 2016, 11:31:46 AM
#72
I myself am very confused about what would be the best blocksize and how should this be incremented. A lot have suggested initially at least increasing it to 2MB and increment it over the years, but I don't really understand what would be the aftereffects of this. Would Bitcoin nodes be downloading and upload a lot more? Would we lose a lot of full nodes because of the higher BW and memory requirements? Also because of this would there be more control over hash-power which could lead to centralization - need for attaining equilibrium?
legendary
Activity: 1792
Merit: 1283
January 15, 2016, 11:27:51 AM
#71
I hope we reach the 1MB limit soon I'm sick of all this fear mongering. Nothing will happen other then threw natural selection the micro transactions will be pushed out of the blockchain.

Why not just soft fork it down to 0.5MB to clear up some of this cruft sooner than later? Bitcoin is a value storage and transfer tool of the wealthy elite, poors may use doge and litecoin.


We should never have gone above 0.5mb
The problem with that though is that quite a lot of people are currently depending on it for it's use a a currency or payment method. Not increasing the block size would just be a slap in the face to those people :-/
sr. member
Activity: 475
Merit: 255
January 15, 2016, 11:20:25 AM
#70
I hope we reach the 1MB limit soon I'm sick of all this fear mongering. Nothing will happen other then threw natural selection the micro transactions will be pushed out of the blockchain.

Why not just soft fork it down to 0.5MB to clear up some of this cruft sooner than later? Bitcoin is a value storage and transfer tool of the wealthy elite, poors may use doge and litecoin.

Because once you allow max block size change there will be endless arguments about which exact size is the right one (0.5 MB, 2 MB, 100 kB, 16 MB, 1 kB, ...)Huh For every size you can find group that would benefit from it.
Only neutral interest-group-free solution is to keep constants fixed. Status quo.
Change is possible, but with much, much higher consensus. 75% is not enough, only miners, only large business, only small merchants, only startups, only investors, only full-noders ... this is not consensus at all. All of them should agree, No one of them should veto. (Every one of them should have right to veto.) Until we find broadly acceptable solution, status quo is the best one.
newbie
Activity: 40
Merit: 0
January 14, 2016, 03:12:31 PM
#69
Blocksize increae is absolutely necessary now and it will be done immediately. There are occasions where we have seen unconfimed transactions for days and even a week or two. The strongly accept the debate over blocksize increase. However, we need more nodes and high performing machines to handle the increase in size.
legendary
Activity: 883
Merit: 1005
January 14, 2016, 01:37:43 AM
#68
I hope we reach the 1MB limit soon I'm sick of all this fear mongering. Nothing will happen other then threw natural selection the micro transactions will be pushed out of the blockchain.

Why not just soft fork it down to 0.5MB to clear up some of this cruft sooner than later? Bitcoin is a value storage and transfer tool of the wealthy elite, poors may use doge and litecoin.


We should never have gone above 0.5mb
sr. member
Activity: 392
Merit: 250
January 13, 2016, 11:17:59 PM
#67
I hope we reach the 1MB limit soon I'm sick of all this fear mongering. Nothing will happen other then threw natural selection the micro transactions will be pushed out of the blockchain.

Why not just soft fork it down to 0.5MB to clear up some of this cruft sooner than later? Bitcoin is a value storage and transfer tool of the wealthy elite, poors may use doge and litecoin.
Pages:
Jump to: