Bitcoin Forum

Bitcoin => Bitcoin Discussion => Topic started by: adamstgBit on September 15, 2015, 01:58:07 PM



Title: block size limit poll
Post by: adamstgBit on September 15, 2015, 01:58:07 PM
so after all the discussion that's been happening, i feel it's time for a new poll.


Title: Re: block size limit poll
Post by: Next BillGates on September 15, 2015, 02:00:35 PM
I really didn't understand this block size thing.


Title: Re: block size limit poll
Post by: Outlander on September 15, 2015, 02:04:40 PM
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!


Title: Re: block size limit poll
Post by: adamstgBit on September 15, 2015, 02:14:02 PM
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.


Title: Re: block size limit poll
Post by: Lauda on September 15, 2015, 05:16:38 PM
he means that's its meaningless because bitcoin1.0 does not allow your voice to be heard just by polling like bitcoin2.0 does:
-snip-
if you can hang on for only 1 month longer, then you will be able to actually vote on your hard forks, and the devs will be bound to do as the poll results state!
Stop promoting this nonsense. There is no Bitcoin 2.0. That is a marketing scam. A voting mechanism that incorporates all users will never happen as users are easily manipulated. Are you going to let random people decide the faith of a multi-billion dollar industry? I think not. You incorporate experts into the equation.



Adam, how about you stop the propaganda (obvious as there is 100% for the first choice for now)? This does not help anyone. This poll will not make a difference at all. Besides the options 1 and 2 aren't properly written. Option 2 still gives room for support of bigger blocks, just not now. Option 1 has no defined time.
Instead of actually proposing something better, you guys focus on fighting the Core vs XT, no increase vs increase and similar. We should be discussing BIP106 and a potential mixture with BIP100 (or some other solution that is better; no BIP101 is not).


Update:
Our developers and community is starting to look like a bunch of incompetent fools.
-snip-
The bigger Bitcoin grows, the harder these decisions will become.  ::) 
I concur.


Title: Re: block size limit poll
Post by: Kprawn on September 15, 2015, 05:32:03 PM
Our developers and community is starting to look like a bunch of incompetent fools. I have worked with a bunch of programmers for years and luckily for us, we had a clear

direction and goal for the company. The task of the engineers/programmers was to find ways to enable these goals. Lately Bitcoin development can be compared to chickens

running around with their heads cut off. Since Gavin has left as Lead Maintainer things has sort of ...uhmmm how can I put it... become more complex? We have Wladimir not

making the big decisions and Gavin wanting to make the decisions, with the help of Mike on the other side. I am not a fan of the whole benevolent dictator thing, but

something has to be put in place to enable quicker decision making in Bitcoin development. The bigger Bitcoin grows, the harder these decisions will become.  ::) 


Title: Re: block size limit poll
Post by: adamstgBit on September 15, 2015, 07:51:46 PM
Our developers and community is starting to look like a bunch of incompetent fools. I have worked with a bunch of programmers for years and luckily for us, we had a clear

direction and goal for the company. The task of the engineers/programmers was to find ways to enable these goals. Lately Bitcoin development can be compared to chickens

running around with their heads cut off. Since Gavin has left as Lead Maintainer things has sort of ...uhmmm how can I put it... become more complex? We have Wladimir not

making the big decisions and Gavin wanting to make the decisions, with the help of Mike on the other side. I am not a fan of the whole benevolent dictator thing, but

something has to be put in place to enable quicker decision making in Bitcoin development. The bigger Bitcoin grows, the harder these decisions will become.  ::) 
like this.
http://cointelegraph.com/news/115264/dash-the-first-decentralized-autonomous-organization


Title: Re: block size limit poll
Post by: Zarathustra on September 15, 2015, 07:58:15 PM
he means that's its meaningless because bitcoin1.0 does not allow your voice to be heard just by polling like bitcoin2.0 does:
-snip-
if you can hang on for only 1 month longer, then you will be able to actually vote on your hard forks, and the devs will be bound to do as the poll results state!
Stop promoting this nonsense. There is no Bitcoin 2.0. That is a marketing scam. A voting mechanism that incorporates all users will never happen as users are easily manipulated. Are you going to let random people decide the faith of a multi-billion dollar industry? I think not. You incorporate experts into the equation.


BS. In Switzerland all 'users' decide the faith of a multi-billion dollar economy/politics. That's the reason why Switzerland performs better than their feudalist competitors.


Title: Re: block size limit poll
Post by: LFC_Bitcoin on September 15, 2015, 08:00:59 PM
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.

I voted for an increase but I'd like it to be as & when it's required. I don't want 8MB or 20MB blocks brought in now as I think that'd be ridiculous at this point.

Maybe increase very soon to 2MB then in a number of years (whenever required) go up to 4MB & so on.


Title: Re: block size limit poll
Post by: NorrisK on September 15, 2015, 08:30:32 PM
I would like them to implement a blocksize on a sliding scale, just as how block difficulty is calculated. If more blocks are filled, max size increases. If less blocks get filled, block size decreases. Shouldn't be too hard I guess?


Title: Re: block size limit poll
Post by: Mickeyb on September 15, 2015, 08:40:13 PM
Isn't this like 10th pool about the block size increase that we had until now?

Anyways, I have voted for an increase in some way, but to make it clear not the XT thing and the BIP101.

I think that we need bigger blocks to keep Bitcoin competitive and growing. After all that I read about this problematic(and I read a lot), I feel that there is no perfect solution, but I think that us staying with 1MB blocks would just choke the growth and slow down the adoption.


Title: Re: block size limit poll
Post by: unamis76 on September 15, 2015, 08:50:07 PM
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.


Title: Re: block size limit poll
Post by: jonald_fyookball on September 16, 2015, 04:53:36 AM
just what we need,another block size debate thread.


Title: Re: block size limit poll
Post by: Kakmakr on September 16, 2015, 05: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.   


Title: Re: block size limit poll
Post by: Liquid71 on September 16, 2015, 06:51:05 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.


Title: Re: block size limit poll
Post by: Amph on September 16, 2015, 07:03:28 AM
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


Title: Re: block size limit poll
Post by: trashman43 on September 16, 2015, 07: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"


Title: Re: block size limit poll
Post by: adamstgBit on September 16, 2015, 03:35:14 PM
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


Title: Re: block size limit poll
Post by: yayayo on September 16, 2015, 03:43:13 PM
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!


Title: Re: block size limit poll
Post by: adamstgBit on September 16, 2015, 03:50:57 PM
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.


Title: Re: block size limit poll
Post by: knight22 on September 16, 2015, 03:59:57 PM
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.


Title: Re: block size limit poll
Post by: adamstgBit on September 16, 2015, 05:34:10 PM
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


Title: Re: block size limit poll
Post by: LiteCoinGuy on September 16, 2015, 05:36:48 PM
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-


 ;D


Title: Re: block size limit poll
Post by: uxgpf on September 16, 2015, 05:49:30 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.


Title: Re: block size limit poll
Post by: adamstgBit on September 16, 2015, 05:52:32 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.


Title: Re: block size limit poll
Post by: uxgpf on September 16, 2015, 06:04:39 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


Title: Re: block size limit poll
Post by: adamstgBit on September 16, 2015, 06:38:23 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.


Title: Re: block size limit poll
Post by: uxgpf on September 16, 2015, 06:54: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. :)


Title: Re: block size limit poll
Post by: adamstgBit on September 16, 2015, 06:56:26 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. :)
:D

yup, i'll try something like that too.


Title: Re: block size limit poll
Post by: uxgpf on September 16, 2015, 07:25:48 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. :)
:D

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.


Title: Re: block size limit poll
Post by: adamstgBit on September 16, 2015, 07:40:51 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. :)
:D

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.