block size limit poll | Bitcointalksearch.org

adamstgBit

legendary

Activity: 1904

Merit: 1037

Trusted Bitcoiner

Quote from: uxgpf on September 16, 2015, 02:25:48 PM

Quote from: adamstgBit on September 16, 2015, 01:56:26 PM

Quote from: uxgpf on September 16, 2015, 01:54:23 PM

Quote from: adamstgBit on September 16, 2015, 01:38:23 PM

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.

uxgpf

newbie

Activity: 42

Merit: 0

Quote from: adamstgBit on September 16, 2015, 01:56:26 PM

Quote from: uxgpf on September 16, 2015, 01:54:23 PM

Quote from: adamstgBit on September 16, 2015, 01:38:23 PM

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

legendary

Activity: 1904

Merit: 1037

Trusted Bitcoiner

Quote from: uxgpf on September 16, 2015, 01:54:23 PM

Quote from: adamstgBit on September 16, 2015, 01:38:23 PM

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

newbie

Activity: 42

Merit: 0

Quote from: adamstgBit on September 16, 2015, 01:38:23 PM

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

legendary

Activity: 1904

Merit: 1037

Trusted Bitcoiner

Quote from: uxgpf on September 16, 2015, 01:04:39 PM

Quote from: adamstgBit on September 16, 2015, 12:52:32 PM

Quote from: uxgpf on September 16, 2015, 12:49:30 PM

Quote from: adamstgBit on September 16, 2015, 12:34:10 PM

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

newbie

Activity: 42

Merit: 0

Quote from: adamstgBit on September 16, 2015, 12:52:32 PM

Quote from: uxgpf on September 16, 2015, 12:49:30 PM

Quote from: adamstgBit on September 16, 2015, 12:34:10 PM

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

legendary

Activity: 1904

Merit: 1037

Trusted Bitcoiner

Quote from: uxgpf on September 16, 2015, 12:49:30 PM

Quote from: adamstgBit on September 16, 2015, 12:34:10 PM

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

newbie

Activity: 42

Merit: 0

Quote from: adamstgBit on September 16, 2015, 12:34:10 PM

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.

LiteCoinGuy

legendary

Activity: 1148

Merit: 1014

In Satoshi I Trust

Quote from: adamstgBit on September 15, 2015, 09:14:02 AM

Quote from: Outlander on September 15, 2015, 09:04:40 AM

Quote from: Next BillGates on September 15, 2015, 09:00:35 AM

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-

Grin

adamstgBit

legendary

Activity: 1904

Merit: 1037

Trusted Bitcoiner

Quote from: knight22 on September 16, 2015, 10:59:57 AM

Quote from: adamstgBit on September 16, 2015, 10:50:57 AM

Quote from: yayayo on September 16, 2015, 10:43:13 AM

Quote from: adamstgBit on September 16, 2015, 10:35:14 AM

Quote from: trashman43 on September 16, 2015, 02:21:30 AM

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

knight22

legendary

Activity: 1372

Merit: 1000

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

Quote from: adamstgBit on September 16, 2015, 10:50:57 AM

Quote from: yayayo on September 16, 2015, 10:43:13 AM

Quote from: adamstgBit on September 16, 2015, 10:35:14 AM

Quote from: trashman43 on September 16, 2015, 02:21:30 AM

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.

adamstgBit

legendary

Activity: 1904

Merit: 1037

Trusted Bitcoiner

Quote from: yayayo on September 16, 2015, 10:43:13 AM

Quote from: adamstgBit on September 16, 2015, 10:35:14 AM

Quote from: trashman43 on September 16, 2015, 02:21:30 AM

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.

yayayo

legendary

Activity: 1806

Merit: 1024

Quote from: adamstgBit on September 16, 2015, 10:35:14 AM

Quote from: trashman43 on September 16, 2015, 02:21:30 AM

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!

adamstgBit

legendary

Activity: 1904

Merit: 1037

Trusted Bitcoiner

Quote from: trashman43 on September 16, 2015, 02:21:30 AM

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

trashman43

full member

Activity: 298

Merit: 100

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"

Amph

legendary

Activity: 3248

Merit: 1070

i want it to be dynamic, it will auto-adjust when the limit needs to be raised not before and not after

repeat when the new limit is saturated

Liquid71

hero member

Activity: 835

Merit: 1000

There is NO Freedom without Privacy

Quote from: Kakmakr on September 16, 2015, 12:22:44 AM

Give us bigger blocks without the side shows and we will be happy. I voted for some kind of increase even though
no immediate panic is needed for now. The Core vs XT debate is over, everyone is in agreement that we need bigger block sizes no matter what will be implemented.

You shouldn't speak for everyone unless you are sure you know everyone's opinion.

Kakmakr

legendary

Activity: 3542

Merit: 1965

Leading Crypto Sports Betting & Casino Platform

Give us bigger blocks without the side shows and we will be happy. I voted for some kind of increase even though
no immediate panic is needed for now. The Core vs XT debate is over, everyone is in agreement that we need bigger block sizes no matter what will be implemented.

jonald_fyookball

legendary

Activity: 1302

Merit: 1008

Core dev leaves me neg feedback #abuse #political

just what we need,another block size debate thread.

unamis76

legendary

Activity: 1512

Merit: 1012

Although simple, this poll is effective, as it contemplates the three biggest options right now and isn't a "partidary" poll (doesn't make you choose between Core or XT). You are voting on an idea, not on a client. No battles is what we need

Voted.

Topic: block size limit poll (Read 1442 times)