im trying not to use buzzwords or over complex things so other readers can understand the fundamentals.

as for the individual spends within LN, they too need to do some things.
the 'secret exchange' in practice does not work. hense the need for the locks aswell.

EG (your concept version)
 i could have a direct connection to a pool and have bribed them to put my tx into a block the exact moment the 1000 block lock is released.. so when i send X in the last second, its in.
you spot mine and think your Y would over ride my X. the problem is that your Y transaction has to relay around the network and sit with the other high fee paying blocks in mempool before a pool accepts it into a block.. which after seeing the mempool bloat this week might be 2 hours.
where as mine gets in. making yours invalid(double spend attack).

thats why locktimes are needed too. to delay mine from being acceptable.

the bip you referenced may have exampled a 24 hour revoke time. but in practice.. users wont accept that.
also that can be attacked/abused in atleast 3 ways.

but hey there are many LN concepts, i just hope the one your viewing is not going to ignore using inner locktimes of descending order.. otherwise thats a weakness of that concept.

yes
i just called it a laymens term of relevant gap/grace period (dont get hung up on my 10minute arbitrary number i used),
the old mechanism "in number of blocks" (as you quoted)
new concepts are using seconds instead. so instead of saying blockheight. or seconds. i for easy explanation for the scenarios said 10 minutes.. but the 10 minutes is not important. its just a demo purpose random number


the point is: gap simply wont be 1 second as that can be abused, much like in paypal everyone waits till the final second to push their bids)

the gap between acceptable bids needs to be more then one second. due to onchain issues about relay-propagation times and other factors
also i factored in that say the gap was 3 seconds. every time a person doesnt use LN for 3 seconds thats one possible lock wasted.
also i factored in that say the gap was 3 seconds. every time a person uses LN in milliseconds that takes away 3 seconds of utility

meaning its not an unlimited amount of transactions right up to the ONCHAIN nlocktime, there are actual limits to LN

to add to this..

in practice.. using say the middle graph (of my last post)
or
"which means if in milliseconds a hub does 259200 tx's  it now has to close within 7 days of opening" (scenario of post previous to that)

even though a onchain timelock wont allow the close session to be allowed/confirmed onchain until:
middle graph agreed tx(close session) reached 2hours 10 minutes
259200tx agreed tx (close session) reached 10 days 10 minutes

it still closes at:
middle graph 40 minutes - but just not confirmed onchain for another 1 hour 30 minutes (after 2 hours from opening due to onchain lock)
259200tx agreed tx 7 days - but just not confirmed onchain for 3 days. (after 10 days from opening due to onchain lock)

in short .. users are waiting hours or days unable to use LN at all, because all (inner LN) locks are used up. where users cant keep spending and the funds are not released onchain.. basically leaving users left in limbo.

meaning practically the channels SHOULD close earlier to not leave users in limbo. hense my gripe that channels should be able to close earlier.


from what i can see is in concept as their 'work around'
while users are in limbo between the LN inner lock being used up and the onchain locktime (scenario1:1h 30mb, scenario2: 3days)
users are persuaded to make a second channel using different funds (while initial funds are locked) to restart using the service while the limbo time of first session expires.

simple illustration


lock= 2 hours
left graph: user spends every 10 minutes
spend at 10th minute - lock release at 1hour 50min
spend at 20th minute - lock release at 1hour 40min
spend at 30th minute - lock release at 1hour 30min
spend at 40th minute - lock release at 1hour 20min
spend at 50th minute - lock release at 1hour 10min
cant use as realtime and locktime release lock is soon
end result lock-in was 2 hours but had to close in an hour - tx processed 5 out of 12

middle graph: user spends every 5 minutes
spend at   5th minute - lock release at 1hour 50min
spend at 10th minute - lock release at 1hour 40min
spend at 15th minute - lock release at 1hour 30min
spend at 20th minute - lock release at 1hour 20min
spend at 25th minute - lock release at 1hour 10min
spend at 30th minute - lock release at 1hour
spend at 35th minute - lock release at 50min
cant use as realtime and locktime release lock is soon
end result lock-in was 2 hours but had to close in 40 minutes - tx processed 7 of 12

middle graph: just once
spend at   Xth minute - lock release at 1hour 50min
time passes locktime release lock is soon
end result lock-in was 2 hours but had to close in at 1 hour 50 minutes - tx processed 1 of 12

locktimes
EG say the locktime is  now+864000seconds (10days) 1480244302+864000seconds = 1481108302
LN does not stay active for 10 days
every transaction within LN uses a lock to keep latest relevance
in conception
tx z: unlock 1481108301
tx y: unlock 1481108300
tx x: unlock 1481108299
which means if in milliseconds a hub does 86400 tx's  it now has to close within 9 days of opening
which means if in milliseconds a hub does 172800 tx's  it now has to close within 8 days of opening
which means if in milliseconds a hub does 259200 tx's  it now has to close within 7 days of opening

also the secret is although being conceived that locktime of +864000 seconds means 864000 transactions are possible. its not
firstly. to secure relevance, there needs to be a gap between locks. so that the most relevant(x) doesnt time out and the next irrelevant(y) becomes relevant again due to there not being enough time to broadcast X before Y's time becomes relevant.

its going to end up that locktimes will be 10mins plus, to give a relevance 'grace' period.
eg
tx z: unlock 1481072302
tx y: unlock 1481036302
tx x: unlock 1481000302

meaning only 1440 transactions are possible in 10 days.

i used 10 days as a simple number because it displays limits clearly. but you might be saying well onchain lockin can be set to say 2 years.
i would counter that with the more complicated maths of hubs.. where by in the fantasy land of the 'visa comparable' scenarios or the 'one world currency' scenarios people are propagandising as to why LN is essential. that instead of happily processing just say 500 transactions per channel
for some day trader/gambler in 10 days.. a hub will be processing hundreds of thousands to millions of transactions (visa/oneworld scenario)

so although a 2 year lock effectively means upto 105120 LN tx (with relevance grace) over 2 years.. a hub will use up all of them 105120 locks very very fast.

eg. imagine onchain only copes with 4500 tx.. but at first LN is chosen by 10%. (450 tx)
yes LN free's up 450 tx no longer being onchain.

but now within LN 450 tx are done every 10 minutes instead of onchain. meaning the 2 year locks are used up within a fortnight due to the hub and spoke/multihop model

in short. if lock was set to 2 years. and 105120 were done in lets say 5 minutes. the channel needs to close in 5 minutes of opening and a new channel opened for 2 years

the benefit is obviously 105120tx are aggregated down to a final and single tx onchain. where bitcoins main net does see all the swaps of 105120tx and only sees 1tx of (laymens: final balance outputs)
but requires users to then re open a channel again which becomes a headache in a hub model

legal tender (fiat) if in a bank account. is tied to regulations. the regulations are tied to the government of the location.
moving legal tender across borders can be a headache.

bitcoin however can be treated as:
a weightless asset reserve (like a gold reserve but without needing a lorry or muscles to move it.. without vaults and armed guards to secure it)
a tax haven
personal 'trust fund'
travellers cheque

things you can do with bitcoin:
declare baskets of 0.00xbtc as shares/bonds of stock. (research coloured coin)
set up a trust where 2 parents/trustees can sign, and then fund it by anyone/anytime they like to then pay out to beneficiary  (research multisig)
used as a global payment. eg all remote workers are paid xbtc a fortnight. thus not having to use different banks to pay different countries

what are other possibilities:
remittance markets
new/expanding industries: consulting, ASIC manufacturing, training, conventions, etc

employment expansion:
IT, customer service, trainers, designers, manufacturers etc

efficiency gains:
retailer: no chargebacks, no creditcard processing subscriptions, no 'card decline', etc
homeless: having a QR code paper sign allows them to accept electronic payment. not just metal pennies
unbankable: able to store value even if a bank refuses due to no ID or bad credit

businesses:
automating manufacturing by robots making/packaging as soon as payment seen on blockchain. so less need for staff
accounting/auditing more transparent. less need for staff
no need to securely store customer creditcard info, meaning less servers, less data protection headaches

are are many more. its just bitcoin is still in the 'innovation' category. all possibilities have not been recognised/thought of yet.

word games..

4mb not= 4x capacity
4mb not= relevance to capacity
the 2.1mb = capacity increase
the 2.1mb = relevance to capacity

LN should not be the compulsory end game solution to capacity scaling. it should just be an open choice/service on the side.

easy enough, and i only used silly analogies due to the person i reply to having silly analogies in the past. so i was trying to speak on their level

i think the debate above has got out of hand where the term "fractional reserve" has the issue

one person lets call him (CB) thinking of it as the traditional meaning of if 10 is deposited then a bank can create 10 new money.
the other person call him (K) thinking. deposit 5 each (10 total). and do a craig wright to get 29.6 where collateral (trust of value) becomes value

EG
in a channel between X,Y they deposit 10 publicly on the blockchain to open the channel
X and Y 'spend' the 10 to another active channel user Z
asking Z to not use LN but to use Z's onchain balance address to pay 4.9 each to X,Y ONCHAIN and Z keep the 10 offchain, to spend later


X: i have control of 10 in LN, i have 4.9 personally ONCHAIN too. this is my 14.9 collateral. i can sign a message to my personal 4.9 and a message as part of the LN 10.
now give me a government grant,VC money up to 14.8

Y: i have control of 10 in LN, i have 4.9 personally ONCHAIN too. this is my 14.9  collateral. i can sign a message to my personal 4.9 and a message as part of the LN 10.
now give me a government grant,VC money up to 14.8

they receive VC funding to 29.6btc. where infact X, Y have ZERO LN collateral. and only 9.8 personal collateral.

fractional reserve is not just about money CREATION like (CB) thinks. its also about faking collateral you don't have or moving funds around, to profit from something that you dont have

now lets get back ontopic of scaling bitcoin

the 4mb bloat has been evaluated.
the main cries over the last few years why anything above 1mb was bad was things like
"not everyone has fast internet"
"chinese firewall"
etc

yet all that has been debunked and tests were done that 8mb is acceptable.. but 4mb was deemed the very safe amount to handle for now as acceptable bloat.
"chinese firewall"
yes thats right. while the west was crying that it cant go above 1mb due to chinese firewall.. the east (inside the firewall) all laughed and said what a stupid doomsday. nothing about the chinese firewall has issues with it and data can be so much more than 4mb


"not everyone has fast internet"
tell that to the millions of people in africa doing skype videocalls. then millions of people uploading to youtube. millions doing livestreaming, whilst online gaming...

so devs now backtracked doomsday and happily said upto 4mb bloat was acceptable.

---

yet still keeping tx baseblock data at 1mb..

i cant wait until they backtrack the 1mb baseblock dooms day when they finally see its just a orphan risk scenario.. hense the need for super high majority consensus to mitigate orphan risk.

the 'it causes altcoin' doomsday is FUD. because oppositions need EXTRA added code to intentionally IP/USERAGENT BAN connecting to certain nodes.. just like ethereum intentionally split '--oppose-dao-fork'
without adding an intentional ban list of IP/useragents. the connected nodes just have an orphan battle on a single chain, they dont keep 2 chains alive for eternity they orphan the minority
high majority consensus means low risk of orphans. and leaves the minority never syncing.. thus again no second chain. just minority left unsynced

---

as for the "linear/quadratic" doomsday.
easy.

if sigops is causing issues... limit sigops.
there is no rational reason for one person to need to do 500-20000 sigops. so limit the number of sigops a tx can have.
aswell as ensuring validation times are not used as a DDoS, the extra benefit is we will not see a block with just 1tx sized at 1mb with hefty amount of sigops to churn through..

much easier rule is not use fees to delay transactions
or blocking addresses

 but transaction maturity.
EG like blockreward maturity of 100 confirms

transactions cant be respent for atleast an hour and dropped out of mempool if someone tries to repeat spend in every block.
atleast it stays more inline with 'priority' than using a fee war to sort out things

much like this topic
your presuming the increase in mempool was due to...........
black friday? spam?

have you ASKED why, RESEARCHED why, or just presumed.
oh one more hint. you can actually get the blockchain data, get all the multisigs and analyse it and see the inputs and outputs and see correlations, patterns of usage.

yes LN needs bitcoins mainnet. and we should increase transaction capacity ONCHAIN due to that need.

however if you read the stuff core and LN devs are saying. they are overselling LN as a system where channels never need to close.
which brings up the issues/concerns. about immutability, trust, permissioned transactions, loss of bitcoins ethos.

if we went with LN's rhetoric of never needing to close channels.. then bitcoins mainnet is never needed once funds are deposited.
can you atleast see the twisting of mindsets about the importance of bitcoins mainnet.

rationally LN should regularly close channels. thus ONCHAIN capacity IS important. aswell as the security of users funds

pretending there is no answer, is different then not asking the question. please try to atleast learn why things happen instead of relying on unknown reasons.

because having no clue of the reasons makes any statistic you give less worthy, as it has no context.
yes there may be multiple reasons. but not even investigating a single reason or multiple reason makes the stats worthless as anything important

yes people are actually currently moving funds to multisigs.. but you are not asking WHY.
even though i dont 'need' multisigs, i have moved funds over to a multisig... do you want to know WHY.

to play out some LN scenarios

im glad to see you are starting to research though, so i will atleast give you a pleasant
have a nice day

but you have not asked yourself why.. or asked bitfury why.. here is the answer

if you think LN should reign supreme, i have to remind you of something (i did warn you)
https://bitcointalk.org/index.php?topic=1450783.msg16998029#msg16998029

seems everyone is trying to shout doomsdays of "we need to be like visa today"
seems everyone is trying to shout doomsdays of "7billion people using bitcoin today"

seems everyone is trying to shout doomsdays of "bitcoin cannot cope with it today"

so lets be rational.
the 4mb BLOAT size increase has no correlation to transaction capacity increase.
the 2.1mb capacity size increase is based on a scenario where LN (dual permissioned multisigs) channel opening and closing reign supreme
the 1.8mb capacity size increase is based on a scenario where peer to peer(permission-less) reign supreme. (bitcoins ethos)

so sticking with bitcoins peer-to-peer permission-less ethos. rationally, segwit is only offering a ONE TIME 1.8x capacity 'side effect boost'.
it a one time event. so 'scaling' is not a buzzword that sits beside one time event.

LN should not be the compulsory solution to capacity 'scaling', to attain a higher (2.1mb+(2.1x)) capacity. LN just remain a side SERVICE that is an open choice.

now thats the short term mindset everyone should have.

---

as for the future.

at 1.8mb (1.8x capacity) side effect of segwit.. the other 2.2mb BLOAT size buffer (bringing total weight to 4mb) should not be wasted on arbitrary data and features that do not enhance capacity. (such as confidential payments)
we need to stick to lean clean transactions.

afterall bitcoin is a financial system, not a store of arbitrary data.

so concentrating on future TRANSACTION CAPACITY (not bloat). bitcoin CAN dynamically grow, naturally over years.

which is where a 2mb base 4mb weight. still falls within cores happy numbers of bloat, but allows less arbitrary data to keep the blockchain lean and clean and concentrating on transaction capacity

as time passes that can be increased. there is no need to jump to 100gb blocks today
as time passes that can be increased. there is no need to hold it back at low limits today

---

bitcoin does not have 7.5billion users now. bitcoin will never have 7.5billion users.
the fee war alone is pricing out over 1 billion people as it is, so cool down on the whole 'one world currency utopia'. and think rationally
 

lol seems you have the wrong hat on today.

yet dynamic blocksize implementations have been publicly released AND RUNNING since last year..
but took core a 10 months to REWRITE their entire implementation.

cores implementation is not just a simple patch, it was a whole rewrite.
i really think its time you learn C++


firstly your playing semantics.. segwit is a BLOAT size increase(4mb). with a side effect of capacity increase (1.8mb-2.1mb)
the 4mb weight limit has no correlation to capacity. the base block and witness does..
which is having a one time side effect on capacity increase, but cannot scale. EG you cannot re segwit a segwit, so has nothing to do with scaling. its a one time boost. stop over selling it.

secondly your right segwit doesnt mean moving txs to LN. (but your just twisting 'why' its not directly involved with LN)
much like seeing a baby take its first step doesnt mean all babies should be entered into a cities marathon race event.

but without being able to take a certain step early on, marathons in the future would never happen.

lets atleast not think that marathons are made compulsory for anyone able to walk in the future.
lets atleast not think LN is compulsory for anyone able to use bitcoin in the future.

so i hope i never see you in the future talk about LN as the solution to scaling. or i will have to refer you to this post to remind you

though code is not finalised. the mindset and concepts are becoming established. by atleast talking about it and making people aware of the concepts being stupid, may tempt the devs to change it before its locked into code..
rather than staying quiet with a wait and see and then have to put up with their code because they were not told what users want and dont want early on.

LN so far, are focused more on incentivizing nodes to stay active by making them profitable.

seems like your asking the big question about why bitcoin is such a big invention, and why immutability is important.

yes, thats the whole point. able to change who deserves what and how much they deserve. done in seconds rather but not secured by bitcoins PoW.
if funds were as secure as bitcoins blockchain while in LN. then we wouldnt need miners..


also remember bank accounts is a choice for the user, whether he or she wants to use it or not. but users can verify thieir balance when they count out the bank notes when closing a bank account

thats very loose logic.. thats like saying dont worry about bank accounts you can always ask them to write you a cheque and get your account closed. and use the cheque to buy gold

yes as a choice, i see its utility for gambling, exchanges, faucets, advertisers.
as for what they are choosing. people atleast have to be aware of the choice. and some people need to be reminded it is just a choice and not try pushing it as bitcoins only future solution.

as for how its deemed banking managed system
DUAL SIGNING. imagine a hub as a local bank branch. lets say there is a walmark bank2.0, starbucks bank 2.0, etc. where the funds are not exactly yours because you need permission from a separate entity to change how much you deserve and permission to separate yourself from their control to go back to the open network (bitcoin mainnet).

shying away from negatives and sitting on hands not even talking about issues solves nothing and doesnt help to make people aware of the whole picture.

having a sit back, shut up and wait and see attitude is something that lets a small group decide the direction of the masses because they are not told anything different. we as a community should be active and part of deciding "what users want". because we are the users, we are all bitcoin and we all should not put "trust" in a small group of people.

firstly. LN was envisioned due to your exact theory.. a background mechanism for exchanges.. blockstream made a private "liquid" network using multisigs. and then realised it could be used more broadly.. and thus LN concepts came to fruition.

it must be noted that channels need to be closed because the locktimes expire due to time and utilizing the time to make old 'payments' irrelevant, thus it runs out of time sooner to keep latest relevant and needs to close to secure a most relevant mutually agreed 'payment' before older LN payments become relevant.

EG imagine now its 02:00:00 26th Nov 2016 that the 'deposit' is paid.
with a locktime of say 03:01:00 26th Nov 2016 (1h1m) for simple explanation
first payment in LN you set and agreed to make it more relevant but unspendable until 03:00:59
next payment in LN you set and agreed to make it more relevant but unspendable until 03:00:58
next payment in LN you set and agreed to make it more relevant but unspendable until 03:00:57
and so on

obviously it doesnt mean you can do 3660 transactions(1h1m).
because:
you may not transact for 10 minutes. meaning you missed out on 600 possible alterations to the locks by doing nothing.
EG time is 02:10:00 - you cant write a tx locked to be unspendable until 02:00:01 because that time has passed.
you can only alter the locks while available locktimes exist ahead of realtime meaning doing nothing for 10 minutes leaves you only 3060 possible tx's

you may not transact for 40 minutes. meaning you missed out on 2400 possible alterations to the locks by doing nothing.
EG time is 02:40:00 - you cant write a tx locked to be unspendable until 02:00:01 because that time has passed.
you can only alter the locks while available locktimes exist ahead of realtime meaning doing nothing for 40 minutes leaves you only 1260 possible tx's

also because
if you opened the channel at 02:00:00 and instantly done 3659 tx's in milliseconds. the altered locktimes have now got to 02:00:01. so you have to close the channel to broadcast that most relevant 02:00:01 tx before older transactions become relevant/spendable

i read it and i can see the theories you are trying to establish.. but i think you need to do a bit more research.
i can see atleast 3 issues which can easily pull apart your debate.

here is a hint about one of them.
the cost to mining pools, you debate about the fee:reward ratio.. but your forgetting another HUGE metric that causes your theory to fall flat.

ignoring kiklo's endless attempts to try selling his zeit altcoin as something better by shaming bitcoin..

LN can be considered a bank network.
afterall.. what is a bank

a system where your not in full control of your funds.
the bank can put limits on your spending habits by refusing to authorise transactions
customers require the banks authorisation/agreement.
the only recourse in a disagreement is to close the account

although LN is not a central bank. it is a next gen localised bank. where LN hubs become the new bank branch managers

you can glorify LN as being linked to the open bitcoin network should a customer want to close channel.

but thats just like saying a bank manager of a local bank branch is a glorified accountant supervisor who has no control of SWIFT/cheque clearing house should a customer wish to close their account and take funds elsewhere.

accepting what LN is.. a side option/service. rather then an endgoal solution to bitcoin.. is the way to think about it.
LN has utility for fast action users like satoshidice, faucets, etc. but its not the solution for everyone

---

oh and as i was saying about the 'concepts' the LN devs are coming up with that are CONS

if anyone wants to know about one of the ECONOMIC methods or thwarting DDoS (rather than code)
if anyone wants to know about one of the ECONOMIC methods or thwarting extortion/deceit (rather than code)
https://lists.linuxfoundation.org/pipermail/lightning-dev/2016-November/000648.html
half way down it says "results" where you can download their open office spreadsheet that displays the prepay buy in and all the penalty fee's

yea i facepalmed reading it
conclusion was the buy-in fee of 0.006(~$4) was not high enough to impact an attacker. (2nd facepalm: the whole posted didnt mention using CODE to fix risk)