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

market caps are a MEANINGLESS number. its a bubble number backed by nothing.

in short make an alt with 5trillion coins premined..
put ONE.. yes ONE coin on an exchange
sell it to yourself for $1.. yes spend just $1..
and BAM market cap of that coin is $5trillion

there is no $5trillion backing the premined coins i used in my example. just like there are not $28+billion in bank accounts backing bitcoins market cap. nor any other altcoin.

the sooner people realise this and stop giving a crap about market cap, the better.

---

here are things people SHOULD care about:
how many merchants accept coin X
how many employee's are working to do something within a certain coin, (devs, consultants/trainers, convention organisers, device(HWwallet/asic,etc) manufacturing employees, payment processors/exchanges etc, etc)
how many users a coin has

though some of these details are not easy to find. they are a hell of a lot more important stat than market cap

the main 'minimum spec' people are trying to keep bitcoin to is the Raspberry Pi spec..

but since 2009. things have moved on.
libsecp256k1 is 5x better than 2009
internet speed averages are no longer basic ADSL/3G.. we are now in the fibre/4-5G era.
hard drives are cheaper than 2009
(list of effiencies is larger than just above)

meaning 2009's 1mb safe.. is now 8mb safe. even core know and accept this. but still want 4mb at most as extra 'safety'
so going up to a 4mb dynamic* single merkle block**, with the extra features people want. and yes the opt-in voluntary segwit/rbf feature and voluntary LN can all go together happily

but segwits 'soft' approach is cludgy, has no guarantee's and doesnt solve old issues.. and is just kicking the can down the road of hope..

*dynamic=network grows when network can accept it (network consensus growth not dev spoonfed growth)
** full network upgrade where everyone is on the same peer layer.. not the 2merkle tier network of full/stripped/filtered/prunned cludgy blocks for different layers of nodes

lol
1. you using the buzzwords/script words "jihan" "paid shill" is foolish.
2. segwit does nothing to stop native tx's filling the baseblock which prevents segwit tx's sitting in the baseblock to put their feet up in the weight area.

a real proposal is to not allow ANYONE have 20% of the block area for a single tx.
a real proposal is to bring back a NEW and DIFFERENT priority formulae that reward infrequent/lean tx users with low fees. and punish frequent bloated users with high fee's. thus not forcing everyone into LN. but making it super expensive for the spammers (spending every block with loaded tx's). into wasting their funds faster or using LN if their frequent/loaded tx's are genuine.

EG reduce the 'large tx' to below 10% of block
EG reduce the sigops to below 20% of block
EG new priority formulae

no, i think jonald is FLAWED to the Nth degree in his understanding of what nodes do. i have face palmed him many times. and corrected him also.

but someone personal beliefs of why they should or should not run a full node is not as big a deal as the empty promises/guarantee's/expectations of segwit which is more of a network wide issue

people should learn about what would truly benefit/hinder the bitcoin ecosystem and what would actually occur due to certain changes, proposals

here is a copy of a PM i sent to jonald as soon as i read this topic

-ck's response.. close eyes, put fingers in ears and just scream go with segwit.
(facepalm)

1. segwit is not as 'compatible' as promised
2. segwits activation event itself, is not about solving quadratics/malleability scaling or anything else. its about setting up the tier network
3. moving funds to segwit keys after activation has a POTENTIAL to affect quadratics/malleability scaling or anything else.
4. but malicious people will stick with native keypairs and continue to do quadratics/spamming to prevent good utility
5. segwit does not stop/disarm/solve native keypairs. thus not 'fix' issues.
6. segwit just disarms innocent people who volunteer to move funds across while letting the network continue doing the same as usual.
7. the 'expected' potential scaling boost of segwit is the same potential scaling of 7tx's on chain of 2009-2017. which still has no guarantee of actual achievability

these guys understand it


in short make an alt with 5trillion coins premined.. put ONE.. yes ONE coin on an exchange and sell it to yourself for $1.. yes spend just $1.. and BAM market cap of that coin is $5trillion

market caps are a MEANINGLESS number. its a bubble number backed by nothing.
there is not $5trilling backing the premined coins i used in my example. just like there are not $28+billion in bank accounts backing bitcoins market cap. nor any other altcoin.

the sooner people realise this and stop giving a crap about market cap, the better.

---

here are things people SHOULD care about:
how many merchants accept coin X
how many employee's are working to do something within a certain coin, (devs, consultants/trainers, convention organisers, device(HWwallet/asic,etc) manufacturing employees, payment processors/exchanges etc, etc)
how many users a coin has

though some of these details are not easy to find. they are a hell of a lot more important stat than market cap

the good(for chance, but bad for your pocket) fee is 240sats/byte - https://bitcoinfees.21.co/

so...sending the 0.00184008 out

edit: oops . didnt check if compressed/uncompressed (as danny highlighted).. maths now sorted

(in:1*180)+(out:1*34)=214(+-10) so go with 224 to be easy
   fee: 224*240=0.00053760               
   so send:   0.00130248   
            
edit: (to explain why i done below) incase you want to pay out to 2 destinations / get back some change if not wanting to send whole amount

(in:1*180)+(out:2*34)=248(+-10) so go with 258 to be easy
   fee: 258*240=0.00061920            
   so send:   0.00122088   split across the two outputs however you want      

i have said for years dont get spoonfed data
dont just take things on face value
dont just read something on a forum/reddit and take it for granted.

do your own tests/research/scenarios/validation.
this is why DAYS AGO i said ill give dino a few months to have his mind blowing experience of seeing the bigger picture of the real depths of bitcoin rather than the 1d overview he has displayed over the last few months.

yet apparently many want me to spoonfeed them everything. and then debunk it before even examining it.. (making it pointless to spoonfeed)

so if you want to learn run your own tests for your own peace of mind.

anyway this topic has meandered soo far off track.

but i still await -ck explain his biased 'only 70ms' timing of all the combined propagation, validation, parts (outside of hashing).. as i want to see how if its just 70ms he and his fellow friends can justify their "2mb is bad" rhetoric

PS. to pre-empt short sightedness
 my "minutes" is not to be taken literally as in for all blocks... but has been the case in the past where certain 'tasks' used to be done certain ways without efficiencies. and more seconds/milliseconds can be shaved off too even now
 but on average the block (non-hashing task) is more than just 70ms..

but i would like to know where -ck can defend a bigger blocks are bad stance if non-hashing tasks are 'just 70ms)

im done with this topic.
if anyone else is unsure about the meandered 'hashtime' stuff.. just run your own scenarios