let me guess your gonna kiss gmaxwells ass like last year and start advertising monero as the replacement for bitcoin.

real funny thing about blockstream scripters
complain that only the chinese are making bitcoins but reprogram the fee estimator to give miners more coin(pools dont care about the fee's. its a bonus, not needed income)

pretend to complain about miner control but only give miners the vote (but fail because miners are more ethical and are willing to wait and see what nodes choose)

pretend to care about the community but only implement code changes for benefit of commercial services(only benefits companies wishing to set themselves up as hubs)

pretend to care about the community. yet stunt real growth of bitcoin and then have the arrogance to say bitcoin cant cope.

DCG -> BLOQ -> gavin
DCG -> coindesk
DCG -> blockstream

timing..
craig wright attempt 1 late 2015 - consensus roundtable late 2015
craig wright attempt 2 early 2016 - conference early 2016

remember.. gavin was at a conference when he was interviewed.
https://www.youtube.com/watch?v=pNZyRMG2CjA
 (hint listen to background. he is obviously not at home)

then during this years satoshi roundtable.. yet again red herring drama to talk about craig wright instead of what actually was talked about at satoshi roundtable 2017

first rule of DCG club. dont talk about blockstream or DGC internal talks. instead point to craig drama and let sheep sleep dreaming about craig, not the real CODE proposals and directions bitcoin may move to

im not saying americans hold peso long term. im saying daytrade arbitrage.. resulting in the bitcoin<->peso levelling out

i made good arbitrage trades during the UK-US exchange rate drama of june and october 2016
(june being the brexit drama, october being the IMF SDR drama)

if the mexican peso vs dollar crashes 15-20% you would NOT see the bitcoin price crash that much

you would see a mix of
americans selling bitcoin for peso's to buy cheap peso's
mexicans buying bitcoin from peso's as a better store of value

resulting in not much of a change in price of the bitcoin<->peso price

miners are NOT the rulers.

what you have to understand is blockstream bypassed real consensus.
pools are not stupid enough to produce something that nodes are not prepared for. pools only produce what the nodes will accept. not the other way round. (otherwise what they make is orphaned off and a waste of even trying to make it)

so this is where core has failed with their soft implementation. 60% of pools are undecided because although blockstream allowed the pools to be the sole voters. the pools are still waiting to see what nodes desire.

blockstreams mindset is if segwit activates blockstream will take the glory, if fail they will blame the pools. blockstreams game plan is obvious.
dont blame pools when it was blockstream that decided.

just think about the fake reason blockstream decided that route. and then realise your own reaction. which even contravenes blockstreams fake reason to go that route.

it definetly shouldnt be done. but it can be done.

its not about IP addresses.. its just about identifying block version numbers and having a code mechanism that auto rejects blocks that have a certain version number

your talking about causing an intentional split.

think long and hard about what you want to do to YOURSELF
you are personally wanting to reject blocks and have a different set of data than the rest of the network.. for segwit.(which solves nothing anyway)

yet cry like a baby when anyone proposes a full node consensus that can actually include real fixes(which could include a practical way to implement segwit) which does not cause an intentional split, purely because of fear it may cause a split.

you are basically asking to amputate your leg to pretend your avoiding getting shot in the foot, but the end result is worse then the fear your concerned about.

i think you have been talking to the wrong people selling you scare stories and overselling segwits possibilities.

even activating segwit does not stop worrying about O(n^2) attacks!!
people wanting to cause O(n^2) attacks will still do O(n^2) attacks

wake up to reality.
O(n^2) attacks are only allievated by those using segwit keys.. the thing you need to understand is attackers wont use those keys even after activation. so the problem is not solved.

its like not wanting gun crimes. so you make a law that creates a new voluntary gun shop to open whichs sells plastic guns that fire paintballs.
hoping everyone will buy these guns.
the thing you need to understand is you have not closed the normal gun shops or put rules to force the normal gun shops to close. all segwit has done is effectively say the plastic paintball guns are x% cheaper to use..... thats it

lol oh look someone used cores 2017 script buzzword "conservative" (becoming too obvious now)

seriously the script readers need to spend more time reading code and running bitcoin scenario's rather then script reading "recommended by.."

segwit is not a fix. malicious people wont use segwit keys. they will stick to native keys. segwit solves nothing
the real solution is to let nodes flag what they can cope with and then pools see the node consensus and then the pools make their own pool consensus of what they will produce that the nodes can accept.

as for bloat/spam.
a more effective method is to have a real 'priority' formulae that actually solves the problem.
a more effective method is to have tx sigop limits to solve the issues
a more effective method is to not be kissing dev's asses, and think about CODE solutions

but there is not an infinite amount of problems for you to worry about finite resources.

its like others who dont want bitcoin to naturally grow to 2mb-4mb blocks because you fear gigabytes by midnight(tonight). the reality is that REALITY, REAL WORLD results wont be gigabytes by midnight.

its like not letting a toddler learn to walk because you worry one day the kid when he grows to be an adult will have an accident crossing the road.

your saying prevent optimisation and cause issues out of a worry of something that's not a problem today and wont be a problem,
you seem to be creating a doomsday that has no bases in reality of actually occurring.

im not seeing the big devastating problem your saying dev's should avoid. these days most computers have multiple cores (including raspberry Pi) so if an full node implementation has a '64-bit' release. then automatically you would think devs have already programmed it so that it is already shifts processing resources across the different cores rather than queuing up on a single core.
so the problem and solution should have been solved by just having a 64bit version of a bitcoin full node

100 blocks?
1000 blocks?

um theres only 20ish pools and the chances of them all having a potential solved block all within the same few seconds is small
at most devs and pools have to worry about is a couple potential blocks competing to be added to the blockheight so dont throw fake doomsdays into a narrative,

you dont need to filter out transactions. you just need a better 'priority' formulae that works with the 2 main issues.
1. bloat of tx vs blockspace allowed
2. age of coin vs how fast they want to respend

rather than the old one that is just based on the richer you are the more priority your rewarded(which became useless)

COST OF LIVING

imagine bitcoin was measured as WORLD AVERAGE cost of living.
where say it was 3.758*CoL  and exchanges done orders presented as

sell            buy
3.759 CoL   3.758 CoL
3.760 CoL   3.757 CoL
3.761 CoL   3.756 CoL
3.762 CoL   3.755 CoL

then every country can then use their minimum wage * 40 hours to get CoL and then multiply it by the CoL valuation

EG
UK (£7.20mw * 40)*3.758)= £1082
US ($7.25mw * 40)*3.758)= $1090


or more simply, measured by the hour
150.32 CoL Hours

sell                 buy
150.321 CoLh   150.320 CoLh
150.322 CoLh   150.319 CoLh
150.323 CoLh   150.318 CoLh
150.324 CoLh   150.317 CoLh

UK (£7.20mw * 150.320 CoLh)= £1082
US ($7.25mw * 150.320 CoLh)= $1090

that way everyone around the world has a fairer ability of purchase based on the circumstances of their local area.
plus arbitrage opportunities to use the stupidly hindered countries that abuse their citizens with low cost of living/minimum wage.

EG someone in cuba. can buy bitcoin for $7.52(equiv) and then sell them for US $1090 (raising cuba's standards of living via bitcoin)
and someone from USA can convert US$ for cuban fiat. and buy lots of bitcoin.

which can lead to cuba forced to raise its minimum wage once world arbitraging messes with the banks

maintain it indefinitely..?
a node should function without total reliance on one man to control what nodes do or dont do

if you just stuck to simple rules rather than half baked rules that skip around the issue with half promises im sure you can get some VC funding.

segwit for instance is not a final fix.. its not even an initial fix. malicious users will simply avoid using segwit keys and stick to native keys.

even schnorr is not a solution because again malicious people just wont use those keys. as it serves no benefit for those wanting to bloat and cause issues.

however finding real beneficial solutions such as a new 'priority' formulae that actually has a real purpose and solves a real problem, benefits everyone and knowing your in the pool dev arena.. thats something you should concentrate on

fixed that for you

LN is a separate network than bitcoin.. the hint is in what the N stands for.
though LN grabs the tx data from bitcoins network. the "private agreement" is on a separate network managed by separate nodes (currently programmed in Go, not C++).

no point bastardising bitcoins network for LN when LN can remain its own separate offchain network that only needs to grab bitcoin data once every couple weeks (current mindset of channel life cycle).

LN should remain as just a voluntary second layer service, outside of bitcoins main utility.

why?
why even have "trusted nodes"..
all nodes should be on the same FULL validation playing field.
if you start introducing different layers, you starts introducing hierarchies and 'kings' and power grabbing..

all full nodes should all do the same job, because thats the purpose of the network. they all follow the same rules and all treat transactions the same.

i think you need to go spend some more time researching bitcoin. and start learning how to keep consensus of nodes.. not fragment it.

you do know there is no central mempool.

every node has their own mempool. and as long as a node is not deleting transactions for random non-rule reasons each node keeps pretty much the same transactions as other nodes... including the nodes of pools. the only real varient is if a node has only just been setup to not have been relayed the transactions other nodes have seen.

pools and nodes validate transactions as they are relayed to them. thus when a block is made there is less reason to re validate every transaction over again.(unless they are new to the network to have not seen the relayed transactions. or as has been hypothesised in this thread. where nodes are biasedly rejecting transactions for no rule breaking reason)

sigops
the way bitcoin is moving, most nodes would have pre-validated the transactions at relay. and all they need is the block header data to know which transactions belong to which block. so sigops are less of an issue at block propagation because the validation by most nodes is pre-done.

if we start not relaying transactions then all of a sudden nodes will start needing to request more TX data after block propagation because some tx's are not in a nodes mempool. we should not be rejecting tx's because it will slam nodes later, causing block propagation delays

however we should think about changing something real simple.
the tx priority formulae to actually solve things like bloat/respend spam. where by the more bloated (tx bytes) and the more frequent (tx age) a spend is made. the more it costs.

the old priority fee solved nothing. but was used to just make the richer tx's gain more priority but a small value tx left waiting weeks to get priority.

so lets envision a new priority formulae that actually has real benefit.

imagine that we decided its acceptable that people should have a way to get priority if they have a lean tx and signal that they only want to spend funds once a day. where if they want to spend more often costs rise, if they want bloated tx, costs rise.. which then allows those that just pay their rent once a month or buys groceries every couple days to be ok using onchain bitcoin.. and where the costs of trying to spam the network (every block) becomes expensive where by they would be better off using LN. (for things like faucet raiding every 5-10 minutes)

so lets think about a priority fee thats not about rich vs poor but about respend spam and bloat.

lets imagine we actually use the tx age combined with CLTV to signal the network that a user is willing to add some maturity time if their tx age is under a day, to signal they want it confirmed but allowing themselves to be locked out of spending for an average of 24 hours.

and where the bloat of the tx vs the blocksize has some impact too... rather than the old formulae with was more about the value of the tx

here is one example


as you can see its not about tx value. its about bloat and age.
this way
those not wanting to spend more than once a day and dont bloat the blocks get preferential treatment onchain.
if you are willing to wait a day but your taking up 1% of the blockspace. you pay more
if you want to be a spammer spending every block. you pay the price
and if you want to be a total ass-hat and be both bloated and respending often you pay the ultimate price

yes its not perfect. but atleast lets think about using CODE to choose whats acceptable. rather than playing bankers economic value games of rich guys always win, that way we are no longer pushing the third world countries out of using bitcoins mainnet.