Topic: Coinbase CEO disagree with "The Bitcoin Roundtable Consensus Proposal" - page 3. (Read 3879 times)

Yeah, I don't know how segwit will impact the need for bigger blocks but hopefully if the real world impact of segwit isn't what they think and it is needed, they will be open to a hard fork before then. We'll see.

I think it is good to have dialogue even if it is not something we all agree with.  I also agree that July 2017 is a long time, too much can happen by then.

Maybe you should focus on english/portuguese translations.

blockchain.info has 6mill wallets, coinbase has 3.3mill.. i would say to be on a safe bet, lets call it 2million active users that hold some bitcoin. becuase i agree some people make a blockchain wallet for temporary purposes or just to test out some bot scripts and then dump the login.. and as for coinbase not everyone continuously uses bitcoin.

i know personally out of 10 people close to me. all using bitcoin only 1 uses coinbase and only another one uses blockchain.info.. so it could be assumed that the 3-6mill accounts only represent 12% of the population.. meaning there could be 24million+ people... but that again is speculating on a huge scale..

i think 2mill as a safe minimum is a good bet

as for the merchants.. there are actually 120,000 merchants this is because coinbase use to be a USA only and so their merchant push was limited to one country. where as bitpay was international and obviously started earlier. so there are more merchants using bitpay.

Yeah I know all what's going on.
Agreed that the blocksize should be increased soon, so with a 2MB block they would have time to work out something better like the sidechains.
Since miners have the control of how much they want to put on a block the increase wouldn't be much of a harm even with the hard fork.

and many company fake their data as well..

gotta cope with teh investors delusions y know..


but we know they are having cash burning issues.. or is it bitpay?

http://qntra.net/2015/03/coinbase-compliance-chief-resigns/
http://qntra.net/2015/02/coinbase-to-shut-down-tipping-button/
http://qntra.net/2015/09/eyewitness-people-walking-out-of-bitpay-office-in-tears/
http://qntra.net/2015/06/bitpay-continues-to-falter/
http://qntra.net/2015/01/bitpay-lays-off-9-employees-today/
http://qntra.net/2015/03/bitpay-showing-more-signs-of-trouble-no-longer-st-petersburg-bowl-sponsor/

are those genuine data, many user can fake their account easily, maybe with stolen id too, so no have one id request is not a guarantee that those user are genuine at 100%

same for the wallets and the other numbers

you sure it is not 1 BILLION users and merchants?

No one is screwing it up, the discussions must happen and sooner or later blocksize limit has to increase. It's better to discuss it before it is needed so there is enough time for the the community to reach a viable consensus that fits most part of the shareholders.

lol ok here is some maths.. you can even use a calculator
9 blocks of 900,000 bytes and just 1 block of 250 bytes WONT show as an average of 900k.. but an average of 810k
900000
900000
900000
900000
900000
900000
900000
900000
900000
250
810025

so even with 90% of blocks being 900k or more.. the average shows as only being 800k.. actual data vs averages dont show the same result

secondly try to rewind your mind back to 2013. where many blocks were only 450k ... now imagine if the block limit was only 500k.. and core wanted to wait 2 years to upgrade it upto 1mb... for the very same reason you are debating..
now imagine what would have happened to bitcoin if the block limit was only 500k right up until 2015..(last year)
then use that scenario to open your mind to the current situation

I wouldn't call that 90%
https://blockchain.info/charts/avg-block-size

This week most blocks are over 900K, OK, but it will probably come a bit down at any moment. It just keeps going up and down.
Ofc it needs to be increased sometime soon, but it's totally dumb to be "OMG INCREASE IT NOW. ARE U NOT GOING TO INCREASE IT? SCREW YOU, I'M GOING TO MAKE MY OWN FORK OF BTC, GET REKT".

seriously.

your still on the mindset of a doomsday scenario of every block being 1.999mb full as of march 2016 if classic got their way..

what i would like to see is Aprils release of core to have the consensus trigger ode to allow a 2mb buffer. not based on 7 days of data(1000 blocks). as that can be sybil attacked. but 70 days of data, that way its not going to be a big shock of 1 week no consensus then 7 days later mass panic.

over 70 days(10,000blocks) people can estimate that if more than 108 blocks a day(75%) have the indicator. then they need to start thinking about upgrading the code to protect themselves.. if 108blocks a day happen on more then a few days then its time to get their act together.. if 3750 blocks of 5000 (over a month) show a consensus pattern then people really need to stop ignoring it and get their ass together if they have not already. and then if after 70 days and 7500 of 10,000 blocks people have still not moved their asses to protect themselves. then there would also be a grace period. to basically say.. 'look people get ur asses into gear or be left holding clams'..

core delayed adding a buffer for a year. now they dont want to add any code for atleast 6 months and ontop of that delay any potential growth for a further year.. the funny part is that core say there is no need for more capacity buffer. yet they are pushing real hard for segwit, sidechains and offchains for..... the very same reason they pretend does not exist

i personally have not favored classic, xt or bu. i just want more capacity buffer without any corporate ownership.. so try to drop the classic mantra and think of scenarios about the code.

that all said.. addressing your question.. i think the april client upgrade is a great time to have the 2mb code consensus stuff inplace that way its a one time upgrade. rather than trying to endlessly get people to upgrade every couple months.

so yes if there is going to be a hard fork. then yes make all the changes needed that can only be done at the time of a hard fork so that people dont need to upgrade every couple months

Would you agree that if we are going to do a hard fork, it is prudent to look for other issues that may need a hard fork to address at the same time? Classic didn't do that.

My bad - I've been drinking coffee since 5am today. I guess it's affecting me. I meant BIP0009

This document specifies a proposed change to the semantics of the 'version' field in Bitcoin blocks, allowing multiple backward-compatible changes (further called "soft forks") to be deployed in parallel. It relies on interpreting the version field as a bit vector, where each bit can be used to track an independent change. These are tallied each retarget period. Once the consensus change succeeds or times out, there is a "fallow" pause after which the bit can be reused for later changes.

the 2mb rule is not a rule to force miners to make bigger blocks.. its to add buffer space to allow natural growth as and when miners choose to grow,

at 75% it a trigger to say to the world "wake up people, miners want to grow". then that atleast should persuade people to upgrade to protect themselves.. and im pretty sure even with the buffer set miners wont risk making actual larger blocks until an even higher majority as we both agree that its not safe for miners to make bigger blocks at 75% as there is a 25% chance their blocks will get orphaned.

and by you talking about classic. it not thinking about a 2mb rule that ANYONE can implement. and trying to sway the argument into the political game.

so try to have a coffee, wipe your mind of XT/Classic/BU and reset your mindset into an open community proposal that ANY client can implement the 2mb rule. then put that into some of your scenarios

I do run a full node. I run bitcoin-core and that's where most of my coins are. Well most of my coins not in a cold address I always use coinbase.
It is clear to me you have reading comprehension problems. I'm sorry for that.

Most of the time I use a desktop, and that's where I run core. The laptops I have - one is windows 7, too insecure for money. The other is an older Thinkpad running CentOS 7 with only 4 GB of memory, don't want to run a node on it.

I use coinbase primarily to buy and sell.

-=-

If a hard fork happened it needs to be a 95% majority to be safe. 75% like classic wanted is dangerous because blocks would continue to be mined on both forks resulting in coins that are only valid on the particular chain possibly entering circulation.

As has been explained several times, a hard fork is not needed now - the blocks as they are right now often have space left in them. The current delays are not caused by lack of block space.

Waiting with the hard fork is wise as has been pointed out in this thread because it potentially allows other issues to be part of it.

Hard forks should be rare, and really only done when the risk of not doing the hard fork is more dangerous than doing it. That wasn't the case with classic.

yes they are, 90% of blocks are over 900k of data.. the 2mb rule is not something that forces miners to make blocks over 1mb.. its to a a safety buffer to allow blocks room to grow, even if it takes months or years. having a buffer is about allowing growth naturally and at their own pace, not forcing growth.

there is no single bit of code that pushes miners to make 1.999mb so by pretending that bitcoin doesnt need 2mb buffer because there is no need for every block to be 1.999mb is because bitcoin doesnt need to make 1.99mb right now.. it just needs the buffer space to naturally grow without hindrance.

in short the community can now have 2mb rule in place and miners can still make <1mb blocks and nothing will change. the buffer itself is not an issue. just like 1mb buffer was not an issue when miners were making blocks 0.000250mb-0.5mb from 2009-2013

that 1mb buffer allowed natural growth over years without argument or debate.
if you think that block limit buffer should only be expanded to 1.1mb to allow a 10% buffer is just going to cause endless debates and chasing our own tail always trying to get the developers to keep adding more and getting the community to upgrade. which is a headach every couple of months

a 2mb allows 100% extra buffer for growth that atleast gives a few years unhindered growth before the debate has to raise its head again

1. thank you for admitting you dont run a full node
2. you do realise if a fork happened it would be by majority and so coinbase would be part of the majority and so coinbase would be on the safer fork, rather than the laggers not upgrading being left behind.

3. the contention is only caused by people refusing to upgrade. so i agree by core saying they will upgrade there wont be contention.. the problem is that if the rest of the community add a few lines of code before core wants.. then core are not protecting their fanboys by avoiding adding the same code themselves. by core delaying and avoiding adding the buffer. they are the cause of their own contention and ultimately the cause of themselves being left behind if majority moves forward without core.. its a self fulfilling prophecy..

Why the urge to increase the blocksize?
I know that we need it, but we don't need it NOW, most block aren't 100%(or close to that) "filled".

I feel ashamed of Bitcoin looking how a great idea has become a stupid war just because no one agrees with others.

Satoshi did well abandoning his project: now he doesn't have to lead with retards and can say "don't blame me, I started it, but those guys that screwed up".

Well that does make sense. In general computing the difference is usually negligible as we're dealing with small amounts of data.

'BIP6'? I don't see it in the list of BIPs.

Anyone can make such bold claims on their website. I'm going to assume that this is the total number of users that have ever used Coinbase (not currently using).