the biggest thing the OP is missing

4 years ago. someone spends $1600 on equipment. that has a power draw of ~1.4kwh = same costs, same electric...
but..... it only hashed at ~300 M/hash(4gpu used on 2mainboards with 2 700wPSU)
this was the olden days of GPU mining

today. someone spends $1600 on equipment. that has a power draw of ~1.4kwh = same costs, same electric...
but..... hashes at ~13 T/hash (1 s9 bitmain)
this was the current days of ASIC mining

in 4 years someone spends $1600 on equipment. that has a power draw of ~1.4kwh = same costs, same electric...
but..... probably hashes at XX P/hash (some crazy assed asic)

you are failing to grasp the basics.
there are ~2100000000000000 units of measure that will ever be produced.. this has been the rule since the genesis block.
people at GUI and human interaction level can be free to call 100 units 'a bit' or 100000000 units a bitcoin. but at code level there are only going to be 2100000000000000 units created by the year 2141 (binary 111-01110101-11110000-01011010-00000111-01000000-00000000)

again AT CODE LEVEL and LOGICAL level of rarity.

if someone has (1btc) 100,000,000 units linked to their keypair..
(100,000,000sat(1btc) = binary 101-11110101-11100001-00000000 where each unit(sat) is binary 00000001)

its only the GUI that displays (binary 101-11110101-11100001-00000000) as 1btc..
its only the GUI that displays (binary 00000001) as 1sat..
if you want to add more units to bitcoin. you have to mess with the binary of units.

because  the code or blockchains stored ledger entry level does not show "btc" it shows and works with binary units. only the GUI displays btc
so
by adding units to the CODE...(changing the binary unit maths) then a decision must be made about how to display it on the GUI.
by making one sat (binary 00000001) to become (binary 00000011-11101000) so that there can be 1000 millisats (1millisat binary 00000001)
meaning because there are more units. the binary equivelent of 21m btc goes up to compensate
binary 111-01110101-11110000-01011010-00000111-01000000-00000000 becomes
binary 11101-00100100-10110010-11011111-10101100-01010010-00000000-00000000 to allow for 1000 extra measures
means things need to change on the GUI

decisions:
1)is each unit(binary 1) a 100 millionth part of a bitcoin. meaning there are 21billion bitcoins (you will say no)
but saying no, requires some how "crediting" a user with 1000x more units to keep them inline with having one 21millionth of the cap, to pretend there is still 21m btc..
so they dont suffer the rarity decline.
good luck trying to program that 'credit', as it requires rewriting old blocks so one sat (binary 00000001) becomes (binary 00000011-11101000) 1000 millisat to then have bitcoin holders still having one 21millionth of the cap

or
2) is each unit as 1000th of a satoshi.
1btc was (binary 101-11110101-11100001-00000000) but is now (binary 10111-01001000-01110110-11101000-00000000)
meaning that AT CODE LEVEL users who had 100,000,000 units still have only now only (binary 101-11110101-11100001-00000000) which at GUI level leaves them with 0.001btc to keep to the "21mill btc cap"

meaning anyone having funds from the last 7years would have their value diluted either way. but miners now get 1000x more units per reward and able to mine for another 40 years before the units are depleted.

please stop thinking about it from the fake GUI display end and think of it from the code protocol end. because you are really starting to reveal your lack of understanding bitcoin and the rules set in place

carlton.
wake up.

1 unit of measure UP =2100000000000000 cap

lets use gold as an example
1 grain of gold. with there being 2100000000000000 grains of gold in the world.
by even suggesting to add more grains of gold. ruins golds rarity. it even affects when 'all the gold' will be mined

even if you then say 100,000,000 grains was an ounce and now lets rename it so 100,000,000,000 grains = an ounce. doesnt change the fact that there are more grains of gold being created. it dilutes the value of each grain.

but its becoming obvious. carlton secretly wants to ruin bitcoins cap as he is really trying to push bitcoin eventually moving the units of measure as being a positive thing.

personally we should not even think about changing bitcoins unit of measure. and only debate who wins the math rounding of the offchain measures when converting back to real sats

to explain
ethereum was not a consensus vote. it was an intentional split. as proven by " --oppose-dao-fork" mechanism that literally bans each side from orphaning off(consensus) each others chain,

if  --oppose-dao-fork was never used, orphans(consensus) would have taken care of the minority to leave only a majority chain

i dont think we should be using ethereums tactic as a dirct comparison to what has been proposed by any bitcoin dev. but should be used as an
example of consequence/warning of proposing such stupid split idea's (again bitcoin dev proposals are not about splits)

bitcoin wants to stick to a consensus (either code required or social pretence) to ensure there is only one chain, chosen by the majority.

lastly miners dont/wont jump the gun soon unless they see good acceptance by users.
EG knowing a payment gateway can validate the segwit transaction, so that miners/pools can spend their funds to pay for electricity and wages.

which unlike ethereum who split before even seeing if exchanges would accept the split. which has caused loses.

inshort miners wont flag their desire for segwit unless they know merchants and exchanges will accept and be able to validate segwit tx's

so as i and Velkro said. be patient its not going to happen until merchants review and accept the code. and miners see their favourite exchanges/services accepting the code to know they can spend funds.

LOL you are failing. its you that doesnt understand. there is no division at code level.
at code level if bitcoin was to change to match LN its not dividing bitcoin, its increasing the units.
at code level it has always been 1sat UP not 1btc DOWN

again
changing the units of measure
2100000000000000 into
2100000000000000000 units which also changes when new coins stop being created. (from the year 2141 to the year 2181)

which makes the units less rare as now there are 1000 times more units to share.
but again i say lets hope we never have to debate such a proposal and only have to argue who 'wins' when rounding out return a real satoshi count

have a nice day in your bubble world of fake misinformation and propaganda

mining will continue.
the reward ends in the year ~2140,
giving over 120 years for the ratio of   reward:txfee   to flip where the txfee becomes the dominant income

its something we should not be pushing for today, as i said we have 120 years for a natural growth and slow flip of the ratio.
the fee's will eventually keep miners having a happy income

im laughing

blockstream is:
funded by banks (yep they also get funds from r3) -  research hyperledger board (R3, DAH) and blockstream connections..
want 4mb (not 2mb)
slide in a change that does need consensus at coding level, but has a threshold for 'social' resemblance of needing consensus
wants to obstruct/delay real capacity
doesnt fix double spends due to adding CPFP which can be used by double spenders. its like fixing a hole and then hammering out another hole elsewhere

anyway. i hope the blockstream fanboys wake up one day to the hypocrisy of blockstream

do you think you will be using the exact same computer in 10 years.
if anyone right now is using a windows XP computer with just a 20gb hard drive and 512mb ram (standard 10 years ago) they only have themselves to blame for not bing able to run a node today.
similar thing wil be said in 10 years.

on average a person upgrades their computer every 4 years. so in 10 years their pc should be 2 generations ahead of now.

LOL

1mb=52gb MAX per year (1*144(day)*365(year))
2mb=104gb MAX per year

as displayed


so traditional 1mb block consensus= 0.52tb MAX after 10 years. (actual bloat will be lower then this)
so traditional 2mb block consensus= 1.04tb MAX after 10 years. (actual bloat will be lower then this)
so segwit softfork 1mbbase 4mb weight = 4.08tb MAX after 10 years. (actual bloat will be lower then this)

doomsday debunked

have a nice day

lightning CAN be used for blackmail.. even people think that right now mining pools demand for txfee is blackmail. yet you call it a "free market" which you have openly said hubs/pools can choose to demand any fee they like 'because of the freemarket'

as for the units of measure, go read some code. please. as it seems even you have forgot/never knew the real unit of measure at code level,

but lets hope we never as a community have a proposal that bitcoins consensus rules need to change the units of measure to match LN. and only have to debate LN's rounding, and who the rounding is in favour of.

i feel you only see what the GUI and human brain calculates it to after the fact.
you seem to be, (using another example) a 'bitcoin averages 1block every 10minutes' (GUI mindset) kind of guy,
where as im more of a 2016 blocks every ~fortnight kind of guy (code level mindset and then flip it to a more fitting laymens understanding)

the uptopian concept is, to lock funds in you have to put funds into a bitcoin onchain tx to the multisig.
you then play around with the hubs 'millisats'
at the end a bitcoin onchain transaction including a bitcoin fee gets put on the bitcoin network to unlock funds.
EG
onchain:
user (0.04) -> hub (0.0399) (0.0001 on chain fee)

offchain (lets say offchain fee was 1sat(1000milisat)
user(3990000000) starbucks(0)
user(3499999000) starbucks(499999000) (user pays 0.005btc((500000000ms)=$3) to starbucks) (LN has 2sat 1 from starbuck 1 from user)
user(2999998000) starbucks(999998000) (user pays 0.005btc((500000000ms)=$3) to starbucks) (LN has 4sat 1 from starbuck 1 from user)
user(2499997000) starbucks(1499997000) (user pays 0.005btc((500000000ms)=$3) to starbucks) (LN has 6sat 1 from starbuck 1 from user)
user(1999996000) starbucks(1999996000) (user pays 0.005btc((500000000ms)=$3) to starbucks) (LN has 8sat 1 from starbuck 1 from user)
user(1499995000) starbucks(2499995000) (user pays 0.005btc((500000000ms)=$3) to starbucks) (LN has 10sat 1 from starbuck 1 from user)

so the user has paid 5sats to do 5 LN transactions
now lets settle

hub (0.04) -> the user (0.01489995) (0.0001 on chain fee)
hub (0.04) -> starbuck (0.02499995)
hub (0.04) -> LNs host (0.00000010)

so LN's host gets 10sats thanks to 5 offchain tx of 2 users at 1sat rate
and bitcoin miners gets 20000 sats thanks to 2 tx lock in and settle

bullcrap
seems you dont understand bitcoin at code level. because at code level there is no 21million bitcoin cap.
at code level the units of measure are not bitcoins but satoshi

its not bitcoin measured down. but satoshi measured up
where each block reward is not producing 12.5btc. but instead
1250000000 units
which halves every ~4 years

which calculates as 2100000000000000 unit cap by the year 2140.

by adding more units (decimals at the GUI front end) makes the amount of units per blockreward change from
1250000000 units to
1250000000000 units

which calculates as the year bitcoin stops producing units change from 2141 to 2181 and produce
2100000000000000000 units instead of
2100000000000000 units

but ofcourse thats if blockstream wanted to mess around with bitcoins 'unit of measure' to match the lightning unit of measure, instead of rounding the lightning unit of measure when closing the channel.

i can see future 'debates' of people arguing who 'benefits' from the rounding to fit bitcoins unit of measure. but i hope we never have to debate
changing bitcoins unit of measure to match lightning. otherwise that is SCREWING bitcoins rarity.

locking funds into multisig is the same as putting funds into a 'managed' account where it requires duel signatures to settle funds movements.

LN can be useful for people that want to raid faucets for a few weeks to receive a few units without 'spamming' bitcoins blockchain. but
LN due to it being 'managed' by some entity should not be trusted as the 'forever solution' where people lock funds in forever.
LN due to it being 'managed' opens up new weaknesses. such as blackmail eg (hub:"we will not sign a tx unless you pay 1btc fee to get funds back"
similar comparisons can be made to pools now, not accepting transactions into a block unless you pay over 0.0001 btc

so its not only who benefits from the 'rounding' but also the corruption of changing/demanding more fee per tx just to close a channel to get funds out. ending up as costing the user more to settle blackmail style or forced to stay in the channel out of fear of losing more then they would getting out.

is the case. deposit real bitcoin into a multisig requiring dual signatures. just like a bank. without their permission you cant withdraw.


then play around with IOU "millisats" which are not bitcoin. obviously due to the 3 extra decimals,
where those funds are then only 'representing' real bitcoins, under the pretence they convert back when settling and rounding down,

as the other person said. all thats left is in a few years people dont deposit into a dual signature address anymore, but a single signature address wholely owned by the hub. "and....... its gone"

it is a deposit system though. watch the video!!
you have to get an address from a lightning hub to deposit funds into
this address is created using the hub. (hub and user make a multisig beginning with 2Mxzw...)
this address is the locking mechanism of the funds and requires lightnings authorisation to unlock, to avoid replay attacks/double spends onchain.
EG if the 2Mxzw address used in the demo solely belongs to the user.. then the user can buy 20 ASCII cats.. offchain. and simultaneously move funds out onchain.
but due to lightning needing to sign too, it locks funds in so that users can then make requests offchain using offchain 'coins'/units (millisats) and not able to touch the onchain funds.

the hub has a fee. and even funnier the hub is creating more "units" (3 extra decimals called millisats) where 0.04000000btc becomes 4000000000 milisats (0.04000000000) btc
as shown by
0.03924280000 millisat amount held (0.03924280 sat deposited)
0.00067600000 millisat fee taken (0.00067600 sat fee)

lightning has potential to help people who spend often. but lets not "do a carlton" and pretend its gods solution to everything bfore its even proven itself, before its removed its issues, bugs, flaws.
and before people like him have yet to understand it.

the video is just a phase 1 demo. im sure when they fix the flaws (big one is the extra 3 decimals which will cause issues) that in a few months it will become more clearer to people like carlton to 'maybe' understand it better.

also it has to be noted its the first TESTNET transaction.. not bitcoin.
because if its not involving bitcoins blockchain, its not bitcoin. (testnet is just an altcoin emulating bitcoin to act as a sandbox)

a blockchain course?? lol thats about 10 minutes of explanation. because blockchain is only 10% of the 'features' that make things like bitcoin secure.

here is the low down of explaining "blockchain"

imagine there was a clump of data.. well lets call it a block of data(reason becomes obvious later).. ill use short example of only 3 entries. instead of thousands.

DAVE: 0.2 sends to ADAM: 0.1
FRED: 1.2 sends to ABBEY: 0.2
PETE: 0.6 sends to MARY: 0.1

instead of sending all 3 (thousands) of entries to compare with other people to ensure they have it too. we can send a single bit of data that represents all of the entries.

for simple explanation. lets use MD5.
by hashing the block of data we get the md5 hash:
f48190892e689319fa01fc5378a2815a

this hash would change if any of the data was missing or altered. so by sending that exact hash, if the other person has it, then they both know they both have the same entries. and all the entries are identical..
cool right? able to validate a block of data without having to send the contents

now here is the next fun part.

imagine we have another block of data,

MIKE: 1.8 sends to TIMMY: 1.1
CLIVE: 0.2 sends to CHRIS: 0.1
JIM: 3.6 sends to DANIEL: 3.1

hashes to
c2f4298a37a830cb219d8539f1b10b80

now lets say you want to ask someone else if they have both blocks of data, and check both blocks of data are accurate.
you dont need to send the 2 hashes. instead you can send one hash.
and here is why

you simply add the hash of the previous block into the data of the current block, thus linking them together
eg

MIKE: 1.8 sends to TIMMY: 1.1
CLIVE: 0.2 sends to CHRIS: 0.1
JIM: 3.6 sends to DANIEL: 3.1
f48190892e689319fa01fc5378a2815a

this block of data now has the hash:
b73c1e9409095b30d1e5a4b3c64fe71e

again knowing that changing any of the data of the first blocks changes that hash and if that hash or the entries of the second block changes, the new hash would change.

so just sending b73c1e9409095b30d1e5a4b3c64fe71e to another person and if they too have that same hash then they both have the exact same
data of both blocks.
now imagine you add the hash to another new block. linking all the blocks to each other and only needing to send the latest hash to prove you have accurate data of all blocks.

this linking of block data via adding a hash to each block is called chaining blocks.. or simply blockchain.

now some notes:
using different hashing methods to achieve this, EG SHA1,2,3 or other hashing variants is within the realm of "blockchain"

but things like double securing the hashes EG ProofOfWork, ProofOfStake and other proofs, are optional extras outside the scope of "blockchain",

now imagine what comes next is great for colleges... (a course 'selling point')
but please feel free to sign up to a proper 'course' on POW (technically detailed)
but please feel free to sign up to a 20 minute 'course' on POS (doesnt need to be technical)

you can also learn about securing individual entries of data and proving the writer of the data has ProofOfAuthority
but please feel free to sign up to a proper 'course' on ECDSA keypairs, messages and signatures  (technically detailed)

its going to take time for miners to review the code and then implement the changes into their own versions.

so dont expect it to be an overnight thing.
this is the same reason core fans say that any fork cant have a month of review followed by a couple weeks grace for the laggers.

so relax it can happen,
but too soon to start calling it a point of lowering the threshold. otherwise it makes core a hypocrite by saying that other implementations should have 16 month 'waiting' periods, but want to rush and lower the thresholds for their own implementations.

after all the code of 0.12 and code of 0.13 have massive differences/rewrites.

in short: too early to tell. be patient.

bankers wont waste cash trying to dump the bitcoin price because even spending $10bill would just be some temporary price drama.

but contracting devs to do certain things to get a tranche of funding has already shown to have manipulated many devs of core into doing things against bitcoins old ethos. by this im talking about core/blockstream

bankers funding the main implementations.
R3 which core hates, actually funds core devs too.

all you need to do is look at who is on the board of hyperledger (Digital Asset Holdings and R3)*, who have invested in both classic and core.

Dah is the link of the national banks for a few countries
R3 is the link of many commercial banks

but shhh the first rule of blockstream is we must not talk about their funding.

i know many will say that only 12-20 devs are funded by banks and core has another 90 'voluntary contributors' but those other 90 are mostly reviewers and spellcheckers. and have little to no impact on the direction bitcoin goes as they are just the woolly sheep to hide the wolves in the field.

we should not rely on 1-2 implementations as thats the route to centralization and dictatorship.

the dev-groups need to follow the same game theory of mining. (avoid 51% dominance of nodes running the same codebase)
we need more diversity of nodes. because even 16000 nodes running core is just as manipulative as having 1 core node.
there should be atleast 3-20 codebases of full nodes by different teams not all paid by banks.

the only thing more nodes of one codebase (16,000 core nodes for instance) can prevent is ddos, viruses and power cuts of strategic locations. but it cant stop the manipulation of funded devs who want to move bitcoin users to a sidechain via increased tx fee's..
yep even core are adding tx fee rules into every node to prevent it transmitting transactions unless they pay a fee. (reinforcing a fee war) before it even gets to mining pools to allow pools to decide what is acceptable.

but hey, the sheep love core and love the centralized nature of having a dominant king dictating the path of bitcoin

wrong
chinese miners are competing because they MAKE the asics.
EG
every $1600 asic sold to mcafee, bitmain can make ~$400 asics..
meaning they can hand one to mcafee and keep 3 for themselves.
meaning they can hand one to mcafee and keep 2 for themselves leaving $400 spare to pay electric
meaning they can hand one to mcafee and keep 1 for themselves leaving $800 spare to pay electric

electricity costs
at 10c/kwh= 13cents an hour, = $3.12 a day, = $1,138.80 a year
at 5c/kwh= 6.5cents an hour, = $1.56 a day, = $569.40 a year

meaning even if mcafee can get 5c electric. unless they make the rigs themselves, mcafee's upfront costs are $2169.40 ($1600 asic + $569.40 electric)
bitmain however
receives $1600, makes 2 rigs gives one to customer, keeps one. and still has $800+ to pay off in full their year of electric as well as spare for wages
meaning they start off with NO costs. and every block they solve is 100% profit

with 1mb blocks that 1000gb will hit in 20 years (1mbX144(day)x365(days)=52gb)
with 2mb blocks that 1000gb will hit in 10 years (2mbX144(day)x365(days)=52gb)
with 4mb blocks that 1000gb will hit in 5 years (4mbX144(day)x365(days)=52gb)

$100 hard drive(2tb) gives 10-40 years space. and in 10-40 years larger harddrives will be cheaper
so lets say
2017 the buffer went to 4mb(but data fill of blocks were only just creeping over 1mb), (150gb historic data)
2018 the buffer was still 4mb(but data fill of blocks were only just creeping upto 2mb), (250gb historic data)
2019 the buffer was still 4mb(but data fill of blocks were only just creeping upto 3mb), (400gb historic data)
2020 the buffer was still 4mb(but data fill of blocks were only just creeping upto 4mb), (600gb historic data)
2021 the buffer went to 8mb(but data fill of blocks were only just creeping upto 5mb), (850gb historic data)

after 5 years thats only 850gb of space used. far far far below the 2tb hard drive it has, but the computer is old. and most people upgrade every 4-5 years anyway.. so in 5 years im pretty sure the standard hard drive installed in new PC's would be higher then 2tb to last another 5 years, and so on and so on
EG 16gb blocks = 5tb for 5years(850gb for 2017-2021 data, UNDER 4tb 2022-2027), no problem having a computer with a 5tb hard drive to last you from 2022-2027, and buying that computer in 2021 will be cheap

the blockchain historic data, is an initial large "chunk" of under 100gb (needed just once) and then thats it for a large "chunk".

after its downloaded the historic data "chunk", you are then only getting live data in small "chunks".. these are called blocks, which average 1mb every 10 minutes. and then transaction data which you get aswell

but remember your not constantly downloading the <100gb large chunk of historic data each month.. only the live data

this live data can be controlled to an extent
the more 'connections' to other nodes you have the more bandwidth you need to use to send the same data out again to those other nodes.
the less 'connections' to other nodes you have the less bandwidth you need to use to send the same data out again to those other nodes.
by connecting to stable nodes that are already synced reduces sending out historic data.
by connecting to unstable nodes that are not already synced increasing sending out historic data.

so if you have a internet contract with limited bandwidth, but your node has 25+ connections. then yes expect to be using 200gb a month bandwidth.

try 10 connections, limit forming a connection to anyone that is well well behind in syncing.. you will thank yourself for seeing less bandwidth per month being used for live data.

think of it like torrents. many merchants/miners and dedicated users have good internet and have real desire to be nodes, so they can be considered as the seeders. then there are the average guy with slow internet that dont critically need to be node(they dont have a bitcoin business or spend much bitcoin) so they can limit themselves while still being part of the network but with only a few connections. these can be considered leachers.

i would rather have leachers only having a couple connections so that they are not interrupting many people. and leachers would rather have
less connections so they are not using as much data. so its win win