Stop fuckin' around, fork the son-of-a-bitch already.

[zimmah]

So you agree there's no normal use case for 1MB or larger transactions, so why do you oppose limiting transactions to 1MB while increasing blocksize?

I don't agree with that. I haven't thought about it, and I'm pretty sure that there may very well be a normal use case for some business.

You do realize that in order to have transactions bigger than 1MB you would need blocks bigger than 1MB right?   
i hope you have at least that level of intelligence.

Considering your contradiction posts on this subject though, I am starting to doubt that. (either that, or you are forgetting your own statements in less than a few hours after posting them).

Statement 1:
I don't want blocks larger than 1MB

Statement 2:
I might want transactions larger than 1MB

These are not compatible with each other (not to mention, they're ridiculous, even in their own, but together they're even worse).

Are you mad because I can destroy your entire argument in 2 minutes of typing?

1) I don't get "mad" when someone rationally shows supreme arguments. 2) You did no such thing.

If you don't understand me, than that's not my problem, but yours.   

I have proven this to be factually correct, and it remains true until you prove proof that your disagreement is backed by logical reasoning and facts.  

You have done no such thing. You're starting to resemble Veritas.

See above comment

And you can teach me?

I may or may not be able to, not that it would matter.

I doubt it.

First of all, technology has become much cheaper in the past 6 years (on average at least). And besides, who really has a hard drive measured in gigabytes anymore?    

Strawman argument.

I'm sure this is in no way a strawman argument.

It's a pure example of strawman fallacy. I never argued that "technology didn't become cheaper" did I? Don't attempt to use fallacies again, else we end up with nonsense as "Strawman nodes".  

It's pretty clear you have no idea what a strawman argument is, and are accusing me of using them while your whole premise is based on one.   
You're only showing that talking with you is a massive waste of anyone's time.

Yes, they're being sold and yes I plan to buy a 1/2 TB drive.

That's still plenty to run 20MB blocksize for several years, even if you falsely assume every single block is full. (and it's still a drive measured in terabytes)

20 MB per block x 6 blocks per hour x 24 hours a day x 365 days a year = ~1051 GB per year. Please explain how a 1/2 TB drive (aka 500 GB drive) would run for "several years".

well, this is the first time you actually have a point, I didn't bother calculating that, so I turned out to be wrong in that statement.

Still, in practice even a cheap 500GB drive would last for at least half a year, and most likely longer because it's unlikely blocks of 20MB would be filled every time at least for the next few years.

It's quite easy, you just divide the blocksize by the average time it takes to find a block.

20 MB / 10 minutes = 2 MB per 1 minute. 2 divided by 60 = 0.03 MB/s. Let me tell you why your thinking is flawed (not that you're going to admit this). If a node is downloading at this speed, it will never catch up. Why is that? By the time that it downloads a 20 MB block, it is likely that another one will be created. The node would still be validating the previous block in addition to having the next one. I do wonder how long it takes to validate a 20 MB block on decent hardware though.

Except that you snipped out the part where I actually admitted this before you even brought it up as an argument, along with saying that this isn't an issue because it's several orders of magnitude lower than even slow internet speeds. So even if you account for this, it's not a problem.     

Not only do you show an inability to reasoning on any level of intelligence, you also are also purposely misrepresenting my quotes. I'm not beyond admitting when I'm wrong, I am wrong sometimes, but that does not invalidate my arguments. Fact is, every single person is wrong sometimes, but that does not make everything they say wrong.

And xthin blocks would solve that issue too, but Core doesn't support xthin (of course, because core doesn't support improvement).

And what is the primary bottleneck then? I'm sure memory won't be a problem with blocksizes smaller than a few gigabyte.

Validation time.

Well, it's a good thing Satoshi was smart enough to keep block times at 10 minutes then, unlike many altcoins who have blocktimes of mere seconds.     
10 minutes should be enough for the slower nodes to keep up with plenty of headroom. (this is also why I oppose of altcoins with very fast blocktimes).

[Lauda]

Statement 1:
I don't want blocks larger than 1MB

Statement 2:
I might want transactions larger than 1MB

These are not compatible with each other (not to mention, they're ridiculous, even in their own, but together they're even worse).

I have made neither one of these statements. Now you're just an outright liar and manipulator (say hi to Veritas for me).

-snip-

Ad hominem nonsense due to losing ground.

You're only showing that talking with you is a massive waste of anyone's time.

You're the one wasting time with wrongful information trying to mislead people into supporting something that is both inherently controversial and dangerous.

Still, in practice even a cheap 500GB drive would last for at least half a year, and most likely longer because it's unlikely blocks of 20MB would be filled every time at least for the next few years.

Until somebody "turns on" the spam again, and suddenly everyone is stuck with massive bloat.

And xthin blocks would solve that issue too, but Core doesn't support xthin (of course, because core doesn't support improvement).

Xthin is half-baked level improvement, just like pretty much any other BU development has been.

10 minutes should be enough for the slower nodes to keep up with plenty of headroom.

No, that's not even nearly enough time, especially not without Segwit.

[zimmah]

anyway
although 20mb is diverting off the current proposals by a factor of 5-10x.. and entering the cosmic theory of doomsday dreams, lets ask you..
are you saying to this other guy that 0.3mb internet speeds is something the world is averaging.
is this 0.3mb speed something you yourself are suffering with..

There's actually some proposals for 20MB blocks and they're widely accepted. source: https://en.bitcoin.it/wiki/Block_size_limit_controversy#Entities_positions

In favor: Magnr, Ethereum (If bitcoin is used as currency), armory, bitcoinreminder, bithours, bitpay, bittiraha.fi, blockchain.info, blocktrail, breadwallet, BTC guild, BX.in.th, coinbase, coinify, adam back, kryptoradio, okcoin, 3rd key solutions, xapo, F2pool (in favor of 5MB, 20MB is too soon for them).

Opposed: bitcoinpaygate, bitrated, greenaddress, mpex, paymium.

The only entity actually providing a reason for opposition is greenaddress, who provided "it's only a temporary solution" as a reason. So they recognize the problem, but they don't agree with the solution because they think it won't fix the problem long-term.


Btw, only 6 out of 144 countries have an average upload speed of < 0.9 Mb/s, only 2 of them have an average download speed of < 0.9Mb/s (burkina faso [0.84 Mb/s] and niger [0.6 Mb/s])

0 out of 144 countries have an average download speed of < 0.3 Mb/s and 2 out of 144 have an average upload speed of < 0.3 (burkina faso [0.29 Mb/s] and niger [0.2 Mb/s])

total population of those two countries is roughly 34 million (both countries are about 17 million)

Those might struggle a little bit, but even they could probably run 20MB blocks (especially if we include xthin blocks)



Although I think it's together with xthin blocks to make the network propagation more efficient by a factor of at least 5 times. So effectively they would be like 4MB blocks but allowing 20MB worth of transactions (and i can only imagine what SegWit/LN could improve on this).

Scaling is possible, it's only some people holding it back, for no particular reason.

[zimmah]

1) You could limit the transaction size while still increasing the blocksize.

It's not a matter of 'could' or 'could not', but rather a matter of "should" or "should not". I disagree with those limitations.

Here you are disagreeing with limiting the transaction size. (limiting it to 1MB is implied, just to be sure you understand, the current limit is 1MB because the blocksize is 1MB and therefore a transaction larger than 1MB doesn't fit).

Other than a mindless fearr of a hard fork, give me 1 solid reason based on logic against a block size increase.

1) Security risk of a DOS due to quadratic validation problem.
2) No hard fork experience.
3) High risk of damaging merchants and businesses that do not manage to update in time (if the activation parameters are improper such as with Bitcoin Classic).
4) Higher storage cost.
5) Higher bandwidth cost.
Even if we disregard the 4 latter, the primary issue is still the security risk.

and here you are disagreeing with increasing the block size.

So even though those statements weren't direct quotes (I never implied they were quotes), I can proof that they align with your statements. Therefore you are contradicting yourself, and falsely accusing me of lying.

Until somebody "turns on" the spam again, and suddenly everyone is stuck with massive bloat.

you can't just block honest transactions because you're afraid of spam. You're doing more harm than good that way.

That's like only allowing 100 users at a time to connect to google.com because otherwise google.com might be DDOSed. So whenever there's 100 users on google, google.com blocks all requests until one of the users is done.    

If google.com would do that, how long do you think google.com remains the most popular search engine?

Not very long.

And yet, that's exactly what bitcoin is doing right now.

No, that's not even nearly enough time, especially not without Segwit.

Not enough time for what? Verifying with an abacus?

Could you get equipment from this century at least?

Ad hominem nonsense due to losing ground.

fun fact, 100% of the troll I have spoken to have used the following arguments when they run out of actual arguments:

*You are using ad hominem
* You are using strawman arguments

Does not matter if I am actually using ad hominem or strawman arguments.

[Lauda]

Here you are disagreeing with limiting the transaction size. (limiting it to 1MB is implied, just to be sure you understand, the current limit is 1MB because the blocksize is 1MB and therefore a transaction larger than 1MB doesn't fit).

What was meant is that I'm against additional imposed limitations in order to favor a HF. I'm undecided about TX size as there haven't been that many discussions about it.

-snip-
and here you are disagreeing with increasing the block size.

Listing cons of something != disagreeing with it. There is likely going to be some headroom with Segwit, where an additional increase of 1-2 MB may be okay. I'm still waiting for Luke-Jr's proposal.

So even though those statements weren't direct quotes (I never implied they were quotes), I can proof that they align with your statements. Therefore you are contradicting yourself, and falsely accusing me of lying.

Taking things out of context in other to strengthen your position is what one would usually define a lying manipulator as.

And yet, that's exactly what bitcoin is doing right now.

No, that's not what Bitcoin "is doing right now". Bitcoin can't do anything on its own as Bitcoin isn't an entity that can decide for itself. In addition to that, the analogy is false since the limit in currently a safeguard from the DOS risk at 2 MB or higher.

Not enough time for what? Verifying with an abacus?

I'll even risk by saying that enthusiast grade hardware will not be able to validate a sigop expensive 20 MB block in time. Someone would need to test this out to confirm though.

[zimmah]

So even though those statements weren't direct quotes (I never implied they were quotes), I can proof that they align with your statements. Therefore you are contradicting yourself, and falsely accusing me of lying.

Taking things out of context in other to strengthen your position is what one would usually define a lying manipulator as.

If you are not against blocksize increase, then why do you keep arguing against it?

I'm not taking things out of context, although I do remember someone doing just that a few posts ago.

No, that's not what Bitcoin "is doing right now". Bitcoin can't do anything on its own as Bitcoin isn't an entity that can decide for itself. In addition to that, the analogy is false since the limit in currently a safeguard from the DOS risk at 2 MB or higher.

So is the analogy, with the side effect that it is limiting users. Which bitcoin is doing right now too. (and you know full well what I mean by that, don't derail the conversation by arguing semantics)

[Lauda]

If you are not against blocksize increase, then why do you keep arguing against it?

Because it's the wrong position to have and it has many cons which should not be ignored. 2 MB is inherently dangerous, hence the additional limitations as added by Gavin's BIP for Classic. Segwit aims to solve this, in addition to increasing the capacity with usage (which should result in around 170-180% increase). After Segwit, we should look into acceptable block size increases. In addition to all of this, deploying a HF just for the sake of a block size increase is horribly inefficient. There are certainly some changes/optimizations that require a HF and those should be deployed along side the block size increase.

I'm not taking things out of context, although I do remember someone doing just that a few posts ago.

Yes, you have. It's still better than the franky1's "You all want Monero to succeed" fantasy.

[illyiller]

1) Security risk of a DOS due to quadratic validation problem.

Today's DOS attack on Ethereum is relevant here:

http://www.ethnews.com/ethereum-network-under-a-dos-attack


I suppose we can keep musing about how irrational it would be for such blocks to mined... but, food for thought.

[Mr Felt]

a 2tb hard drive is only 800,00 kuna (im guessing your still in croatia) (£90 : $120 for those not wishing to convert kuna to western currencies)

No, I am not and have never been in Croatia.

hmm.. lets pick a country .
ok africa..http://www.africawebtv.com/
ok korea..http://www.afreecatv.com/
ok russia..http://www.vichatter.com/

i could go on..

The most interesting thing about the above-quoted list is that nobody wants to play the obvious zinger in response. Have a little fun. Please.

[franky1]

The most interesting thing about the above-quoted list is that nobody wants to play the obvious zinger in response. Have a little fun. Please.

if your talking about why i switched from talking about hard drive to bandwidth, obviously hard drives are cheap so the other 'cost' is internet speed
if your talking about my reasoning to talk about UPLOAD instead of download.. there is a technical reason for this
if your talking about why i am mentioning uploading live video. as oppose to a tweet there is an obvious reason for this too

the reason i used live streaming is because its a real life scenario people can understand of large data moving..
(upload 10minutes of SD(0.5mbIT/sec) quality video=~37mbyte of data)

months ago lauda attempted to debunk WATCHING videos as that was only download bandwidth to which i replied months ago with UPLOAD stats of livestream recording at that time. and today was reminding him of the facts that the internet as a whole is not a problem for 2-4mb blocks upload and by default definitely no issues for download

though the internet is proven to be fast for hundred of MILLIONS of people as shown by all the countries doing livestreaming to prove its not a dream. the community accept some places can get over 100mb/s, but as a safe level the majority feel 2-4 is acceptable.. even core believe 4mb is acceptable now.
im not going to get into the debate of someone else advocating 20mb, as that is just poking laudas bear and not something the community as a whole could consider right now(though technically possible).

i personally have only been advocating for 2mb this year knowing rationally that in the near future technology progresses to allow for more (even if the technology is already available now. its best to stay in the safe zone)

in short 4mb is internet safe, 2mb is even safer so data speed debate of 2mb should be considered resolved as it was before late 2015 (even in cores 4mb eyes, 2mb is safe)

which is why i laugh hard when lauda was saying 2mb was bad.. yet his friends are saying 4mb is acceptable, and lauda has now backtracked to say 4mb is acceptable "because its core". but 2mb is still bad.

even if its a 2mb base 4mb weight linear validation rules.. lauda will still not be happy and will always try to debate some crap to keep core as the overlords, rather than all implementations coming to a joint agreement making all implementations all on the same level playing field coming to a joint consensus, which the community thought we reached before last christmas. and then tried to get core back inline in spring. and then again in summer..

[Lauda]

-snip-
I suppose we can keep musing about how irrational it would be for such blocks to mined... but, food for thought.

But, but, BU team promised me everyone would be playing nice and creating sigop friendly blocks? 

-snip-
months ago lauda attempted to debunk WATCHING videos as that was only download bandwidth to which i replied months ago with UPLOAD stats of livestream recording at that time. and today was reminding him of the facts that the internet as a whole is not a problem for 2-4mb blocks upload and by default definitely no issues for download

Comparing live-streaming to running a node is also a 'false analogy fallacy'. One has incentives, the other one doesn't for example.

im not going to get into the debate of someone else advocating 20mb, as that is just poking laudas bear and not something the community as a whole could consider right now(though technically possible).

Sure, even 1 TB blocks are technically possibly. This doesn't make it safe.

which is why i laugh hard when lauda was saying 2mb was bad.. yet his friends are saying 4mb is acceptable, and lauda has now backtracked to say 4mb is acceptable "because its core". but 2mb is still bad.

I have no friends, ergo this statement is an outright lie.

lauda will still not be happy and will always try to debate some crap to keep core as the overlords,

As said many times, not that it matters, I have no relationship to any Core contributor whatsoever.

rather than all implementations coming to a joint agreement making all implementations all on the same level playing field coming to a joint consensus, which the community thought we reached before last christmas.

The problem is that these "other implementations" only have half-baked, horribly coded improvements.

[Mr Felt]

The most interesting thing about the above-quoted list is that nobody wants to play the obvious zinger in response. Have a little fun. Please.

if your talking about why i switched from talking about hard drive to bandwidth, obviously hard drives are cheap so the other 'cost' is internet speed
if your talking about my reasoning to talk about UPLOAD instead of download.. there is a technical reason for this
if your talking about why i am mentioning uploading live video. as oppose to a tweet there is an obvious reason for this too

the reason i used live streaming is because its a real life scenario people can understand of large data moving..
(upload 10minutes of SD(0.5mbIT/sec) quality video=~37mbyte of data)

months ago lauda attempted to debunk WATCHING videos as that was only download bandwidth to which i replied months ago with UPLOAD stats of livestream recording at that time. and today was reminding him of the facts that the internet as a whole is not a problem for 2-4mb blocks upload and by default definitely no issues for download

though the internet is proven to be fast for hundred of MILLIONS of people as shown by all the countries doing livestreaming to prove its not a dream. the community accept some places can get over 100mb/s, but as a safe level the majority feel 2-4 is acceptable.. even core believe 4mb is acceptable now.
im not going to get into the debate of someone else advocating 20mb, as that is just poking laudas bear and not something the community as a whole could consider right now(though technically possible).

i personally have only been advocating for 2mb this year knowing rationally that in the near future technology progresses to allow for more (even if the technology is already available now. its best to stay in the safe zone)

in short 4mb is internet safe, 2mb is even safer so data speed debate of 2mb should be considered resolved as it was before late 2015 (even in cores 4mb eyes, 2mb is safe)

which is why i laugh hard when lauda was saying 2mb was bad.. yet his friends are saying 4mb is acceptable, and lauda has now backtracked to say 4mb is acceptable "because its core". but 2mb is still bad.

even if its a 2mb base 4mb weight linear validation rules.. lauda will still not be happy and will always try to debate some crap to keep core as the overlords, rather than all implementations coming to a joint agreement making all implementations all on the same level playing field coming to a joint consensus, which the community thought we reached before last christmas. and then tried to get core back inline in spring. and then again in summer..

I just mean that Africa is not a country, goober.  People are tightly wound these days.   

[franky1]

I just mean that Africa is not a country, goober.  People are tightly wound these days.   

ok i get your point about generalizing, well played,

[franky1]

rather than all implementations coming to a joint agreement making all implementations all on the same level playing field coming to a joint consensus, which the community thought we reached before last christmas.

The problem is that these "other implementations" only have half-baked, horribly coded improvements.

says the guy who hasnt even read a line of code.
nor even knows a line of core code without spoonfeeding

[Lauda]

says the guy who hasnt even read a line of code.
nor even knows a line of core code without spoonfeeding

I don't need to read nor know a single line of code in BU. There's something called third party code review (which unfortunately isn't as common as it should be). Oh wait, you wouldn't know that since you don't resort to knowledge nor rational arguments, but rather character assassination.

[RawDog]

Interesting, freedom of choice no one will force you to run a software... never.

For every bitcoin you have, you will now have one bitcoin, and one bitcoin classic!  May the best coin win!

[redsn0w]

Interesting, freedom of choice no one will force you to run a software... never.

For every bitcoin you have, you will now have one bitcoin, and one bitcoin classic!  May the best coin win!

Exactly, it's just a spin-off of the actual bitcoin blockchain .
I don't care about the name bitcoin classic, unlimited or I don't know... the important thing is that they increase the blocksize and add other few interesting things.

[Lauda]

Exactly, it's just a spin-off of the actual bitcoin blockchain .
I don't care about the name bitcoin classic, unlimited or I don't know...

So introducing confusion in addition to the media portraying Bitcoin as a joke due to that is what you want?

the important thing is that they increase the blocksize and add other few interesting things.

Fun fact: Neither one of those teams have developed anything worth incorporating into Bitcoin Core. Don't get me started on idiotic ideas such as "header-first mining".

[redsn0w]

the important thing is that they increase the blocksize and add other few interesting things.

Fun fact: Neither one of those teams have developed anything worth incorporating into Bitcoin Core. Don't get me started on idiotic ideas such as "header-first mining".

I don't know but check this: https://ww.reddit.com/r/btcfork/comments/53tfnb/hfp0_an_early_prototype_of_a_bitcoin_hard_fork/

[Lauda]

I don't know but check this: https://ww.reddit.com/r/btcfork/comments/53tfnb/hfp0_an_early_prototype_of_a_bitcoin_hard_fork/

optional change of POW (modified scrypt, CPU mineable and hopefully ASIC-resistant)

This obviously wouldn't be Bitcoin anymore, and no way is any miner ever going to support this. Not to mention the amount of botnets that will hop onto this bandwagon.

an implementation of BitPay's adaptive block size algorithm, adjusting in the range 2MB-4MB

Unsafe without Segwit, although I like the idea of adaptive block size algorithm with an lower and upper bound (as long as the upper one isn't beyond safe limits).
I have no idea why they want this to be associated with Bitcoin when it clearly isn't Bitcoin. I'll take a wild guess: Manipulation.