no. the 2 merkle ""< temporary relief >"" being the only option also bad.
other options allow decisions because there are options to decide.. just having only 1 choice is not a choice.. its a dictatorship

the 2 merkle SegWit < temporary POSSIBLE relief > should not be the only choice.
and no suggesting it "has to be accepted by the people that are running the Bitcoin software." are words of dictators

its just core should have back in 2015 made a plan B that the whole community want..
not made their own plan A which even in days after 2015 showed community revolt, yet they still want to force plan A all the way to 2019

yes core want to keep pushing this < temporary relief> all the way to 2019 (UASF.co quote: 'late 2018')

you do realise the asicboost drama is temporary.
lets say in 2019 core did remove the 2nd merkle to then be a proper network wide single block of 4mb which core say they promise will eventually happen.. then asicboost becomes viable again.

which means some private company can grab the genesis and privately start at block 1 and use asic boost and create their own chain and get to blockheight say 500,000 faster. and by the time the 2nd merkle gets removed. publish their chain and bam.. their chain becomes the new height everyone diverts/syncs to.. orphaning off the satoshi 10year chain
..
by letting us bitcoiners use whatever is most efficient, mitigates risks of outsiders trying to make their own longest chain, by us bitcoiners having the longest chain, by us bitcoiners using the most efficient mining methods there is

the solution is simple

not A:
cludgy
2 merkle(block1mb inside a block4mb) (1mb block but reality more due to bad math)
4k txsigops pretending to be 16ktxsigop math manipulation (causing block full attack only using 5tx of 4k txsigops to get to the 20k blocksigop pretending to be 80k blocksigop)
100kb txbytelimit  but reality is upto 400kb real data due to bad math
growth of 2x only if 46m outputs move to and use new keypairs

but B:
single merkle 4mb block single block consensus buffer (initial policy grows 1mb - 4mb.. just like the past consensus buffer: 1mb. policy: 0.25mb 0.5mb 0.75mb)
2k txsigops that are actually 2k sigops that do not change ever, (nor pretend to be anything else via bad math)
blocksigops that rises with the blocksize (nor pretend to be anything else via bad math)
all the different keypair types people want (native, segwit, schnorr, new opcode for new contracts) all together
new fee priority forumulae that punish people that move funds if frequently (more than once a day, making LN voluntarily viable option for frequent spenders) while not punishing EVERYONE (not punishing a hoarder with the same fee as a spammer)

that way everyone gets what they want and it actually decreases native tx attack vectors, issues

ripple
1. ripple token is not even on a real blockchain
2. ripple token not scarce
3. ripple token is centralised.
4. but some of the services are decentralised

bitcoin
1. bitcoins token is on a real blockchain
2. bitcoins token scarce
3. bitcoins token is decentralised.
4. but some of the services are centralised

if you are talking about the UTILITY
bitcoin is used by WELL over 300,000 merchants
bitcoin is used by millions of people

ripple is used by a few hundred, maybe a couple thousand
ripple is used by far less people

if your talking about the market cap

screw it, dont even bother
anyone can create an alt with 5trillion coins. sell one for $1 and instantly have a market cap of $5trillion
market caps are meaningless so dont even take a second glance of market caps.

bitcoins purpose vs ripples purpose are 2 different things.

if you want to find real value
look at:
merchants using
users using
businesses involved in
people employed to work on
people employed and paid in

and you will see bitcoin wins

as for my statement about bitcoin having some services that are centralised. this is because bitcoin is so powerful that when businesses get too big for their boots and start beating their chests, they forget one fundamental thing that inspired bitcoin into existence.. nothing is too big to fail
as such core removing code rules and replacing it with economic hopes is a betrayal of the original ethos that inspired bitcoins existence.

so when businesses, dev teams, VC's get too centralised. you can tell it is not going to end well. either for the team, company or service. and if they try to change bitcoin too much from bitcoins original vision/purpose. then bitcoins utility will drop

only reason to boycott bitpay is for the DCG to sway people to litecoin via coinbase.

in the end its just DCG chest beating drama because behind all the drama they are all in the same team
yep bitpay are under the DCG portfolio too...

its just meaningless social drama to distract people away from the real stuff..

lol
antpool: 650peta = ~50,000 S9's...
even at $2k retail price a pop, thats just $100mill
or $50m at cost..

i bet i can find bigger businesses in the bitcoin ecosystem than $50m/$100m

havnt you followed the roadmap..
blockstream avenue leads to DCG portfolio street leads to capital one banker highway leads to banker hyperledger superhighway.
ask DCG where it gets its funds from (barry silbert who is your brother.. alan silbert: capital one healthcare)
twitter.com/hyperledger/status/791291547404861440

blockstream just think of bitcoin as an experiment to show off skills hoping for the big money from bankers if they win hyper ledger contracts..

but hey even when gmaxwell stands next to a poster showing who he is sponsored by, people will try to dismiss it
even when blockstream ar hyperledger members people will dismiss it..

yet its all chinese 16% jihans fault...?

^ typical racist reply.. sounds like the fox news crowd
fox: america = independence
 if your not american you must be bombed or told to stay on your side of the wall..
reddit: core = independence..
kill chinese. destroy PoW, RKT all but blockstreamists

Satoshi:0.14.1   1599 (22.74%)
Satoshi:0.14.0   1589 (22.59%)
Satoshi:0.13.1   775 (11.02%)
Satoshi:0.13.2   586 (8.33%)

and you havnt even got anywhere close to 95% nodes either...
and you wonder why pools are hesitant..
they know that segwit is cludgy and creates a tier network that can cause issues. they wont risk anything unless there is a PROPER good node count to mitigate orphan risks.

plus you cant blame pools for being the electerate, when it was blockstream that handed only the pools the ballot paper(analogy not literally)

yet the DCG portfolio group of blockstreamists really wanna push the UASF granade. rather than sit down and ask what can the devs do to get more community consensus.

meanwhile anything not blockstream are not threatening PoW nukes, no mandatory delay deadlines, no threats.

i have a question for you..
do you even understand segwit.
EG
1. activation or users moving funds over to segwit keys, which do you think will actually cause any difference
2. what does segwit do to prevent native/legacy issues

i know the answers, but lets see your rhetoric
when answering 1-2 do not resort to checking reddit or twitter for pre-scripted replies.
i wonder how much you actually know about segwits gestures. hopes, expectations.. vs reality

you say your using an old electrum..

best thing to do back up your privkey/seeds/wallet in triplicate and in different forms incase one corrupts/doesnt backup correctly.

uninstall the old electrum and use a different version/brand.
then the new wallet import the privkey/seed and you will see your funds unspend.

and because its a new version/brand it wont be locally 'stuck' in your mempool because that disappeared when to uninstalled/use different version/brand

and all the blockstreamists seem yet again desiring to point the finger at jihan/china..
damn the reddit scripter should really go work for fox 'bomb them bomb them bomb them' news.

16%jihan , 51%other =67%+ saying no/abstaining

yep even sipa's stats say it 67% (at time of post) nay/abstain
http://bitcoin.sipa.be/ver9-2k.png

not everything is jihan

not my best work, just found sometimes people cant read and prefer to see pictures..

but anyway IF you had 100BTC and wanted to pay E 100btc.. then the DNS system would have to find a route of participants that would get from A to E and al of which have OVER 200 in the channel, per channel to to be able to hop the funds along

from all the talk at the moment most LN devs are saying that LN should only hold around $60 or 0.05btc per counterpart.
which i think is fair due to LN's utility only being for the small stuff and the risks that LN devs still has not patched yet

LOL...
thre are many many many attack vectors.

maybe worth you playing out more scenarios check for weaknesses not looking for semantics to brush issues under the carpet..

and malleability has never had a problem in the LN concepts anyway.. it was just a narrative played on repeat to make segwit seem more needed.

it still needed their signature before they fell into a volcano!!!

its a multisig.. short for: MULTIPLE SIGNATURE

EG
its not lke a traditional transaction where you are the only signee..

if you were to compare it to lets say a cheque... LN/multisig is like a joint account needing 2 signatures.
A and B have to agree together

again its not like you have you own funds and your wife has her own funds completely separate (#1)..
you both are in the same 'account/channel' and both need to agree on who spends/deserves what.(#3)

in a hop concept your channel you need your counterparts permission to be part of a route. you then need others to agree aswell.

needing permission is not permissionless

although the permission can be automated, its still permissioned

EG you dont need a bank manager to physically agree or physically sign a bank account movement manually.. but by using a bank requires it set its system to auto authorise things in the system. they can take that away.

you can decide to remove yourself from a channel should a counter part try to blackmail or decide not to give permission, much like withdrawing from paypal.. but by your sending a tx, the counterparty can(if malicious) then invoke their CSV which then in laymmans terms is like a chargeback. taking your funds away from you before your funds have matured.

LN has a niche, dont get me wrong.. but it is not as utopian limitless, permisionless as people think, pretend.

i am not trying to scare anyone, i am just making sure people know more about it then the polished best case scenario sales pitches. so they can see the reality of it

EG

A provides a fresh public key 1A4c3p0...
B provides a fresh public key 1Br2D2...

the 2 public keys combine to create a multisig  3Bb8...

A funds 3Bb8 0.1btc    - txid a1cd
B funds 3Bb8 0.1btc    - txid b4cd

channel is now open

parties agree how the payout should begin (#6)

when they agree to a new balance they both sign and have something like

if later B wanted to pay A 0.05

if later A wanted to pay B 0.01

now if A regrets paying B 0.01(txid:2515).. A could send (txid:ae48) but what you dont realise is that A's (txid:ae48) has a CSV condition
meaning B could send (txid:2515), which then revokes A's output

note this example is very simplified for laymens

to explain LN channels(hop)..

firstly ill display this image and then explain it


first some people think anyone can set up a channel with a click and remain permissionless(#1).. wrong!
 you have to set it up WITH ANOTHER PARTY (#2) !! permissioned as you need their signature to sign off on payments !!

next you cant just instantly pay anyone. for instance A cant just pay E,
you  need to have to find a route to the intended 'anyone' by finding a path of channels that can link you to the intended party.

this involves some parties having more than one channel open (#3) as you can see B has 2, C has 2, D has 2..

next is the funding..
A doesnt just fund E.. A has to pass funds to B(plus a fee) in the A_B channel... B then needs to use a separate channel B_C with separate funding to fund C, and so on. (#4)
this means with a cap per channel of lets say 0.1btc
B needs to deposit 0.1 into 2 channels
C needs to deposit 0.1 into 2 channels and so on

now, with many channels available and channels having funds, this then allows a path (route)(#5) to be established from A to E

---

now lets say A wants to pay E
we will start with the blank slate(#6)
imagine A wants to pay E 0.01btc... and each 'hop' cost 0.001 fee to thank each person of the route for participating.
(dont knit pick the fee or take it literally. i chose 0.001 randomly for demo purposes only, i simply couldnt be arsed to do lengthy decimals to show a very small fee)

as you can see in(#7) A has worked out it would cost him 0.003 in fee's to get to E and so A passed 0.013 to B
B in A_B is where B's 0.001 fee remains.

in (#8) B using the separate stash knows its going to cost him 0.002 in fee's to get to E and so B passed 0.012 to C
C in B_C is where C's 0.001 fee remains.

in (#9) C using the separate stash knows its going to cost him 0.001 in fee's to get to E and so C passed 0.011 to D
D in B_C is where C's 0.001 fee remains.

in (#10) D using the separate stash passes 0.011 to E
D in D_D is where D's 0.001 fee remains.


which when if they all closed channels and totalled up their holdings
(#11) A=0.087 B=0.101 C=0.101 D=0.101  E=0.110
which means the guys in the middle are 0.001(fee) in profit from acting as routes(hops) and E has the 0.01 which indirectly came from A
because A is down by 0.01... (and down by 0.003 for the fee's)

---

all that the mainnet chain see's to set up the channels is the 8 transactions (into a channel) to set up the 4 channels (2 tx per channel)
as shown by the arrows in (#5)
A(0.1)->A_B               B(0.1)->A_B               B(0.1)->B_C                C(0.1)->B_C  
C(0.1)->C_D               D(0.1)->C_D              D(0.1)->D_E                E(0.1)->D_E

and 4 final transactions when closing the channels
A_B(0.2)->A(0.087)B(0.103)                  B_C(0.2)->B(0.088)C(0.102)    
C_D(0.2)->C(0.089)B(0.101)                  D_E(0.2)->B(0.09)C(0.110)  

which when if they all closed channels and totalled up their holdings
(#11) A=0.087 B=0.101 C=0.101 D=0.101  E=0.110

which means the guys in the middle are 0.001(fee) in profit from acting as routes(hops) and E has the 0.01 which indirectly came from A
because A is down by 0.01... (and down by 0.003 for the fee's)

---

the steps #7 to #10 are funds moved all off chain.. never seen by the mainnet chain
and funds can move back and forth as many times as possible off chain as long as:
the channels have enough funds to work as a route for the particular payment
and
there are enough channels to link/create a route

the only problem is the "community coming together for a solution" dispeared in 2015.

now its just the closed door invite only conventions/round table events organised by the same portfolio group
http://dcg.co/portfolio/

i did..
EG last april i spotted the anyonecanspend issue..
their response.
ridicule me for months..
facepalm themselves after that when they realised.
then do a cheap cludgy work around create/plan the tier network to prevent native nodes from getting relayed unconfirmed segwit tx's after activation..

problem then, nothing stopped a malicious person MANUALLY copying a unconfirmed segwit TX from a segwit node mempool and then messing with it.. in a native node

to which the workaround was to not allow keypair utility until after activation and so that they can then drop accepting native blocks from being mined to prevent malicious uses of my previous sentence as part of the tier activation.

but there are still issues with that too.
it just keep going on and on and on.. core have opened up more attack vectors with their cludgy soft segwit, than there were this time in 2015 pre segwit announcement

the ultimate solution is a 1merkle peer network (not a 2merkblock block in a block on a tier network of stripped/unstripped blocks) which has a lot of other features the community want to.. and done in a manner of a full node and pool consensus upgrade event.
where by everyone gets what they want.. a real main blocksize increase and other features along with the opt in stuff like segwit/ln..

rather than the cludge that leads people into using LN by force due to soo many issues onchain

its nt about getting all 5million+ users to be full nodes.. but certainly not about trying to pretend that nodes are meaningless to hope people turn off nodes to then give pools majority node count to make it easy for pools..

but yes merchants and those that do care about security and protection of the network should run a full node.
there is always has been and should always be a symbiotic relationship. to ensure no one has overall control.


there are MANY mechanisms in a node that protect the network.. bitcoin is nothing like the banking system.. nodes are not just duplicate copies of a database.
the consensus/orphan mechanism, to name just one feature... does not need users to do anything manually apart from run the node. the node knows the rules and will throw out any block that doesnt meet the rules. and then the whole network consensus syncing/relay mechanism sorts out the weak from the strong, leaving behind the weak..

well to take one example from history (BU's 1.000250 block mistake)
non mining nodes response
.. then if the 50% of pools accepted it when the pool makes a new block where by the previous hash was
^000000000000000000cf208f521de0424677f7a87f2f278a1042f38d159565f5

the non mining nodes would reject that next block too..
the non mining nodes would only accept a block where all the previous hashes of blocks followed the rules.

in short over 50% of pools end up making/wasting time making blocks ontop of a block that merchants and users wont see/accept. and those pools wont get to spend their rewards with those merchants/users in 16 hours time..

pools know this!! and for years have been following this knowledge..
which is why when they see its rejected they dont build ontop. instead they go back and find a blockheight that was accepted by the majority and only build ontop of that block. to ensure they are building on the most acceptable chain that will allow them to spend their rewards

this is why NODE+pool consensus events should happen.. and where core went wrong thinking only pools should have the vote
and where core fanboys went wrong thinking the non-core proposals would actually act just on mining flags. when the reality is that things will only happen if there was a combined node and pool consensus


cores plan B is if the community say no, dont back track and listen to the community and make something different.. but continue on and press even harder my making it mandatory, with another year delay
UASF quote: mandatory by late 2018

cost is about under $100 for a raspberry pi and a microsd..
what you are talking about is a sybil attack.. also traditionally called a invasion / corporate take over..

many people never read trumps books, manifesto's or plans.
many people never read segwits code, documentation or plans.

those that have end up seeing why people facepalm when they see supporters of both.
do you know the difference between what segwit activation does vs what the keypairs do
do you know the difference between what segwit activation does not do vs what the keypairs do not do

do you know what gestures/features/promises will actually get to be seen.

or are you just settling for the idea that because blockstream worked on it since 2014, that its too late to just ask them to try something different/better. due to the mindset of 'they put so much work into it, we should just accept it'

P.S even in 2017 the actual keypairs that segwit will utilise are still not etched in stone. so its not really actually been fully tested since 2014.. its been worked on since 2014.. which is totally different. they are still tinkering with it even now