Bitcoin Forum
November 17, 2018, 08:14:13 AM *
News: Latest Bitcoin Core release: 0.17.0 [Torrent].
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: why are developers not increasing blocksize ?  (Read 108 times)
btctousd81
Sr. Member
****
Offline Offline

Activity: 392
Merit: 252


View Profile WWW
December 17, 2017, 02:55:11 AM
 #1

i mean ,current unconfirmed count is 150k and its stable at that point , means new high fees tx are only getting mined.

amd network is very slow and congested., it take around 30-40 minutes to get 4-6 confirmations for single tx having 420 sats / byte fees. and its very high fee.

why not increase blocksize , and allow more tx to fit in a single block, and make it quicker to send btc like it was before.


its really pain in the ass, sending btc from one place to another and this another place requires 6 confirmations to verify the payment.,
and it takes around 40- 45 minutes sometimes 60 minutes for tx to show on .

bitcoin is already popular and new people are jumping in to it..,

so tx count / second is gonna increase, eventually, why not get ready for it ?

who decides what will be block size ?

code developers ?
consensus ?

will all miner's code needed to be modified ? even ASIC ?


1542442453
Hero Member
*
Offline Offline

Posts: 1542442453

View Profile Personal Message (Offline)

Ignore
1542442453
Reply with quote  #2

1542442453
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1542442453
Hero Member
*
Offline Offline

Posts: 1542442453

View Profile Personal Message (Offline)

Ignore
1542442453
Reply with quote  #2

1542442453
Report to moderator
1542442453
Hero Member
*
Offline Offline

Posts: 1542442453

View Profile Personal Message (Offline)

Ignore
1542442453
Reply with quote  #2

1542442453
Report to moderator
1542442453
Hero Member
*
Offline Offline

Posts: 1542442453

View Profile Personal Message (Offline)

Ignore
1542442453
Reply with quote  #2

1542442453
Report to moderator
Foxpup
Legendary
*
Offline Offline

Activity: 2366
Merit: 1187



View Profile
December 17, 2017, 02:59:15 AM
 #2

They already did. SegWit increased the block size limit from 1MB to 4MB. Nothing else to do but wait for more people to start using it.

Will pretend to do unverifiable things (while actually eating an enchilada-style burrito) for bitcoins: 1K6d1EviQKX3SVKjPYmJGyWBb1avbmCFM4
btctousd81
Sr. Member
****
Offline Offline

Activity: 392
Merit: 252


View Profile WWW
December 17, 2017, 04:51:27 AM
 #3

They already did. SegWit increased the block size limit from 1MB to 4MB. Nothing else to do but wait for more people to start using it.

what do you mean by people ?

miners or bitcoin-core software users running full node ?

ranochigo
Legendary
*
Offline Offline

Activity: 1568
Merit: 1094

Somewhat inactive.


View Profile WWW
December 17, 2017, 06:43:40 AM
 #4

why not increase blocksize , and allow more tx to fit in a single block, and make it quicker to send btc like it was before.
Wasn't this discussed to death? The result was just Bitcoin and Bitcoin Cash. Bitcoin Cash has an increased block size.
its really pain in the ass, sending btc from one place to another and this another place requires 6 confirmations to verify the payment.,
and it takes around 40- 45 minutes sometimes 60 minutes for tx to show on .
The first confirmation matters. Any block after that counts as one confirmation.
bitcoin is already popular and new people are jumping in to it..,

so tx count / second is gonna increase, eventually, why not get ready for it ?
Segwit was their solution. Doesn't seem like the adoption is big though.
who decides what will be block size ?

consensus ?
Consensus.
will all miner's code needed to be modified ? even ASIC ?
No. Just their mining backend. ASICs are fine.

what do you mean by people ?

miners or bitcoin-core software users running full node ?
Neither. It's Bitcoin users. Segwit is activated right now and segwit transactions are included in the blocks. However, if theres no one utilising segwit, there is no benefit to Bitcoin.

Kakmakr
Legendary
*
Offline Offline

Activity: 1470
Merit: 1138

★ ChipMixer | Bitcoin mixing service ★


View Profile
December 17, 2017, 07:35:50 AM
 #5

It does not fit the plan/roadmap for the implementation of the Lightning network. When the LN is implemented, big Blocks are not needed. Most micro transactions will be done off-chain and the congestion on the Blockchain will be resolved.

Most services are also not using SegWit that was supposed to offer a temporary solution for congestion. <This is not Bitcoin Core developers fault, because they supplied the solution and these services are boycotting them by not implementing it for political reasons> 

The consensus was reached to implement SegWit and now some services are boycotting it. Blame them!

LoyceV
Legendary
*
Offline Offline

Activity: 1302
Merit: 2260


Self-made Legendary!


View Profile WWW
December 17, 2017, 06:25:44 PM
 #6

It does not fit the plan/roadmap for the implementation of the Lightning network. When the LN is implemented, big Blocks are not needed. Most micro transactions will be done off-chain and the congestion on the Blockchain will be resolved.
A working Lightning Network would be great, but it doesn't work yet. Blocks should have been increased years ago, long before miners were earning $10 million per day on fees alone, and long before it was heavily debated and dividing the community. It would have been a simple upgrade, just like Satoshi envisioned, and a great solution until the Lightning Network becomes available.

Quote
Most services are also not using SegWit that was supposed to offer a temporary solution for congestion. <This is not Bitcoin Core developers fault, because they supplied the solution and these services are boycotting them by not implementing it for political reasons>
I'm using Bitcoin Core, but I wouldn't even know how to use SegWit addresses. It's nowhere to be found in any of the options, and the few times I looked for it, I couldn't find it either.

Quote
The consensus was reached to implement SegWit and now some services are boycotting it. Blame them!
The New York Agreement wasn't really based on consensus, it was the miners fearing the User Activated Soft Fork. And - kinda as I expected - the miners backed out of the 2x part, because they profit largely from small blocks.

When I started with Bitcoin, 0.01 mBTC was enough for a transaction up to 1 kB. Fees are now about 500 times higher when measured in Bitcoin, and Bitcoin is worth 80 times more. That makes fees 40,000 times higher, in less than 3 years. It really pains me to see Bitcoin crippled like this. I can no longer make a few transactions to demonstrate to a friend how easy Bitcoin works, unless I want to spend $50 on fees. Many services are now asking a consolidation fee too, on top of my own fee. I don't care how it scales, but it really needs to scale. And not in a few years, it needs it yesterday.
Despite the high price, Bitcoin can't handle more users when it can't handle more transactions. Bitcoin Cash wouldn't exist if Bitcoin would have scaled properly.

KaliLinux
Hero Member
*****
Offline Offline

Activity: 503
Merit: 500


View Profile
December 17, 2017, 07:04:48 PM
 #7

i mean ,current unconfirmed count is 150k and its stable at that point , means new high fees tx are only getting mined.

amd network is very slow and congested., it take around 30-40 minutes to get 4-6 confirmations for single tx having 420 sats / byte fees. and its very high fee.

why not increase blocksize , and allow more tx to fit in a single block, and make it quicker to send btc like it was before.


its really pain in the ass, sending btc from one place to another and this another place requires 6 confirmations to verify the payment.,
and it takes around 40- 45 minutes sometimes 60 minutes for tx to show on .

bitcoin is already popular and new people are jumping in to it..,

so tx count / second is gonna increase, eventually, why not get ready for it ?

who decides what will be block size ?

code developers ?
consensus ?

will all miner's code needed to be modified ? even ASIC ?


Segregate Witness (Segwit) is the process already implemented and few future plan for the same in order to increase the block size. But still we're facing the slowness issue. I think they need to expand the segwit process for better performance.
We did't expect these much users and investors entered which is increasing the loads of transaction. Now a days we are in the position to say transaction is not speed as earlier. Segwit has some what managed. Imagine if didn't have the segwit process how bad we may stuck with transaction.
ArtPt
Member
**
Offline Offline

Activity: 62
Merit: 10


View Profile
December 17, 2017, 07:07:33 PM
 #8

Because not everyone agrees on bitcoin usage like cash, this is crypto for holdings. so small transactions are not really necessary. Increasing block size will waste disk space on holding dust like transactions.
hatshepsut93
Hero Member
*****
Offline Offline

Activity: 966
Merit: 604


Vires in numeris


View Profile
December 17, 2017, 08:17:00 PM
 #9

Because not everyone agrees on bitcoin usage like cash, this is crypto for holdings. so small transactions are not really necessary. Increasing block size will waste disk space on holding dust like transactions.

This is wrong, Bitcoin users don't dictate to other users how to spend their coins and what size their transaction should be. But the reality is that users who run full nodes can't agree to increase blocksize, because it will start consuming more of their resources (RAM, CPU, disk storage, connection bandwidth) to the point when they will not be able to run their full nodes. And as full nodes will start leaving the network, it will become more and more centralized and easier to attack or control - such network would not be able to grow in its value, it won't be able to secure billions worth of value because of central points of failure.

LoyceV
Legendary
*
Offline Offline

Activity: 1302
Merit: 2260


Self-made Legendary!


View Profile WWW
December 17, 2017, 08:30:46 PM
 #10

This is wrong, Bitcoin users don't dictate to other users how to spend their coins and what size their transaction should be. But the reality is that users who run full nodes can't agree to increase blocksize, because it will start consuming more of their resources (RAM, CPU, disk storage, connection bandwidth) to the point when they will not be able to run their full nodes.
A more fundamental problem is that full nodes don't earn anything. Miners take $40 million per day at current prices, full nodes get nothing. Just 1% of $40 million per day would be enough to fund tens of thousands of nodes, and 1 GB extra per week shouldn't be a problem at all.

Either way, Bitcoin needs to scale to keep up with demand.

hatshepsut93
Hero Member
*****
Offline Offline

Activity: 966
Merit: 604


Vires in numeris


View Profile
December 17, 2017, 08:41:27 PM
 #11

This is wrong, Bitcoin users don't dictate to other users how to spend their coins and what size their transaction should be. But the reality is that users who run full nodes can't agree to increase blocksize, because it will start consuming more of their resources (RAM, CPU, disk storage, connection bandwidth) to the point when they will not be able to run their full nodes.
A more fundamental problem is that full nodes don't earn anything. Miners take $40 million per day at current prices, full nodes get nothing. Just 1% of $40 million per day would be enough to fund tens of thousands of nodes, and 1 GB extra per week shouldn't be a problem at all.

Either way, Bitcoin needs to scale to keep up with demand.

If I'm not mistaken, so far no one invented a Proof of Node system that is resistant to Sybil attack (spawning big amounts of virtual nodes), so we can't reward nodes like miners or let them vote.

But with growing popularity of Bitcoin full nodes might start to monetize to cover at least some part of costs. This might be possible by running Lightning Network nodes, or adding LN microdonations or microfees for those full nodes that serve various SPV clients.

No one denies that Bitcoin as to scale, but Bitcoin should never attempt scale at expense of decentralization.

olubams
Hero Member
*****
Offline Offline

Activity: 770
Merit: 503



View Profile
December 17, 2017, 09:30:32 PM
 #12

i mean ,current unconfirmed count is 150k and its stable at that point , means new high fees tx are only getting mined.

amd network is very slow and congested., it take around 30-40 minutes to get 4-6 confirmations for single tx having 420 sats / byte fees. and its very high fee.

why not increase blocksize , and allow more tx to fit in a single block, and make it quicker to send btc like it was before.


its really pain in the ass, sending btc from one place to another and this another place requires 6 confirmations to verify the payment.,
and it takes around 40- 45 minutes sometimes 60 minutes for tx to show on .

bitcoin is already popular and new people are jumping in to it..,

so tx count / second is gonna increase, eventually, why not get ready for it ?

who decides what will be block size ?

code developers ?
consensus ?

will all miner's code needed to be modified ? even ASIC ?



The same thought came to me too but the earlier posts was about creating a new forked coin in other to get that to reality in the case of either SegWit or BCH but why cant they just increase bitcoin size itself instead if creating another coin. In the solution offered by BCH m, it then means we should abandon the bitcoin and focus on another coin but that is not solving the situation because if all the transactions move to BCH, sooner or  later, the entire blocksize would also be saturated and we would be faced by the same situation all over again.

       ▄▄█████████▄▄
    ▄█████████████████
  ▄████████▀▀▀▀▀▀▀▀▀▀
 ▄███████▀   ▄▄   ▄▄▄▄▄▄▄▄
▄████████▄▄▄████  ▄▄▄▄▄▄▄▄
█████████▀▀▀▀▀▀▀  █████████
█████████   ▄▄▄▄   ▀███████
█████████   █████   ███████
 ▀▀▀▀▀▀▀▀   █████   ██████▀
 ▀▀▀▀▀▀▀▀   ███▀▀   █████▀
      ▄▄▄▄▄▄███▄▄▄▄█████▀
     █████████████████▀
       ▀▀█████████▀▀
Bitcoin Air 
 
.
█      ███
█      ███
  ██
  ██  ███
  ██  ███
  ██  ███
      ███
█  ██
  ███
█  ██
  ███
   ██
  ███
█  ██  ███
█  ██  ███
█  ██
....MEDIUM....
.....GITHUB....
.....REDDIT....
     ██  █
███  ██  █
███  ██
███  ██  █
███  ██  █
███  ██  █
███      █
███  ██ 
███  ██ 
     ██ 
███
  ██ 
███
  ██ 
     ██
 
.
.
khaled0111
Full Member
***
Offline Offline

Activity: 532
Merit: 106


NHCT (NanoHealthCare Token)A blockchain powered ec


View Profile WWW
December 17, 2017, 11:05:33 PM
 #13

i mean ,current unconfirmed count is 150k and its stable at that point , means new high fees tx are only getting mined.

amd network is very slow and congested., it take around 30-40 minutes to get 4-6 confirmations for single tx having 420 sats / byte fees. and its very high fee.

why not increase blocksize , and allow more tx to fit in a single block, and make it quicker to send btc like it was before.


its really pain in the ass, sending btc from one place to another and this another place requires 6 confirmations to verify the payment.,
and it takes around 40- 45 minutes sometimes 60 minutes for tx to show on .

If you paid enough fees then you should not worry about the next six confirmations because it usually takes about an hour.
One block is added to the blockchain every 10 minutes thus you will get your 6 confirmation after 60 minutes.
The problem is that many exchanges don't accept a transaction until it become 6 blocks deep to avoid double spending risks.
 
bitcoin is already popular and new people are jumping in to it..,
so tx count / second is gonna increase, eventually, why not get ready for it ?
who decides what will be block size ?
code developers ?
consensus ?
will all miner's code needed to be modified ? even ASIC ?

developers just offer solutions but it is up to the community to support it.

▄██ NanoHealthcare Token ██▄
  ▄ A Blockchain powered ecosystem of Total Health ▄
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!