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

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

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

Questions? [email protected]

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.

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

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.


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


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


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

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.

These two sentences are contradictory.

if mining pools dont upgrade. they wont accept SW transactions..  as told here:
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

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


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?

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

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

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.

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!!

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.

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

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

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!!

No.

Full nodes who have not updated can still safely use and deal with regular transactions and fully verify every economic activity they are involved with.


That's exactly what segwit does


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.

so you admit, that people would need to upgrade and download a new version just to be a full node and stay part of the network...
hmmmm hard fork!