dont oversell it.

that 1,8x old stat and the updated 2-2.1x new stat is ONLY TRUE. if 100% of people move funds away from legacy(old) keypairs and directs funds over to the new segwit compatible HD seeded keypairs, and 100% sticks with using segwit.

if not all users used segwit it WONT be close to your numbers. so dont oversell it

segwit was a blockstream project under the "elements" codebase, unrelated and incompatible with bitcoin in 2015-mid 2016.
 
it was put onto its own sandbox (altcoin testnet) in the spring 2016, totally not emulating bitcoin, but thrashed about until it kinda resembled what bitcoin does. it did not even get a chance to be on a bitcoin emulating sandbox (testnet) until june 2016.

this means just to get basic bitcoin-esq functionality it has only been in bitcoin-esq ability for 4 months (june to october). even the latest release 0.13.1 is not a final, fully functioning version just waiting to be activated. it requires a further download after activation..

so TKEENAN, has got some things right as do the others with differing opinions on both sides. it is not the same 2009-2016 bitcoin we knew,
it is just an implementation that has been made compatible to then divert people away from the traditional bitcoin keypairs and data store methods for those that choose to use it for that possible one time capacity boost.

---

its been 1 year since their scaling promise(that also promised dynamic blocks) and they have only released activation parameters for a onetime boost. where that one time boost is only possible if everyone drops their standard private-public keypairs and moves funds to segwit compatible HD seeded keypairs.

it has required users to download 4 different implementations to get to a stage of even being close to activating their one time boost.

lets atleast hope that by the blockstream devs saying 'its all ok'. they are currently this second preparing that 5th download to include dynamic block sizes along with the actual segwit wallet capability to actually utilise segwit. so that everyone can get what they want.

after all, they obviously have spare time to work on dynamic blocks now they believe segwit code is ready and have nothing else to do.. right!?.

user nodes cannot veto it out.
and now you see why blockstream went for a soft fork.


all blockstream needs to do is coax 15-20 pools

so far they tried it by doing fully paid all inclusive weekend meetups..
they already had 4 this last year..
unless they were hoping the 'scaling bitcoin' in Milan this October would have been enough. (should have picked somewhere warmer)

but hey, theres always the new year to plan a nice tropical spring break to kiss some ass

anyway blockstream have a year to coax pools. no need to rush.
but here is a hint listen to the community: dynamic blocksize+segwit
like promised last year
heres another hint:

dynamic blocksize: default starting at 2mb base 4mb weight.

that way its both segwit and actual scaling.
and yes 2mb base 4mb weight DOES actually mean 1mb base 4mb weight is acceptable

do it as a 2 stage consensus
1a)usernodes, 95%(yes it might take upto a year, but nothing will happen before that so no harm in atleast releasing he code to give a choice)
1b)followed by a 2 week grace period.

THEN
2a)pool 95%(yes it might take upto a year, but nothing will happen before that so no harm)
2b)followed by a 2 week grace period.

so its win win

knowing the time of (1b)->(2b) than enough time to reduce the 260(5%)nodes of 5400 that didnt upgrade at (1a) by them upgrading

yep thats right the nodes get to have a say, after all they are the ones doing the validating, relaying and storing the blockchain. only fair they get to be part of activating something by being full node ready to accept it by the time it activates.... not after

unlike segwit is doing the opposite. which is going to wait for pools to activate and then waste a few weeks twiddling thumbs before actually releasing 0.14 that actually has segwit (and wallet) features fully utilisable.

but hey..
segwit thinks christmas seems "safe".. so they should not argue about any timescales.
especially knowing a real consensus upgrade wont actually activate without node consensus, the way it should be

i feel pity for anyone that may reply to defend blockstream and the 90 unpaid interns. purely "because blockstream rules".
i feel pity for anyone that may reply to defend blockstream and the 90 unpaid interns. purely "because blockstream should dictate".
i feel pity for anyone that may reply to defend blockstream and the 90 unpaid interns. purely "because blockstream owns bitcoin".

those types of people have no clue

nope... the unit of measure has moved from X to xxxx
they would just resized the barrels. to keep an artificial human visual accounting limit of 21 million barrels. yet each barrel contains more litres.

EG
lets break it down into binary


1 sat is 00000001
you cannot go any lower!!

1btc is 101111101011110000100000000

however adding more units does not mean that 1btc stays the same
for instance, lets say.. going to millisats.

1btc - 101111101011110000100000000
becomes
1btc - 1011101001000011101101110100000000000

do you notice that although there are only 21m btc.. not just the unit of measure has changed but it also affects how
it is stored on your computer.

in short anyone holding a value of 1BTC now. would be only holding 0.0001btc if a change happened. because the immutable blockchain has the value LOCKED as:
101111101011110000100000000
which cannot suddenly be magically changed to
1011101001000011101101110100000000000
to ensure you still have the new "1btc"

the bait and switch however would be hidden in code.
it would also require people to redownload and resync the entire blockchain to store 1btc as
1011101001000011101101110100000000000
instead of
101111101011110000100000000

its not a case of having an orange and instead of selling a whole orange, your selling segments of oranges at a fraction of the price
its having a basket of oranges that you just call an orange. an then the individual (old) oranges you then call segments.

which means if you do the maths and look at the code. farmers have to farm for longer. but on the fruit stall sign you have stated there are still 21 million oranges (new baskets) but your fruitstall is more crammed (more bytes of data, more units of measure)

i understand the greed mentality of "yes i can buy one bitcoin (basket of oranges) and it will feed more people(more units of measure). the issue is that 1btc (basket) will drop in price due to supply and demand

the rule is 2.1quadrillion units of measure limit.  quantified as baskets of satoshis called bitcoins equating to a 21million bitcoin limit for easy human understanding.
the hard rule about rarity and scarcity is how obtainable individual amounts, not baskets volume.

every time the price rises someone always tries to demand that the units of measure changes to go above 2.1quadrillion exchangeable units of measure limit

here is just one of the early ones.. from 2011. pretty much within 2 months of satoshi leaving people wanted to go against satoshi's design (facepalm)


it was not the first attempt and wont be the last

its an endless cycle. price rises, people then want to be able to split up their holdings to hand out to more people (double profiting in their mind) but if it actually happened the opposite to their greed would actually result

so your blaming a dead cat connected to a rotten car battery, for why and the house of 20 people is a mess.........
................ think about it

day 1.

day 2.

day 3.

bitcoin unlimited are not proposing a fork in the way you are suggesting.
seems you need to research some more.

if you did not realise it BU has released and full code running since 2015. running on bitcoins mainnet.
core for instance have made many propositions. such as rusty russels millisats, luke Jr's tonal bitcoin both of which change the units of measure.

also its actually core making demands for BU to fork off.. (not very community spirited for what bitcoins ethos of open no barrier of entry, WAS)
anyone thinking only CORE should exist with no diverse counterpart to level the playing field are people that want a dictatorship where there are no ways to veto out bad rule changes

cores latest implementation that meant to offer extra new features is not actually running. yep. they deactivated the segwit wallet. you cannot make a segwit transaction right now. and are required to download yet another implementation after activation.

BU doesnt require you to download endless implementations.. getting spoon fed by devs in a oliver twist script of "please sir can i have some more"

core so far have had atleast 5 implementation releases concerning the ability to make segwit possible and its still not ready to run live.
also even after activation its not 100% running live. they will make you wait for the activation, wait for the grace period, then wait again until they deem it ok for users to make segwit transactions by requiring you download yet another implementation.

please research and dont preach the 'core' choir especially when you dont understand that satoshis 2009-2013 "qt" is nothing like blockstream funded employee and volunteer intern handled "core" of 2014+.

be realistic

im laughing at you blaming a possible segwit veto on BU

you do realise that even without BU's ~9%.. there are pools with HIGHER % that are not confident about segwit. for reasons UNRELATED to BU.
trying to put all the blame on BU is like blaming your dog for having a messy house of 20 people(pools)

the reality is while everyone is pointing at the dog atleast 5-15(pools) people are creating the mess you are worried about.

wake up have a reality check and get some prospective

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