i edited your post to show another thought you should also be thinking about.. why btcc was instantly waving happy flags for segwit.. even before actually peer reviewing and making their own node that had the rules set in october

but imagine it this way. instead of 100 addresses sending out and respending every 10 minutes. they have to wait an hour.
imagine if they tried to respend right at that 6th block. the next maturity is 2 hours..

where as everyone else that only spends once or twice a day, or week or month never gets maturity locked out, because it matures before they need to respend. but know they can respend because the waiting time is AFTER confirm.. thus they know they have been paid. instead of the current setup that delays due to spam leave them waiting before confirm and unsure if they will be even paid..

thus ethical people can spend when they want and malicious people are ending up having to wait.. and its all done by code rules.. not 'fees'

yep LN for instance..
when withdrawing out of LN (settling) even when the settlement tx is confirmed LN want to have a 3-5day maturity (CLTV) where funds are unspendable. that way it still gives the other party 3-5 days to take the funds back as a chargeback (CSV revoke).
other penanties exist while inside an LN contract, which all LN contracts need second party authorisation. LN is paypal2.0 once people start pricing up the internal 'hop' penalties/fee's and start using hubs to decrease the penalties/fee's.

learn about RBF double spends
learn about tx drop offs.

no one should trust a zero confirm tx

learn about CSV chargebacks
learn about orphans

no one should trust a immature confirmed tx

only if you are spending a small amount should you risk accepting a tx 'as paid' as soon as seen.. but the tx fee has priced small purchases out. so the risk exists because we cant spend micro amounts to not care about risks

no.. under 95% of nodes just increases the orphan risk. which eventually sorts itself out.. the lower the % the longer and more headache the orphan drama persists. until one chain is ahead leaving minority nodes unable to sync

only an intentional split. (banning the opposing side) which then avoids each side from seeing the blocks to see the orphans. is what causes 2 permanent chains alternate. by avoiding using consensus


agreed that LN will cause issues if that is the only end goal core devs want to aim for. LN should only be treated as a voluntary side service.. not the end solution

yes an intentional spam attack is when one entity is respending funds as soon as it confirms..
there is no logical reason to respend so fast.

this kind of thing could be mitigated by having transactions have a 1-6 block maturity after confirm. instead of using 'economics' to cost people out of utility.

that way the code protection of spamming harms less innocent people while actually reducing the malicious parties.
but hey the devs decided to do what banks do best. charge people more rather then have proper safeguards for protection. (they are doing the same stupid economic mindset in their LN project too.. avoiding using real code protections and instead letting economic penalties dissuade malice)

firstly you need to learn the difference betweent soft and hard. and the the subcategories of each.
many people talk about the best case scenario of a soft. but the worse case of a hard.. but they avoid talking about best case of hard when yapping about soft.. and avoid talking about worse case of soft when yapping about hard.

so here it is

softfork: consensus - >94% pools no banning of minority. result: small 5% orphan drama then one chain. minority unsynced and dead
softfork: controversial - >50% pools no banning of minority. result: long big% orphan drama then one chain. minority unsynced and dead
softfork: bilateral - intentionally ignoring/banning opposing rules and not including them. result: 2 chains

hardfork: consensus - >94% nodes, then >94% pools no banning of minority. result: 5% orphan drama then one chain. minority unsynced / dead
hardfork: controversial - >50% nodes, then >50% pools no banning of minority. result: big% orphan drama then one chain. minority unsynced / dead
hardfork: bilateral - intentionally ignoring/banning opposing rules and not including them. result: 2 chains

ultimately the only difference is do you let the nodes get to vote first(hard), or just the pools(soft)

now that is explained.. rationally the community want the consensus.. and to ensure it works without issue hard is more secure.. the only issue with hard is that its a double vote, which takes time.
yep core hoped to get it activated by christmas by going soft. but they didnt factor in that pools wont jump at something without being sure that the network can take it.

so concentrating on the consensus, remember this.

if pools are not sure that nodes can handle a change, then pools will be unsure to show desire for it..
this is where soft consensus failed. because while the nodes dont actually vote.. pools still for pools own confidence and reassusance privately look at the node count, before deciding.. and with only a 50% node count.. only 25% of pools have show desire for segwit..

now if it was hard (node vote first, then pool vote second) the nodes have to reach target before pools even need to decide.. so that would actually give pools the confidence much faster.

P.S dont meander the topic into the doomsday of bilateral(altcoin creation).. no sane person has proposed a change that is bilateral. apart from a particular core dev who has demanded non core devs to bilaterally split off,to which they refused. so no need to even try shouting the doomsdays of bilateral (altcoin creation)

/Satoshi:0.13.1/   1502 (26.84%)
/Satoshi:0.13.2/   1168 (20.87%)
/Satoshi:0.13.99/     119 (2%)

nodes: under 50%

try not to include old nodes pre october 2016.. they are not segwit..

pools: 24%

and this is why people should not be sheeple, idolising any particular people and treating them as kings. trying to get other devs to run away to only give power to a few devs.

because when they go, they are gone.

bitcoin needs to be diverse have multiple implementations and multiple open platforms.
not a centric one circle of 12 corporate paid devs and 90 interns hoping for a job if they show blind loyalty to the paid devs.

but multiple implementations and many teams all working in consensus. that way if one falls away there's still diversity and openness.

if all you care for is the fiat price then your end game is to return to fiat.
i guess bitcoin ethos has been missed by you.

the price can move.
but bitcoin (mainnet) utility has to stop being halted by those wanting large fee's to pressure offchained permissioned contracts. as thats erroding bitcoins ethos.

if people are locking funds into LN contracts with:
CLTV(after confirmation maturity (analogy: 3-5 business day funds unavailable))
CSV(after confirmation revocation (analogy: chargebacks))

people will not see the benefit of bitcoin because it ends up doing what banks do.

my mindset is to not idly sit on my hands hailing people as kings. but to test and check things out and know the risks.

devs should have more critical minds.. like the old
"punch holes in it to see if it breaks"
"hack it and fix the bugs until it cant be easily hacked"
"treat it as broken until you have kicked it a few times and it still stands up"

i see too many glory utopian dreamers, and not many critical thinkers.
i see too many people protecting the devs instead of protecting the network. even going as far as messing with their network connections to give glory to devs (like the jetcash example)

well w already know the blockstream camp exaggerate their devotion.. people are actively banning and ignoring nodes that are not part of cores group of nodes
EG

so left image was the utopia expectation of segwit being the (upstream) gatekeepers getting the full data from pools and the sending stripped blocks to old nodes.

the right is the vision which includes the blockstream fanboy phsychy of intentionally blocking anything not core.. as exampled by some naive people

left = no biased connecting
right = biased connections )where the pools are left to do the sending of stripped blocks to old nodes)
          (bar a couple purple lines between new and old i didnt add)

id let old nodes connect yes.
i just hope the POST-activation release has whitelisting turned off so it auto connects to anything and not having it secretly set as on. and needing those that like to tinker, to have to manually whitelist old nodes or disable whitlisting so that it becomes not biased
whiles those that dont tinker, dont realise they are biased by default

i asked you a genuine question before..
when (if) segwit activates, are you going to whitelist old nodes or just connect to segwit nodes and leave it for pools and others to send stripped blocks to old nodes.
be honest. (i dont mean to ask negatively or in any attack i just want an honest open answer)

i do talk about the tech, but if i mention someones name suddenly the topic meanders into "defend the leader" spam posts, where the tech and explanations get sidelined.

maybe also best that you dont defend the leader and waste time posting stuff unrelated to the tech and spend time reading the tech stuff.. thus everyone benefits.

https://www.huobi.com/?lang=en
still working.. still trading

guess bitcoin wisdom lost connection

http://bitcoinity.org/markets/huobi/CNY
guess bitcoinity lost connection too..

seems there is an API/bot issue.

maybe they stopped API due to DDoS.

edit
checked again
https://www.huobi.com/?lang=en

there is live trading occuring but slower than usual.. im guessing the bots got shut down.. maybe now we will see what real manual trading looks like for a while

edit
seems as 18 hours prior to this post, their live trade volumes have significantly dropped. usually they average 500btc-8000btc each 15min count... but each 15min count for the last 18 hours has been at best 400btc and as low as just under 20btc.

if they have done the research they would rebuttle with actual lines of code and actual scenarios. they would quote the context in a honourable and meaningful way..

but.. all i see is
rule 1: dont talk about segwit
rule 2: dont talk about leaders of segwit
rule 3: flame anyone negatively talking about segwit
rule 4: flame anyone negatively talking about segwit leaders
rule 5: just vote for segwit blindly

spend more time researching bitcoin and understanding it. and less time screaming insults to defend someones name.

the orphan consensus.. vs just rejecting blocks due to who made it. leaves segwit only seeing one chain of blocks and making their own blockheight. where other nodes make another chain of blocks without bias and ultimately having a higher blockheight. because they are not throwing blocks aside

consensus is where the network as a whole end up with just one chain of blocks of the same height

blocks should only be rejected if they have bad data. not because of 'brand bias'.

try running a scenario where gmaxwell mentions purposefully orphaning off opposing blocks..
and see what happens when you start banning certain pools as if they dont exist and then compare the resulting chains segwit see's to the chain the rest of the network see's. it will surprise you.

simply put: if there were this chain of blocks,
ADEBFADBECADEBFADBEC

imagining C is the opposer
legacy sees: ADEBFADBECADEBFADBEC
segwit sees: ADEBFADBE  [halt, unsync from network]

segwit stalls. because the A has a 'previous hash' of C which segwit refuses to recognise. so segwit cant accept A.. or the following blocks after that..

so now segwit pools need to make a block thats has a previous hash of E
and now the chains diverge..