Understanding Segwit ( Segregated Witness )

[adamstgbit]

here's a great place to start if you want to get a high level view of what Segregated Witness actually does.

https://letstalkbitcoin.com/blog/post/lets-talk-bitcoin-277-separating-signatures-with-segregated-witness

start 3:00mins in, to skip the intro.

then skip more bla bla bla, and go to 15:45

segwit will add Versioning to Bitcoin Script Lang! goto ~45:00mins in.

 

[AdrianX]

I'll just leav this here.

@dlareg

the easiest way to think about the math is that all assumptions flow from what a core dev central planner really believes is the maximum blocksize "relay-able" across the network despite what they have been claiming over the last year; that blocksize which he believes the network can handle w/o excessive orphaning. in the SW case conceptualized by pwuille and gmax that Magic Number is now 4MB! WTF happened to 1MB? anyways, once you fix that number, then you determine what actual blocksize you want permanently embedded in the blockchain as storage; in this case they want to keep the established 1MB to allow for a SF so that old nodes simply cannot refuse to adopt SW tx's. nvm that their security will forcefully get downgraded to ANYONECANSPEND SPV node levels where you can't check the validity of txs coming through your node. so to get from 4MB down to 1MB you need to multiply by 0.75 0.25; that's where the 75% discount comes from. hence the formula, a+b/4<=1MB. they could've just as easily said they believed that the maximum blocksize relay-able by the network is 2MB, then they'd have to multiply by 0.5 for a 50% discount, or a+b/2<=1MB. Or even a+b<=1MB and no discount; but that might be too fair to people wanting to do normal p2pkh txs. Can't have that.

in any case, these discounts preferentially favor/promote LN multisigs since they by definition involve larger, more expensive signatures. Blockstream knows that to get ppl to use LN, they need to offer them something; like a discount for the larger more expensive signatures required to setup a payment channel. otherwise ppl might not use them since most tx's are charged based on satoshis/byte. plus, they have to pull the wool over the eyes of miners and full nodes by obfuscating the fact that they will have to transmit all this extra signature data at a discount by telling feeding them bullshit like they get to consolidate the UTXO set at a discount (!) and that a functional LN will afford them 100x the current tx fees that they are currently getting. lol.

 

[adamstgbit]

segwit is a monstrous update thats for sure.
just because a fork is "soft" doesn't mean it won't change things drastically ( if widely adopted ).
all it means is the code is backward compatible.
[doublepost=1458067386,1458066677][/doublepost]softforks are way more dangerous than hardforks!

say the softfork is believed to be fully backward compatible and then once it has 20% adoption, bitcoin forks off , and devs are like "oh shit thats right we forgot about this extremely special case in which its NOT backward compatible" altho we can recover from this, it would hurt.

this actually happened once, Bitcoin0.7.x had some code that was wrong, network forked off, we had to go back a version and rebuild the blockchain a bit. everyone's TX got included in the reconstructed blocks, it was amazing to watch all this happen, but avoiding these situations would be best....

 

[adamstgbit]

I just learnt that segwit will have the same 75% need to agree to accept to be activated.

it's a sotf fork that they are treading like a hard fork.

thats goooood.

 

[Cconvert2G36]

There's nothing soft about changing how the entire protocol works via a handful of mining pool operators activating it while the entire node network is blissfully unaware anything has happened.

 

[jl777]

segwit is NOT backward compatible!

nodes that dont update will be able to receive payments, but they wont be able to verify or spend them.

doesnt anybody see what a disaster that would be? It basically forces the entire userbase to upgrade to this "softfork", or have incompatible bitcoins.

 

[adamstgbit]

There's nothing soft about changing how the entire protocol works via a handful of mining pool operators activating it while the entire node network is blissfully unaware anything has happened.

maybe it should be call shock&awe fork

 

[dlareg]

Here is a great post by Jonathan Toomin on Reddit explaining the 4X adversarial attack surface that segwit creates upon adoption and forever into the future. Basically an "accounting trick" which gives a "tax subsidy" for Lightning and sidechains.

 

[jl777]

SEGWIT WASTES SPACE PERMANENTLY

https://bitcointalk.org/index.php?topic=1398994.msg14211197#msg14211197

And on route it totally breaks bitcoin as any wallet that doesnt update wont be able to validate or spend the segwit wtxids.

It is a hardfork pretending to be a softfork that avoids a hardfork

 

[Lee Adams]

Where is the rollout (e.g. 75%/95%) of soft fork seg wit documented? Why isn't in the FAQ?

 

[sickpig]

@Lee Adams

the last 2 succesful soft-forks BIP66 and BIP65 both have this deployment strategy: new rule in effect when at least 750 out of 1000 blocks has the new version. When 950 out of the 1000 blocks block produced with older version become invalid.

https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki
https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki

the same is valid for BIP141 (aka SegWit)

https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Deployment


edit: better english (maybe)

 

[adamstgbit]

Core will deploy segwit in a minor release (0.12.x)

 

[Chronos]

segwit is NOT backward compatible!
nodes that dont update will be able to receive payments, but they wont be able to verify or spend them..

Isn't this a non-issue, because nodes that don't update won't ever generate a "segwit payment address"? They would always receive payment through standard p2pkh addresses. Or is this not correct?

 

[jl777]

it was clarified for me that you need to generate a segwit address to receive funds to, so unless you generate such an address without having segwit node, you are correct this wont happen.

but no node will be able to mine any blocks with any segwit inputs unless it is a segwit node, but I was told that is standard for any softfork.

so the upshot is that segwit doesnt save any space, in spite of the marketing of it as a way to get more tx capacity and a 2MB hardfork is getting fractionally more tx capacity without any of the complexity

It has yet to be seen what attack vectors the more complicated setup creates

 

[freetrader]

Nothing like reviving an old thread.

I'd like to clarify exactly when SegWit implementations start emitting witness blocks onto the network. I can't really find a clear description of that in BIP141, so I've opened this thread:

Correctly understanding SegWit activation in relation to BIP9