Topic: Small blocksize increase should be done first and SegWit second - page 3. (Read 3493 times)

You should try and be less insulting if you actually want anyone to pay attention to a single word that you say.


If you think that Mike Hearn works for Blockstream then you are rather seriously confused (I think even an 8yo could even work that out).

And if you don't think that Mike Hearn works for Blockstream then exactly who do you trust (as it would appear to be absolutely no-one)?

It is simple enough for an 8 year old to understand....

Keep 1 mb blocks, and the only way that Bitcoin continues to grow is via Sidechain buildout.  All other possible avenues are killed dead in their tracks. 

Of course, Blockchain players then star yapping about "oh, but bigger blocks aren't needed yet - and when they are we will get to it."  Problem with that is that there is already concensus, and Blockstream players are blocking it, so the whole Trustworthiness of Leadership is raised.  The whole conflict of interest is raised.

When you get to a situation like that, investment and development in other directions is stifled because people get nervous when you have unsteady and obviously interest-conflicted leadership.  So that slows competitive process.

So the next stupid argument you will try and drag me into is "specifics".  You'll say tell me "specifically how they gain monopolistic advantage".  But that is so obvious I am not going to get in that mud pit with you, except to say...

By abusing their authority over the engineering decisions made with bitcoin, they effectively limit, delay and cut off funding for competitive strategies, and they increase their own potential customer base by creating an atmosphere of doubt regarding competitive strategies.  I mean - if I am a bank..... what solution am I going to choose?  The one whose leadership actually controls the technology, or one that is at the mercy of their competitor?

And this is why Blockstream Players are forcing a hard fork, or a fiat to arise.  If they weren't acting so blatantly in their own self interests, then others might accept a Bitcoin only path, trusting in fair and open engineering solutions to roll out over time.

But nobody trusts the Blockstream Players anymore.  I don't trust Mike Hearn.  I don't Trust the Blockstream Players.

Bitcoin Governance is currently flawed and doomed on its current path.  It cannot ever be trusted in an as-is setup.

You really ought to learn to stop posting rubbish.

Try and actually "read what people post" before using the FUD word.

You are starting to look like not only a shill but also a troll - so choose your next words carefully if you actually want to continue any dialogue with me (it doesn't bother me one bit to just "unwatch" this topic as I do many such other topics that involve such posters).

You say it is a threat to their plan to gain monopolistic advantage but you don't even explain why - would you care to do that?

FUD.  Lying FUD.  Again, no one is suggesting that we JUST raise blocksize and then immediately stop all other technological innovation.

I'm not the one that made it political.  The fact are the facts.  Again... what technobabble?  

I support Lightning Network, am open to SegWit, but acknowledge that almost universal concensus exists that the block size be raised.  

Yet, Blockstream Players have decided that to follow almost universal majority concensus that block size needs raising is a threat to their plan to gain monopolistic advantage in their minority vision of how bitcoin should develop.  And they are abusing their conflicted interest positions as Comitters to do so.  

It's very simple, and yes it is political, and there is no technobabble needed to understand the concept.

It is really disappointing that I have to repeat myself again but I will:

Just increasing the block size won't scale.

Do you get it yet?

(the question is not about 1MB or 2MB or 10MB but about how Bitcoin can scale)

1 MB is just round number thats why it was choosen, yet many treat this 1 MB as holy unchangable number today.

This number should be whatever the average computer can process/store to keep Bitcoin decentralized, not a fixed number when people have faster computers with more storage and faster internet over a time - the maximum blocksize should exactly follow such average people computer speed ups to keep the same decentralization, yet noone cares and just paving the way to more centralized offchain solutions when I argue there is still room for blocksize increase over time based on average computer speed/storage/internet increases without loosing any decentralization

BTW if your holy number was choosen 256 KB instead in the past, where we would be today - start thinking please

Indeed it is obvious that you are only interested in making this political - so why not just stop posting the technical nonsense then (as has been pointed out to you by others) and just post your political rants.

No need to confuse the newbies with technobabble is there (or is there)?

I cry "FUD!"

NOBODY has suggested limiting other solutions.  NOBODY says sidechains can't continue to exist and be developed and improved upon.  Most people aren't suggesting Segregated Witness might not have a place to help take some load off.  NOBODY is saying to raise the Block Size and then forever stop working on improvements.

The only engineering limitation being put on this is by the BLOCKSTREAM Players.  They want to limit engineering options, thereby guaranteeing the sole  survival of their engineering model.

No - this is political.  It is pretty much purely political at this point. 

Just increasing the block size "does not scale" (keep doing that and you'll end up with blocks with so many txs that it will actually take longer than 10 minutes to verify them all not to mention that internet bandwidth doesn't follow Moore's law).

This has been pointed out again and again but still seems to be (most likely purposely) not picked up by many of the posters here.

Stop thinking politics and start thinking engineering - please.

Here is what Satoshi wrote how to increase block size limit:



So if you put such line in Bitcoin Core 0.12, where blocknumber happens at end 2016/early 2017, by then probably Bitcoin Core 0.14 will be out and most full nodes will be running on Bitcoin Core 0.12 or better so the hardfork will impact only those running today version of Bitcoin Core 0.11.2 or older which will be notified to upgrade near the cutoff block number anyway - not much to fear of such hard fork.

But it needs planning ahead plus the will to follow original Bitcoin project which current Blockstream Core devs have not intentions for

I think everyone pretty much just needs to get it through their head that there is probably going to be a messy, divisive hard fork unless people step up to the plate and come up with an intelligent, fair solution, which also will most likely involve a hard fork, but that can be done with as much concensus as possible.

And I absolutely agree it could be done by late 2016.  I actually don't see a problem with it happening in early/mid 2016.  The solutions are there.  Let's not pretend that there is still some sort of magical line of code that is missing and therefore preventing this.  This is primarily a political issue.   The Blockstream Players are blocking it.  They forced Hearns/Gavin to attempt XT, which at least was an attempt at progress, even if it was overambitious and stupid.

But I want to address THE most important line in the above post....  "Remove Fear of a hard fork."

The problem is not primarily fear of a hard fork, it is the uncertainty surrounding the competency and trustworthiness of those making the decisions.  We can get through a hard fork - all it takes is solid leadership.  The rest is FUD.

so your admitting that it needs everyone to upgrade to work. your admitting something wont work if people dont upgrade.. thank you thats a hard fork!



emphasis on the word FULL.
if its not doing the full work its not a full node. so if a old version cant see, verify, understand a transaction, then its no longer a full node..
the description is in its name .. FULL

i think you need to really stop looking at your bank balance and start thinking real hard about segwit..
its only the SW clients that will store atmost 1mb as they are ignoring the signature merkle..

EG
(by the way dont knit pick numbers, their just examples.. concentrate on the reasoning)
lets say a miner was SW upgraded
lets say a normal tx was 250bytes 1pay,1receive(220 tx data 156 signature)
-----
Input:
Previous tx: f5d8ee39a430901c91a5917b9f2dc19d6d1a0e9cea205b009ca73dd04470b9a6
Index: 0
scriptSig: 304502206e21798a42fae0e854281abd38bacd1aeed3ee3738d9e1446618c4571d10
90db022100e2ac980643b0b82c0e88ffdfec6b64e3e6ba35e7ba5fdd7d5d6cc8d25c6b241501

Output:
Value: 5000000000
scriptPubKey: OP_DUP OP_HASH160 404371705fa9bd789a2fcd52d2c580b65d35549d
OP_EQUALVERIFY OP_CHECKSIG
-----
if all tx were normal it could fit <2700 tx in 1mb.. right
but remember sw promises more transactions per block

so a sw miner sets the tx merkle to 1mb and the sig merkle to Xmb
now the tx merkle can store 4,500tx (tx 1mb/220byte=4500)
but the sig merkle is 0.7mb (totalling 1.7mb for tx+sig)

yea many fanboys will say things are great if as they can have 4500tx's for only 1mb
but regular unupgraded full nodes will have either
blocks being 1.7mb (containing 100% normal tx)
blocks being 1mb but (containing txdata they cant verify as it looks like a pay to script)
or something in between

Lol. Oh! mercy

Edit: imagine someone else said it. Would it still be wrong?

The "author" is an obvious Government Stooge working for the Big Banks... you expect me to read that?

In the article I mentioned, the author suggests miners and merchants should both prefer a hard fork.

A hard fork would break old nodes in an obvious manner. A soft fork would give the illusion that nothing had changed on your old node (even though it had). LukeJr (I believe) is credited with devising some opcode magic to shoehorn segwit in with a soft fork.

It definitely is not. I mean, specifically in the case of SegWit it could be done differently and probably with less complexity with a hard fork. However, usually a hard fork is not the preferred way of making upgrades.

^Why is a hard fork preferable? Is it?