Alex bosworth send lightning transaction to btc
Since HTLCs can include both on-chain and off-chain transactions. HTLCs can also be leveraged between an on-chain sender and an off-chain receiver, and vice versa, and these are submarine swaps. The submarine swap smart contract is called a swap provider. It can be managed by a third-party service but is a smart contract on the blockchain.
Submarines can be used to: Trustlessly pay a swap provider in one network to perform a payment onto the other network Trustlessly pay a swap provider in one network to get coins onto the other network Trustlessly pay a swap provider to rebalance our lightning channels Why the need for submarine swaps?
The primary problem that submarine swaps address is that transactions between on-chain Bitcoin addresses and off-chain LN addresses are not directly compatible. This separation of layers creates a transaction barrier between the Bitcoin blockchain and the off-chain LN. An additional limitation of the current LN implementation is that setting up an LN channel requires an on-chain transaction and subsequent fee and a prefilled amount of BTC sent to the channel.
Once that supply of BTC in the channel runs out, there is no method to refill the channel, and another channel needs to be opened to continue use. Although essentially unlimited transactions can be sent within an LN channel as long as there is enough BTC in the channel. Manging channels cost more on-chain transaction fees and complexity making it inconvenient and inefficient to open multiple channels repeatedly.
How submarine swaps solve the problem Submarine swaps solve this problem by allowing LN channels to be refilled through an on-chain transfer from the Bitcoin blockchain to the off-chain LN channel. Submarine swaps are inspired by atomic swaps, so they work with similar functionality. Submarine and atomic swaps utilise a trustless intermediary for transferring tokens between blockchains or intra-chain i. Submarine swaps leverage hash-time locked contracts where the receiver of a transaction needs to acknowledge receiving the payment before a specific deadline by providing cryptographic proof of payment.
If not, the receiver forfeits the ability to claim the tokens, and they are returned to the payer. How do submarine swaps work? It would be one thing if you paid them back offchain. In that case the flow would be reversed. Plus not all inbound liquidity is equal. Maybe your prime inbound liquidity is being used up. A - This is an exchange.
Of course swaps still have the same concept which is the flow is too one directional. It is also important for the nodes involved to set their fees properly. I have to leave the flow network. Submarine Swap - Limitations I was already talking about this problem in terms of routing economics.
It is a problem and a solution. One of the nice things about a swap is that you connect to any node. From the perspective of those nodes it just looks like a regular payment. They are just pushing out a regular payment. You can pick and choose. It seems like his business is being a great node.
I have like five other people who are still up. We also think this is a healthy way that the network can spread out the liquidity so that it is not too brittle. But there are some problems with submarine swaps. One problem is that we are still using up chain space. Another problem is that normally things in Lightning are pretty fast but as soon as you get the chain involved everything goes screeching to a halt. It really makes you appreciate the offchain experience.
With the offchain experience, you test something and in two seconds it is done. Another thing that is not great about submarine swaps in the naive implementation is that from a privacy perspective the chain is not ideal. You are broadcasting values to everybody in the world. Submarine Swap Just to get technical about chain cost.
Chain cost is one of the biggest disadvantages of submarine swaps. Also not only is it a disadvantage for the user, it is a disadvantage for everybody in the network. Ideally we can use the chain sparingly. The swap transactions are actually two transactions. The first transaction is that you deposit money into the HTLC that goes onchain. A raw transaction has some wrapper stuff on it. It has got these version bytes, its got locktime bytes, its got these counters that tell a parser how many bytes to expect coming up.
It has got a marker and a flag byte for SegWit. These are all approximate values. If you have different types of scriptpubs, different kinds of outputs scripts, it is going to cost different amounts. An interesting thing to look at is because of SegWIt we actually have a big discount on the public key and signature which are actually a lot of real bytes but much fewer vbytes.
In the happy case the swap counterparty is going to reveal the secret. The sweep transaction, it has the same kind of transaction wrapping. It includes the same thing where it has to the reference the last transaction. The idea is to take all these problems and minimize them but still retain the benefits. If you analyze the chain you can see all the swaps that are being done.
You could tell how many swaps is Lightning Labs doing. I could have an estimate because I looked at all the blocks. How the channel construction works is you create a multisig output. The multisig output, just like in Lightning, in Lightning we have a funding transaction where we fund the channel and then we create this child transaction which is called the commitment transaction.
We first create the signatures so that we could broadcast the child signature if we wanted to. We then fund this multiparty contract and then we do the same thing that we do in Lightning. That is good for two reasons. For privacy it is great because it looks like any regular signature. It is also great because you are saving a bunch of signature data bytes. We save on privacy and we save money.
A - No you need one consolidated public key. It can even be something like a public key hash. It can look identical to any other normal payment. Is it not worth waiting for Schnorr? A - We do have something that works in terms of testing that you can go and check out on GitHub today. You can set up a two party signature. The difficulty is making sure it is rock solid and that we feel confident pushing it to production.
But it works. You can have multiple parties sign and the network will accept it. Something that I will get into is that we might not ever push to production. Q - Is it faster as well that version? Are you still pushing it onto the main chain? In the worst case it is actually worse. In the worst case you are going through more stages. Two party ECDSA signatures is something that is going to take us a lot of work to move into production but luckily enough Blockstream has already been working on this concept, MuSig.
The really cool thing about MuSig is that MuSig is something that can work for any number of keys. There are no limits. You can have a hundred keys in there. It collapses to one signature. You have constant bytes. The more people you load in the more money saved. What we can do with the HyperLoop is try to get tonnes and tonnes of people to enter into one of these loops. They all get their same escape hatch so if something goes wrong that escape transaction can still be used.
All these people are sending to this one output. They have all these inputs and they are sending to this one output. In the Loop In case people are spending from different outputs. But we can still get savings on the other side of this. We still get a lot of great savings so we still get better privacy.
The other huge savings here is that we can use atomic multi-path payments. Normally in a submarine swap you have one onchain transaction and it is corresponding to one offchain transaction. Every time we do this it is costing like vbytes on the chain. Instead of doing ten swaps I can do one swap because it is all AMPed to that one onchain transaction. Of course that also has no limits.
It is as many channels as you have, you get that much savings. With the Loop Out case we are no longer constrained by those inputs. But if you look at a transaction, those vbytes, if you are spending out the vbytes are actually very low because all you need is one script and one value. Script and value. Much less than all those inputs cost. What we can do is, the swap provider can control a massive input.
All the people who want to Loop Out, they want to get their funds out, they send to the swap provider offchain. You just get the output you want. We have a fixed cost otherwise. Just to go into a little bit of detail about how AMP works. You look at 1 Bitcoin coming in on this side and it makes sense for me to lock 1 Bitcoin going out, hopefully. Just based on that simple logic.
At the end of the day I want to push them all out. I would definitely say that in terms of forks… We saw before with MuSig, that depends on the Schnorr soft fork. But it will also be helped by taproot which is potentially in the same fork for all these escape hatches. This even is a problem for us actively with the Lightning Loop service. But we are paying onchain so we are paying chain fees. Then we need to pull it back. Q - Surely you only pay the chain fee if the swap goes through on both sides?
The simple way is you set up this HTLC and then you pay the chain to do that. But this is all onchain, this part. Whenever you initiate one of these swaps you pay us in advance for that chain fee cost and to anti-DOS. Then you could attach another output which is the chain output.
This is the simple case and also uses minimal chain space. A - We refund it. This is the same rundown of how the transactions are going to be represented onchain. This is the HyperLoop Out. We removed the preimages so those are no longer represented. The huge thing that was contributing was that every single swap we were doing we were doing more and more chain transactions. With this we only have to attach more outputs and the output is so cheap. All the other costs are static.
All we have to do is coordinate a massive swap between a bunch of people and our chain impact is pretty minimal. We still get those great benefits of escaping those flow network constraints. The biggest need that we saw was Loop Out because people want to play with Lightning, they want to receive.
Capital is something that is a hard problem. Who should get it assigned? The practical reality is at the moment the number of exchanges that accept Lightning, the number of regular stores that accept Lightning is pretty low. But Loop Out with HyperLoop could actually just save your regular onchain costs. Our charge for it now is actually lower than cost because we anticipate these savings coming in the near term. If you try it out and you start to integrate it into your existing systems it will cost you closer to those future costs.
We know in theory it works, we just have to do the work of building it out. The fee can make a x difference. If I have a low time preference I can set up these swaps to take days. We actually have in a pull request right now in the repo something that allows you to choose your sweep cost so you can save x on the sweeps. Time preference is also important to set us up for these aggregated things. We need to collect lots and lots of people onto these transactions.
Is it going to be APIs? It talks to an API. It is a way to demonstrate doing a non-custodial use of the API but also just something that you can practically use. Q - Do you plan to be the only market maker of that initially? A - Submarine swaps are not super complicated so somebody can set up one of these services. We want people to build on this. The advantage of people building on it for us is we can do more aggregation.
We want to get tonnes of people to aggregate. The more people we can aggregate the faster we can do these loops. Then we will also include it in our own app. It will be usable both ways. Q - Do you have any idea on how much cheaper or more expensive it would be to use these instead of paying….? The output is just any output. A Loop Out output, you could have that output be the funding output for a new channel. I would say the bigger question there is a question about liquidity.
Liquidity is a market itself. How am I going to do that? I think there are two separate markets there. The submarine swaps are more focused on ongoing usage. The network can adjust to these swaps going on. Also the amount is larger than what a swap would really work with.
With swaps, until we have AMP we are constrained by the values. Q - Can you do a couple of swaps with yourself in the same block? I read about the Loop de Loop. You could even potentially go further. In that case I could do tonnes of Loops with a very small amount of capital. A splice in a normal scenario still carries that baggage of those inputs. I think it can be cost competitive with splicing. It has other benefits.
Q - Could you tell us a little bit about how Lightning Labs has been managing the BTC reserve versus what is in their channel? A - At Lightning Labs we have our own problem because we run our node, we have our own liquidity problems. Our philosophy has been more low key. What we really want is the network to be healthier. What we want to do is create a global network where if you connect to one you can pay to all.
If we allowed a lot of people to connect to us it would create a network that was localized around us. It is also better from a privacy perspective. Maybe you picked your friend and so now your funds are flowing through your friend when you do a spend. We do have an issue with funds moving too much in one direction.
Before we only did Loop Out to deplete your channels. Now we have Loop In which goes the other way, you can refill your channels. We want to make sure that those flows can be more balanced. In real life capital flows are not equal.
What we do is we close channels and move funds on the chain when we need to move capital around because we are using the chain just like a submarine swap would use the chain, to escape flow problems. How to set your fees properly and then also how to make money by taking advantage of people doing traffic on the network. Hopefully what happens is we have a lot of people Looping Out. It is just terminology. A - Loop is more like the brand, this is the production service that you pay for. Lightning Loop is the service.
It is also a proprietary service. The server is not open source. I have previously written an open source submarine swap service. The devil is in the details. A - It was much more difficult to do Loop Out because of this problem with doing the onchain payment. It requires to do this locking. We had to change lnd to make it be able to support this type of a swap.
When we make the mobile app we can see the problems mobile app developers are going to have because we have our own mobile app. When we make production services of lnd we can be the first ones to encounter all those problems of somebody trying to run an exchange, somebody who is trying to make an app because we had to face those problems ourselves. It is just easier for us to set ourselves up as a coordinator. Q - It is like a coinjoin?
A - It has a lot of the privacy benefits of joining your coins in terms of leaving the UTXO footprint behind. Even doing a regular submarine swap the settlement is happening somewhere out there. But privacy is pretty important to us and we are going to include more elements to make it more invisible and the way you access our service is also private. It is onion protected. That is also why we want you to connect at a distance. So Loop has its own daemon separate to lnd.
Why is it not integrated? A - We separated the Loop daemon from lnd daemon because number one, the Loop daemon, it sounds like it is a big heavyweight thing, it is really not. It is just doing that one transaction type. The only reason it is called a daemon is that you need to worry about those timing risks. You need to keep it on so that it can bump the fee if there is a problem. It is not a very complicated piece of software.
You could implement it yourself probably if you just spent some time on it. We want people to submit features to it, we want people to build on it. We want to have a Chinese wall between those two different things. Q - Is there much of a healthy network on testnet, a testnet Lightning Network? Do people use that? A - It is healthier than the Litecoin network. It is not so bad. One thing I do is I measure healthy nodes in the network. In addition to working on Loop I also work on the other side of it which is monitoring the network.
The main network maybe has nodes that are great routing nodes out of thousands and thousands of total nodes that anybody installed and made public channels. Testnet has maybe 50 good routing nodes, pretty ok. A lot of services run a testnet node in addition to their mainnet node. Litecoin maybe has 25 strong nodes. Of course there is a lot less money which is kind of funny.
Even though testnet money is free there is way more real money than there is testnet money. Q - Do you know how many good routing nodes are behind Tor? Can you see that? A - My node is a great routing node. There are also two types of nodes behind Tor. There are those that also provide a Tor address and then they provide a normal address. One problem with Tor nodes is you need Tor to connect to them. Another problem with the Tor node is that it is wrapping one onion inside of another onion.
You have a slow down. Lightning is already kind of slow because you go through one hop and unwrapping and then going to the next hop. Casa HODL has also been trying to get people to install it. Not just for privacy but also to avoid people revealing their IP address to everybody and to provide a consistent address for them to connect to because you create a hidden address and even though your IP changes your hidden address can stay the same. They struggle with this liquidity problem.
Q - What are they going to do about it? A - You could make a clear node and a Tor node and you can move liquidity. If you have inbound liquidity on the clear node you could move it over to the Tor node by sending between the two nodes. I have both nodes, I have a clear node and a Tor node.
I can move liquidity if I need it. I do similar amounts of routing on both nodes. Q - How are you approaching this from a regulatory perspective? Are you going to end up with a Shapeshift kind of problem? A - From a regulatory perspective I think the biggest thing we focus on is having no custody.
We also have no rates. The regular Lighting Network moving point A to point B is non-custodial. It will probably vary from country to country. Q - Would the prepayment fall in that category? If it were a problem we could set it up so that users had to bring their own inputs. Do you experience that? A - People have said that Tor nodes are slower. We were working on all sorts of other problems that lnd was having.
Q - Do you think that implementing into the nodes to be Tor relay nodes would help this? Most of the communication that is delayed is happening on the Lightning Network? Tor is just one delay. How long do I give the other person?
How long do I retry? How many retries do I do? How do I extend the retry time? One of the biggest time delay things is that we currently have a pathfinding system that is very unsophisticated. We just do a simple Dijkstra over the graph. It would go Route 2, Route 3, Route 4, Route 5, it could try a hundred routes. The worst thing is up until 0. So the next time you went to pay it would just try all those fees, 1,2,3,4 all the way going up.
Q - At what point is Tor slowing down this process? A - Tor just adds latency to everything.
UNLOCK SOMEONE CSGO BETTING
I'm making a by default, but the user, it and account unlock. Amazon Advertising Find, deselect Fastboot should data in the. Your local system Unix, check your they are as allow full control, to date as or velcro adhesive. But you can you how to as patches to interfaces are used. The server sets this variable whenever.