Topic: Questions on - Signature aggregation and Lightning networks (Read 338 times)

achows post above proves that you cant just connect to anyone. you have to meet their terms and conditions.
(should i open that can of worms debate)
and as i said. although on day one B might have 10btc available.... IT CAN GET RAIDED
meaning 'he decided to setup the channel with B then because in the "lets make a channel" message,' it WAS available... so they created a channel
but due to other channel payments lets say minutes after the channel opening. NOW that amount is not available

also achowe highlights that people instead of just onchain sending funds of $100,000 to someone. if they wanted to use LN. they would have to make a tx of many channels splitting up the funds to have the hopeful best possibility of being able to transmit some-all of it (no promise/guarantee)

i personally see the network(IN THEORY) like a 8degrees of separation theory. meaning that in theory people only need 8 peers to connect to, who have 8 peers themselves, who have 8 peers.. etc etc.. whereby everyone is connected..(well a few million if you into maths)
but in practice. its not the case due to daily spend terms/conditions and if users are online, etc.. 8 channels per user wont work

so lets say 1000 outputs to start up 1000 channels that have a $100 limit (safe daily spend limit many would agree on) to be able to shift $100,000 easily in one day, to have the fluidity and no debate to get those 1000 counterparties to all agree to send $100 through their routes to hope that the whole $100,000 can get aggregated to the desired destination

yep most peers would have a $100 daily spend limit as a safe goal

which then raids 1000 other peoples other channels their $100 spendability.. meaning they have to close channels to move their $100(if thats all they are holding in total)
EG
lets use 2 counter parties(for simplicity) to A.. lets call them B and X, and whereby destination is C
[a:$0- B:$100] [B:$0- C:$100]
[a:$0- X:$100] [X:$0- C:$100]

if B only had $100 in [b-c] then B needs to close [a-b] and then onchain send that $100 to a [b-c] channel

however.. here is a kicker
for B to survive more than a day without closing. B would need to have say ~$3k(depending on how many days of month there are,.. in each channel, with a $100 a day route spendability, just to allow the channels to stay open for a month.

but B cant just have 1 channel open (as achowe admits to) so B would need to he a hub. with lets say 1000 channels.. which means B has to have 1000 channels. each of $3000, each with a $100 daily spend limit.. meaning he has to have 'invested' $3,000,000 to be a hub

again.
hop model does not work (peer-to peer direct) because of terms/conditions, routing agreements it ends up being a hub model whereby there are terms that need to be met and agreed (like a bank application)...

oh.. and of them 1000 channels when being set up. each channel agrees a 50:50 of the onchain closing fee meaning of a $2 onchain fee, $1 from each side is deducted .. costing A $1000 in total in closing fee's for his 1000 channels and same goes for B because B is also acting as a hub for other people too

---

achowe stop thinking about the beauty of developers coding/promoting the dream. and wear a critical hat and run scenarios. and stop being afraid to admit things can go wrong/ have issues/limits/problems

yes i remember you(with lauda) charging people a fee to act as a middle man when someone couldnt open their wallet. but then failing to submit the problem to devs to find a workaround that didnt involve middlemen so that users would never have that problem.

imagine its much like the 1990's where wordpad didnt have underline. so you would prefer to charge someone a fee to print out their paragraph, use a pen and ruler to underline what they wanted. and say it's 'fixed' ..rather than scream at devs to add a underline feature. all because you think wordpad has no errors and its the users problem for not being able to underline

in short
admit lightning is not the dream thats being promoted and highlight the issues.. dont hide/deny the issues
lightning is NOT the scalability solution..
hint:
each month B closes his channels of 1000tx's of 2input-2output (each channel is a 2 output to show A then has 0 and B has $100)

just to then open fresh channels in the next block of 1tx of 1000 outputs to open a fresh set. (where each output goes to each channel)
..AND his 1000 counterparties who connect to him will have to send the same 1tx of multiple outputs for their "well connectivity"

.. can you not see the tx mempool bottleneck cause by just one hub

ill shut up for now and let achowe and others process what is said above (hopefully without the core/dev defence hat on)


P.S  i have been doing 'bank reserves' trades using multisigs (much like a joint bank account where couples leave money in account but on paper argue over % share of account holding).. for a few years. and yes even i had to do onchain tx's at certain points to get funds out and also put funds back in. so i recognise the limitations.

It's cheaper if you open your channels in the same transaction, which, by the way, is possible.

Also, if you are a party in a channel, you don't necessarily have to fund the channel. One person can fund the channel, and the other person just has 0 balance in it initially. In fact, that's how the protocol currently works. So you could actually have many channels, of which many were not funded by you.

Strange that he decided to setup the channel with B then because in the "lets make a channel" message, both A and B would have explicitly stated the terms of their channel. This includes the maximum amount that B is willing to transmit for A (and vice versa), the transaction fees to be paid in the commitment (can be updated later), who is funding the transaction, etc. All of this is done before any transactions are made so that A and B know exactly what they are getting into. It's strange that A would choose to open a channel with B if he knew that B would not be open to transmitting 10 BTC to someone else.

A can see what channels X has open, and he can see that X is also connected to Y and Z, as well as the hub. If he sees that X is advertising 10 BTC transmission, but has multiple channels open where he could, in theory, have more than 10 BTC attempt to be transmitted and his other channel only has 10 BTC, A might want to consider not opening a channel with X. Of course this would also all happen before any transactions are made.

Alternatively, A could not put all of his life savings in one channel. Instead he could open 2 or 3 channels using the same on chain transaction which might only cost him another 50 cents to open 2 additional channels. If he does that, he will be better connected and have more opportunities to be able to send his money.

I never said it was. What I am saying is that many of Lightning's detractors don't seem to understand how it works and like to ignore the fact that it's shown to be an improvement over the current on chain situation. This has thus far been shown on both mainnet and testnet where people are able to make payments that are way below the dust threshold and make payments to others in the network with little (on the order of single digit satoshis) or no fees.

I suggest you do that too. I am always wearing my "critical thinking" hat, but you never seem to be. It's always the "I have to shit on everything that Core does and everything that is not on-chain" that you seem to be wearing. I don't have to promote anything nor am I being paid to promote anything. Hell, LN is not even part of Core and we don't really have an interest in integrating it into Core. The people working on LN are completely different from those working on Core.

its also funny how achow admits that B can refuse acting as a route...
which kills the 'trustless' "infinite" "barriierless" argument.. and it proves the banking 2.0(hub) debate. because now B is admitting he has control of other peoples payment choices much like a bank can refuse a wire transfer if it doesnt like you moving say $100,000 in on lump. thus you have to withdraw your funds(close channel) and move to a different 'bank'(open new channel)

but anyways, lets explain it:

"well connected graph"
translation
each person has MANY channels(many onchain fee's to set up) to have many routes, to be 'well connected'..(hub model)

translation
at $2+ per onchain fee.. it cost more then $4(2 channels) to set themselves up as a well connected peer to have more than 2 directions/connections

translation
its not cheap to be a peer if you want to be well connected.. unless you want to be connected to a hub(bank2.0)

translation
HOPS do not work, and HUBS (bank2.0) become the routing model


as achow REVEALED
if an unbanked african guy (A) spends a weeks salary of $2 to set up a channel to B. if B refuses to accept A's villages life savings of 10btc to be moved because B refused to handle such amount,.
A has to close the channel (another $2 fee) to unlock his 10btc from the A-B channel and then open another channel (another $2) to connect to another peer who might allow 10btc payments.

but.. for how long will this new peer X have 10btc 'available' to always be open to help A out
maybe X advertises having 10btc open to a hub... but X is also connected to Y, Z and Y raided that 10btc before A got to use it

achow.. lightning is not a infinite moneypot of money that is always open and infinitely usable.
stop thinking with the "i have to promote this" hat on.. and wear a "critical thinking" hat

pre-empting rebuttles:
peers wont use lightning for life saving amounts, its meant for coffee drinkers:-
in which case if each channel only has say $60 of btc 'available' then they would get raided within 30 payments
meaning at most a channel costing an onchain fee of $2 is only open for probably a month (not forever as promoted)
or only 1 day if that peer has 30 'connections' raiding its $60 'availability' because those 30 people want coffee tomorrow

in short
imagine B would have to have 30 channels open with normal people offering each channel only 1 coffee payment a day. but with its 31st channel to starbucks it has to have $60 a day spendability to starbucks

in short
starbucks eventually becomes the bank2.0 with thousands of channels connected with each channel having a $60 a day spendability with middle men
but then has to close the channel at some point to then move the funds from each middle man. to then pay out wages/supplies/leasing costs

after all with only a $60 available channel with the middle men.. starbucks cant exactly sendbackwards $1000 through the middlemen to pay just one staff their monthly salary or the many $thousands for the monthly building lease via the already established middlemen channels. because the middle men only have a $60 daily limit

achow. again please take off the "i have to promote this" hat.. and wear a "critical thinking" hat

but have a nice day

This argument relies on a model where the Lightning Network is in a degenerative case where it is a linked list and not a well connected graph. From current testing and use of the Lightning Network on both testnet and mainnet, we can clearly see that the Lightning Network is not this degenerative case and is instead a well connected graph. If a channel is chosen as part of a route going one direction, it can also be chosen for a similar transaction going the other direction, and that would re-balance the channel.

Furthermore, you can limit how much you allow in routes through your channels. So if B wanted to ensure that he still had money to pay C, he can refuse to route A's transaction of 10 BTC. A would instead have to find another route, which, given a well connected graph, is not very hard.

^ and here shows the problem ^

imagine 5 people (a.b.c.d.e) opened a channel and each funded 10btc
[A:10  -  B:10]  [B:10  -  C:10]   [C:10  -  D:10]  [D:10  - E:10]
in this case A has 1 channel(to B)
in this case B has 2 channel(to A and C)
in this case C has 2 channel(to B and D)
in this case D has 2 channel(to C and E)
in this case E has 1 channel(to D)
in total there are only 4 channels open because they are shared

now imagine A wanted to pay E 10btc
here is what happens
1st 'hop' - A pays B 10btc in channel 1 using channel 1 funds
[A:0  -  B:20]  [B:10  -  C:10]   [C:10  -  D:10]  [D:10  - E:10]

2nd 'hop' - B pays C 10btc in channel 2 using channel 2 funds..  channel 1 funds do not move
[A:0  -  B:20]  [B:0  -  C:20]   [C:10  -  D:10]  [D:10  - E:10]

3rd 'hop' - C pays D 10btc in channel 3 using channel 3 funds..  channel 1 and 2 funds do not move
[A:0  -  B:20]  [B:0  -  C:20]   [C:0  -  D:20]  [D:10  - E:10]

4th 'hop' - D pays E 10btc in channel 4 using channel 4 funds..  channel 1, 2 and 3 funds do not move
[A:0  -  B:20]  [B:0  -  C:20]   [C:0  -  D:20]  [D:0  - E:20]


now you may see the problem.
A has raided B's ability to pay C, D or E because B has nothing in channel 2 to 'pay forward'
A has raided C's ability to pay D or E because C has nothing in channel 3 to 'pay forward'
A has raided D's ability to pay E because D has nothing in channel 4 to 'pay forward'

so imagine you were B. and you only had 20btc to your name
you open 2 channels.. one with A and one with C

before you can even buy a coffee(C) for yourself .. A has leached you dry
before you can even buy a doughnut(D) for yourself .. A has leached you dry
before you can even buy a eclair(E) for yourself.. A has leached you dry

your only options are to close your channel with A (costing you a onchain tx fee to get it added to a block) then open a new channel to redeposit your 20BTC from [A-B] to go into [B-C]. costing another onchain fee. just so you can buy a coffee

big emphasis
you cannot take the funds from [a-b] and put them into [b-c] without closing [a-b] to then reopen a new [b-c]

another way to imagine it
Aguy has a Beautiful wife, they have a joint bank account
the Beautiful wife has a separate joint Cashcard account to monitor her Childs allowance

Aguy tell the wife she can have $10 of their joint account if she pays $10 to the child out of her separate cashcard account
that payment agreement is done
.. but now the Beautiful wife doesnt have $10 in her cashcard account to pay the child next weeks allowance.... unless she withdraws funds from the joint account (costing a fee) and deposits them into a new cashcard account(costing another fee)..

...
i hope this illustrates that channels are not limitless. nor are they trustless. because it requires counter party agreement. not sole control

i expect achowe to rebutt that if A was to sent 10BTC knowing it will wipe out B's future own spending ability with C,D,E.. that B will refuse..
but that raises the problems of:
1. not having many reliable hops willing to surrender their spendability to helpout the network of hops
2. it ends up requiring people to have MANY channels in the hopes that just one partner will agree to helpout
3. the onchain fee's to open and close these many channels are not cheap
4. the need to close and re-open to 'balance the books' and redeposit will spam the network

imagine it
costing onchain fee for every channel open and close..
would you use paypal if it cost you $2-$6EACH to open a channel knowing you will need to open channels with 2-10 ebay merchants ($4-$60) for the hope that oneone will agree to surrender some or all of their spendability to help the network

the devs are still stuck in the 'does it break' mindset but have never even thought about the 'is it useful long term' mindset
they are too busy looking for code bugs. that they cant see the FUNCTION/UTILITY bugs

Thanks achow101 for clarifying my questions.  I now have some clarity on how an alternative opcodes to OP_CHECKSIG will have to be implemented as the validity of separate inputs are no longer independent since we'll only now require one signature per transaction instead of multiple. I guess it's a matter of additional research on whether the new opcodes can be ported to older addresses or if users will need to migrate to a new version of an address with a newer witness version.

Also, thanks for clarifying all my lightning network questions. I'm seeking to running a full time node once LND has a public GA. I'm also assuming that if I'm connected to a node that's in turn connect to many other nodes then probably I need not open any new payment channels since I'll be able to make payments to nodes within 20 hops?

It will likely only be available for addresses beginning with bc1, and even then it won't work with all addresses that begin with bc1. Rather it will likely only work with those addresses which encode another witness program version (the current ones are for witness version 0). This is because introducing signature and key aggregation will need to use new script opcodes which are more easily introduced via a soft fork in a new witness version. Basically, since Bitcoin does not currently support key or signature aggregation, new script opcodes will need to be created that do support those things and the only way that they can be used is if new outputs use them. Thus all current outputs that do not use those currently nonexistant opcodes will not be able to use signature or key aggregation.

Note that this is not a guarantee. There has not yet been a proposal for implementing this in Bitcoin. All that we have so far is just the cryptography itself. So perhaps someone will think of a way to make key and signature aggregation work with old outputs.

If the other party in all of your channels has a balance of 0, then you cannot receive Bitcoin. What would need to happen is that you either transaction and send money to someone else thus moving funds to the other person in your channel, or someone opens up a channel with you and they fund the channel.

AFAIK, currently you cannot do that. But there's no reason why that can't be implemented in the future.

No. So long as you have channels established with other people and have active connections to other nodes, you can be chosen to be part of a route without accepting incoming connections.

I've been reading up on Signature aggregation and usage of lightning networks on certain blogs recently. I've had a couple of questions on the top of my head which I couldn't find answers to on subsequent searches. Also, since I have multiple questions I feel I should ask them in one particular post. I would be glad if anyone knowledgable on the topics could help answer few of my questions. My Questions are:

1) Will signature aggregation / Key aggregation be available for legacy addresses that start with '1' or are these only for multi-signature addresses that start with 3 or bc1? If not, could somebody explain to be in an easy to understand way on why is this the case?

2) I've tried opening a lightning channel using the lightning-app on testnet, I really loved playing around with it and am Impressed with the instant payments. I was wondering if anyone else could send me ligthning payments (me receiving them) if my channels were already fully funded and the 'Available to receive' is '0'. If this were to be the case, would the sending party have to independently open a new channel with me to send me the funds instead of having to rely on existing channels?

3) Will the users be allowed to set an nLockTime or a time period after which the channels will be automatically broadcasted to the bitcoin network and closed? Currently I've tested Eclair for android, lightning-app and Bitcoin + lightning wallet for android and they all seem to not provide this option. I'm assuming it's a 'To be developed' thing?

4) Will I need a lightning node with a public IP broadcasted in order to be able to earn from fees for nodes using my channel to transact between each other?