Pages:
Author

Topic: . (Read 24756 times)

hero member
Activity: 546
Merit: 500
.
February 20, 2016, 04:54:40 PM
Before this deteriorates any further, try to stay focused.
Don't break this up into a zillion sub-topics, with each word I type addressed in a separate catty comeback.
inb4 not a zillion: no. stay focused. resist. We want one cogent, cohesive response, even if you miss out on a few snark opportunities.

Now then: My traffic analogy.
It's fucking great, no sense being coy about it. Unoriginal, sure -- network traffic is typically visualized/modeled/ in terms of everyday meatspace traffic.b What don't you like about the analogy?

it's not that i don't like it. it's that you haven't shown how it's applicable. what evidence do you have that there is such a "traffic jam" or if there is, that it is an actual problem?

Which seamlessly segues us to the main thrust of this opus. Pay attention, 'coz what's coming up is the only important bit. Up 'til now, it was fluff, sort'a like what you did to me with your gudxillion sub-quotes.
Enough! Reader, follow me!

TehGist:
1. You made a claim that "blocks aren't actually full on average."
2. I replied that while this is the case, it is impossible for things to be otherwise -- blocks *can never be 100% full on the average*.
3. If analogies are a strain (abstract thought could be a bitch for some), here's the actual mechanics: as long as a miner is able to mine an empty block, the average can't be 100% full blocks. Because that's how averages fucking are. That's how they work.

I hope this helps.

i was referring to the actual growth in transaction volume (therefore block size) over time. i'd have thought this would be obvious. seems relevant to your suggestion that capacity is insufficient. there is a tendency to point to short term batches of 9xx kb blocks, then to ignore the 400-600 kb blocks that come after the backlog has cleared.

the network actually isn't under the constant load that some suggest, and during the times that it temporarily is, paying an extra tiny fraction of an mBTC in fees alleviates the issue.

anyway, this has nothing to do with evidence of your suggestion that there is an urgent problem here. since the transactions backlogs are always cleared and fees are miniscule, what's the problem again?
You were "referring to the actual growth in transaction volume (therefore block size) over time"? How does the fact that "blocks aren't actually full on average" figure into this? Taking into account that it's as likely for blocks to be "full on average" as it is for the busiest road to be bumper-to-bumper jammed, on the average, which is to say "not at all"?
Why bring up a meaningless metric?
At the risk of belaboring the obvious: Blocks will never be "full on average." Don't wait for blocks to be full on the average.

>since the transactions backlogs are always cleared and fees are miniscule, what's the problem again?
If you're stuck in traffic for 6 hours on your way back from work, what's the problem? I mean, you get home eventually, every day, amirite?
The road is clearly of sufficient capacity, no one *never* gets home. In other words, "traffic jams transactions backlogs are always cleared."
I like the analogy, however in the case of Bitcoin there is simply not enough capacity for everyone to get "home", regardless of the fee that is payed.

Furthermore as a counter argument, if we imagine this road being like a toll road, then we can say that other roads exists, in the form of potential Bitcoin forks and altcoins. If the other roads are both faster and cheaper then I think people will choose to drive on those alternative roads instead, the economics of it all are quite simple really when it comes down to it. I think that if we allow the Bitcoin network to become overloaded making transacting much more expensive and unreliable then I think Bitcoin will simply be outcompeted and obsolesced.

I am glad you installed Bitcoin Classic David Rabahy, that is the solution to this existential crisis after all. Wink

>I like the analogy, however in the case of Bitcoin there is simply not enough capacity for everyone to get "home", regardless of the fee that is payed.

Well, thus far "traffic jams transactions backlogs are always cleared," so everyone can still get home, for now. Which is not to say there are no traffic jams & backups, making our road less attractive, especially since it's not the only one & "other roads exist."

But, just in case it's not obvious, I do agree with you. When I said "If you're stuck in traffic for 6 hours on your way back from work, what's the problem?" i was being sarcastic.
Yeah sorry for not noticing the sarcasm lol. You are right though, I should qualify the statement, "there is simply not enough capacity for everyone to get "home" with increased adoption" which should be expected if this exponential growth in transaction volume continues. Thank You. Smiley
full member
Activity: 154
Merit: 100
February 20, 2016, 03:41:03 PM
Before this deteriorates any further, try to stay focused.
Don't break this up into a zillion sub-topics, with each word I type addressed in a separate catty comeback.
inb4 not a zillion: no. stay focused. resist. We want one cogent, cohesive response, even if you miss out on a few snark opportunities.

Now then: My traffic analogy.
It's fucking great, no sense being coy about it. Unoriginal, sure -- network traffic is typically visualized/modeled/ in terms of everyday meatspace traffic.b What don't you like about the analogy?

it's not that i don't like it. it's that you haven't shown how it's applicable. what evidence do you have that there is such a "traffic jam" or if there is, that it is an actual problem?

Which seamlessly segues us to the main thrust of this opus. Pay attention, 'coz what's coming up is the only important bit. Up 'til now, it was fluff, sort'a like what you did to me with your gudxillion sub-quotes.
Enough! Reader, follow me!

TehGist:
1. You made a claim that "blocks aren't actually full on average."
2. I replied that while this is the case, it is impossible for things to be otherwise -- blocks *can never be 100% full on the average*.
3. If analogies are a strain (abstract thought could be a bitch for some), here's the actual mechanics: as long as a miner is able to mine an empty block, the average can't be 100% full blocks. Because that's how averages fucking are. That's how they work.

I hope this helps.

i was referring to the actual growth in transaction volume (therefore block size) over time. i'd have thought this would be obvious. seems relevant to your suggestion that capacity is insufficient. there is a tendency to point to short term batches of 9xx kb blocks, then to ignore the 400-600 kb blocks that come after the backlog has cleared.

the network actually isn't under the constant load that some suggest, and during the times that it temporarily is, paying an extra tiny fraction of an mBTC in fees alleviates the issue.

anyway, this has nothing to do with evidence of your suggestion that there is an urgent problem here. since the transactions backlogs are always cleared and fees are miniscule, what's the problem again?
You were "referring to the actual growth in transaction volume (therefore block size) over time"? How does the fact that "blocks aren't actually full on average" figure into this? Taking into account that it's as likely for blocks to be "full on average" as it is for the busiest road to be bumper-to-bumper jammed, on the average, which is to say "not at all"?
Why bring up a meaningless metric?
At the risk of belaboring the obvious: Blocks will never be "full on average." Don't wait for blocks to be full on the average.

>since the transactions backlogs are always cleared and fees are miniscule, what's the problem again?
If you're stuck in traffic for 6 hours on your way back from work, what's the problem? I mean, you get home eventually, every day, amirite?
The road is clearly of sufficient capacity, no one *never* gets home. In other words, "traffic jams transactions backlogs are always cleared."
I like the analogy, however in the case of Bitcoin there is simply not enough capacity for everyone to get "home", regardless of the fee that is payed.

Furthermore as a counter argument, if we imagine this road being like a toll road, then we can say that other roads exists, in the form of potential Bitcoin forks and altcoins. If the other roads are both faster and cheaper then I think people will choose to drive on those alternative roads instead, the economics of it all are quite simple really when it comes down to it. I think that if we allow the Bitcoin network to become overloaded making transacting much more expensive and unreliable then I think Bitcoin will simply be outcompeted and obsolesced.

I am glad you installed Bitcoin Classic David Rabahy, that is the solution to this existential crisis after all. Wink

>I like the analogy, however in the case of Bitcoin there is simply not enough capacity for everyone to get "home", regardless of the fee that is payed.

Well, thus far "traffic jams transactions backlogs are always cleared," so everyone can still get home, for now. Which is not to say there are no traffic jams & backups, making our road less attractive, especially since it's not the only one & "other roads exist."

But, just in case it's not obvious, I do agree with you. When I said "If you're stuck in traffic for 6 hours on your way back from work, what's the problem?" i was being sarcastic.
hero member
Activity: 546
Merit: 500
February 20, 2016, 03:13:57 PM
I am glad you installed Bitcoin Classic David Rabahy, that is the solution to this existential crisis after all. Wink
It's good to know someone around here has a sense of humor.  I was almost inspired to run both Classis and Core at the same time.  Almost.  I'd like a version which alternates between them.  Smiley
You can always run Bitcoin Unlimited as well, it is my preferred implementation, it is compatible with any block size increase or decrease depending on how the user configures the node. On the default setting it will simply follow the longest chain. That way you could switch between different blocksize policies within the same node if you would like as well. Smiley

http://www.bitcoinunlimited.info/
hero member
Activity: 709
Merit: 503
February 20, 2016, 03:08:41 PM
I am glad you installed Bitcoin Classic David Rabahy, that is the solution to this existential crisis after all. Wink
It's good to know someone around here has a sense of humor.  I was almost inspired to run both Classis and Core at the same time.  Almost.  I'd like a version which alternates between them.  Smiley
hero member
Activity: 546
Merit: 500
February 20, 2016, 02:45:48 PM
Before this deteriorates any further, try to stay focused.
Don't break this up into a zillion sub-topics, with each word I type addressed in a separate catty comeback.
inb4 not a zillion: no. stay focused. resist. We want one cogent, cohesive response, even if you miss out on a few snark opportunities.

Now then: My traffic analogy.
It's fucking great, no sense being coy about it. Unoriginal, sure -- network traffic is typically visualized/modeled/ in terms of everyday meatspace traffic.b What don't you like about the analogy?

it's not that i don't like it. it's that you haven't shown how it's applicable. what evidence do you have that there is such a "traffic jam" or if there is, that it is an actual problem?

Which seamlessly segues us to the main thrust of this opus. Pay attention, 'coz what's coming up is the only important bit. Up 'til now, it was fluff, sort'a like what you did to me with your gudxillion sub-quotes.
Enough! Reader, follow me!

TehGist:
1. You made a claim that "blocks aren't actually full on average."
2. I replied that while this is the case, it is impossible for things to be otherwise -- blocks *can never be 100% full on the average*.
3. If analogies are a strain (abstract thought could be a bitch for some), here's the actual mechanics: as long as a miner is able to mine an empty block, the average can't be 100% full blocks. Because that's how averages fucking are. That's how they work.

I hope this helps.

i was referring to the actual growth in transaction volume (therefore block size) over time. i'd have thought this would be obvious. seems relevant to your suggestion that capacity is insufficient. there is a tendency to point to short term batches of 9xx kb blocks, then to ignore the 400-600 kb blocks that come after the backlog has cleared.

the network actually isn't under the constant load that some suggest, and during the times that it temporarily is, paying an extra tiny fraction of an mBTC in fees alleviates the issue.

anyway, this has nothing to do with evidence of your suggestion that there is an urgent problem here. since the transactions backlogs are always cleared and fees are miniscule, what's the problem again?
You were "referring to the actual growth in transaction volume (therefore block size) over time"? How does the fact that "blocks aren't actually full on average" figure into this? Taking into account that it's as likely for blocks to be "full on average" as it is for the busiest road to be bumper-to-bumper jammed, on the average, which is to say "not at all"?
Why bring up a meaningless metric?
At the risk of belaboring the obvious: Blocks will never be "full on average." Don't wait for blocks to be full on the average.

>since the transactions backlogs are always cleared and fees are miniscule, what's the problem again?
If you're stuck in traffic for 6 hours on your way back from work, what's the problem? I mean, you get home eventually, every day, amirite?
The road is clearly of sufficient capacity, no one *never* gets home. In other words, "traffic jams transactions backlogs are always cleared."
I like the analogy, however in the case of Bitcoin there is simply not enough capacity for everyone to get "home", regardless of the fee that is payed.

Furthermore as a counter argument, if we imagine this road being like a toll road, then we can say that other roads exists, in the form of potential Bitcoin forks and altcoins. If the other roads are both faster and cheaper then I think people will choose to drive on those alternative roads instead, the economics of it all are quite simple really when it comes down to it. I think that if we allow the Bitcoin network to become overloaded making transacting much more expensive and unreliable then I think Bitcoin will simply be outcompeted and obsolesced.

I am glad you installed Bitcoin Classic David Rabahy, that is the solution to this existential crisis after all. Wink
hero member
Activity: 709
Merit: 503
February 20, 2016, 02:02:37 PM
Whatever; I've installed classic -- whee.
hero member
Activity: 709
Merit: 503
February 20, 2016, 02:00:45 PM
As confirmation times and fees rise adoption stalls or worse declines leading to less workload; self-regulation.  The appearance will be that we're ok and in a sense we are but is this our vision?

Hurry up and get SegWit out *but* that fundamentally cannot be the end of the story, right?

Perhaps we should practice hard forking, e.g. 1.1MB, just to get use to it.  Hmm, or are we saying we never want a hard fork ever again?
legendary
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
February 20, 2016, 10:28:54 AM
I would prefer to not do it now because increasing the block size requires a hard fork and hard forks should only happen when there really isn't another solution.

Yes at some point it will be needed even with SegWit - do it then. There is no point to doing it now, most blocks are not full and it is cheap to get your TX seen quickly.


There is absolutely a point to doing it now.

here's why:

1. Look at the graph.  We've went from .3 to .65 in 12 months.
https://blockchain.info/charts/avg-block-size?timespan=1year&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address=

Assuming Bitcoin is the awesome distrupting technology a lot of say it is, and want it to be,
we should be expecting exponential growth.  Could quadruple in the NEXT 12 months.

2. It takes many months to safely do a hardfork.

So, given those two  points, really makes sense to do it now.

Plus consider this:

You can make the argument that segwit is going
to buy us plenty of time (questionable), but that I don't see
any benefit of waiting to fork.   Why is doing it later better or
less risky than doing it now?  If anything its going to
be much more risky to rush the hard fork by waiting
till its an urgent problem.  Don't you agree?


full member
Activity: 154
Merit: 100
February 20, 2016, 06:05:34 AM
Before this deteriorates any further, try to stay focused.
Don't break this up into a zillion sub-topics, with each word I type addressed in a separate catty comeback.
inb4 not a zillion: no. stay focused. resist. We want one cogent, cohesive response, even if you miss out on a few snark opportunities.

Now then: My traffic analogy.
It's fucking great, no sense being coy about it. Unoriginal, sure -- network traffic is typically visualized/modeled/ in terms of everyday meatspace traffic.b What don't you like about the analogy?

it's not that i don't like it. it's that you haven't shown how it's applicable. what evidence do you have that there is such a "traffic jam" or if there is, that it is an actual problem?

Which seamlessly segues us to the main thrust of this opus. Pay attention, 'coz what's coming up is the only important bit. Up 'til now, it was fluff, sort'a like what you did to me with your gudxillion sub-quotes.
Enough! Reader, follow me!

TehGist:
1. You made a claim that "blocks aren't actually full on average."
2. I replied that while this is the case, it is impossible for things to be otherwise -- blocks *can never be 100% full on the average*.
3. If analogies are a strain (abstract thought could be a bitch for some), here's the actual mechanics: as long as a miner is able to mine an empty block, the average can't be 100% full blocks. Because that's how averages fucking are. That's how they work.

I hope this helps.

i was referring to the actual growth in transaction volume (therefore block size) over time. i'd have thought this would be obvious. seems relevant to your suggestion that capacity is insufficient. there is a tendency to point to short term batches of 9xx kb blocks, then to ignore the 400-600 kb blocks that come after the backlog has cleared.

the network actually isn't under the constant load that some suggest, and during the times that it temporarily is, paying an extra tiny fraction of an mBTC in fees alleviates the issue.

anyway, this has nothing to do with evidence of your suggestion that there is an urgent problem here. since the transactions backlogs are always cleared and fees are miniscule, what's the problem again?

You were "referring to the actual growth in transaction volume (therefore block size) over time"? How does the fact that "blocks aren't actually full on average" figure into this? Taking into account that it's as likely for blocks to be "full on average" as it is for the busiest road to be bumper-to-bumper jammed, on the average, which is to say "not at all"?
Why bring up a meaningless metric?
At the risk of belaboring the obvious: Blocks will never be "full on average." Don't wait for blocks to be full on the average.

>since the transactions backlogs are always cleared and fees are miniscule, what's the problem again?
If you're stuck in traffic for 6 hours on your way back from work, what's the problem? I mean, you get home eventually, every day, amirite?
The road is clearly of sufficient capacity, no one *never* gets home. In other words, "traffic jams transactions backlogs are always cleared."
full member
Activity: 182
Merit: 107
February 20, 2016, 03:06:57 AM
I would prefer to not do it now because increasing the block size requires a hard fork and hard forks should only happen when there really isn't another solution.

Yes at some point it will be needed even with SegWit - do it then. There is no point to doing it now, most blocks are not full and it is cheap to get your TX seen quickly.
legendary
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
February 20, 2016, 01:37:14 AM
Before this deteriorates any further, try to stay focused.
Don't break this up into a zillion sub-topics, with each word I type addressed in a separate catty comeback.
inb4 not a zillion: no. stay focused. resist. We want one cogent, cohesive response, even if you miss out on a few snark opportunities.

Now then: My traffic analogy.
It's fucking great, no sense being coy about it. Unoriginal, sure -- network traffic is typically visualized/modeled/ in terms of everyday meatspace traffic.b What don't you like about the analogy?

it's not that i don't like it. it's that you haven't shown how it's applicable. what evidence do you have that there is such a "traffic jam" or if there is, that it is an actual problem?

Which seamlessly segues us to the main thrust of this opus. Pay attention, 'coz what's coming up is the only important bit. Up 'til now, it was fluff, sort'a like what you did to me with your gudxillion sub-quotes.
Enough! Reader, follow me!

TehGist:
1. You made a claim that "blocks aren't actually full on average."
2. I replied that while this is the case, it is impossible for things to be otherwise -- blocks *can never be 100% full on the average*.
3. If analogies are a strain (abstract thought could be a bitch for some), here's the actual mechanics: as long as a miner is able to mine an empty block, the average can't be 100% full blocks. Because that's how averages fucking are. That's how they work.

I hope this helps.

i was referring to the actual growth in transaction volume (therefore block size) over time. i'd have thought this would be obvious. seems relevant to your suggestion that capacity is insufficient. there is a tendency to point to short term batches of 9xx kb blocks, then to ignore the 400-600 kb blocks that come after the backlog has cleared.

the network actually isn't under the constant load that some suggest, and during the times that it temporarily is, paying an extra tiny fraction of an mBTC in fees alleviates the issue.

anyway, this has nothing to do with evidence of your suggestion that there is an urgent problem here. since the transactions backlogs are always cleared and fees are miniscule, what's the problem again?

Lets say for the sake of argument that you're right.

Transactions are still growing.  Do we really need an "urgent problem"?  Why not be prudent and increase the blocksize already?
Feel like im taking crazy pills here.



Increasing transaction rate is what is needed. Increasing block size is one way to do that, but not the only way to do that.

Why do you feel increasing block size is better than the solution that core developers have actual working code for, currently in testing, that does not require a hard fork?

I agree its not the only way to do it.

To answer your question, its better because its simpler and more robust. Faster and easier to implement.
A blocksize increase will be required sooner or later so the fact that a hard fork is part of it, is not a reason not to do it (since its necessity is inevitable).

And a question to you: Why NOT do it now, since an increase to 2MB is likely harmless, and
the community is loudly demanding it, to the point where contentious forks are possible.



full member
Activity: 182
Merit: 107
February 20, 2016, 12:50:08 AM
Before this deteriorates any further, try to stay focused.
Don't break this up into a zillion sub-topics, with each word I type addressed in a separate catty comeback.
inb4 not a zillion: no. stay focused. resist. We want one cogent, cohesive response, even if you miss out on a few snark opportunities.

Now then: My traffic analogy.
It's fucking great, no sense being coy about it. Unoriginal, sure -- network traffic is typically visualized/modeled/ in terms of everyday meatspace traffic.b What don't you like about the analogy?

it's not that i don't like it. it's that you haven't shown how it's applicable. what evidence do you have that there is such a "traffic jam" or if there is, that it is an actual problem?

Which seamlessly segues us to the main thrust of this opus. Pay attention, 'coz what's coming up is the only important bit. Up 'til now, it was fluff, sort'a like what you did to me with your gudxillion sub-quotes.
Enough! Reader, follow me!

TehGist:
1. You made a claim that "blocks aren't actually full on average."
2. I replied that while this is the case, it is impossible for things to be otherwise -- blocks *can never be 100% full on the average*.
3. If analogies are a strain (abstract thought could be a bitch for some), here's the actual mechanics: as long as a miner is able to mine an empty block, the average can't be 100% full blocks. Because that's how averages fucking are. That's how they work.

I hope this helps.

i was referring to the actual growth in transaction volume (therefore block size) over time. i'd have thought this would be obvious. seems relevant to your suggestion that capacity is insufficient. there is a tendency to point to short term batches of 9xx kb blocks, then to ignore the 400-600 kb blocks that come after the backlog has cleared.

the network actually isn't under the constant load that some suggest, and during the times that it temporarily is, paying an extra tiny fraction of an mBTC in fees alleviates the issue.

anyway, this has nothing to do with evidence of your suggestion that there is an urgent problem here. since the transactions backlogs are always cleared and fees are miniscule, what's the problem again?

Lets say for the sake of argument that you're right.

Transactions are still growing.  Do we really need an "urgent problem"?  Why not be prudent and increase the blocksize already?
Feel like im taking crazy pills here.



Increasing transaction rate is what is needed. Increasing block size is one way to do that, but not the only way to do that.

Why do you feel increasing block size is better than the solution that core developers have actual working code for, currently in testing, that does not require a hard fork?
legendary
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
February 20, 2016, 12:28:56 AM
Before this deteriorates any further, try to stay focused.
Don't break this up into a zillion sub-topics, with each word I type addressed in a separate catty comeback.
inb4 not a zillion: no. stay focused. resist. We want one cogent, cohesive response, even if you miss out on a few snark opportunities.

Now then: My traffic analogy.
It's fucking great, no sense being coy about it. Unoriginal, sure -- network traffic is typically visualized/modeled/ in terms of everyday meatspace traffic.b What don't you like about the analogy?

it's not that i don't like it. it's that you haven't shown how it's applicable. what evidence do you have that there is such a "traffic jam" or if there is, that it is an actual problem?

Which seamlessly segues us to the main thrust of this opus. Pay attention, 'coz what's coming up is the only important bit. Up 'til now, it was fluff, sort'a like what you did to me with your gudxillion sub-quotes.
Enough! Reader, follow me!

TehGist:
1. You made a claim that "blocks aren't actually full on average."
2. I replied that while this is the case, it is impossible for things to be otherwise -- blocks *can never be 100% full on the average*.
3. If analogies are a strain (abstract thought could be a bitch for some), here's the actual mechanics: as long as a miner is able to mine an empty block, the average can't be 100% full blocks. Because that's how averages fucking are. That's how they work.

I hope this helps.

i was referring to the actual growth in transaction volume (therefore block size) over time. i'd have thought this would be obvious. seems relevant to your suggestion that capacity is insufficient. there is a tendency to point to short term batches of 9xx kb blocks, then to ignore the 400-600 kb blocks that come after the backlog has cleared.

the network actually isn't under the constant load that some suggest, and during the times that it temporarily is, paying an extra tiny fraction of an mBTC in fees alleviates the issue.

anyway, this has nothing to do with evidence of your suggestion that there is an urgent problem here. since the transactions backlogs are always cleared and fees are miniscule, what's the problem again?

Lets say for the sake of argument that you're right.

Transactions are still growing.  Do we really need an "urgent problem"?  Why not be prudent and increase the blocksize already?
Feel like im taking crazy pills here.

legendary
Activity: 1652
Merit: 1483
February 19, 2016, 10:08:39 PM
Before this deteriorates any further, try to stay focused.
Don't break this up into a zillion sub-topics, with each word I type addressed in a separate catty comeback.
inb4 not a zillion: no. stay focused. resist. We want one cogent, cohesive response, even if you miss out on a few snark opportunities.

Now then: My traffic analogy.
It's fucking great, no sense being coy about it. Unoriginal, sure -- network traffic is typically visualized/modeled/ in terms of everyday meatspace traffic.b What don't you like about the analogy?

it's not that i don't like it. it's that you haven't shown how it's applicable. what evidence do you have that there is such a "traffic jam" or if there is, that it is an actual problem?

Which seamlessly segues us to the main thrust of this opus. Pay attention, 'coz what's coming up is the only important bit. Up 'til now, it was fluff, sort'a like what you did to me with your gudxillion sub-quotes.
Enough! Reader, follow me!

TehGist:
1. You made a claim that "blocks aren't actually full on average."
2. I replied that while this is the case, it is impossible for things to be otherwise -- blocks *can never be 100% full on the average*.
3. If analogies are a strain (abstract thought could be a bitch for some), here's the actual mechanics: as long as a miner is able to mine an empty block, the average can't be 100% full blocks. Because that's how averages fucking are. That's how they work.

I hope this helps.

i was referring to the actual growth in transaction volume (therefore block size) over time. i'd have thought this would be obvious. seems relevant to your suggestion that capacity is insufficient. there is a tendency to point to short term batches of 9xx kb blocks, then to ignore the 400-600 kb blocks that come after the backlog has cleared.

the network actually isn't under the constant load that some suggest, and during the times that it temporarily is, paying an extra tiny fraction of an mBTC in fees alleviates the issue.

anyway, this has nothing to do with evidence of your suggestion that there is an urgent problem here. since the transactions backlogs are always cleared and fees are miniscule, what's the problem again?
sr. member
Activity: 294
Merit: 250
February 19, 2016, 09:47:18 PM
We can wait for Bitcoin to become very hard to use when people constantly sends more transactions than can even be included in blockchain, also know as denial of service attack, but this will erode a lot of trust in Bitcoin as well, very likely beyond repair. So not much safer choice eighter - unless you believe people will be happy to use Bitcoin with 1) huge fees, 2) long 1st confirmation times 3) never confimed transactions. I dont know of any coin with restricted blocksizes so people can hardly use it, yet very popular and people eager to use this coin  Roll Eyes

any evidence for this "sky is falling" attitude? any evidence of huge fees? what is "huge?" i've always been able to get my transaction in the next block for minimal fees.

bitcoin has "restricted blocksizes" yet, it is "very popular and people [are] eager to use this coin."


I see common mistake of small blockers to dont have any imagination at all what future might look like. With "restricted blocksizes" I obviously meant artifically restricted blocksize way below constant demand.
full member
Activity: 154
Merit: 100
February 19, 2016, 09:19:50 PM
You mean roads are often widened *before* there's a traffic jam 24/7/365? But until all the lanes are bumper-to-bumper 24/7/365, the road isn't even at 100% capacity yet Huh

what proof do you have that there will be "a traffic jam 24/7/365?" because there's a bunch of unconfirmed transactions that are eventually cleared from the mempool and included in blocks?

the horror!

Where have I suggested there'll be "a traffic jam 24/7/365"?

you said, "You mean roads are often widened *before* there's a traffic jam 24/7/365?" suggesting that this might actually happen.

On the contrary, my point was such traffic jams are almost impossible, and the most congested of roads, the ones where you sit in traffic for hours during rush hours? Those roads are, on the average, operating at less than 50% capacity.

Thus, 50% average doesn't imply that the traffic is not at a standstill during rush hours, that the road has 50% excess capacity, or that it doesn't need to be widened.

what do your musings about traffic jams have to do with bitcoin transactions? how does "a bunch of unconfirmed transactions that are eventually cleared from the mempool and included in blocks" = a traffic jam? if it does, what's the problem?

This should be obvious to an average 7-year-old, so assuming you're trolling.

nope, just think you should justify the comparison. youre suggesting that there is some urgent problem with bitcoin, but you can't seem to provide any evidence of it aside from irrelevant comparisons to traffic jams

Before this deteriorates any further, try to stay focused.
Don't break this up into a zillion sub-topics, with each word I type addressed in a separate catty comeback.
inb4 not a zillion: no. stay focused. resist. We want one cogent, cohesive response, even if you miss out on a few snark opportunities.

Now then: My traffic analogy.
It's fucking great, no sense being coy about it. Unoriginal, sure -- network traffic is typically visualized/modeled/ in terms of everyday meatspace traffic.b What don't you like about the analogy?

Which seamlessly segues us to the main thrust of this opus. Pay attention, 'coz what's coming up is the only important bit. Up 'til now, it was fluff, sort'a like what you did to me with your gudxillion sub-quotes.
Enough! Reader, follow me!

TehGist:
1. You made a claim that "blocks aren't actually full on average."
2. I replied that while this is the case, it is impossible for things to be otherwise -- blocks *can never be 100% full on the average*.
3. If analogies are a strain (abstract thought could be a bitch for some), here's the actual mechanics: as long as a miner is able to mine an empty block, the average can't be 100% full blocks. Because that's how averages fucking are. That's how they work.

I hope this helps.
legendary
Activity: 1652
Merit: 1483
February 19, 2016, 08:47:22 PM
You mean roads are often widened *before* there's a traffic jam 24/7/365? But until all the lanes are bumper-to-bumper 24/7/365, the road isn't even at 100% capacity yet Huh

what proof do you have that there will be "a traffic jam 24/7/365?" because there's a bunch of unconfirmed transactions that are eventually cleared from the mempool and included in blocks?

the horror!

Where have I suggested there'll be "a traffic jam 24/7/365"?

you said, "You mean roads are often widened *before* there's a traffic jam 24/7/365?" suggesting that this might actually happen.

On the contrary, my point was such traffic jams are almost impossible, and the most congested of roads, the ones where you sit in traffic for hours during rush hours? Those roads are, on the average, operating at less than 50% capacity.

Thus, 50% average doesn't imply that the traffic is not at a standstill during rush hours, that the road has 50% excess capacity, or that it doesn't need to be widened.

what do your musings about traffic jams have to do with bitcoin transactions? how does "a bunch of unconfirmed transactions that are eventually cleared from the mempool and included in blocks" = a traffic jam? if it does, what's the problem?

This should be obvious to an average 7-year-old, so assuming you're trolling.

nope, just think you should justify the comparison. youre suggesting that there is some urgent problem with bitcoin, but you can't seem to provide any evidence of it aside from irrelevant comparisons to traffic jams
full member
Activity: 154
Merit: 100
February 19, 2016, 08:38:54 PM
You mean roads are often widened *before* there's a traffic jam 24/7/365? But until all the lanes are bumper-to-bumper 24/7/365, the road isn't even at 100% capacity yet Huh

what proof do you have that there will be "a traffic jam 24/7/365?" because there's a bunch of unconfirmed transactions that are eventually cleared from the mempool and included in blocks?

the horror!

Where have I suggested there'll be "a traffic jam 24/7/365"?
On the contrary, my point was such traffic jams are almost impossible, and the most congested of roads, the ones where you sit in traffic for hours during rush hours? Those roads are, on the average, operating at less than 50% capacity.

Thus, 50% average doesn't imply that the traffic is not at a standstill during rush hours, that the road has 50% excess capacity, or that it doesn't need to be widened.

This should be obvious to an average 7-year-old, so assuming you're trolling.
legendary
Activity: 1652
Merit: 1483
February 19, 2016, 08:27:08 PM
You mean roads are often widened *before* there's a traffic jam 24/7/365? But until all the lanes are bumper-to-bumper 24/7/365, the road isn't even at 100% capacity yet Huh

what proof do you have that there will be "a traffic jam 24/7/365?" because there's a bunch of unconfirmed transactions that are eventually cleared from the mempool and included in blocks?

the horror!
legendary
Activity: 1652
Merit: 1483
February 19, 2016, 08:25:33 PM
I'll tell you a little secret: Blocks will never be full on average. Even if we cap it to 100KB.

If you think that means we don't have a problem then there's not much more to say.

average is simply a metric to filter out noise. by your logic, increasing the block size was urgent years ago when the first nearly-full block was mined. yet, we've continued to have a robust system that keeps chugging along, and fees are still cheap as fuck.

what proof do you have that there is actually an urgent problem?
Pages:
Jump to: