there is still much discussion about "blocksize" and a bit of a cold war between core and classic.

fake is relative, there are real poeple funding these nodes...
its not as tho there isn't support for classic
there is MASSIVE support for classic. ~100.8 PH/s of support
its funny how no one acknowledges that.

i will continue to believe in bitcoin even if it doesn't turn out exactly as i had planned.

second layer solution
on chain scaling.
High fee, low fees
2MB, Segwit.

all completely irrelevant to my belief that bitcoin is far better than fiat.

Core is guilty of having 0 communications with the community.
they are simply unwilling to hear our concerns
they simply dismiss stakeholder wish for swift resolution of blocks becoming full, as short sighted greed. when they themselves are blinded by greed, blockstream.
they simply do not understand what the big fuss is about because of the above reasoning i gave.
there suport will hold indefinitely because the first poeple to GTFO will be those who disagree with their idea. ex mike hearn
so now, everything hangs in the balance as we await the second layer to solve all these problems.

the problem solves itself...

TX that are >72hours old get dropped out of minners mem-pools ( so no the mem-pool will not grow indefinitely )
what will happen is a % of peoples TX will get dropped out of the mempool
fees will rise to the point where poeple no longer want to Transact using bitcoin

problem solved.

 

and thats why i own bitcoin

more or less guaranteed to double in value every few years

once block subsidy runs dry miners will need to turn to TX fees in order to get paid for securing the network.

what should be the the long term plan for TX fees?

this is a fairly big problem.

created by the ill conceived notion that running a full node should be accessible to everyone and anyone at a low low cost.

transacting on the blockchain should be accessible to everyone and anyone at a low low cost, not running its infrastructure..

i can't Believe i have to make this case. 

this is not somthing new i picked up from the other forum
i never expected that devs would make such an effort to keep node requirements low enough to run on a raspberry pi.
in fact i was lead to believe that full node centralization was natural evolution
this was the creator's vision as well.


some node centralization Vs settlement layer prohibitively to expensive to use by everyone
i'll pick full node centralization....

its not like not running a node will prevent anyone from participating in the development or discussion
i'm just point out that by keeping requirements low, makes node count MEANINGLESS
just look at classic nodes, if we go by that metric classic is the favored implementation.
if it cost 1000$ a year to run a node, node count would actually mean somthing.

clearly there is a balance to be stuck between keeping node requirements low and allowing the main chain to grow.

1MB isn't it.

segwit + 1MB is a good start but I want MORE!

also i want to feel as tho the devs are on the same page, they will do everything they can to allow mainchain to grow.

this is all rather complex, let's try to keep in mind this is an incomplete set of pros and cons bound to have mistakes in it.

I should include sources...
this is where i got the idea https://bitcointalk.org/index.php?topic=1398994.msg14211197#msg14211197

i think the idea is that the wtxid and txid and the dupped merkle tree, all have to be there to accommodate the softfork, had it been a hardfork there wouldn't any duplicated data structures in order to allow for backward compatibility

the fact that these data structs are or are not saved to the blockchain is insignificant, they have to be relayed, this is the most costly part. 

thank you knightdk

i will study your post and attempt to correct OP.

hmm we'd have to confirm that... but notwithstanding this attack
there will be twice as many TX included pre block, requiring nodes to process relay and store twice as many TX, just as if we had simply increased block size.


but its cheap like dirt! ( is some cases Free ... )
maybe, it would be OK to increase node requirement such that its no longer cheap like dirt to do a Sybil attack.
by keeping requirement low we are opening an attack vector, and allowing the voice of nodes that matter to be downed out by 1000's "fake" nodes.

more is not always better?

IMO way too much emphasis has been placed on keeping node requirement low. and to ill effect, 1000's of classic node flood the network at the click of a button...

let's see how long i am tolerated.

segwit increases full node requirements just as much as 2MB blocks.
if you believe 2MB blocks will lead to node centralization, then you should come to the same conclusion with segwit.

removing the ability to create a full node on a free AWS server should not be seen as a bad thing.

the discussion about these pros and cons can be found here https://bitco.in/forum/threads/segregated-witness-sotf-fork-segwit-pros-and-cons.986/

i thought i would post this here for more exposure

Pros
________________________________________________________

Effective block size increase
this increase would be about 1.6 MB to 2.0 MB.
as far as relay speeds and network load is considered segwit blocks or 2MB traditional blocks, would cost the same.

Segwit is a softfork
- it hardly qualifies as a soft fork; users & wallets that do not implement segwit and receive funds from a segwit TX will end up with TX they cannot validate.
they should be able to spend the funds even if they dont upgrade they simply see the TX as anyone-can-spend, when infact noly they can spend...
- Segwit allows a softfork by requiring a significant wast of space in the wtxid, it should be implmented as a hardfork.
its only 1kb wasted, softforks are favorable.
- calling segwit a softfork might lead people to believe they do not need to upgrade, confidence in the dev team will drop as these users figure out that it was indeed a mandatory upgrade.
-SegWit is technically superior as a hard fork. Witness proofs would be about 50% or 1,000 Bytes larger, and code would be more complex, as a soft fork.  


Fixes third-party transaction malleability allowing LN and sidechains to be developed .
Possible 66% additional improvement in bi-directional channel efficiency by consolidating channel open and close operations.

Allows the ability to more easily upgrade Bitcoin’s Script language.


Includes fraud proofs.
enables sidechain type contracts.
it does not currently include fraud proof validations and it won't include it even in the first deployment.

fixes which is the O(n^2) hashing problem.
With segwit it is incredibly difficult to produce a large transaction which would require several seconds to a few minutes to verify.

Cons
________________________________________________________

The implementation of segwit is complex and multifaceted
- all the different wallets will need to implement segwit themselves, its unlikely they will all get it right the first time, could lead to some serious loses.
core devs have helped with that by creating a document to explain all of the segwit changes and help developers implement segwit into their code. See https://bitcoincore.org/en/segwit_wallet_dev/

Bitcoin is fairly simply to explain, poeple can trust it because they understand it,  segwit makes understanding bitcoin an order of mangure more complex, which could lead to poeple not trusting bitcoin.


Upon adoption, segwit creates a 4X adversarial attack surface.
miners and network engineers have to design their systems to be able to handle 4 MB blocks without bogging down, but we only get to actually use about 40% of that capacity. This 4x adversarial case will make it very difficult to increase the blocksize limit in the future. With a 1 MB base block size, it's 4 MB, but with a 2 MB base block size, the adversarial case would be 8 MB.


Makes use of an existing feature (anyonecanspend) that was never meant to be used this way.

Introduces a new type of DOS attack (go-fish-wit-ddos)
An attacker mines a segwit-block with 1000 transactions the network has not yet seen (The attacker creates these TX herself )The attacker has the witness data readily available. When other miners try to validate this block they will go through every single one of these TX and say "I don't have the witness data for this TX_ID, I have to call TCP::GetWitnessData( TX_ID ) aw yes this is valid"


Subsidizes signature data in complex/large multisig transactions.
Weights signature data at 1/4 the level of transaction/UTXO data. Signatures are more expensive to validate than UTXO, so this is not justifiable in terms of computational cost.

Increased resource usage (capacity, bandwidth, processing power)


***
Black Text Is a Pro or Con related to segwit .
Green Text Is used to highlight key points which give the Pro or Con more validity
Red Text Is used to highlight key points which debunk or lessen the validity of the Pro or Con



We are compiling a list of some basic pros and cons for segwit softfork. please post below some Pros or Cons for segwit, and discuss them. Feel free to try and debunk the pros / cons i will try and follow the discussion and summarize / post links to these posts with more information. Free feel to ask me to reword a Pro or Con listed in OP for added clarity, please provide full text as you believe it should appear.

In a few month Core will be looking push segwit out onto the network, Its is my hope that this Pro & Con List will help users and miners understand all the specific issues related to segwit. so they can be confident about their decision to accept it or not.

Thank you for your input!

you are not under a sybil attack, until the nodes start misbehaving.
the nodes in question are working perfectly relying TX, working within expected parameters.
all this is an economic show of force by the bitcoin classic community. there is nothing hostile about it.

i think its worth noting segwit will have the same effect on node count as 2MB, it will increase requirement to nodes in more or less the same way.

and i think we can all agree maximizing node count shouldn't be a major concern, classic nodes are popping up left and right on AWS. keeping full node requirements very low, only opens the door to a sybil attack, and makes it easy to drown out the voices of real participants dependent on the system.

if anything the barrier to entry on running a full node should be raised to make it easier to hear the voice of Serious participants, participants that matter like bitpay, bitfinex, or tiger direct.

I"M BACK BABY!!!!!!!!!!!!!!!!!!

so your saying your standards are slightly higher than microsoft's standards

you sure it's not your loyalty holding you back?