Topic: Will segwit reduce the number of transactions by any significant amount? (Read 1157 times)

Excatly. Who will do that?

A huge assumption.

not my best work, just found sometimes people cant read and prefer to see pictures..

but anyway IF you had 100BTC and wanted to pay E 100btc.. then the DNS system would have to find a route of participants that would get from A to E and al of which have OVER 200 in the channel, per channel to to be able to hop the funds along

from all the talk at the moment most LN devs are saying that LN should only hold around $60 or 0.05btc per counterpart.
which i think is fair due to LN's utility only being for the small stuff and the risks that LN devs still has not patched yet

LOL...
thre are many many many attack vectors.

maybe worth you playing out more scenarios check for weaknesses not looking for semantics to brush issues under the carpet..

and malleability has never had a problem in the LN concepts anyway.. it was just a narrative played on repeat to make segwit seem more needed.

A big transfer like that could still be handled on-chain, you just pay the normal fee.

Nice colourful diagram.

Now if i am A and i want to transfer 100 BTC to E.

B, C, D would require 200 BTC + fees deposit?

Cough cough....

But then - my little piggy - the TIME LOCK would kick in and simply refund us after X amount of time..

( .. I would have a copy of that txn BEFORE I send funds to the joint account.. Let's remember that malleability is fixed with SegWit..! Yippee! )

(.. and if he refused to sign the refund, then I wouldn't send money to that address anyway.. )

It's open source code, like Bitcoin. And all the claims for Lightning's node hopping, instant transfers and low (or zero) fees have been proven on Bitcoin testnet (and soon on live Litecoin network).

You sound like the people who say "Bitcoin is a virus, because WannaCry". Or people that try to make it sound super complicated , take a look at the user interface for Lightning software, it's pretty simple stuff (and will be simplified more once it's out of the early stages it's in right now)

it still needed their signature before they fell into a volcano!!!

If you pay a fee and make it onto the chain - it's not spam. And to do as you suggest would be VERY expensive..


The txn you each hold IS ALREADY SIGNED by the counter party.

If I start a channel with someone, and they fall into a volcano, and can't sign, I can still cash out..

its a multisig.. short for: MULTIPLE SIGNATURE

EG
its not lke a traditional transaction where you are the only signee..

if you were to compare it to lets say a cheque... LN/multisig is like a joint account needing 2 signatures.
A and B have to agree together

again its not like you have you own funds and your wife has her own funds completely separate (#1)..
you both are in the same 'account/channel' and both need to agree on who spends/deserves what.(#3)

in a hop concept your channel you need your counterparts permission to be part of a route. you then need others to agree aswell.

needing permission is not permissionless

although the permission can be automated, its still permissioned

EG you dont need a bank manager to physically agree or physically sign a bank account movement manually.. but by using a bank requires it set its system to auto authorise things in the system. they can take that away.

you can decide to remove yourself from a channel should a counter part try to blackmail or decide not to give permission, much like withdrawing from paypal.. but by your sending a tx, the counterparty can(if malicious) then invoke their CSV which then in laymmans terms is like a chargeback. taking your funds away from you before your funds have matured.

LN has a niche, dont get me wrong.. but it is not as utopian limitless, permisionless as people think, pretend.

i am not trying to scare anyone, i am just making sure people know more about it then the polished best case scenario sales pitches. so they can see the reality of it

EG

A provides a fresh public key 1A4c3p0...
B provides a fresh public key 1Br2D2...

the 2 public keys combine to create a multisig  3Bb8...

A funds 3Bb8 0.1btc    - txid a1cd
B funds 3Bb8 0.1btc    - txid b4cd

channel is now open

parties agree how the payout should begin (#6)

when they agree to a new balance they both sign and have something like

if later B wanted to pay A 0.05

if later A wanted to pay B 0.01

now if A regrets paying B 0.01(txid:2515).. A could send (txid:ae48) but what you dont realise is that A's (txid:ae48) has a CSV condition
meaning B could send (txid:2515), which then revokes A's output

note this example is very simplified for laymens

I've read many "bits and pieces" about LN and SegWit, and seen some videos. Franky has a nice explanation too.
But still, it's not entirely clear to me how it works. I see some benefits, but it also seems like a lot of extra (programming) work for something that is as simple as adding a few bytes to a block now.

Couldn't this be abused by spam? Join all payment channels, then close all. Do this over and over again, and the 1 MB blocks are full again.
I hope I'm wrong though. Is there anything in LN that prevents a spam-attack on channels?

Sure you can -- if you can find a route. But if there is anyone on the entire planet that knows how trustless decentralized anonymous routing works, they've not been telling.

Thanks, great explanation.

Wow - Very Nice. Like the Diagram.. ^^

And a great description of the inner workings.

Thanks.

..

BUT - it is NOT permissioned..

You can cash at AT ANY TIME without the permission of the HUB. The whole point is that you both hold valid TXNs that you can publish at any time should you wish to.

This is called 'Closing the Channel'.

It's not a new concept - it's just like a payment channel.

Stop scaring people Franky..  

...

I would imagine ALL the crypto exchanges run LN Hubs.

BlockChain.info would run a hub.

CoinBase would run a hub.

Any 'social group' could run it's own hub..  and Cafe's, Restaurant, Bars, Casinos! etc etc.. ( So any txn between any of these participants would be LN based )

Now ( I reckon.. ) MOST of the current BTC traffic would be off-chain, instant, and for as little as a satoshi.. ( it's all of us moving money in and out of exchanges that really clogs things up.. ).. Seriously - like 90%.

THIS IS WHY THE BLOCK SIZE WON'T MATTER. We may find 1MB is PLENTY. (For now..)

(..or in SegWit's case 1+3MB..)

The purpose of SegWit to fixed the malleability problem of bitcoin and to increase the blocksize is not the main reason to implement SegWit.

The lightning network as an off-chain solution for bitcoin to make the transaction will be faster.

Without SegWit, LN just will less on his benefits.
I mean SegWit is not to solve the scalability problem.

to explain LN channels(hop)..

firstly ill display this image and then explain it


first some people think anyone can set up a channel with a click and remain permissionless(#1).. wrong!
 you have to set it up WITH ANOTHER PARTY (#2) !! permissioned as you need their signature to sign off on payments !!

next you cant just instantly pay anyone. for instance A cant just pay E,
you  need to have to find a route to the intended 'anyone' by finding a path of channels that can link you to the intended party.

this involves some parties having more than one channel open (#3) as you can see B has 2, C has 2, D has 2..

next is the funding..
A doesnt just fund E.. A has to pass funds to B(plus a fee) in the A_B channel... B then needs to use a separate channel B_C with separate funding to fund C, and so on. (#4)
this means with a cap per channel of lets say 0.1btc
B needs to deposit 0.1 into 2 channels
C needs to deposit 0.1 into 2 channels and so on

now, with many channels available and channels having funds, this then allows a path (route)(#5) to be established from A to E

---

now lets say A wants to pay E
we will start with the blank slate(#6)
imagine A wants to pay E 0.01btc... and each 'hop' cost 0.001 fee to thank each person of the route for participating.
(dont knit pick the fee or take it literally. i chose 0.001 randomly for demo purposes only, i simply couldnt be arsed to do lengthy decimals to show a very small fee)

as you can see in(#7) A has worked out it would cost him 0.003 in fee's to get to E and so A passed 0.013 to B
B in A_B is where B's 0.001 fee remains.

in (#8) B using the separate stash knows its going to cost him 0.002 in fee's to get to E and so B passed 0.012 to C
C in B_C is where C's 0.001 fee remains.

in (#9) C using the separate stash knows its going to cost him 0.001 in fee's to get to E and so C passed 0.011 to D
D in B_C is where C's 0.001 fee remains.

in (#10) D using the separate stash passes 0.011 to E
D in D_D is where D's 0.001 fee remains.


which when if they all closed channels and totalled up their holdings
(#11) A=0.087 B=0.101 C=0.101 D=0.101  E=0.110
which means the guys in the middle are 0.001(fee) in profit from acting as routes(hops) and E has the 0.01 which indirectly came from A
because A is down by 0.01... (and down by 0.003 for the fee's)

---

all that the mainnet chain see's to set up the channels is the 8 transactions (into a channel) to set up the 4 channels (2 tx per channel)
as shown by the arrows in (#5)
A(0.1)->A_B               B(0.1)->A_B               B(0.1)->B_C                C(0.1)->B_C  
C(0.1)->C_D               D(0.1)->C_D              D(0.1)->D_E                E(0.1)->D_E

and 4 final transactions when closing the channels
A_B(0.2)->A(0.087)B(0.103)                  B_C(0.2)->B(0.088)C(0.102)    
C_D(0.2)->C(0.089)B(0.101)                  D_E(0.2)->B(0.09)C(0.110)  

which when if they all closed channels and totalled up their holdings
(#11) A=0.087 B=0.101 C=0.101 D=0.101  E=0.110

which means the guys in the middle are 0.001(fee) in profit from acting as routes(hops) and E has the 0.01 which indirectly came from A
because A is down by 0.01... (and down by 0.003 for the fee's)

---

the steps #7 to #10 are funds moved all off chain.. never seen by the mainnet chain
and funds can move back and forth as many times as possible off chain as long as:
the channels have enough funds to work as a route for the particular payment
and
there are enough channels to link/create a route

And also it would just lower the transaction fees in any transactions. It really would fasten transactions because of the reduced amount now that the witness or blockchain has its own. but i think it is not enough for the growing problem in the blockchain recently. i would see hardfork also as a good solution for the blockchain. Other than that i observed segwit is really helpful in other coins as far i have observed.

Does lightning network can make transaction much faster and can it really lower the transaction fees. There are many claims that the lightning network can solve the slow confirmation and its name suggests that it has the power to do so. But it is too early to say those things we can only tell if we are already using lightning network. After which we can claim if it is fast or slow, if it is cheap or not.

Probably he is talking about the reduced of unconfirmed transaction once SegWit is implemented.  I believe that is the purpose of Segwit, to establish the fix for bitcoin scalability if I am not mistaken.  It gives way to Lightning Network that will greatly help in the transaction.