OK, Franky here is the challenge :
Give me the use cases where you think LN would work nicely in your opinion.
Where will SegWit and the LN not work for you?
What would be your ideal end solution for this scaling issue?
Where will BU address issues that are not being addressed by SegWit and the LN? {Where in your opinion would BU do it better?}
You obviously feel strongly about this... so let's take the dev's out of this issue and just concentrate on the code and what it might bring to the
table.
as for LN
niche market:
those multi spending every day: faucet raiders, satoshidice instant gambling etc
where LN fails to meet market need:
those only buying a weekly shop of groceries or occasional monthly remittance/rent payment.
EG if onchain cost $0.30 each and LN payment was $0.01 and default channel lock was 2 weeks.
niche:
if you gamble once a day. you might aswell voluntarily use LN because LN will cost you $0.74 to deposit, pay for 14 payments and withdraw(close channel). onchain would be $4.20 for 14 tx's
fail:
if you only pay rent every fortnight. you might aswell just stay onchain and pay $0.30. because LN will cost you $0.61 to deposit, pay and withdraw
segwit "promises" wont be achieved.. native malicious tx users would see to that. they wont voluntarily move their funds to segwit keypairs to foolishly disarm themselves..
malleable tx's will still occur, sigops, and just general tx spam will still fill up the base block preventing utility of the weight due to lack of segwit keypair users getting txdata into the baseblock.
plus:
there are 46million!! native UTXO's to 'spend' if you ever hope to achieve everyone moving over to segwit keys to then block off native key utility and actually get the promises.(never gonna happen)
as for malleation. well inside a LN its not just one person signing.. its 2 people.
so if a malicious person signed. their channel counterparty can double quadruple check what and HOW it was signed to see if malleation was used. and then sign their half. obviously the honest guy isnt going to sign the same tx later (malleated then non malleated).. thus the malicious party cant double spend because LN itself makes them reliant on the other person, thus unable to quickly push another tx with higher fee out to override the first one. as their counterparty wont allow it(by not signing).
meaning malleation is solved simply because its a multisig rather than a single sig requirement, making LN a malleability defence in itself without segwit required
to mitigate sigop and data bloat spam.. limit the txmaxsigoplimits. EG increase the blocksigoplimit. but bring the txsigop back down to 4000. or even less.
its kind of foolish to have a v0.12: 20k blocksigop limit and a 4000tx limit. meaning block cant take anymore tx if 5tx's max out blocklimt (5*4k=20k).
its kind of foolish to have a v0.14: 80k blocksigop limit and a 16000tx limit. meaning block cant take anymore tx if 5tx's max out blocklimt (5*16k=80k).
have it as a v0.14.1: 80k blocksigop limit and a 2000tx limit. meaning block cant take no more if 40tx's max out.(40*2k=80k).
(personally id have gone with 500 txsigop limit. not 4k-16k, that way atleast more tx's get into a block with only quadratic milisecond delays)
also reduce the 0.4mb 'large tx'data bloat) allowance.. why oh why oh why does anyone need 20%(sigop) or 40%(bloat) of a whole blocks limits. for a single tx.. seriously.. thats just asking for abuse.
as for LN in general. the dont re-use address 'side channel' attack is still a risk of LN exploitation(they see many sigs to attempt to figure out privkey) and segwit has not mitigated and has no fix for that
also imagine the promoted LN hop (where people are falsely promised a get rich quick by making profit simply being LN hope nodes)
alice< >daisy < >chris< >eddie< >bob
imagine it cost $0.01 per hop
alice wants to pay bob, but needs to pay daisy $0.03 to cover daisy($0.01 ) and chris($0.01 ) and eddie($0.01) to ensure everyone agrees to get the payment to bob
now imagine the hub
alice< >daisy< >chris
^ ^
v v
eddie bob
now daisy is a hub. alice can now pay bob for just $0.01 fee because eddie and chris are not needed as intermediaries(hop). only daisy is
if you think people will pay $0.03+ to remain decentralised.. when commercial hubs are more direct...with less counterparty issues/disconnects/issues/blackmail risks.. and ofcourse only 1sat.. you will see that LN will become just a massive HUB(bank) where daisy signs the second half of the (bank:cheque) payment for everyone.
P.S cheaper for alice.. but chris and eddie no longer get their $0.01 each when alice wants to pay bob because chris/eddie are not required. only daisy is
so for everyone thinking they are going to earn lots of money just running a LN node.. think again. spenders will bypass the stranger danger risks of hops that can blackmail/revoke and play games. avoid the unneeded extra expense and instead just use a hub instead
also LN is utilising other banking features of 3-5day fund availability after channel close(withdrawal) confirmation CLTV and ofcourse revokes(chargebacks) during that cltv maturity period by using CSV revoke codes
also LN has other issues. you cannot predict the ONCHAIN fee weeks in advance. so what may seem cheap to just throw $5 into an LN this week because you might want coffee at the weekend.. costs you maybe $0.3 to open a channel, $0.01 to pay starbucks and $0.70 to close a channel due to rampant onchain fee leading up to the weekend.
which messes up the $4.29 coffee you were hoping for. because starbucks needs another 40cents to close the channel because the onchain fee is now 70cent not 30 cents
(ln concepts have already envisioned people needing to deposit upto $6 ontop of what people hope to spend just to be used as a separate refundable amount to cover possible close channel onchain tx fee's and also INchannel hop/hub fee.. which rules out utility for the less privileged third world classes who could of benefited from only needing to deposit 20hours labour($1) to buy groceries.
so we should not be pushing LN as the final result and end goal of scaling. because then bitcoin is just SWIFT.NEFTS or RTGS of the banking world where people no longer own their assets due to it all being locked under 'daisy's' control (needs her signature and her morals to not hit a CSV revoke funds button)
overall.
solutions.
stop giving tx's such obsurd txsigop limts of 20% of block limit.
re invent a new priority formulae that actually is not snooby in favour of the rich bypassing priority costs just by staking more. and instead works to penalise those who actually want to bloat every block.
example of one hereoh and lets not forget have the blocksize adjustable at runtime so that its not a dev spoonfeed event once every 8 years but more of a community consensus where there are 2 settings:
upper (EG for now 8mb no go above zone) utilised in maybe consensus.h
and a
lower ('preference' where majority halt it bock size, minority below move up to it) utilised in maybe policy.h
where by if
3% had 1mb..
1% had 1.5mb
1% had 1.7mb and the other
95% were scattered at 2mb-8mb..
the policy/pref consensus would see 2mb was the preferred lower bound amount for now.. all of which are way below the harder to move 8mb limit of technical tested allowable amount, whereby the 5% minority were pushed up to the 95% acceptance..
hell.. even have a speedtest algo in a node that tests the propagation of seeing a new height, downloading, validating and then relaying out.
and get a 2016 block average to set as the upper limit (no go above limit) where by the preference is more free choice below this, that is affected by preference/policy dynamic consensus
.. rant over.. for now
