Small blocksize increase should be done first and SegWit second

[franky1]

all im saying is that while bitcoin-core can stay the same...

people can if they want less data is download a lite client that ignores data it doesnt need..

but changing bitcoin core, which will mean everyone needs to upgrade to bitcoin-core-sw is a damn hard fork.. and these bitcoin-core-sw would still be storing 1.3mb of data even with a 1.0mb block rule.. which makes the point of the rule useless..

because relaying data that has no signatures will throw up errors for people running older versions of bitcoin-core.. meaning bitcoin-core users would need to upgrade just to see and accept these new blocks..

so it is a hard fork!!

[1715205902]

1715205902

[1715205902]

1715205902

[1715205902]

1715205902

[1715205902]

1715205902

[franky1]

Not true, miners will still push out blocks containing regular transactions which the full nodes who haven't updated can still fully verify.

Segwit does not change the nature of the blocks so as to make it incompatible with older Core versions. That's just plain wrong.

2 merkle tree's instead of one sounds very much like changing the nature of a block making relayed data incompatible with older clients
relaying txdata without signatures sounds like making relayed data incompatible with older clients

older clients that receives a block(with 1.3mb data(with signatures) will throw up an error
older clients that receives a block(with 1.0mb data(no signatures) will throw up an error

in both cases they will orphan those blocks and treat them as invalid. which is a fork! as they would only accept standard blocks..

and if you are going to now say that mining pools dont handle blocks differently.. then that means that there will still be a 4000tx per 1mb limit as always and not the 5000tx potential segwit 'promises'

the only way segwit can promise more transactions is to change how blocks are created and relayed.. which will affect older clients..

[franky1]

so brg444
answer this
will segwit just be a lite client that doesnt change anything for bitcoin-core. but allows people the option to download a lite client that stores only 0.7mb per block
thus not affecting older versions or current versions of bitcoin-core. nor increasing tx/s because miners dont change anything

or

will segwit want miners to upgrade so that they change to 2merkle tree's and store 1.3mb of data, so that they can bait and switch 5000tx per block in the main merkle.. meaning older bitcoin-core users will get errors requiring an upgrade just to be able to accept these new blocks..

[brg444]

Not true, miners will still push out blocks containing regular transactions which the full nodes who haven't updated can still fully verify.

Segwit does not change the nature of the blocks so as to make it incompatible with older Core versions. That's just plain wrong.

2 merkle tree's instead of one sounds very much like changing the nature of a block making relayed data incompatible with older clients
relaying txdata without signatures sounds like making relayed data incompatible with older clients

older clients that receives a block(with 1.3mb data(with signatures) will throw up an error
older clients that receives a block(with 1.0mb data(no signatures) will throw up an error

in both cases they will orphan those blocks and treat them as invalid. which is a fork! as they would only accept standard blocks..

and if you are going to now say that mining pools dont handle blocks differently.. then that means that there will still be a 4000tx per 1mb limit as always and not the 5000tx potential segwit 'promises'

the only way segwit can promise more transactions is to change how blocks are created and relayed.. which will affect older clients..

I'd very much like to answer your questions but you are seemingly so confused I really don't know where to start.

May I suggest reading the BIP? https://github.com/bitcoin/bips/pull/265

You have a fundamental misunderstanding of how it works.

As a soft fork, older software will continue to operate without modification.  Non-upgraded nodes, however, will not see nor validate the witness data and will consider all witness programs as anyone-can-spend scripts (except a few edge cases in version 0 witness programs which are provably unspendable with original script semantics). Wallets should always be wary of anyone-can-spend scripts and treat them with suspicion. Non-upgraded nodes are strongly encouraged to upgrade in order to take advantage of the new features.

[franky1]

As a soft fork, older software will continue to operate without modification.  Non-upgraded nodes, however, will not see nor validate the witness data and will consider all witness programs as anyone-can-spend scripts (except a few edge cases in version 0 witness programs which are provably unspendable with original script semantics). Wallets should always be wary of anyone-can-spend scripts and treat them with suspicion. Non-upgraded nodes are strongly encouraged to upgrade in order to take advantage of the new features.

witness data is transaction info!!!!!

to older clients it would appear as screwed up tx's it cant validate.. meaning old clients will fork because they dont see it as valid..
meaning to stay on the network validating transactions (which is what a fullnode should do) they need to upgrade
meaning its a damned hard fork!! because not upgrading makes old (true fullnodes) become limp and unsecure!!

seriously are you being paid by the guys that want segwit!!

[brg444]

As a soft fork, older software will continue to operate without modification.  Non-upgraded nodes, however, will not see nor validate the witness data and will consider all witness programs as anyone-can-spend scripts (except a few edge cases in version 0 witness programs which are provably unspendable with original script semantics). Wallets should always be wary of anyone-can-spend scripts and treat them with suspicion. Non-upgraded nodes are strongly encouraged to upgrade in order to take advantage of the new features.

witness data is transaction info!!!!!

to older clients it would appear as screwed up tx's it cant validate.. meaning old clients will fork because they dont see it as valid..
meaning to stay on the network validating transactions (which is what a fullnode should do) they need to upgrade
meaning its a damned hard fork!! because not upgrading makes old (true fullnodes) become limp and unsecure!!

seriously are you being paid by the guys that want segwit!!

Segwit is a feature. It is not forced on everyone. If you do not choose to you can still send and receive regular transactions whose signature data is not segregated.

Full nodes continue to validate regular transactions.
Upgraded full nodes validate Segwit data

Happy?

We can't have this conversation if you continue to play stupid.

[franky1]

Full nodes continue to validate regular transactions.
Upgraded full nodes validate Segwit data

Happy?

We can't have this conversation if you continue to play stupid.

full nodes should validate ALL DATA.. this is forcing full nodes to become limp and not full nodes. and to require upgrade to become full nodes again..

its not a soft fork at all..
please stop looking at your increased bank account, look outside the box and realise that its a fork.. that does not benefit any true full nodes as the true full nodes would be storing 1.3mb of data.. instead of 1.. while you SW fan boys tell people its only 1mb

seriously if people need to upgrade just to fully validate.. then you might aswell just raise the limit to 2mb because people that want to be full nodes will be upgrading anyway..

[brg444]

Full nodes continue to validate regular transactions.
Upgraded full nodes validate Segwit data

Happy?

We can't have this conversation if you continue to play stupid.

full nodes should validate ALL DATA.. this is forcing full nodes to become limp and not full nodes. and to require upgrade to become full nodes again..

its not a soft fork at all..
please stop looking at your increased bank account, look outside the box and realise that its a fork.. that does not benefit any true full nodes as the true full nodes would be storing 1.3mb of data.. instead of 1.. while you SW fan boys tell people its only 1mb

seriously if people need to upgrade just to fully validate.. then you might aswell just raise the limit to 2mb because people that want to be full nodes will be upgrading anyway..

You can continue to fully validate whatever transactions you are involved with as long as you don't need to deal with SW.

If you must receive or sent transactions involved segwit than you upgrade.

The security model is exactly the same for full nodes who don't upgrade

[johnyj]

IMO, the biggest difficulty for SW to be adopted is its complexity

Some ideas are easy to explain but hard to execute. Other ideas are easy to execute but hard to explain. Segregated witness (segwit) seems to be the latter.

Ok it is very easy to write the code and implement it, but to convince the users to use your client is totally another story. Since SW is so difficult to explain, majority of users without enough time to dig into the slides and codes for weeks will just ignore it and take the simple approach of raise the block to 2MB

If you are operating a million dollar worth of mining farms, are you going to risk your investments on a set of not-time-tested new architecture which even the author have difficulty to explain to you how it works?

[franky1]

IMO, the biggest difficulty for SW to be adopted is its complexity

Some ideas are easy to explain but hard to execute. Other ideas are easy to execute but hard to explain. Segregated witness (segwit) seems to be the latter.

Ok it is very easy to write the code and implement it, but to convince the users to use your client is totally another story. Since SW is so difficult to explain, majority of users without enough time to dig into the slides and codes for weeks will just ignore it and take the simple approach of raise the block to 2MB

If you are operating a million dollar worth of mining farms, are you going to risk your investments on a set of not-time-tested new architecture which even the author have difficulty to explain to you how it works?

if mining pools dont upgrade. they wont accept SW transactions..  as told here:

You can continue to fully validate whatever transactions you are involved with as long as you don't need to deal with SW.
If you must receive or sent transactions involved segwit than you upgrade.

and users of SW will drop it and go back to bitcoin-core v0.12 instantly because their SW tx's are not being accepted and validated

if mining pools do upgrade to v0.13sw. the merkle tree is now 2 not one. and the data bloat for mining pools is 1.3mb not 1.0. (which negates the point of the 1mb)
v0.12 full node clients will then feel limp and receiving data they cannot check and so they are forced to upgrade..

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

the SW fanboys are underselling the impact and overselling the features.. just for a 30% possible reduction for liteclients (but 30% increase for full nodes)

there are easier ways to increase the blocksize and implement malleability fixes. which if people need to upgrade.. should be done properly.. not this half assed manipulation that is only a temporary fix..

separately, lite clients can still save data by simply not saving signatures when they put it on their hard drives.. which should be a local decision for that lite client.. not a network decision

[Cconvert2G36]

-snip-
If you must receive or sent transactions involved segwit than you upgrade.

The security model is exactly the same for full nodes who don't upgrade

These two sentences are contradictory.

[LiteCoinGuy]

IMO, the biggest difficulty for SW to be adopted is its complexity

Some ideas are easy to explain but hard to execute. Other ideas are easy to execute but hard to explain. Segregated witness (segwit) seems to be the latter.

Ok it is very easy to write the code and implement it, but to convince the users to use your client is totally another story. Since SW is so difficult to explain, majority of users without enough time to dig into the slides and codes for weeks will just ignore it and take the simple approach of raise the block to 2MB

If you are operating a million dollar worth of mining farms, are you going to risk your investments on a set of not-time-tested new architecture which even the author have difficulty to explain to you how it works?

i agree.

Sipa has even agreed (on IRC) that the closer short term (2016) numbers are around 1.25 with soft fork adoption rates based on historical data, NOT 1.75x. 1.75x is a assumption of 100% adoption including all wallet providers, exchanges, PSP's upgrading to support SW style transactions, which we can all agree is not going to happen in 2016. Its going to take 6 months to code, test and deploy IF we are lucky, which puts us at 2017 before 100% adoption occurs.

[brg444]

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.

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?

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.

[ATguy]

One of the main problems is that people (especially some of the developers) are afraid of a hard fork. I have no idea why that is. If there were warnings pretty much everywhere about the required change (incl. alert system), I'm pretty sure that we would come close to 99% of clients upgrading to the next version. I always wondered why they don't bump it up to 2 MB or something and then proceed with their roadmap.

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

[MyBTT]

Yes, the blocksize things seems to be a neverending issue, although in most people's eyes it does not seem as complicated and the majority advocates the blocksize rise.

People continue to make such a big deal about the block size. Our opinions aren't going to change anything. The person or company that made Bitcoin, will decide what to do about the block size. The 1MB block size was put in place to stop spam and to increase the security of Bitcoin. Why fix something that isn't broken? It is fine as it is, we don't need to change it.

[Cconvert2G36]

Yes, the blocksize things seems to be a neverending issue, although in most people's eyes it does not seem as complicated and the majority advocates the blocksize rise.

People continue to make such a big deal about the block size. Our opinions aren't going to change anything. The person or company that made Bitcoin, will decide what to do about the block size. The 1MB block size was put in place to stop spam and to increase the security of Bitcoin. Why fix something that isn't broken? It is fine as it is, we don't need to change it.

Questions? jobs@blockstream.com

[Lauda]

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

[Cconvert2G36]

If I may...

Yes, the blocksize things seems to be a neverending issue, although in most people's eyes it does not seem as complicated and the majority advocates the blocksize rise.

People continue to make such a big deal about the block size.

Lots of people want to be able to use Bitcoin and hope to use it more in the future.

The person or company that made Bitcoin

*Pretending you didn't say that.*

Why fix something that isn't broken? It is fine as it is, we don't need to change it.

Doing nothing is still doing something, and it could price a bunch of potential users out too early.

And here's why soft forks aren't really forks.

Am I wrong?

Well they're definitely forks... with something like segwit, not so soft unless you upgrade just like you would preceding a hard fork.

[BlindMayorBitcorn]

^Why is a hard fork preferable? Is it?

[Lauda]

^Why is a hard fork preferable? Is it?

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.