Small blocksize increase should be done first and SegWit second

[Cconvert2G36]

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.

[BlindMayorBitcorn]

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

If you are a miner or a merchant, you should prefer changes to be made via hard forks.

[If you are a merchant] you really want to be sure that a transaction that’s paying you is valid according to the majority, and you want that as fast as possible. That means your node needs to be running the majority rule set. If you get left behind, you can be defrauded. This means you need to know ASAP if you’re no longer in the majority, and you want to ignore transactions that you couldn’t verify.

[Cconvert2G36]

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

[BlindMayorBitcorn]

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

Lol. Oh! mercy

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

[franky1]

if mining pools dont upgrade. they wont accept SW transactions..  

That just tells me you don't know what the hell you're talking about. SegWit, as with every other softfork, is enforced when a supermajority of miners upgrade.

if mining pools do upgrade to v0.13sw. the merkle tree is now 2 not one.

FOR SEGWIT TRANSACTIONS. Regular transactions w/ signature data still contained within original merkel tree still exist ie. backward compatible.

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!

v0.12 full node clients will then feel limp and receiving data they cannot check and so they are forced to upgrade..

Are nodes who did not yet upgrade to a version supporting CLTV also not full nodes because they can't verify related transactions?

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

now in my last 2 sentences.. if mining pools and full node clients are upgrading and mining pools are happy to have more than 1mb of data per block(which they have to be to even allow SW).. we might aswell up the block limit to 2mb and not have to make 2 merkle tree's

backward compatible. nodes who choose not to upgrade will still process at maximum 1mb of data per block.

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

[keepdoing]

Obviously even emergency hardforks had been used in the past where you had update immediatelly, but it created havoc. For acceptable hardfork no one needs to fear (or make argue of fear to prevent hardfork), you need the change in Bitcoin client long time preferrably almost a year before most nodes naturally updates to this version of the Bitcoin client. But obviously even increasing to 2MB is not plan of current Bitcoin devs for 2016, they just pave the way to Blockstream

But how hard would it be to schedule a hard fork for late 2016? I'm pretty sure that almost everyone would upgrade by then and this could be used both to:
1) Increase the block size
2) Remove fear of a hard fork

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.

[ATguy]

Obviously even emergency hardforks had been used in the past where you had update immediatelly, but it created havoc. For acceptable hardfork no one needs to fear (or make argue of fear to prevent hardfork), you need the change in Bitcoin client long time preferrably almost a year before most nodes naturally updates to this version of the Bitcoin client. But obviously even increasing to 2MB is not plan of current Bitcoin devs for 2016, they just pave the way to Blockstream

But how hard would it be to schedule a hard fork for late 2016? I'm pretty sure that almost everyone would upgrade by then and this could be used both to:
1) Increase the block size
2) Remove fear of a hard fork

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.

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

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.

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

[CIYAM]

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.

[keepdoing]

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 here.

Stop thinking politics and start thinking engineering - please.

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. 

[CIYAM]

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

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)?

[ATguy]

Just increasing the block size "does not scale" (keep doing that and you'll end up with blocks with so many txs that actually will take longer than 10 minutes to verify them all).

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

Stop thinking politics and start thinking engineering - please.

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

[CIYAM]

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

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)

[keepdoing]

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

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'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.

[keepdoing]

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

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)

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

[CIYAM]

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.  

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?

[CIYAM]

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

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).

[keepdoing]

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.  

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?

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.

[CIYAM]

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

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

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

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)?

[thejaytiesto]

afaik segwit, it's only an effective 2mb increase as average with a 4mn as a peak, so it would be pointless to do it after a mini increase like 2mb

segwit is an increase of only 1,75 - 2 MB in the mid term and much more complicated than the 2 MB increase.

a 2 MB hard fork (which everyone agrees on and has zero risks / easy to deploy) will at least double the capazity.

funny that we are now at 2 MB and not even then some devs like Peter Todd agree on that. i guess when one or two people can veto against the will of 99%, bitcoin is in trouble.

No hard fork has zero risk, seg wit has much lower risk than 2 mb hardfork. Also where did you get that "everyone agrees" with that? as far as I know a lot of people disagree with that.

[keepdoing]

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)?

Don't be intentionally stupid.  Of course Mike doesn't work for Blockstream.  But politically they are no different is my point.  They both try and shove their solutions down the community throat.   I've made that clear in all my posts and you are just trying to confuse and muddle things.   I've actually come to believe Mike's approach deserves a bit more respect, seeing as how he probably reacted out of utter frustration in dealing with the Blockstream Players.

The Blockstream Players are simply finally being revealed for what they are.... manipulative liars.   It doesn't really excuse the way Mike handled it (basically I just think XT would have worked if he hadn't gotten overly ambitious).

And regarding trust... I basically at this point simply do not trust anyone having anything to do with Blockstream having a Comitt position.