Off-Chain Scaling Solutions for Permissionless Blockchains

Transcript

great so today's talk is as you're already aware about octane scaling solutions so why do we need scaling first a little motivation so if you're moving from a centralized payment system to a decentralized payment system they actually many questions popping up in a centralized system if bob is sending a payment to Ellis through a centralized party we know very well the security properties that are in place because the bank is just like the anchor of trust here we know the privacy requirements only LS Bob and the bank knows what the payment and we know how fast the bank can scale the payment flow because the more they can process a central entity well the more transactions we have but

if we now remove this central entity and replace it with a cloud of miners developers and the p2p network well there are many questions that are popping up so in particular on the security side on the privacy side but recently and even more importantly now on the scalability side so I just want to briefly speak about unchain confirmation of transactions so let's assume we have a couple of peers that are sending transactions that are creating transactions so these are just users like you and me that want to send payments to other participants these transactions they're basically reaching a set of miners those that are extending the current blockchain and once a lucky miner finds the block he can include

this transaction within the blockchain and then propagated within the network and transaction security is basically relying on the fact that if you have a blockchain and there's a particular transaction which is included in a block B 1 then an adversary should not be able to construct a parallel blockchain also called a fork to basically double spend this particular transaction so the red transaction which pays the adversary here should not I mean should not be able to be constructed so an adversary might choose to perform an override

action if he is able to create this longer blockchain effectively overriding the current owners chain so if you do that then later on the onus chain or the honest- they will just continue working on the longest chain so this is transaction security for Unchained transactions and many people might have told you okay how many how many confirmations do you need in Bitcoin for transaction to confirm y6c how do you come up with this number the probability is is true I mean the

longer you wait the more unlikely it is that an adversary is able to double spend to transaction but these numbers are actually not they're not really I mean six doesn't mean anything and actually the number should change over time because the network is changing the resilience of Bitcoin is changing actually the security of the Bitcoin transaction is dependent on the vidcom price and this actually applies also to other functions so it shouldn't be constant it should be something flexible but just for the sake of this talk I'm going to show you that so in my PhD defend PhD thesis I've shown that for example six Bitcoin block confirmations equivalent to 37 III and block

confirmations given an adversary with 30 percent of the hash rate okay so these are static numbers is just for a particular instant of the network that I measured at the time but you can you can basically calculate then the time that it would take so any theorem this would take about 10 minutes give them the 15 second block interval on average and about 16 minutes in Bitcoin so you can also extend this to other block chains like like corn corn or any other proof of work from chain okay so now you might ask okay is this optimal this really is if you're an optimal well to answer this you actually need to simulate all possible types of

drop chains proof of work best block chains that you can have there so I I've produced an open source Bitcoin later with which you can do that so what you can put into the Bitcoin simulator is for example different consensus parameters like a block interval distribution the mining power distribution of the mining pools their different network layer parameters actually the network layers one of the most important elements in scaling the the information propagation needs to be fast you have a peer-to-peer network it takes really time to forward a message so Christian Decker did an awesome work on measuring information propagation in Bitcoin a few years back and just to show you like a few numbers so actually

the geographic distribution of the notes and the - it's quite important as well so at the time when I measured about 70% of the hash rate was in asia-pacific and if you look at the distribution of the nodes it's actually about 50 percent in in Europe so the results of the simulator I've simulated like quite many parameters there online available on the website so you don't have to run similar to yourself you can just like look up the results but there are some parameters that give you better throughput for scalability point of view then those chosen by Bitcoin or those chosen by a few so just example parameter because I'm not like a big fan

of being religious about particular constant it's just an example parameter if we choose a one minute block interval into one mega megabyte block size we get about 60 plus transactions and according to my research this doesn't change the security of the network so the stable block rate maybe some of you have heard it so the number of blocks that do not confirm in the main chain do not does not change so this means the the security has not changed the security is not affected by this change obviously these parameters they or the security of those parameters changes over time so this is only valid for the measurement at the time of the experiment okay so we can scale maybe to 60 maybe to a hundred transactions per

second if we change the parameters of the current block chains if you only do parameter changing is that enough it's not enough so this this is just taken like a few days ago so almost 200,000 unconfirmed transactions alone in Bitcoin that's huge so these are transactions that are waiting to be confirmed and that's why that actually also applies to e3 I think if you I checked okay you can read that it's about 20,000 attending transactions in the mempool memory pools I mean the the pool that contains the unconfirmed transactions and this is reflected finally in the in the fees so in order to pay a fee to confirm a transaction in the blockchain

it's an arms race it's a bidding war between all those that want to write to the blockchain so the transaction feels in Bitcoin worried about more than 20 u.s. ago and more than two US dollar and I'm sure this gonna go quite high this year and disabled actually many opportunities so the main problem that I see of this high transaction fee that it actually brings us back to a centralized system so maybe have seen the liquor exchange which was working operating on the on the Bitcoin blockchain it decided for operational purposes to switch back to a centralized

system so we are already seeing basically they're basically the the effect on the on the decentralization of Bitcoin and I think after all most of us so many of us are in this field because we like that the idea of decentralization we like the idea of peer-to-peer okay so what are the blockchain scaling directions that we can take there's one which is changed in the consensus algorithm at least this is what some people claim so some people claim that if you change your consensus algorithm to proof of stake you have more transactions per second I have difficulties understanding this this reasoning because proof of stake for me

is just the concept of leader election or block selection Rock election and after all this block which you create whether it's proof of work or something else our proof of stake you still need to propagate it in the network and if this propagation is not fast enough then you don't really you're not really able to scale so I think we should be we should be a bit critical when people say we can scale through proof of state there might be though alternatives which take into account proof of stake and partitioning and charting that might work out so definitely for example is doing is proposing a random beacon and at the same time a set of shopping so this might be a possible way to scale so I've

already spoken about charting the basic idea is just to compartmentalize into different partitions the set of validating nodes okay we're not talking about today today we're talking about off chain transactions so those transactions that are basically confirmed on chain later okay so what kind of block chain scaling directions exist so I would like to separate those into two classes on one class there are two party payment channels okay so these are just between you and me you and me you're me and you right so it's just like peer-to-peer direct payment channels so they can be either unidirectional so if I choose to only go

with one they can be bi-directional they can be linked payments which I will talk about about in a bit and there can be two party payment hubs so basically nodes that have many connections many channels but the other category that I think we need to consider as well are n party hubs so basically channels or option technology which is not based on a two party channel and I would call them bi-directional n party hubs or just nerves so how does the off chain payment work or this this lifecycle of an off chain channel so the first thing that happens is typically a broadcast to establish the channel so there are two

parties here they want to interact with each other so they're happy they broadcast the transaction that says we want to open a channel together and then the - that mine this transaction which takes a bit of time and then a lucky miner finds the block and then this is this is registered in the blockchain and we have this channel once this channels open then those two peers they can transact off chain because they have collateral in the blockchain which allows them to use this collateral and only up to this collateral to transact with each other okay so the option transactions are secured by the on chain collect all that has been put on before in the end if one of the parties wants to close the

channel they can just broadcast so coach and closure transaction which is again mined by a DA by the miners it's a non same transaction takes on time and it gets confirmed in the rupture okay so the first and most simple channel that we can think of our so-called unidirectional payment channels so this means a party a wants to send off chain funds to a party B so in order to do so this party that wants to send funds needs to deposit some collateral let's say one either here and once this is done the party concerned what we call it micro transaction because it's always smaller than collateral it can send one or multiple micro transactions to the

receiving pier so what you can see in blue here is actually the off chain balance so this is the balance that is not updated to the blockchain yet but it's kept off change so this is the book that the two parties keep so bi-directional payment channels are actually quite similar it's just the only difference is that now both parties put collateral there in the channel okay what's important is that this collateral needs to be locked all over the the time period that the channel exists right so it's it's actually a burden and we will talk about this a bit later so now one party can send some off chain funds and the off chain book gets updated then the other party can send some funds in the

other way the author of chamber gets invalidated it's very important and the new of chain balance gets valid alright pretty simple so now let's assume those two piers they actually not connected not directly connected they don't have a payment server of the treatment sir so what can we do well we can enable a so called linked payment channel transaction so if we have intermediate nodes that have open channels and it is very important where the deficits or the collateral put into the chain is actually sufficient then you can do a linked payment transaction among different peers so let's assume those peers these are all unidirectional

payment channels and they have deposited one either which they can use off chain so the leftmost peer can start its forwarded its forwarded and it arrives at the pier and the off chain balance is then adjusted by the by the individuals so what I've omitted here is for now is that these peers that are forwarding option transactions they might take fees right I mean why would they forward your payments I mean maybe like you but they're not doing much work for free so there might be some some yeah fees that are being taken by the intermediate nodes so there are few considerations after like seeing the concept of payment

surrenders now so first of all I mean finding the route might not be that easy so there's a lot of information that needs to be exchanged if you're familiar with internet routing there you need to communicate quite extensively to find another peer and these channels or the routes that are possible to follow they need to be kept up to up-to-date and life contrary to internet routing I think one of the major roadblocks here is that you're not forwarding data packets you're actually forwarding funds so it's much more critical than I mean you don't really care for data packet gets lost left or right but if you're losing funds this is this is much more pretty another

major issue is general maintenance so let's assume the these peers are just continuing to send transactions in this direction at some point the the the collateral is used up so why should the intermediate then update the the channel for another person it's expensive to do an option transaction to update the channel so transaction security is obviously than one something that everybody cares about if the transaction security of the payment system is not guaranteed and it's not a payment system anymore so guaranteeing the security along the path lack of of payments that are sent along the path is critical I think one of the major issues

of payment channels that we have nowadays to party payment channels at least is the problem that they are vulnerable to congestion of the blockchain and we have seen congestion I've just shown you on the slides that they're two hundred thousand pending transactions in Bitcoin so these payments give me timeout so if you're not able to answer to a particular challenge on time for a payment channel so if your if your opponent closes the channel with an invalid state and we say that you think it's not valid and you don't have time or you just don't have the resources to answer a challenge then bet you're

basically losing funds so and this problem gets aggravated if more and more people wants to close their channels so blockchain congestion I believe is is one of the major issues for payment channels so but this I mean I've already briefly touched on it but the so one problem or consideration of tensions are school balances so let's assume we have this route from before but the middle channel is now no longer usable so what happens is we have to find another Road so this means another intermediate node yeah and this means more relaying fees more transaction fees so we can send the payment now across this other node but this is this is obviously an issue so to

party payment channels deterioration penalties are first of all longer routing routes and you have to keep them up to date and on same top up so I'm presenting you now a solution that I've come up with which is called rebirth so rebirth is basically a method of making payment channels more scalable so you need less unchain top-ups okay so how does this work so in real life we basically produce so-called rebalancing transaction sets so we developed an algorithm which allows you to define just the number of transactions that you can execute off chain to rebalance the payment channels of of your peers so the input that you

give to this algorithm is just current channel balances and you might have certain preferences of how many funds you want to have in which channel so the output of the algorithm is basically the payments that you need to execute and the payments that we need to execute we put them into a protocol that allows two and four those transactions atomically atomically means either all of them pass or no not impossible so here the input is just what we take from the previous algorithm and the output is execution or the failure of all pains that's why it's at home so we've implemented the proof concept on if you William using the sprites

payment channels so it's open source you can you can use it it's it's available for for anybody so what we need for this is obviously we need a blockchain to execute it on we need turing-complete smart contracts which are provided by a theorem we need to party payment channels or sprites was actually a payment show that we were able to use we need to connect a topology so this works actually on cycles we'll talk about this later and we need some optional communication capability just means like internet connection between multiple peers so how does this work so how does this transaction set generation work so we model basically the problem as a

linear program so we have two participants U and V and we have a particular transaction amount that we want to turn from UT that is modeled by Delta U and V okay so we can give to this to this particular program we can give them I mean there are certain constraints that needs to be satisfied so the first constraint is that all the incoming funds that you get should be some zero sum with the outcoming outgoing funds yeah so rebalancing shouldn't change any balance basically right I mean it shouldn't change your overall balance the second constraint that we have is that we need to account

for some user preferences so either you just make everybody Harv's their channels so like equal preferences or some of the peers they might have particular preferences of because some channels are more skewed than others and finally we have to take into account that the actual channel balance should not be changed so the the the overall funds between the channels should never change so this is basically we need an optimization algorithm so the basic requirement is that the maximum and in the the total amount of funds should endure we should maximize the total amount of funds that that are to

be rebalanced okay so as an optional strategy we can say okay the user the default user preferences to balance each channel so that the the option funds that you have are just half between them so like equal equal amounts between the channels we also support to bring your own strategy if you like to it might create some it might make the linear program solver just more complex so we prefer to use simple simple strategies there's one issue with the linear program solver because linear program solvers are basically I mean the output

values are not integers but real values so there might be minuscule losses when you solve a linear program so the basically what you can lose is the minimum amount of transaction unit that you can transfer in the blockchain so any theorem this will be one way one way is 10 to the power of minus 18 ether it's negligible so the running time of a linear program is I mean the complexity of linear program solvers has been difficult to analyze so the worst-case running time is actually exponential however we have seen in practice that

well the expected time is actually a polynomial time in the number of variables so number of variables would be number of users that are that are participating in the in the solving of this linear program so it's it's feasible so how this rebalancing protocol would so what we have is basically we have here leader that we have to elect so there's a initial setup phase and instead of set of face we basically elect leader and the leader notifies the other peers that are participating in a particular rebalancing step so what's very important is that all the

participants that are participating in the rebalancing they should freeze their current channels so just so that the amount of transact that the transaction funds which are frozen they are constant I mean that that otherwise if you came to obtain transactions while you're rebalancing then you you just I mean this this doesn't work so the what the real leader receives he requests from all the participants to receive their particular balances ok so and this means that after they froze their channel the the different channel channels the leader computes the transaction sets he solves the linear program given the

constraints that he has been given by the u.s. users initially so the next step is a signature aggregation so that's very important so the participants receive from the leader the transaction set that that everybody is sentiment so this means the the participant he is only signing the transaction set if he is ok with the transaction set that would rebalance the channels so then after after the leader collected all the signatures leader basically distributes the full transaction set so in case of disputes rebalancing can can be challenged on

chain so the good part is then we can always recourse to the blockchain in case of disputes so particularly regarding the dispute stretches so how can how can something be disputed so in case something goes wrong we use the underlying blockchain and the dispute process basically relies on the underlying payment channel to be extended with the transaction set so the underlying payment payments are so in our case it was sprites it needs to be augmented to understand what rebalancing means so and then given given the transaction sets and along with all the signatures of the

rebalancing so we are basically given with broadcasting and okuru and all the signatures of the transactions and then we can we can basically dispute I mean we can resolve the dispute of a particular pier in the reverb protocol okay so the security properties that we get particularly interesting I think they so the the balance actually of honest participants always conserved so you're sure if you participate in is protocol you will not lose any funds I think this is something that everybody wants what you don't want that your that your funds can be changed if you participate in the in an off chain

protocol what's also important is that the rebalancing is done in a fair manner so and why is it fair because before you sign the particular transaction set to rebalance yeah you will see it so you will never sign something that you don't agree with and that's why it's fair we got any privacy we're not making any guarantees so the leader is basically requesting the channel balances of everybody that's participating so the leader will know about the Chilam Balam channel balances of the peers so no privacy but this is not something new future work so regarding usability considerations I would recommend you to using revive I would recommend you to

only do rebalancing with peers that you already know so reputation is important for practical purposes you don't want to go to the dispute case and be required to do on-site transactions to resolve disputes so the number of participants the more participants we have the more signatures needs to be committed to the blockchain so the more expensive the disputes get so it should be within reasonable bounds what's actually interesting if you if you are using multiple channels yourself in the rebalancing scheme it actually gets more optimal for yourself and you should only use feasible optimization objectives so for example this halving of the balance between

between two peers is reasonably simple if you're using two complex optimization strategies than the linear solver might not be but not to be optimal basic so you might ask okay when can I do is rebalancing so the problem is the the problem is you can only do this if you have a cycle so this topology is fine this topology is not fine so once you have once you have a tree structure topology you cannot apply rebalancing but you can apply rebalancing as soon as you have a cycle in your graph okay very good so they take advice takeaways from

revive is that payment channels if you use them their quality will be deteriorated so you will have scoot channels within one direction you will need to top up some at some point so either you do longer routing or you do top up which is expensive so you can use revive to rebalance payment channels if you have cycles in your in your topology so what we have shown you is a rebalancing transaction set generation algorithm so it generates the set of transactions to rebalance of chain and a protocol to implement them so the code is available on the skid hop link and the academic paper that was accepted at the t1 conference is available there good but what kind of other payment

parts to party payment solutions are well there's lightning I guess everybody heard of it there's Raiden and there's for example Tom Babbitt so lightning was presented a few years back and scaling become Hong Kong and it's there's so much effort going on in lighting that's really great to see so lightning is already running a test match there are different nodes being 800 notes are currently life in a test net it's it's a two-party payment channel solution some some peers are already running it on the Bitcoin main chain I don't know if this is a good idea but we will see it's a backbone and Raiden is doing

payment channels on on ethereum they have already published for the main net uni-directional payment channels which everybody can use so you can already use those channels or in particular the the the implementation if you want to so I think it's it's also a great effort on this side humble bit is it's another project that might be less known but I think it's very interesting it actually is is a Bitcoin mixer by default but it can operate as a as a hub or like it's a two-party payment hub I would call it in the sense that it is more privacy-preserving so it allows you to to to use to use obtain transactions in a

privacy-preserving manner okay so you can't link the input to the output transaction and now I would like to ask you what you think is this topology from which network does this come from I think I heard like ok very good yes it's lightning and it's the test matter a few days ago and what can you see there what kind of structures do you see exactly so we're actually seeing an in real life that it seems there's some kind of hops evolving right so naturally some of the nodes are gonna have more connections than others so there's gonna

be some kind of distribution which tells us there will be some really heavy nodes and many with very few connections so enlightening you would create such a hop by doing something like this so by directory channels and the node in the middle would be called the two-party payment hub so this node needs to needs to look quite some collateral right it actually needs to lock collateral for each individual appear here if it's a bi-directional there's obviously awesome the other counterparty some some collateral deposited so a problem is you have to maintain that there's a lot of

frozen deposit and in particular if you're just looking at the deposit from the hub here in this particular example let's imagine there are like transactions coming in their transaction coming in there so it seems that the left most node here receives more transaction volume than the other notes so how can you anticipate this as a hop operator that's really hard right you don't really know I mean you have to basically anticipate the how much incoming funds you get from other peers to a particular peer to optimize control for each channel that you're having here this means on top up I don't like on ten top ups nobody likes it right so what

I'm working on is the liquidity Network it's basically a project to build efficient of chain payment hops because we believe that option payments have are going to be there and they're complementary to two-party financials so we need both technologies but we need efficient hubs so what we're currently working on is to to get basically a payment heart which has very low set up costs it has low maintenance costs it has in particular failure safety on blockchain congestion so it shouldn't be as as winnable to Brockton congestion as typical to party payment channels and we want to support at least a hundred

thousand users part which would be quite quite significant cheap so the architecture is rather simple so I'm not showing I we don't have any technical vital yet as of today but just to give you an overall picture so we still have the blockchain we have a smart contract that is the liquidity Network smart contract we have an off chain liquidity network server and this is basically an off Jen hub so this is the over architecture as you as also is the case for typical to party of chain payments so our goal is to build an open I hope if they want to and the good part

is that we can actually also really use revive our protocol for rebalancing among different hubs so if you were to set up for example three different hubs they can actually be connected in a cycle and they can just rebalance their transaction so it's again increasing the scalability off of those those hubs so one thing I would like to discuss briefly is the option registration process so one of the beauties I think of of the hub is that if you're a new user and you want to join this up here you can actually perform an optional registration for free with the hub you're just sending a TCP mayor's message to the hub with the your

scientism address and then another user can actually send you an option transfer which you can directly forward so there's no need for you to do any registration like any deposit any on shell transaction so a new piece can actually join and already receive off chain funds and for example they could pay in some fiat currency and get off chain funds directly right so you actually never had one chain phones anymore so yes it would be interesting to see how this evolved so we have one demo of the of the wallet up on youtube if you want to if you want to check out the wallet how it would work so this was recorded basically from our internal

test nuts and so we are working on the deployment on aetherium so we will deploy the test net on in q1 of this year and also release more technical specification I can just encourage you to turn our slack in the meantime or follow us on Twitter so regarding scale so to summarize today so regarding scaling we have different scaling opportunities I think we parametrizing blockchains isn't isn't gonna work but still we need to understand the best limitations of the unchained permit parameterization so it's possibly that we can go of like up to a hundred

transactions per second with light changes starting an option transactions is is another way to scale on one side in for option transactions there are two party payment channels different types of payment channels that you can think of and they also end party payment hops that I believe will be necessary to actually scale thank you very much I'm happy to take your questions you mean between the uncle number of unconfirmed transactions the

transaction fees for transaction to put I would say the price of Bitcoin doesn't matter too much although although it's sure that the transaction fees they just half because they become tries hard so it it should have an impact there I don't think it's it's not uncorrelated but I think the transaction fees they're driving they should drive the price down because it makes the chain less usable it makes corporations go from a decentralized to a centralized model and

it's just it it makes you lose interest it's because there's too much demand but it's also because some corporations are not batching transactions so you can actually you can actually try to write more efficient transactions where you you batch together many many of your customers transaction and I think yeah it's quite some room where this offer because in in Bitcoin you just have a

limited capacity so the the capacity of transactions that you can process is limited by the box size right so how many transactions can you fit in and the intervallic the time frequency at which you generate box so it's just that so if you have one megabyte every 10 minutes that's that's your limit and the transaction is on average 20 50 bytes so it's a very good question I would

just be cautious we're saying the core team because then you imply a centralized party and then you imply these are the only ones that decide right which is not the case it's true I would say the majority of the peers agree I would put it like this always but but you're right it's not that easy so but coming back to your to actually an actual question you're very right we need to stand out and lightning is actually working very well on that I mean the Lightning specific the both specifications they explain very well the standard of of how to how to perform off chain transactions in Bitcoin it we are trying I mean actually with

liquidity we want to be compatible with them it will take some time because we first have to get basically our tests not running and understand I mean and basically just get the feedback from the community as well to some degree but I think compatibility is key so it's important to not brew your own kernel but actually be compatible with others I think that's true in revive its just round-robin so there's nothing no fancy leader election algorithm so if you have a set of different peers you can just have a

round-robin between the different peers you can just decide like on a random leader it doesn't really matter from a security perspective it's just you need like a particular a particular note that lets me tells everybody hey freeze your channels that gets all the signatures from everybody and then sends them the result no it doesn't have to be that no can be can be anybody in the okay it can actually be an external party yeah doesn't have to be help oh I think it will work

I mean it's just for for for easiness we have implemented on a few real with the sprites payment channels which is an Ethiopia channel implemented by Andrew Miller and other great researchers but we I think I think should certainly work on mounted sure you're right and it's not absolute I don't I mean I would need to to verify I haven't thought it over the death but it's likely that you don't need it yeah it should be able to run on script as well good question I mean for researchers it's just easier to do

prototypes and if your room because solidity just gives you more flexibility I agree but we're going to - we go into production with some research today are you have to differentiate between payments and state so cryptic it is is it's a smart contract where you likely need state channels and not payment channels right temperature is only for transmitting funds so no it is you're transmitting parts well how do you run a

nice you of a microwave so you would need to before you basically [Music] immature I see - your favorite i0 and so this needs to be done on chain right and then you stand them little like smaller transactions than your initial deposit right so why would you do that there's just there's not not real I mean at least I don't see how this would work if however you have already some amount of funds off chain in the network for example in a hub or in some reason

lightning Network if you already have some of chain funds then you could just forward them to do your favorite ICO that's that's a good question I would say the main difference is that you actually have side chains here and I wouldn't call pay mention on the side chain so this is the main difference I don't know I would I would also be happy

to get more technical details on class on how this would actually work I mean I understand that it takes some time to develop that I mean even liquidity we are not yet able to disclose like all the technical details but yeah it will I think we need more more details on how they would actually work the plasma yes on these socialist decentralized exchangers okay so promising zero transaction fees is

not a good idea I think the actual transaction fees have the purpose right they should prevent spam so I think we still need to do quite a lot of research on the on the deck systems or iota back systems to understand whether they are secure as they are proposed to having a coordinator even only a temporary accordingly to that you say it's only necessary at the beginning doesn't make too much sense to me but maybe I'm missing something so I'm happy to eat again like class mom happy to understand more and we need to throw security analyzes of this I mean even even for like standard proof of web block chains

we don't know why six block confirmations are enough right so before going ahead and like proposing the next big thing we should really go a bit back and understand what we're actually doing right now I haven't looked into so I think the I mean the market should

go towards I mean if we're talking about octane providers let's say off chain providers in there whether to party hop or whatever right I think the market would go towards solutions that favor less fees right I mean it should should just be like this that if you have a hub or if you have some some peers that's connect you to others off chain enter just take less fees they will be favored there is a lesson there's a cost into in changing your connections because you have to do on chain transactions closing one transaction opening another another transaction but ultimately I believe the network will go towards the cheapest transaction fees where-where's some manipulation

while damming the chain costs you write quite a lot of money so I don't know how I haven't made the calculations I think yep I think the idea I mean with off chain transactions I think the markets will be rather clear I mean we're just like people that because you don't actually many peers will be able to provide option services not many peers can do mining so there should be it should be a bit more competitive it's a very good question thank you and so

indeed it's it's a single point of failure if you have only one so that's why we envisioned this to be open true so anybody that wants to can create a hub so there will be a network of hubs that you can connect to and obviously there will be some peers or some hubs that have like much more connections than others just like as you've seen in the Lightning test net right so if a particular hub is just too powerful or is abusing its powers then people will change now what can I help do actually to abuse this power what's the worst thing that can happen it can actually deny transactions we can allow you it can deny two forward transactions that's so bad it's a dinner of service yeah but

if you have a congestive blockchain then you just can't do anything as well right so I think the the worst case notes are not that bad and it's not a bank because it doesn't have funds to your it doesn't have access at any point to your funds right so there's a fundamental difference and this is why we were in boxing I guess awesome I'm sure you can just a multi-party computation to improve that which would reduce the efficiency and increase the

communication among the peers but certainly yeah I mean we have we have been proposing this just as a means to show that you can actually do often rebalancing and you don't need function transactions but privacy is is something that everybody needs to work on and that's why I also put up humble but right because they are actually working to improve the privacy and I think this is this is very important