SegWit and Hardfork

[zahra4577]

Is there any difference between SegWit and hardfork or is the same term used interchangeably?
What I could researched is SegWit is about removing unnecessary information from block to make more space in a block so that it can accommodate more transaction.Is it right?
What is hard fork than and why we need both (or dont need any)

[fireball4]

Is there any difference between SegWit and hardfork or is the same term used interchangeably?
What I could researched is SegWit is about removing unnecessary information from block to make more space in a block so that it can accommodate more transaction.Is it right?
What is hard fork than and why we need both (or dont need any)

Afaik first of all segwit is not removing the unnecessary information from the block, it would just make the transactions not require the approval from the blocks in order to get confirmed. Basically there would be no need to send the transactions via the blocks and pay the massive fees as they wouldn't get filled as much. Though it should be still possible to send it over the regular way.

What hardfork means is that the blockchain of bitcoin would be split in half. There would be two different chains like it happened with ethereum after the dao attack. ETC (ethereum classic) and ETH (ethereum) was created and one etc is dominated by eth ehat would most probably happen with btc as well, one chain would die off and another would dominate. Though you shouldn't be worried about it as you would get your coins on both chains if you control your private keys. Thus, basically segwit and harfork are two different things, but it is possible that it happens one after another.

If for example on 1st August when the uasf happens for bip 148 and segwit gets implemented via the soft fork (same as hard fork: the code change, but without splitting the coin in two) and after the implementation the nodes that do not support segwit will remain ignoring it, the chain will split in two as well as the uasf nodes will stop accepting the regular nodes that don't tolerate segwit blocks. Thus a hard fork would happen.

Long story short, segwit can help with scaling bitcoin as it doesn't need the miners, hard fork is the change in code that causes the chain split, soft fork change in code that is accepted by everyone thus it doesn't split the chain. We need segwit with soft fork as the  hard fork with chain split would do a lot of harm to bitcoin.

[pawel7777]

Is there any difference between SegWit and hardfork or is the same term used interchangeably?
...

Jesus Christ lad...


In short and simple terms, without technical details:

SegWit - proposed change to the protocol

Softforks/hardforks - methods of implementing changes to the protocol. Softfork - unlikely to cause blockchain split. Hardfork - likely to cause blockchain split. [edit: oversimplification removed to avoid confusion]

You can implement SegWit as either Softfork or Hardfork

[franky1]

Softfork - unlikely to cause blockchain split. Hardfork - likely to cause blockchain split.

sorry pawel.. but wrong

soft AND hard can cause splits.. equally.. (seems you been reading too much of the reddit soft best case scenario hard worse scenario, and then hypnotised to think that is the 'norm' expectation)

soft just requires pools to do something different that 'should'/'may' not cause issues to nodes, meaning nodes dont just switch off... and nodes dont have to do anything different

hard requires nodes AND pools to do something.. this means everyone has to agree to a change.

a healthy hardfork where everyone agrees, thus does not cause a split. as would a healthy soft fork where everyone agrees thus does not cause a split.

but with all the 'pools rejecting/orphaning' opposing pool drama.. soft can have splits too
and with the nodes banning opposing node drama . hard can have splits too.
...

remember if users(nodes) dont get a vote/veto.. dont have to do anything. its soft
but a UA(user activated) is actually a HF...

anyone saying UASF is just using flawed buzzwording to sooth the sheep to sleep. because it requires users nodes to do something which is the definition of hard fork not soft fork

[Rahar02]

Softfork - unlikely to cause blockchain split. Hardfork - likely to cause blockchain split.

sorry pawel.. but wrong

soft AND hard can cause splits..

soft just requires pools to do something different that 'should'/'may' not cause issues to nodes, meaning nodes dont just switch off... and nodes dont have to do anything different

hard requires nodes AND pools to do something.. this means everyone has to agree to a change.

a healthy hardfork where everyone agrees, thus does not cause a split. as would a healthy soft fork where everyone agrees thus does not cause a split.

but with all the 'pools rejecting/orphaning' opposing pool drama.. soft can have splits too
and with the nodes banning opposing node drama . hard can have splits too.
...

remember if users(nodes) dont get a vote/veto.. dont have to do anything. its soft
but a UA(user activated) is actually a HF...

anyone saying UASF is just using flawed buzzwording to sooth the sheep to sleep. because it requires users nodes to do something which is the definition of hard fork not soft fork

Quote for reference.

I'm wondering, how could you know all of those things that you've explain to us in this forum.
You must read and learn a lot of things regarding bitcoin, thanks for share.
So, I want to ask you Mr. franky1 ; what kind of solution that you think could be solved bitcoin problems, about so many unconfirmed transaction and we have to pay high fees? but still, we have to wait for a long time to get it be confirmed.
I'm sorry if you have mentioned and explained it before. Thanks

[franky1]

Quote for reference.

I'm wondering, how could you know all of those things that you've explain to us in this forum.
You must read and learn a lot of things regarding bitcoin, thanks for share.

i have been around for years
i dont browse reddit
i dont browse reddit and then spend months just believing the reddit dribble.. i spend those months others waste, by looking beyond the scripts and learning the inner details. the beyond the smoke and behind the mirrors. the facts beyond the fiction

So, I want to ask you Mr. franky1 ; what kind of solution that you think could be solved bitcoin problems, about so many unconfirmed transaction and we have to pay high fees? but still, we have to wait for a long time to get it be confirmed.
I'm sorry if you have mentioned and explained it before. Thanks

with everyone throwing different split proposals (yep even bip9 does also reject/orphan off pools/blocks)
it just makes logical sense if the blockstream/DCG aka BScartel all envisioning different methods to kill pools/blocks to fake a majority to activate segwit..

we might aswell come to the conclusion.. between august 2017 and late 2018 segwit will inevitably be forced to activate via one split or other as no unanimous compromise can be made using the BScartels multiple bait and switch plans

so lets just skip all the 2merkle block inside a block cludges, skip all the math manipulation and blockcount manipulation.. afterall
bscartel think that a user activated thing can happen between august-november. which debunks their 'it takes 18 months' notion


and so just do a proper 1merkle block full network upgrade.

go back to the 0.12 template.. and then

make the block consensus dynamic during runtime (meaning no more years of dev pleading) with a starting point of 4mb block..

also add/adjust
tx's limited to 4k sigops or less
tx bloat is limited to well well under 100kb
all the other things like thin/weak blocks are added
all the other keypair types like schnorr

and then set a date when it all goes live(far sooner then18 months)

then segwit AND native keypairs equally sit side by side in the same area.

and then have pools do what they have done for years, increment below the consensus limit*

*eg imaging 4mb as the old 1mb.. where pools then incremented within that from 0-0.999(meaning incrementing1mb-4mb)
.. which then when nearing the 4mb, the nodes at runtime without dev involvement decide the new upper limit

that way pools are subject to a limitation empowered by nodes. as a second safety barrier of which NODE capability decides

[Rahar02]

Quote for reference.

I'm wondering, how could you know all of those things that you've explain to us in this forum.
You must read and learn a lot of things regarding bitcoin, thanks for share.

i have been around for years
i dont browse reddit
i dont browse reddit and then spend months just believing the reddit dribble.. i spend those months others waste, by looking beyond the scripts and learning the inner details. the beyond the smoke and behind the mirrors. the facts beyond the fiction

So, I want to ask you Mr. franky1 ; what kind of solution that you think could be solved bitcoin problems, about so many unconfirmed transaction and we have to pay high fees? but still, we have to wait for a long time to get it be confirmed.
I'm sorry if you have mentioned and explained it before. Thanks

with everyone throwing different split proposals (yep even bip9 does also reject/orphan off pools/blocks)
it just makes logical sense if the blockstream/DCG aka BScartel all envisioning different methods to kill pools/blocks to fake a majority to activate segwit..

we might aswell come to the conclusion.. between august 2017 and late 2018 segwit will inevitably be forced to activate via one split or other as no unanimous compromise can be made using the BScartels multiple bait and switch plans

so lets just skip all the 2merkle block inside a block cludges, skip all the math manipulation and blockcount manipulation.. afterall
bscartel think that a user activated thing can happen between august-november. which debunks their 'it takes 18 months' notion


and so just do a proper 1merkle block full network upgrade.

go back to the 0.12 template.. and then

make the block consensus dynamic during runtime (meaning no more years of dev pleading) with a starting point of 4mb block..

also add/adjust
tx's limited to 4k sigops or less
tx bloat is limited to well well under 100kb
all the other things like thin/weak blocks are added
all the other keypair types like schnorr

and then set a date when it all goes live(far sooner then18 months)

then segwit AND native keypairs equally sit side by side in the same area.

and then have pools do what they have done for years, increment below the consensus limit*

*eg imaging 4mb as the old 1mb.. where pools then incremented within that from 0-0.999(meaning incrementing1mb-4mb)
.. which then when nearing the 4mb, the nodes at runtime without dev involvement decide the new upper limit

that way pools are subject to a limitation empowered by nodes. as a second safety barrier of which NODE capability decides

Well, thanks​ for your explanation. It mean you propose;  an upgrade to 4Mb blocksize?
make the block consensus dynamic during runtime (meaning no more years of dev pleading) with a starting point of 4mb block..


Which one from all of those (whether segwit or else which some people/devs have proposed solution (fixed nodes)) that at least close to your opinion franky1? That you think it will going better for bitcoin development.

[franky1]

Well, thanks​ for your explanation. It mean you propose;  an upgrade to 4Mb blocksize?
make the block consensus dynamic during runtime (meaning no more years of dev pleading) with a starting point of 4mb block..


Which one from all of those (whether segwit or else which some people/devs have proposed solution (fixed nodes)) that at least close to your opinion franky1? That you think it will going better for bitcoin development.

all the proposals are outdated.
even the sgwit2mb is outdated.. that would have been acceptable for 2015.. but now we are in 2017 and it will be 2018 before people actually get any utility out of any proposals once activated.. so we need to think about 2018, not just keep pushing 2015 proposals, as they are too late now.

this is why in another thread i said all the proposals are weak. because they all miss atleast one thing and many miss many things the community need right now and soon

[U2]

Uh nope segwit and hardfork can't be used interchangeably but there needs to be a hard fork for UASF to be activated which is another version of segwit if I understand correctly. And yes segwit basically just removes part of the useless stuff from a transaction to try and make it smaller without making bigger blocks. Idk why they don't just go ahead with bigger blocks but whatever...