New answers tagged

1

As far as I understand (but I did not double check the code) the answer is yes. The error messages in the onion seem to be encrypted in a way so that only the origanal sender of the onion can decrypt it. Since the error also had to be padded to keep the error onion of constant length the key derivation scheme for sending onions is kind of reused. In that ...


0

So there are a couple things to consider here: The database, it needs to be remotely available if you are going to failover your Lightning node. We talk about adding support to eclair for a remote database (postgres) in our blog post here Safely accessing the database. If you have two nodes writing to the database at the same time, it is possible that they ...


1

From what I understand there are two types of backups. On-chain backups which store the keys of your on-chain funds that is on-chain channels and on-chain funds in the lightning implementation. This is the hsm_secret file in C-lightning. The other backup is the channel state which stores the commitment transaction state, the revocation keys etc. This is the ...


4

Tl;dr: also in lightning we have: not your keys, not your coins. More detailed explanation: I assume you mean with backup the private keys of the lightning node together with the history of the state data. Then the same would happen as in the onchain case if you loose your keys. You could not move the coins anymore. Or in a onchain 2-2 multisig wallet (...


0

This is a trusted service for now but it utilizes the Lightning Loop to do a reverse submarine swap https://reckless.capital/swap At the moment of writing this website is on the Lightning Testnet. Soon this service will be available for use on Mainnet. Also full disclosure I am the owner of the website.


2

The tlv_payload is a modification to the way onion packets are created between the 1.0 version and the 1.1 version (current working version) of the BOLT specs. The (optional) feature is named var_onion_optin in BOLT#9. In V1.0 of the spec, there was a fixed structure for sending onion payloads to hops along a route, which contained a short_channel_id, a ...


1

The two answers provided are great, but I just wanted to add something short and to the point, to address what I think is the main point of your misunderstanding: To open a LN channel, you will coordinate with a peer to create a multi-sig address and funding transaction that pays to it (there are some further details that are agreed upon during channel ...


4

This is a very good question and I will give a quick summary of what is happening here. The longer version can be seen on my educational video on how to create payment channels starting at 33:41 (though I would recommend to watch from the beginning to review bitcoin and notation.) My understanding being the multi sig wallet is a temporary address which ...


2

The "instant" payment of Lightning is only possible for already-established Lightning channels. New channels are subject to confirmation times like any other bitcoin transaction. When a channel is opened, the fundee specifies a minimum depth at which the channel must be confirmed for it to be considered active. Once it has been broadcast and has reached ...


1

The issue of waiting for signatures also holds true in the single funded channel. Let us assume Alice wants to open a single funded channel. As long as she has not gotten signatures for the commitment transaction via commitment_signed message she cannot publish the funding tx. In the dual funded case there need to be two rounds of signature exchanges (one ...


Top 50 recent answers are included