increasing the blocksize in a natural pace, as a dynamic scaled approach where nodes set their limit and consensus forms what the next rise gets to based on what the nodes allow.

no harm can be done if using consensus.
nodes already exist on the networl for the last couple years with their settings at 2-8mb and nothing has gone wrong.. because the blocksize rule is for anything below X.... meaning even 1mb is acceptable.

pools will only move forward making blocks any larger than 1mb when pools see their is no risk of their attempts getting orphaned. so they are not going to be foolish and do something controversial/bilateral.

forget the doom of "gigabyte blocks by midnight" and "servers". because nodes will set the max capacity.

this can be done by nodes doing a 'speed test' that sets a score. or users manually setting the limit. and that score/limit is then inserted as part of the user agent or a few bytes as part of users tx's. so that the network can see whats in majority accepted

there are many many ways to get nodes to know whats acceptable.. the important part is it being consensus.. not bilateral

google: barry silbert blockstream - top answer
Thrilled to invest in @Blockstream alongside a fantastic group of forward thinking global investors

google: barry silbert BTCC

to put it short. the whole list of his 'stakes'/investment
http://dcg.co/network/

barry silbert owns DCG (digital currency group) which then has investment/advisory/chairman board seat demands of many groups
you will see he is the guy behind "consensus 2016"

this is why coindesk is very biased and in favour of companies owned by barry silbert(DCG) because coindesk is ownd by him

then check out DCG hyperledger

barry silbert to bitcoin/blockchain world.. is like rupert murdock to the fiat world

thats where
one guy makes a single TX of say $1 to send to 1000 addresses of $0.001 .. and thats it. game over.

but other spam attacks that cause more hassle long term is where
one guy makes a TX of say $1001 to send to 1000 addresses of $1

then 10 minutes later sends all them $1 transactions to another address combining the funds
then 10 minutes later splitting the funds back to $1..
then 10 minutes later sends all them $1 transactions to another address combining the funds
then 10 minutes later splitting the funds back to $1..
then 10 minutes later sends all them $1 transactions to another address combining the funds

endlessly.
this is when devs think they can mitigate this type of spam attack by raising the fee to make the guy lose alot of his $1000 investment each time he respends.. but the reality is that it just prices ethical/moral people out of using bitcoin less often.

however a maturity lock stops this endless spam without the 'penalty' hurting innocent people

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.