rusty russel of blockstream LN fame wants to first introduce millisats into LN. and later change bitcoins measure to comply with LN.

one thing to know

its not 21million rule, thats just named that for the human mind to put the real rule into a less coded, less mathematical concept average joe can understand without their mind exploding, buzzword.

it does create 21million btc. but you have to understand HOW

the rule is actually:
each block reward was 5,000,000,000 units of measure from block 0 to block 210,000(50 btc per block for 210,000blocks)
totalling 1,050,000,000,000,000 units of measure in circulation (10.5million btc)

then it halves for the next 210,000 blocks.
meaning
each block 210,001-420,000 reward was 2,500,000,000 units of measure 210,000(25 btc per block for 210,000blocks)
releasing 525,000,000,000,000 units during this period (5.25million btc)
totalling 1,575,000,000,000,000 units of measure in circulation  (15.75million btc)

then it halves for the next 210,000 blocks.
meaning
each block 420,001-630,000 reward is 1,250,000,000 units of measure 210,000(12.5 btc per block for 210,000blocks)
releasing 262,500,000,000,000 units during this period (2.625million btc)
totalling 1,837,500,000,000,000 units of measure in circulation (18.375million btc)

and every 210,000 blocks the reward halves, releasing half as much and so on and so on until no more units of measure are rewarded

thats whats wrote in code.
which calculates in the year 2140ish each block will only make 1 unit of measure per block.. and then thats it. no more.


bringing the total ever made to just about 2,100,000,000,000,000 units of measure
more precisely 2,099,999,997,690,000 units of measure (20,999,999.9769btc (~21million btc)

the rarity is that at best it can be split up into 2.1quadrillian parts

however human minds dont like big numbers. so the user facing GUI treats
a unit of measure has been called a satoshi (singular 'sat' for short, plural 'sats' for short)
1 unit of measure as 1 sat
100 sats as 1 bit
100,000,000sats as 1btc or 1,000,000 bits
1,250,000,000sats as 12.5btc or 12,500,000 bits
2,500,000,000sats as 25btc or 25,000,000 bits
5,000,000,000sats as 50btc or 50,000,000 bits
and ofcourse
2,100,000,000,000,000sats as 21million btc or 21,000,000,000,000 bits

---

the main premise is bitcoin would only make 2.1quadrillian sharable units ever. and that was a hard rule no one should change as its an economics rarity thing

---

now.. here is the thing.. although the code is measured in sats and only the GUI / human brain sees btc..
some banker paid devs are actually trying to play with the units of measure that will be rewarded to mining pools.

EG
instead of:
1,250,000,000sats, being rewarded per block they want
1,250,000,000,000 millisats

code form
1,250,000,000units of measure.. becomes
1,250,000,000,000units of measure

meaning 1000 more units of measure (1000x more split-able and shareable(less rare)) which also extends the minimum life expectancy to change from the year ~2140 to ~2180

this trick is done by although at code level making there be 1000 more units of measure. they still want to play with peoples heads by:
1,250,000,000,000 millisats is a btc.

and
1 unit of measure is a millisat
1,000 units of measure is 1 sat
100,000 units of measure is 100 sats or 1bit
100,000,000,000 units of measure is 1btc or 1,000,000,000 bits

they are hiding the split-ability, separability, (destroying/diluting rarity) by moving how many units of measure is declared a bitcoin.

and yes this is being done by developers funded by bankers

---

here is another thing,
them same banker paid devs want to mess around with the halving mechanism and even make the individual blockrewards adjustable as a punishment for wanting more transaction capacity in said block
like this https://github.com/maaku/bitcoin/commit/ad4c77f1ff2c370f67538e01fd082d231b57f2d0

your scenario using outdated concept already has.. but ill explain in easy steps based on your outdated scenario
you can read previous pages.. but here step by step.

1. do you agree that LN uses multisig. where 2 parties co-sign agreed tx data. if yes read on, if not, research and come back later

and why do you think banks do charge backs.
seriously.

think about it.. your topic is about scaling. where you are thinking that LN is the solution. will the whole community use LN and not care about onchain?

no

a system where funds are locked for a week after settling. where they cant be spent....... = worse then merchants/customers get from accepting visa/paypal
a system where the other person can trick the system and chargeback in that week........ = same as visa - worse than wire transfer
a system that

at the moment some of those issues that you are trying to disguise are being weeded out and thrown out. hense your out of date.
however there are still some issues even with the latest concept.

i think you should let go of the tight grip you have on last May. go read the mailing list, go check out IRC. if you prefer google. use the search tools and set it to only 1 month ago.
get yourself upto date..

oh and yea. the article writer.. is not a coder, his speciality is politcs and history.
it may help you to actually create a multisig and actually see the things you can do with a multisig. play around. go to a testnet and do some stuff. learn more about it.

for instance the many other penalties LN dev's are dreaming up on one banker funded team.. vs the other concepts that are just doing ethical and dual signed mutually assured version of LN. where CODE ensures no risk no loss.

you can usually spot the banker paid devs who thing economic penalties are the answer. and holding funds ransom for days is the answer

move passed the May2016 article, it will help you

have a nice day

you literally talk about a chargeback method where bob can get funds destined for alice, then suddenly say its impossible

but im loving how your changing the theory..
im guessing you need to update yourself

anyway. you can continue theorising with old concepts. while i continue looking into the latest stuff that has overcome some of the issues your OLD concept had.

goodluck though
have a nice day

lol

your article is out dated. its actually time stamped may 2016.

also even if you believe its current try reading it fully.. learn multisig.

have a nice day

core devs dont care about bitcoin. they want everyone offchain so they can throw the onchain tx sky high to make people hate bitcoins blockchain.
then push people over to hyperledger..

core devs spend most of their time working on the hyperledger.. by core devs i mean the PAID devs.. not the 90 unpaid interns that just spellcheck the code.
pieter wuille - paid by blockstream - team leader segwit - also programs bankers hyperledger
Rusty Russel - paid by blockstream - team leader LN - also programs bankers hyperledger
matt corralo - paid by blockstream - main committer - also programs bankers hyperledger
greg maxwell- paid by blockstream - main committer - also programs bankers hyperledger

i could name more

i see your failure.
1. outdated. may 2016
2. belief that alice and bob have separate(slightly differing) copies (um thats the opposite of the bidirectional buzzword)

in simple terms
its one transaction data they BOTH agree on and both treat as most relevant and both keep
EG (ignore the addresses they are random letters and numbers obviously)

Txid
In:3abcdeklmn987654321 val:5btc (originally A(X) deposit)
In:3abcdeklmn987654321 val:5btc (originally B(Y) deposit)
Out: 1abcdefghij123456789 val: 9btc (goes to A(X))
Out: 1klmnopqrs987654321 val: 1btc (goes to B)
Signature (A(X) signed inputs and output to agree)
Signature (B(Y) signed inputs and output to agree)
lock: now+9d23h58m

where they simply change the out values to who deserves what and then sign together to enforce it.
a tx wont get into a block without both signatures.
so both need to sign the same copy

thats the whole point of multisig. (buzzword bidirectional)

obviously with the out which goes to A can be a script that can halt A from being able to spend it straight after its confirmed
obviously with the out which goes to B can be a script that can halt B from being able to spend it straight after its confirmed

but its one transaction not 2 transactions.
its not about A holds one tx in their favour
its not about B holds one tx in their favour

they both hold the same relevant tx at the same time.

however if they keep a channel open that surpasses the locktime(onchain) set up when opening the channel EG
20 blocks after.. the malicious user can look at their LN history and grab a tx from the say 1-19 relevance ago. and that too would also now be relevant because they went passed the deadline.
which is the case not just for recent concepts but the outdated concept you dragged up from may2016

in your concept. there is a 1000CSV block delay even after its in the blockchain (much like blockreward coinbase tx has 100 block delay)
however the failure of that is simple.
your article says it

having a week CSV delay(1000 block) that can be interrupted by another person broadcasting a more relevant tx.. fails
because the LN outputs are already on the blockchain when alice (x in your other scenario) closed the channel.

also another fail is because although on the blockchain. it cant be spent untill it matures in a week. thus like banks... its not "available balance" which then is worse than Visa because visa settles in 2 days.

and by going by your scenario. during that week it can be "charged back" to bob (Y) going by your scenario

see the social issues with that.. funds not being spendable for days..and chargebacks possible!!

thats why other concepts are doing the opposite. having relevance time locks within LN to close a channel sooner and getting it broadcast sooner and simply opening a new channel if the 2 parties want to continue transacting

ok clear the matter up.

at any majority. the orphan game will eventually sort it self out.
at a low majority say 55%. it might take a many blockheights where half is disagreeing and the orphan rate is say 65 blocks of 144 have a corresponding orphan..
headache nightmare .. headache nightmare .. headache nightmare
mining pools will be screaming. nodes will be syncing and losing sync.. bad for everyone.. but deemed temporary drama as eventually it leads to one chain and the minority left unsynced.
retailer merchant guidance: wait upto say 100 confirms before fully trusting a tx

at a low say 70%. it might take a many blockheights where a third is disagreeing and the orphan rate is say 42 blocks of 144 have a corresponding orphan..
blah blah same thing. a bit less screaming, but lots of crying still while the orphan drama sorts itself out
retailer merchant guidance: wait upto say 70 confirms before fully trusting a tx

at say 85%. it might take a few dozen blockheights where inder a quarter  is disagreeing and the orphan rate is say 20 blocks of 144 have a corresponding orphan..
blah blah same thing. not screaming, but not much crying while the orphan drama sorts itself out, but not happy
retailer merchant guidance: wait upto say 45 confirms before fully trusting a tx

at say 95%. it might take a a couple blockheights where a few is disagreeing and the orphan rate is say 7 blocks of 144 have a corresponding orphan..
not as bad and miners could live with a slight risk elevation compared to the usual 1-2% a day they usually put up with.
retailer merchant guidance: wait upto 10 confirms before fully trusting a tx

usual daily 1-2% risk advises waiting upto 6 confirms

you do know that multisigs needs 2 signatures.
you do know that to agree to what you call a "commitment" both parties need to see and agree to it.

so if your saying Y cannot transmit X's preferred tx because Y has never seen it, been handed it or knows of its existance.. then im guessing whatever LN concept you are viewing has far more weaknesses.

i made the bits bold that you mention.. first bold bit.. an old state.. im assuming for practical reasons Y did infact see that state earlier in the day/weeks when it was relevant. so by seeing it, would have (lik any malicious user) kept a copy of it. then as shown by the second bold part its assumed Y is involved to signing the commitments by seeing the commitments..

reason being both SHOULD be signing together.. so my last paragraph is highlighting even your scenario assumes this to be true..
so im not sure why last post says Y never had first state

^ wrote to try showing how X cant attack but reveals Y is now the attacker
which is another attack vector.

cant you see the attack vector..
dont think about X doing the 9btc.. for X to gain.. thats then everted by Y(your hope of scenario outcome)

think about Y broadcasting th X9Y1... triggering X so Y can then get 10btc
lets say Y broadcasts X's 9btc. to then allow Y to broadcast the tx that gives Y the whole 10btc

anyway theres many concepts throwing about. and many attack vectors in each.
the bip u quoted is not strong enough on its own and actually makes one person gain.

not really a moral/equal paradigm like some other concepts i have seen

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