Maybe I'm wrong but from my understanding of SegWit's BIPs (*) blocks propagation will include also witness data. In fact it's impossible for a full node to validate a block without signatures data, only once validation is performed the full node operator could decide to drop (or keep) the witness data. Before that moment they seem mandatory to me.  

(*) segwit BIPs:
https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki
https://github.com/bitcoin/bips/blob/master/bip-0142.mediawiki
https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki
https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki
https://github.com/bitcoin/bips/blob/master/bip-0145.mediawiki

Despite, as you said, mine is an easy question, still the answer provided is, in my humble opinion, wrong.  

A 2MB SegWit block is equal to a 2MB normal block in terms of bandwidth consumption.

In fact at best of my knowledge full nodes could discard witness data only after having validated a block.

For normal txs relying/validation this is not even possible, txs in mempool will get both base data and wit data (for SPV client things are different, though).

To make a long story short if a full node operator decide to prune witness data after validation step we have a reduced storage consumption. while  bandwidth (BW) usage remain the same.

Isn't BW a more scarce / costly resource in respect to storage?

That said, I suppose my question remain unanswered, doesn't it?  

The relay limitations of all miners are not equal. Orphan risk is unequally distributed based on these limitations, which threatens the viability of groups of miners controlling a minority of hash power = miner centralization risk. See Pieter Wuille's simulation: https://www.reddit.com/r/bitcoin_devlist/comments/3bsvm9/mining_centralization_pressure_from_nonuniform/

What defines "too big?" Without some hard limit that defines this, there is nothing to prevent miners from forking networks.

Being able to drop your bank and use an international currency that has a finite amount...I'd say that's quite a bit.

Can I do that with ethereums?

Bitstamp will be adding ETH soon, a source (a credible one) told me yesterday that the implementation is done and they are just testing and tweaking things at the moment... you know what is funny, I posted this on /r/ethtrader daily discussion and I got so many down votes, one went so far telling me I am trading my books this just gives you a hint about people trading position.

It is. But what I'm often asking myself is not whether Gavin would adopt segwit, but if ...Satoshi would. Would he be pro or against such a change, and for what reasons...

Some will say Satoshi is irrelevant right now, so... but still, I have that question in my mind.

I've yet to see a single person who completely understands Segwit and is against it.

yeah me too,not interest of this debate because i'm not miner but can you explain to me what definetly of Unlimited that support by you?
tell me the detail and dont tell me that was joke

Classic or Core . Be same more or less

808 nodes for a maximum of 213 supporters

its not about the short term implications
short term everyone should be fine with either segwit or 2MB
its the longer term I dont like the sound of. I think LN is a drastic change and may prove to be non user friendly and impractical... ( not to mention not at all "free" its going to cost 2 BTC TX fees to open and close payment channels )

I need to be able to SELL the idea to poeple.
if bitcoin is >1$ to TX on its hard to SELL poeple on the idea... digital money that is expensive to TX feels like broken digital money ( especially when every other alternative, crypto or otherwise, can offer lower fees/TX )


on the other hand, if we go with classic all we get is a theoretical drop in security ( less full nodes ) ( let's not kid ourselves my paper wallets are not less secure due to hobbyist nodes getting forced out of a GROWING ecosystem  )

and i can continue to SELL the idea of truly frictionless money + we also get segwit!!!

thats why we continue to discuss


frictionless money thats the thing we are losing goign with core


we lose the frictionless  part AND we lose the money part

i like these parts and i dont want to give them up so easily

In the US, to pay for healthcare the government steals from every citizen.

A tax on just being alive.

Segwit soon + 2mb fork being scheduled by core = around 4mb blocks during 2017, there's nothing to discuss about block size unless you demand 8mb now.

You should expect more nodes dropping off but not as much as classic.

The 1.8 MB to 2MB Effective capacity increase from segwit places similar but less pressure as raising maxBlockSize limit. The reasons it places less pressure than a 2MB maxBlockSize limit is principally because these 2 reasons in the short term.

1) Average capacity limit  is 1.8MB -2MB , not 2 MB, so less impact.
2) Reducing UTXO growth by making tx cost more that burden the UTXO set . This means that the attack on the network now that has clogged blocks with low txs could cost up to 4x more to accomplish. Too big of a UTXO set is directly what is crashing nodes due to lack of ram and RAM isn't cheap with VPS's.
3) Separating out signatures into a separate merkle tree allows older sigs to be pruned therefore these nodes have less bandwidth and storage needs.
4) Segwit separates out the signing of the input value which allows hardware wallets or embedded devices to function better
5) Removing the quadratic scaling of hashed data for verifying signatures makes scaling linear instead of quadratic on signature tree


Longterm benefits for nodes -

1) Fraud proofs allow more pruned nodes to exist with higher level of security than SPV nodes
2) Fixing Tx malleability is critical to payment channels rolling out

There are other benefits to segwit but these are the benefits to address your concern about nodes. I understand that one criticism for Segwit is that it increases the adversarial attack surface by up to 4x on the 2nd tree which is a valid criticism in it of itself but is out of concept with items 2 and 5 above which are far more of a benefit than the risk of the increased attack surface.

... Gavin's own tests reflects that Classic can have a worst case scenario 60% node drop off rate, and he is fine assuming this risk where most other developers don't like this escalated form of centralization where we already have multiple centralization problems that we need to dig out of.

Your statement was a bit ambiguous , so I answered it with the assumption that you suggested developers stayed with core because that was the only legitimate implementation to pad their resume.

If you are insinuated that Gavin and Garzik aren't Experienced or "legitimate" developers , than I would have to disagree with you. The reason they appear to both work on core and classic is principally because their concerns and values aren't aligned with a majority of other developers. I.E... Gavin's own tests reflects that Classic can have a worst case scenario 60% node drop off rate, and he is fine assuming this risk where most other developers don't like this escalated form of centralization where we already have multiple centralization problems that we need to dig out of.

You are suggesting it is a popularity thing that developers are trying to pad their resume with the "principally important" implementation?

This seems highly unlikely because ...

1) When Developers aren't being paid, they are principally concerned with working on items they are technically interested in or that make sense(are feasible). Bitcoin Core doesn't pay any salaries , and all other sources have no restrictions on what implication to work on , in fact the only implementation to bribe developers to work on it is Classic and perhaps Bitpay's Bitcore(not to be confused with Bitcoin core).

2) Developers aren't idiots , if they really believed in Classics roadmap than they would simply move over , miner would instantly agree as they aren't against classic per say, and than Classic would become the reference implementation with their resume padded on the right one.