wait for who/what

oh for bitcoin to grow legs and a voicebox and walk into your local store and have a word with the manager..

remember YOU being here having bitcoin makes YOU part of bitcoin. if YOU want YOUR local store to accept bitcoin YOU and people near YOU and YOUR local store need to be the arms and legs and voicebox for bitcoin.

bitcoin protocol is just code. not a sentient being.

i done my part i can buy food pay bills etc and helped a few businesses and individuals with bitcoin. i havnt needed to look at my fiat bank balance since 2012-2013

if everyone done something in their area the butterfly effect would see faster results.
if everyone sat on their hand waiting for bitcoin sentient protocol to do it all....... well.. you can wait as long as you like

they would actually creep up in increments, thats the smart thing. (as the 500k berkely locks/levelbdb upgrade drama has taught the community)
they done so in the past.(policy.h v0.7 0.5mb, policy.h v0.8 0.75mb, now 0.999mb)

but here is where your missing a few idea's

moving at say 250byte a block increments, means they can reasonably safely get to 2mb in about a month.
so it wont be 2mb activation day .. and it wont be 2mb by 2020 by being slow about the increments.

250byte per block increments = 4 weeks-ish
500byte per block increments = 2 weeks-ish
1kb per block increments = a week-ish

they may even once say the first few blocks above 1mb havnt caused issues. increment it in 0.25mb increments. taking possibly a day or less to get to 2mb... but one thing is for sure they wont just jump to 2mb straight off. they will see if there are unknown bugs/orphan risks etc

so not that long when you think about it

i think im going to drive your mind crazy now.. sorry in advance

5% of pool consensus of blocks does not mean 5% hashpower.
5% of pool consensus of blocks does not mean 20x longer to make a block once going at it with 95% less competition...

save re-writing it

ok im gonna take a break.. (brain switched off in 3.2.1)

in the post from like an hour ago which u revised

actually it can.

an altcoin can be made by just 1 node deciding it wll do its own thing if it wanted to.
an altcoin can be made by majority banning and splitting that last 5% minority will do its own thing if it wanted to.
an altcoin can be made by the last 5% minority banning and splitting themselves do its own thing if it wanted to.

but then that minority have to ask themselves is there a good enough reason to try keeping it going.

(so many scenarios running through my mind.. kinda hard to summarise it all)

a few things we are sure of
1. BU and other lik minded peers wont trigger unless safe majority of node and pool (no threats, no time bombs, no blackmails. just plod along and let nature handle it)
2, core will have the triggers, time bombs and threats and could trigger while things are contentious, forcing the issue or at consensus. but its core rocking the boat more than anything else

still too early to tell

its not a simpl "hash wins"

it is about nodes, network confidence of majority nodes and also which merchants allow deposits of it.

funny part is..
by the exchanges saying they will accept bu (and if controversially call it BTU/BCU or consensus call it bitcoin and segwit BCC/SWcoin)
they are actually helping BU and other dynamics to be accepted as "the bitcoin" in a majority event
remember BU wont trigger itself unless it it has the 3.. hash, nodes and merchants.

other matter is.
BU is just one implementation. if a base blocksize limit movement trigger does occur. many implementations(classlic xt) would work with it.
core is just one implementation. if a segwit block trigger does occur. many implementations(btcc, knots) would work with it.

so its not strictly a BU event or a BU chain.. its more of a

dynamic peer vs segwit tier
rather than
bu vs core

but thats just confusing the matters more.

i removed this line:
If BU survives and the minority chain dies off, BU transforms from altcoin into "Bitcoin".
because if BU had majority. its already bitcoin along with the other implementations (where segwit is the altcoin or just dead)

theres still some irregularities even with the FTFY summary. due to when/if core triggers their bip9/UASF/PoW change, and which markets treat it as such. and as highlighted if there remained 2 chains or not. or the opposing implementations give in to join the peer or tier network
but its close enough

a fork is a different path.
it does not mean it has to survive more than on block. it does not mean it has to live on forever. it just means a different path has opened up

orphans are where forks are killed

lol by the time an announcement to get people to revv up their own GPU's occur. the big companies will already have new blueprints of a next-gen ASIC that will dominate any new algo.

they can be back in business at the top again before a PoW change activates.

i do laugh though
"blame china"
"blame jihan"

...
nah. blame core for intentionally going soft and giving pools the vote where by 58% are not even jihan

if core went hard(node then pool) by actually involving the nodes the confidence boost of nodes being ready would make more of the 58%-74% vote towards it.

pools simply wont vote for anything to any high degree unless they know nodes will accept that change. core shot themselves in the foot by avoiding that confidence logic.

bitmain forking off at 16%.. im laughing
plase learn consensus.. strangely in the last 48 hours i thought you were starting to grasp it.. now your talking about controversial and bilateral splits
why would a pool do that at just 16%.

hell while we are at it.. why would/wouldnt BTCC/bitfury do the exact same thing... (putting shoe on other foot)


or just do a core. and not listen to the community. and instead bribe(fee discount), blackmail(BIP9/UASF) and threaten(PoW along change) to get what only core desire.. and stand their ground point fingers at everyone else playing a victim card

if core actually took a step back and thought.. hmmm voting isnt going well. lets try something that the community might accept. then things could move forward.

having different implementations actually can help increase the odds of something happening

your trying to ask a question about chain of events,

but its not a 2 answer question.
also we can speculate all day long about will core actually pull the trigger to their bip9 early(possible) if they would UASF or even PoW banish.

without knowing if core will trigger it at say dynamic vote of under 50%... or wait for things to get very threatening for core by waiting for majority on dynamics side of 75%-95%

the chain of events can alter

no.. im saying
there are 3 possibilities.. well 6 in total of what happens.
depending if its consensual (one chain all agree, opposer's just left dead in the water unsynced)
or controversial they dont agree but they fight it out with orphans and swapping chains drama and headaches and double spend risks etc
or bilateral, by ignoring and thats when there is 2 linear nonfighting chains

as i said too many people just take soft and only mention softs best case.. then take hard and only mention hards worse case


it all depends on circumstance there are 6 possible results.. not 2


dependant on whats been changed. yes while the POOLS(soft) are either endlessly fighting or going separate ways
the non-mining nodes could also be in the orphan drama or just not getting relayed anything.. leaving them stuck and unsynced.

like i said for months.. its not a simple yes no answer multiple things can occur.

but based on BU refusing to bilateral split and only want consensus.

if BU got consensus.. nodes such as BU,classic, xt and other including some core nodes that did tweak their blocklimit will carry on.
the blockstream(core) that refuses dynamics or shifting to a higher base block would be left stuck and not syncing. dead in th water

however core are threatening soft bilateral. which then can allow corefanboy pools(soft) to build on by ignoring dynamic pools.
and then that leads the nodes(hard) are in controversy because of orphan drama.. because there are 2 chains(but core would orphan the dynamic one) eventually leading to nodes(hard) doing a bilateral, to avoid seeing the dynamic block just to stop auto orphaning them by just being blind to them.. meaning it becomes a hard bilateral split.

excuse the pun... its not a trigger.. its a CHAIN of events

well you did add the "non-contentious".. rather than just ask about soft..
but here goes.


in short PoolA simply ignore and automatically reject blocks of certain version. and they just build on their own.

by pools doing this. they can keep building their own without halting just by looking at the version and declining it. without even validating its tx contents

what you will find it that there are 2 chains. growing forever.. but because its soft. the non-minin nodes(hard) will get confused be and swapping between the two dependant on height (non-mining node mega orphan drama(causing hard controversy) which then forces the nodes to pick a side just so the nodes dont see the orphan drama causing a hard bilatral split.. or remain with the orphan controversy mega orphan drama of endlessly swapping

but with or without non-mining nodes the pools are building 2 chains and not fighting, just ignoring each other

see now your twisting things

soft can be consensus meaning no split.. or contentious possibly split or bilateral guaranteed

by you intentionally saying non-contentious.. your baiting...
try
"Can you explain to me how two surviving chains could exist in a non-consenus softfork?

and your answer is bip9 has code in it to trigger banning and orphaning..
oh and UASF does too.. i think you can guess what the S stands for

yes they can
and thats where the fake sales pitch of the reddit script writers have fooled you

by only talking about the best case scenario of soft
and worse case of hard.. but not mentioning all the options

you think core is perfect..
hmmm 8 years of orphans - https://blockchain.info/orphaned-blocks  (if perfect there should never be a orphan)
major orphan event in 2013

even now
https://github.com/bitcoin/bitcoin/issues

oh and need we forget. if core is soo perfect then segwit is not needed because there is nothing to "fix"

you do know there is not actually 20 billion in fiat sat around in bank accounts with bitcoins name on it

remember core have been REKTing xt, classic, bu and bitcoinj

yet BU want consensus of all diverse nodes working together.
its core with the ban hammer and blackmails (bip9, UASF, PoW algo change) not the other way round

cough testnet cough

run it on testnet.. oh look now you have your own separate network to test it in the wild

impoosible (sarcasm)
core are immortal and indestructible gods.
they are needed or bitcoin would die

core never make mistakes. and everyone should(sarcasm again) run core, get rid of diversity, give core their Tier network and then bow down to the overlord of perfection.

P.S sipa was involved in the 2013 transistion from berkely to leveldb and didnt spot the lock bug. hmm. sipa, oh yea the head honcho of segwit..

told you this months ago. starbucks/walmart becomes the new bitcoin BANK2.0 with 3-5day maturityCLTV after confirm.. and revoke CSV chargeback facility

i even told you a few attack/blackmail methods too to trigger such CSV revokes and blackmailing for higher INchannel fee's by refusing to sign

ofcourse DCG(blockstreams corporate partner) would hope to be the hub between alot of services to rake in the funds to cover blockstreams $70m debt and coinbases $6m and all the other debts

you have no clue what bitcoin is about.. and have been drawn into a debate that seems to have gone over your head.
maybe spend less time on reddit and more time learning bitcoin consensus. and think about bitcoin onchain vs offchain(this topic).

this topic is about LN. but to correct your BU fails.. BU will not trigger unless it has full community consensus. thats why for the last 2 years and counting it has just been plodding along making no threats, setting no deadlines and not provoking.

however its core that have threatened banning nodes, orphaning blocks and splitting the network (bip9/UASF/PoW algo change) if core doesnt get their TIER network core want.
sticking to consensus. BU would work as part of a PEER network with many implementations (bar official core(blockstream) releases) so if BU gets majority BU is only part of bitcoin where there is still only one chain, like now.. of many brands happy to accept the new settings and keeping the network diverse by not having a king, where they all validate and work on the same level playing field.

if core trigger.. there will be altcoins where if core get majority it owns bitcoin. as the upper filter TIER treating any other node as unneeded second TIER nodes in a cesspool of stripped block(no witness) nodes, prunned block nodess and spv nodes.

---

but to address your theory that LN is quicker..
LN: deposit into multisig 10min-30min. make payment 1sec.. withdraw (2week N-lock) followed by 3-5day CLTV delay = nearing 3 weeks before you can spend your change with someone onchain...

onchain: send payment to recipient 10min-30min. = 30min before you can spend your change with someone onchain.

read my first paragraph reply of previous post as to why not everyone needs/will want to use LN (hint, only spending once a fortnight)

as for LN
niche market:
those multi spending every day: faucet raiders, satoshidice instant gambling etc
where LN fails to meet market need:
those only buying a weekly shop of groceries or occasional monthly remittance/rent payment.

EG if onchain cost $0.30 each and LN payment was $0.01 and default channel lock was 2 weeks.
niche:
if you gamble once a day. you might aswell voluntarily use LN because LN will cost you $0.74 to deposit, pay for 14 payments and withdraw(close channel). onchain would be $4.20 for 14 tx's
fail:
if you only pay rent every fortnight. you might aswell just stay onchain and pay $0.30. because LN will cost you $0.61 to deposit, pay and withdraw

---

segwit "promises" wont be achieved.. native malicious tx users would see to that. they wont voluntarily move their funds to segwit keypairs to foolishly disarm themselves..
malleable tx's will still occur, sigops, and just general tx spam will still fill up the base block preventing utility of the weight due to lack of segwit keypair users getting txdata into the baseblock.
plus:
there are 46million!! native UTXO's to 'spend' if you ever hope to achieve everyone moving over to segwit keys to then block off native key utility and actually get the promises.(never gonna happen)

---

as for malleation. well inside a LN its not just one person signing.. its 2 people.
so if a malicious person signed. their channel counterparty can double quadruple check what and HOW it was signed to see if malleation was used. and then sign their half. obviously the honest guy isnt going to sign the same tx later (malleated then non malleated).. thus the malicious party cant double spend because LN itself makes them reliant on the other person, thus unable to quickly push another tx with higher fee out to override the first one. as their counterparty wont allow it(by not signing).
meaning malleation is solved simply because its a multisig rather than a single sig requirement, making LN a malleability defence in itself without segwit required

---

to mitigate sigop and data bloat spam.. limit the txmaxsigoplimits. EG  increase the blocksigoplimit. but bring the txsigop back down to 4000. or even less.
its kind of foolish to have a v0.12: 20k blocksigop limit and a 4000tx limit. meaning block cant take anymore tx if 5tx's max out blocklimt (5*4k=20k).
its kind of foolish to have a v0.14: 80k blocksigop limit and a 16000tx limit. meaning block cant take anymore tx if 5tx's max out blocklimt (5*16k=80k).
have it as a v0.14.1: 80k blocksigop limit and a 2000tx limit. meaning block cant take no more if 40tx's max out.(40*2k=80k).
(personally id have gone with 500 txsigop limit. not 4k-16k, that way atleast more tx's get into a block with only quadratic milisecond delays)

also reduce the 0.4mb 'large tx'data bloat) allowance.. why oh why oh why does anyone need 20%(sigop) or 40%(bloat) of a whole blocks limits. for a single tx.. seriously.. thats just asking for abuse.

---

as for LN in general. the dont re-use address 'side channel' attack is still a risk of LN exploitation(they see many sigs to attempt to figure out privkey) and segwit has not mitigated and has no fix for that

---

also imagine the promoted LN hop (where people are falsely promised a get rich quick by making profit simply being LN hope nodes)

alice< >daisy < >chris< >eddie< >bob

imagine it cost $0.01 per hop
alice wants to pay bob, but needs to pay daisy $0.03  to cover daisy($0.01 ) and chris($0.01 ) and eddie($0.01) to ensure everyone agrees to get the payment to bob

now imagine the hub

alice< >daisy< >chris
          ^   ^
          v    v
     eddie   bob

now daisy is a hub. alice can now pay bob for just $0.01 fee because eddie and chris are not needed as intermediaries(hop). only daisy is

if you think people will pay $0.03+ to remain decentralised.. when commercial hubs are more direct...with less counterparty issues/disconnects/issues/blackmail risks.. and ofcourse only 1sat.. you will see that LN will become just a massive HUB(bank) where daisy signs the second half of the (bank:cheque) payment for everyone.
P.S cheaper for alice.. but chris and eddie no longer get their $0.01 each when alice wants to pay bob because chris/eddie are not required. only daisy is

so for everyone thinking they are going to earn lots of money just running a LN node.. think again. spenders will bypass the stranger danger risks of hops that can blackmail/revoke and play games. avoid the unneeded extra expense and instead just use a hub instead

---

also LN is utilising other banking features of 3-5day fund availability after channel close(withdrawal) confirmation CLTV and ofcourse revokes(chargebacks) during that cltv maturity period by using CSV revoke codes

---

also LN has other issues. you cannot predict the ONCHAIN fee weeks in advance. so what may seem cheap to just throw $5 into an LN this week because you might want coffee at the weekend.. costs you maybe $0.3 to open a channel, $0.01 to pay starbucks and $0.70 to close a channel due to rampant onchain fee leading up to the weekend.

which messes up the $4.29 coffee you were hoping for. because starbucks needs another 40cents to close the channel because the onchain fee is now 70cent not 30 cents
(ln concepts have already envisioned people needing to deposit upto $6 ontop of what people hope to spend just to be used as a separate refundable amount to cover possible close channel onchain tx fee's and also INchannel hop/hub fee.. which rules out utility for the less privileged third world classes who could of benefited from only needing to deposit 20hours labour($1) to buy groceries.

---

so we should not be pushing LN as the final result and end goal of scaling. because then bitcoin is just SWIFT.NEFTS or RTGS of the banking world where people no longer own their assets due to it all being locked under 'daisy's' control (needs her signature and her morals to not hit a CSV revoke funds button)

---

overall.
solutions.
stop giving tx's such obsurd txsigop limts of 20% of block limit.
re invent a new priority formulae that actually is not snooby in favour of the rich bypassing priority costs just by staking more. and instead works to penalise those who actually want to bloat every block. example of one here

oh and lets not forget have the blocksize adjustable at runtime so that its not a dev spoonfeed event once every 8 years but more of a community consensus where there are 2 settings:
upper (EG for now 8mb no go above zone)  utilised in maybe consensus.h
and a
lower ('preference' where majority halt it bock size, minority below move up to it)  utilised in maybe policy.h
where by if
3% had 1mb..
1% had 1.5mb
1% had 1.7mb and the other
95% were scattered at 2mb-8mb..
the policy/pref consensus would see 2mb was the preferred lower bound amount for now.. all of which are way below the harder to move 8mb limit of technical tested allowable amount, whereby the 5% minority were pushed up to the 95% acceptance..

hell.. even have a speedtest algo in a node that tests the propagation of seeing a new height, downloading, validating and then relaying out.
and get a 2016 block average to set as the upper limit (no go above limit) where by the preference is more free choice below this, that is affected by preference/policy dynamic consensus

.. rant over.. for now