You Mad Bro?

[adamstgBit]

Deal with it

[Slark]

And the moral of the story is?
We should develop advanced AI and put it in charge of bitcoin development? Because we as Humans could never achieve total bias and emotion less judgement.

[adamstgBit]

And the moral of the story is?
We should develop advanced AI and put it in charge of bitcoin development? Because we as Humans could never achieve total bias less judgement.

https://www.youtube.com/watch?v=x7ozaFbqg00

[thejaytiesto]

And the moral of the story is?
We should develop advanced AI and put it in charge of bitcoin development? Because we as Humans could never achieve total bias and emotion less judgement.

Core is showing results, developing improvements and done actual measurements, Classic is showing appeal to emotion and false promises, they are not being scientific and conservative enough, they haven't proved to do anything useful for Bitcoin.

Being an unbiased robot is impossible but Core acts more like this than Classic and it's easy to see by anyone that has been paying attention.

[Jet Cash]

Well I'm a Bitcoin newbie, but I'm getting pissed off by the stroppy 2Mb people who are trying to force an apparently simplistic solution that isn't needed yet. I have yet to see a compelling argument that provides a justification for an immediate blocksize increase.

[pedrog]

Well I'm a Bitcoin newbie, but I'm getting pissed off by the stroppy 2Mb people who are trying to force an apparently simplistic solution that isn't needed yet. I have yet to see a compelling argument that provides a justification for an immediate blocksize increase.

That's because you don't use bitcoin.

Here's your argument:

https://blockchain.info/unconfirmed-transactions

https://chain.btc.com/en/block

[monsanto]

I have yet to see a compelling argument that provides a justification for an immediate blocksize increase.

Double the coins yo 

[adamstgBit]

https://medium.com/@bitcoinroundtable/a-call-for-consensus-d96d5560d8d6#.a53kl32tj

[adamstgBit]

https://forum.bitcoin.com/bitcoin-discussion/an-open-letter-from-sam-cole-ceo-of-knc-miner-t4868.html#p14848

[Lauda]

The is yet another useless propaganda post that does not help. The position of Core is very viable and the wanted increase in transaction capacity is coming with Segwit.

[Jet Cash]

Well I'm a Bitcoin newbie, but I'm getting pissed off by the stroppy 2Mb people who are trying to force an apparently simplistic solution that isn't needed yet. I have yet to see a compelling argument that provides a justification for an immediate blocksize increase.

That's because you don't use bitcoin.

Here's your argument:

https://blockchain.info/unconfirmed-transactions

https://chain.btc.com/en/block

This is the latest block recorded in your link
399,189    AntPool
   1    208    25 + 0.00000000 BTC    3 minutes ago    0000000000000000066105de87b895cc3d0631838da51af0fa33edee1b61600e

That's 208 bytes in size. How will doubling the blocksize help when miners are submitting these.

[Lauda]

This is the latest block recorded in your link
399,189    AntPool
   1    208    25 + 0.00000000 BTC    3 minutes ago    0000000000000000066105de87b895cc3d0631838da51af0fa33edee1b61600e

That's 208 bytes in size. How will doubling the blocksize help when miners are submitting these.

It won't. If anything it will make things worse as more miners will want to use this advantage and submit smaller blocks.

[Kprawn]

unyielding 1MB position? ... Where are you getting that from...? Last time I checked they suggest many possible solutions for these problems. I

think their roadmap is clear enough and would scale block size as needed and when it is needed. The debate is healthy for this experiment and forced

scalability and scare tactics should be left to the reserve banks and politicians.   ... No need to get mad!

[adamstgBit]

unyielding 1MB position? ... Where are you getting that from...? Last time I checked they suggest many possible solutions for these problems. I

think their roadmap is clear enough and would scale block size as needed and when it is needed. The debate is healthy for this experiment and forced

scalability and scare tactics should be left to the reserve banks and politicians.   ... No need to get mad!

you've been lied to 

[pedrog]

Well I'm a Bitcoin newbie, but I'm getting pissed off by the stroppy 2Mb people who are trying to force an apparently simplistic solution that isn't needed yet. I have yet to see a compelling argument that provides a justification for an immediate blocksize increase.

That's because you don't use bitcoin.

Here's your argument:

https://blockchain.info/unconfirmed-transactions

https://chain.btc.com/en/block

This is the latest block recorded in your link
399,189    AntPool
   1    208    25 + 0.00000000 BTC    3 minutes ago    0000000000000000066105de87b895cc3d0631838da51af0fa33edee1b61600e

That's 208 bytes in size. How will doubling the blocksize help when miners are submitting these.

Dude, c'mon, learn a bit more...

That's actually an argument for bigger blocks, if one block comes empty the thousands of transactions in mempool stay in there a bit longer, and next block can only include 1MB, it's like a snowball, if transaction volume doesn't go down network becomes shit.

Bear in mind, 10 years of 2MB blocks = 1TB.

Anyway, damage is already done, block size increase should have happened like 3 months ago, more two months of bad user experience aren't going to do much more damage.

[blunderer]

Well I'm a Bitcoin newbie, but

Lurk moar.

The is yet another useless propaganda post that does not help. The position of Core is very viable and the wanted increase in transaction capacity is coming with Segwit.

The is yet another useless propaganda post that does not help. The position of Classic is very viable and the wanted increase in transaction capacity is coming with 2MB max_blocksize increase.

If ~A is as compelling as A, A is not compelling (teh tilde test).

[franky1]

blockstreams lame rebuttles not to do 2mb

1. 2mb is too much data
debunk: segwits real world data can be 1.5mb-4mb

2. the processing time of handling more transactions is too much for average computers
debunk: 1mb works on a raspberry Pi, so 2mb can work even on a 2005 basic laptop as that is twice the capacity in every way imaginable.. further more we are not in 2005 we are in 2016 so average technology is even better than that

3. segwit offers a better scaling solution
debunk: for about a couple of months until other roadmap feature re-bloat up the data of transactions that segwit first saved.

4. if we implement 2mb the malleability issues will cause further problems.
debunk: if you include the 2mb buffer in the April release (when malleability is supposedly fixed) there wont be an issue

5. but blocks will be 2mb full constantly
debunk: no, miners wont risk losing reward by pushing twice the data out straight away, they will dip their toe in the water in small increments. just like 2013 when there was a 1mb buffer but miners were only making 0.5mb blocks. slowly incrementing as they found a comfortable pace to add more transactions, over years, not days.

6. but there is just no need for scaling.
debunk. well average blocks can only hold 2500tx.. and there is a mempool of over 7,000 growing, just sitting there as they are not getting added to blocks. so there is a backlog that needs to be sorted. its not like the 1mb buffer is sufficient because there are only 0.5mb sat in the mempool. theres many blocks at 0.99mb(at top capacity) and a mempool of 10mb backlog. the only reason blocks are made below capacity is not due to lack of transactions to process. but greed of some miners making empty blocks

7. but if there is no backlog, then people dont need to pay fee's as there is room for everyone
debunk: the block reward is sufficient payment for miners for a couple decades because of the deflationary fiat valuation of bitcoins keeps the valuation high enough.. so fees should have no part of the coding /logistics debate for a long time.

8. gavinsta, toomin, hearne, R3, blah blah blah.
debunk: the 2mb buffer can be incorporated into any client.. yep that includes Core, and the other dozen, so dont twist it into politics. as the code can be used by anyone. if your against the idea just because of who owns a particular client. then put the code into another client not owned by them

[Cconvert2G36]

This is the latest block recorded in your link
399,189    AntPool
   1    208    25 + 0.00000000 BTC    3 minutes ago    0000000000000000066105de87b895cc3d0631838da51af0fa33edee1b61600e

That's 208 bytes in size. How will doubling the blocksize help when miners are submitting these.

It won't. If anything it will make things worse as more miners will want to use this advantage and submit smaller blocks.

Either Lauda doesn't understand... or is barefaced lying to misleading you. Immediately after a block is found, miners will work on an empty block based on the header of the last block while they verify it. After it is verified, they will know all the transactions it contains and can begin working on a block that is full of transactions. Blocks solved in a minute or less after the previous will often always be like this.

The creator of Bitcoin offered a solution to "regularly at the limit" blocks, all bedecked in elegant simplicity:

It can be phased in, like:

if (blocknumber > 115000)
    maxblocksize = largerlimit

It can start being in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don't have it are already obsolete.

When we're near the cutoff block number, I can put an alert to old versions to make sure they know they have to upgrade.

Almost seems a no brainer while scenes like this have become commonplace:

[Amph]

basically the only real argument against the 2mb thing vs segwit, is the hard fork aspect

it seems that last time we had one, people needed many month or years to sync with the other, they remained stuck with the older version....

[franky1]

basically the only real argument against the 2mb thing vs segwit, is the hard fork aspect

it seems that last time we had one, people needed many month or years to sync with the other, they remained stuck with the older version....

even that is a non argument.
as the 2mb buffer only gets implemented if atleast a majority is reached.

but segwits softfork messes with blockchain data, which means some of the current fullnodes wont be fully verifying nodes anymore, and with no witness mode aswell, makes even more nodes no longer holding all the data to allow other nodes to leach off of. so it will affect more users who will need to upgrade, which is the same needing to upgrade for the 2mb..
though its a "softfork", by not upgrading your becoming a limp client... so its not a shiny and glossy pretty picture as blockstream make out

if core simple as the 2mb buffer in their April release then there wont be issues there is no 2mb or segwit.. but 2mb+segwit.. (2 birds one stone, no debate)