block size limit poll

[knight22]

i don't like the options.

i chose "be raised in some way" but really my opinion is "be raised in some way carefully and gradually with emphasis on security over cheap fees"

right

~80% of users think it should be raised in some way, i think we can all agree that at the very least it could be raised carefully and gradually

~20% of users think "stay the same for now", which seems to indacte that they will vote "should be raised in some way" given some time or the right conditions full blocks >80% of blocks?

It's good to see 0% think it should never be increased

It's not suprising at all. The critical point is not if, but how much and in which way.

I'm for block size increases as well, provided that decentralization is not hurt. Because without a healthy, decentralized network Bitcoin is worth zero. Therefore I'm strongly opposing BIP101, because it is an extremist position that does not care about decentralization at all.

Successfully scaling Bitcoin requires an upper layer that reduces data load on the blockchain in addition to small increases to maximum block size.

ya.ya.yo!

yes i agree, all this discussion has lead me to the same conclusion.
after some improvement to reduce the amount of redundant traffic on the network, block size limit should increase dynamically based on keeping a small but constant pressure on fees. bacily something like retargeting block size to keep avg block size at 50%full with some ultimate upper limit to make sure its never prohibitively expensive to run a full node at home. and this upper limit should be adjusted upward as internet connectivity / PC get better.

Miners resources are already scarce and this should be enough to put a pressure on fees. Not an artificial limit. They are already free to limit the block size they mine and drop transactions that does not contain enough fees. Miners should compete to provide the most efficient resources to the network which allows a competitive fee market.

[1714124476]

1714124476

[1714124476]

1714124476

[adamstgBit]

i don't like the options.

i chose "be raised in some way" but really my opinion is "be raised in some way carefully and gradually with emphasis on security over cheap fees"

right

~80% of users think it should be raised in some way, i think we can all agree that at the very least it could be raised carefully and gradually

~20% of users think "stay the same for now", which seems to indacte that they will vote "should be raised in some way" given some time or the right conditions full blocks >80% of blocks?

It's good to see 0% think it should never be increased

It's not suprising at all. The critical point is not if, but how much and in which way.

I'm for block size increases as well, provided that decentralization is not hurt. Because without a healthy, decentralized network Bitcoin is worth zero. Therefore I'm strongly opposing BIP101, because it is an extremist position that does not care about decentralization at all.

Successfully scaling Bitcoin requires an upper layer that reduces data load on the blockchain in addition to small increases to maximum block size.

ya.ya.yo!

yes i agree, all this discussion has lead me to the same conclusion.
after some improvement to reduce the amount of redundant traffic on the network, block size limit should increase dynamically based on keeping a small but constant pressure on fees. bacily something like retargeting block size to keep avg block size at 50%full with some ultimate upper limit to make sure its never prohibitively expensive to run a full node at home. and this upper limit should be adjusted upward as internet connectivity / PC get better.

Miners resources are already scarce and this should be enough to put a pressure on fees. Not an artificial limit. They are already free to limit the block size they mine and drop transactions that does not contain enough fees. Miners should compete to provide the most efficient resources to the network which allows a competitive fee market.

for miners it wouldn't be a big deal to consume more then 1GB of data every 10mins, but this in turn make bitcoin less decentralized. like it or not at one point block size will be too high to allow for a very decentralized network, it better the fee market is exposed to this kind of pressure now rather than later. home full nodes are already pushing limits, its not hard to argue that a slow increase in blocksize is necessary, but how slow? let demand determine that...

if we proceed slowly we will see full node turn off slowly at which point we can say " stop the block size increase now or all the full nodes will drop out", at which point bitcoin capacity is said to have maxed out. fees run up. lighting network becomes increasingly important etc.

idk what the optimal limit for max TPS Vs Max decentralization is. lets take it slowly and play it by ear.

theres one thing we can all agree on.
we need improvements to reduce the amount of redundant traffic

[LiteCoinGuy]

I really didn't understand this block size thing.

It is a hot debate recently!

IMO it has been discussed a lot! You poll is meaningless!

my poll is meaningless?

how so?

we'll see if there's anyone that believes 1MB limit should stay in place forever.

my guess is more or less everyone is onboard for some kind of an increase.

it should be lower!


-Luke-


 

[uxgpf]

home full nodes are already pushing limits, its not hard to argue that a slow increase in blocksize is necessary, but how slow? let demand determine that...

I don't agree with this. It would be true only if average user runs 90s 56k modem.
Even 1 Mb internet connection works fine. (Though initial sync would take few days, but you only need to do that once.)

My opinion about Chinese nodes (which could take forever to sync due to great firewall) is that bitcoin shouldn't be technically limited due to Chinese government actions. Almost anyone in western countries would be abole to handle full 32 MB nodes right now. Even without a hard limit it would take years before blocks grow that large.

[adamstgBit]

home full nodes are already pushing limits, its not hard to argue that a slow increase in blocksize is necessary, but how slow? let demand determine that...

I don't agree with this. It would be true only if average user runs 90s 56k modem.
Even 1 Mb internet connection works fine. (Though initial sync would take few days, but you only need to do that once.)

the data is currently redundantly received and transmitted again and again.
run a full node yourself and get back to me.

[uxgpf]

home full nodes are already pushing limits, its not hard to argue that a slow increase in blocksize is necessary, but how slow? let demand determine that...

I don't agree with this. It would be true only if average user runs 90s 56k modem.
Even 1 Mb internet connection works fine. (Though initial sync would take few days, but you only need to do that once.)

the data is currently redundantly received and transmitted again and again.
run a full node yourself and get back to me.

I'm running one. Currently 31 connections, 5.5 kB/s down 9.2 kB/s up.

[edit] Killed the node while fiddling with it...so now only 15 connections.  Anyway, here's some more numbers.

Code:

Every 10.0s: bitcoin-cli getinfo            Wed Sep 16 21:21:33 2015

{
    "version" : 110000,
    "protocolversion" : 70010,
    "blocks" : 374827,
    "timeoffset" : -1,
    "connections" : 15,
    "proxy" : "",
    "difficulty" : 56957648455.01000977,
    "testnet" : false,
    "relayfee" : 0.00001000,
    "errors" : ""
}

5 snapshots from download and upload bandwidth:

Code:

$ for i in {1..5}; do awk '{if(l1){print ($2-l1)/1024"kB/s",($10-l2)/1024"kB/s"} else{l1=$2; l2=$10;}}' <(grep wlan0 /proc/net/dev) <(sleep 1; grep wlan0 /proc/net/dev); sleep 1; done
2.47266kB/s 9.90723kB/s
5.45605kB/s 10.3809kB/s
0.604492kB/s 0.650391kB/s
7.7959kB/s 8.41016kB/s
3.51953kB/s 10.4092kB/s

[adamstgBit]

home full nodes are already pushing limits, its not hard to argue that a slow increase in blocksize is necessary, but how slow? let demand determine that...

I don't agree with this. It would be true only if average user runs 90s 56k modem.
Even 1 Mb internet connection works fine. (Though initial sync would take few days, but you only need to do that once.)

the data is currently redundantly received and transmitted again and again.
run a full node yourself and get back to me.

I'm running one. Currently 31 connections, 5.5 kB/s down 9.2 kB/s up.

[edit] Killed the node while fiddling with it...so now only 15 connections.  Anyway, here's some more numbers.

Code:

Every 10.0s: bitcoin-cli getinfo            Wed Sep 16 21:21:33 2015

{
    "version" : 110000,
    "protocolversion" : 70010,
    "blocks" : 374827,
    "timeoffset" : -1,
    "connections" : 15,
    "proxy" : "",
    "difficulty" : 56957648455.01000977,
    "testnet" : false,
    "relayfee" : 0.00001000,
    "errors" : ""
}

download and upload bandwidth used (just a snapshot...averages could differ):

Code:

$ awk '{if(l1){print ($2-l1)/1024"kB/s",($10-l2)/1024"kB/s"} else{l1=$2; l2=$10;}}' <(grep wlan0 /proc/net/dev) <(sleep 1; grep wlan0 /proc/net/dev)
2.67871kB/s 3.96973kB/s

interesting,

i'm currently syncing myself a full node to test this out myself.

[uxgpf]

interesting,

i'm currently syncing myself a full node to test this out myself.

Worst thing about synching is that CPU usage. I swear I could have fried eggs on my computer case while it was doing it. Had to actually open the balcony door as I feared it would overheat and shut itself down.

Seems like this bandwidth usage varies a lot. Those numbers for 31 connections were BS as I'm getting more with 20 now. (had some jumps to 25 kB/s) also updated the snippet with with 15-16 connections in previous post.

Maybe I should write a script and let it run for few hours to count averages with connections fixed to some value (I guess this can be set in config file.)

It would give a better idea of the bandwidth needs. I just have to remember not to download any pron while I'm at it.

[adamstgBit]

interesting,

i'm currently syncing myself a full node to test this out myself.

Worst thing about synching is that CPU usage. I swear I could have fried eggs on my computer case while it was doing it. Had to actually open the balcony door as I feared it would overheat and shut itself down.

Seems like this bandwidth usage varies a lot. Those numbers for 31 connections were BS as I'm getting more with 20 now. (had some jumps to 25 kB/s) also updated the snippet with with 15-16 connections in previous post.

Maybe I should write a script and let it run for few hours to count averages with connections fixed to some value (I guess this can be set in config file.)

It would give a better idea of the bandwidth needs. I just have to remember not to download any pron while I'm at it.

yup, i'll try something like that too.

[uxgpf]

interesting,

i'm currently syncing myself a full node to test this out myself.

Worst thing about synching is that CPU usage. I swear I could have fried eggs on my computer case while it was doing it. Had to actually open the balcony door as I feared it would overheat and shut itself down.

Seems like this bandwidth usage varies a lot. Those numbers for 31 connections were BS as I'm getting more with 20 now. (had some jumps to 25 kB/s) also updated the snippet with with 15-16 connections in previous post.

Maybe I should write a script and let it run for few hours to count averages with connections fixed to some value (I guess this can be set in config file.)

It would give a better idea of the bandwidth needs. I just have to remember not to download any pron while I'm at it.

yup, i'll try something like that too.

Number of max connections can be set in ~/.bitcoin/bitcoin.conf:

Code:

# Maximum number of inbound+outbound connections.
maxconnections=20

If you are behind NAT it will only use 8 outbound connections unless you open/forward a port (TCP 8333) on your router for it.

[adamstgBit]

interesting,

i'm currently syncing myself a full node to test this out myself.

Worst thing about synching is that CPU usage. I swear I could have fried eggs on my computer case while it was doing it. Had to actually open the balcony door as I feared it would overheat and shut itself down.

Seems like this bandwidth usage varies a lot. Those numbers for 31 connections were BS as I'm getting more with 20 now. (had some jumps to 25 kB/s) also updated the snippet with with 15-16 connections in previous post.

Maybe I should write a script and let it run for few hours to count averages with connections fixed to some value (I guess this can be set in config file.)

It would give a better idea of the bandwidth needs. I just have to remember not to download any pron while I'm at it.

yup, i'll try something like that too.

Number of max connections can be set in ~/.bitcoin/bitcoin.conf:

Code:

# Maximum number of inbound+outbound connections.
maxconnections=20

If you are behind NAT it will only use 8 outbound connections unless you open/forward a port (TCP 8333) on your router for it.

i guess the more connections the more bandwidth i'll be using

i'll keep it at the default and see what the gives.