1
|
Bitcoin / Development & Technical Discussion / Re: The Lightning Network node experience
|
on: March 03, 2023, 10:12:29 PM
|
Core-Lightning v23.02 has just been released. There are two things worth pointing out: NEW experimental feature: peer storage - back up your encrypted emergency channel backup with your peers Protocol updates: Offers (BOLT12) and dual-funding breaking changes to comply with updated lightning spec
You can learn more about the peer backup feature here. Note that this backup allows you only to close all of your channels (as the other peer stores a Static Channel Backup). Closing channels through the SCB require the other party's cooperation so it should be your last resort anyway.
|
|
|
2
|
Bitcoin / Development & Technical Discussion / Re: Mastering the Lightning Network book
|
on: January 13, 2023, 10:56:08 PM
|
So to avoid it you need to broadcast the most up-to-date settlement transaction to the network.
Again, there's a period of time after B broadcasts such a state (closes the channel unilaterally), during which you can come back online and provide a newer state (state 2).
Actually, you don't broadcast another commitment transaction. If that was the case then there would not be any punishment. Every commitment transaction has at least two outputs ( to_local and to_remote). to_remote refunds the other party their share of funds. This output can be spent immediately. to_local refunds the person who broadcast the commitment transaction their balance. This output can be spent: 1) after X number of blocks have been mined since this commitment transaction was confirmed, where X is usually 144 blocks by default, 2) immediately using revocation private key and other party's signature. So if A attempts to cheat and broadcasts an outdated commitment transaction, B can construct a penalty transaction which consumes A's to_local output and sends it to their wallet. How does B know the revocation private key? Well, it's complicated. Long story short, when both parties sign a new commitment transaction, they exchange secrets (in a specific order) which can be used to generate the revocation private key for the commitment transaction that is being revoked.
|
|
|
3
|
Bitcoin / Development & Technical Discussion / Re: Can you transfer large amounts of BTC using Lightning Network
|
on: January 13, 2023, 10:38:33 PM
|
Is the Lightning Network used strictly for small transactions between two parties or can one party use it to send a large quantity of BTC (e.g. 35 BTC) to the other party? Is there any advantage to sending large amounts using the Lightning Network vs. using the normal bitcoin Blockchain?
Large payments can be split into multiple smaller payments, but sending 35 BTC would be impossible unless you had a direct channel with the recipient. For such large payments, you should generally use on-chain transactions. Anyway, I guess you wouldn't mind paying a premium fee for such a high-value transaction to place it in the first block in the mempool, so LN's instant payment settlement wouldn't be a huge advantage. Also, the larger the payment (value-wise), the higher fees you pay on the Lightning Network.
|
|
|
8
|
Bitcoin / Development & Technical Discussion / Re: The Lightning Network FAQ
|
on: November 04, 2022, 11:36:07 PM
|
IMPORTANT: LND users should update their nodes to either v0.15.4-beta or v0.14.5-beta. You can learn more about the fixed vulnerability here. I'm just reminding this, because I honestly never understood what was the purpose of all this hassle and bustle. Funds' restoration should be rather trivial thing to do.
Sorry about that! I have been extremely busy with my new job. I will try to find some spare time this weekend!
|
|
|
10
|
Bitcoin / Electrum / Re: What is "swap refund", and how do I avoid it?
|
on: October 23, 2022, 09:00:18 PM
|
But would it also be the case outside of “swaps”, say if the party I'm sending an LN payment to is offline, or if I shut down after sending an LN payment but before they receive it (for whatever reason)?
You can't send Lightning payments to offline nodes. If you disappear while your Lightning payment is being routed, your channel might end up being closed uncooperatively by the other party.
|
|
|
11
|
Bitcoin / Bitcoin Technical Support / Re: How can I connect lightning network wallet to main blockchain?
|
on: September 22, 2022, 11:56:32 AM
|
If I decided to be using lightning network channel, after I have gotten my appropriate wallet for it. How will I now connect my wallet or will the wallet automatically connected main blockchain?
Every Lightning-compatible wallet has its own Bitcoin wallet. You have to fund it before opening any channels. When you open a channel, some of your coins will be moved to a multi-signature address controlled by you and your channel partner. This involves a Bitcoin transaction. Secondly must recipient also be on lightning network channel before the transaction can take place.?
If the other person has a Lightning node/wallet then you should be able to send a payment, but: 1) if you have a channel with that person then the transaction will be instantaneous and free of charge, 2) if you have a channel with some other person then the transaction will be routed through other nodes, as long as there is a path between you and the payee. You will very likely pay a fee, which is negligible for low-value transactions. In both cases, the payment might failed due to lack of liquidity; it's a more complex topic. Let me know if you are keeping up so far. If the other person does not have any Lightning channels, you can do a submarine swap. There are third-party services that will accept your Lightning transaction and send an on-chain transaction to the provided address.
|
|
|
12
|
Bitcoin / Bitcoin Technical Support / Re: sphinx - lightning hardware wallet
|
on: September 21, 2022, 02:48:17 PM
|
since i am a noob in the technical stuff, can anyone here say something more about the device?
Stuff such as a Lightning signer seems necessary for the long term. Air-gapped lightning funds aren't possible with the current model.
I think that it works very similarly to LND's remote signing which has been around for quite some time now. I haven't seen any hardware wallet implementation of it, though.
|
|
|
14
|
Bitcoin / Development & Technical Discussion / Re: The Lightning Network FAQ
|
on: September 13, 2022, 12:41:36 AM
|
I would have expxected a 'Lightning Force Close' transaction to have 1 (Multisig) input and 2 outputs.
While you and I both know how a force close works in theory, I haven't found an actual flow graph or similar, that would definitely help explain the current situation (only one of the 2 nodes got the 'Lightning Force Close' transaction, basically).
I made a post explaining the uncooperative channel close some time ago. First of all, the timelock is decided before the channel is established. By default, most nodes force the other peer to wait 144 blocks (~1 day). The maximum acceptable value by default is 2016 blocks (~2 weeks). I configured my node to create channels with their_to_self_delay = 432 blocks (~3 days), so if someone decides to close the channel opened to my node uncooperatively, they will have to wait 432 blocks (after the commitment transaction has been included in a block) before they can spend the output belonging to them. Those timelocks are relative which means that you do not have to sign a new commitment transaction whenever a new block is mined. New commitment transactions are signed periodically because their fees need to match the current state of the mempool. There is no point in paying 60 sat/vbyte when 1 sat/vbyte transactions are getting confirmed in just a few minutes. It also applies the other way around.
The first transaction is the commitment transaction. Let's say there's node A(lice) and node B(ob), and node A broadcasts the commitment transaction. That commitment transaction includes two outputs:
- output #0: 3 BTC (spendable by node B's private key) - reflecting node B balance - output #1: 6 BTC (RSMC) - reflecting node A balance
There is one more important detail before we go any further. Whenever a new commitment transaction is signed, both parties exchange revocation keys for the previous commitment transaction so that they can both be sure that the other party is very unlikely to broadcast an old state of the channel.
RSMC is short for Revocable Sequence Maturing Contract. Such an output contains a relative timelock. This means that you can't spend this output until a certain amount of blocks have been mined since the transaction which includes that output was mined.
Let's say node B didn't change the default value of 144 blocks and the commitment transaction has been confirmed. There are two possible scenarios.
1) Node A attempts to cheat and broadcast an old commitment transaction. Node B has 144 blocks to spend the RSMC output using his and node A's revocation key which he got while they were working on a new commitment transaction.
2) Node A broadcasts the latest commitment transaction. In such a case, node B never got node A's revocation key for that commitment transaction, so he cannot spend that RSMC. Node A can broadcast another transaction spending that output after 144 blocks have been mined.
In this case, node 2 broadcast a commitment transaction with the following outputs: 1) RSMC (P2WSH)- this output can be spent by node 2 after 144 blocks. Node 2 should move those coins to its own address as soon as possible in case node 1 somehow got their hands on the revocation key. 2) Standard output (P2WPKH) - this output can be immediately spent by node 1 So, what can you do to recover your coins? Well, use lightning-hsmtool guesstoremote just like @n0nce has already suggested. As for max_channel_dbid.... max_channel_dbid is your own guess on what the channel_dbid was, or at least the maximum possible value, and is usually no greater than the number of channels that the node has ever had. You have to count all channels - even closed ones. So, if your node has had a total of 3 channels, you should set that parameter to 3. I can give you a more detailed explanation on why that's necessary once you confirm that it has worked.
|
|
|
15
|
Bitcoin / Hardware wallets / Re: Nano Ledger S?
|
on: September 03, 2022, 08:01:47 PM
|
Ledger has already ceased the production of the Nano S. You can still order the "Final Edition" limited edition. Does this also mean anyone that has a nano ledger s would eventually need to get a nano ledger s plus or x in the future? I know lot of people from years back bought the nano ledger s and store their coins there. But is there any concern now that because this product is discontinued, it won't work later on in the future such as there won't be any firmware updates for it anymore?
Ledger might stop providing software updates at some point in the future. No one knows when that's going to happen. You will always be able to use your device with older versions of Ledger Live and Electrum. Do you recommend everyone with just a nano ledger s now buy another hardware wallet such as the nano s plus or the x and just input their seed phrase into the new hardware wallet and no longer use the nano ledger s anymore or there is absolutely no need for that now?
Why would you replace it if it's still functional? By the time the Nano S becomes unsupported, there might be a ton of new hardware wallets to choose from.
|
|
|
18
|
Bitcoin / Development & Technical Discussion / Re: Testing C-Lightning v0.10.2 Offers! [BOLT12]
|
on: August 30, 2022, 08:32:16 AM
|
The receiver needs to reveal it!  The only reason I know BlackHatCoiner's public key is because we considered opening a channel. There's no way to do keysend without revealing node ID. The receiver needs to reveal their node id in an invoice as well. If the node id is not provided directly, it is recovered from a signature which proves that the invoice has not been modified by any malicious third-party. Also, it looks like c-lightning doesn't support blinded paths for BOLT 12 offers yet. Run the following command: lightning-cli decode [any BOLT12 offer]You will see that your node id is encoded in the offer.
|
|
|
19
|
Bitcoin / Development & Technical Discussion / Re: The Lightning Network node experience
|
on: August 29, 2022, 12:27:52 AM
|
Here are the stats for June and July. I haven't been paying much attention to my Lightning node lately - I rarely adjusted my feerates and I didn't rebalance any of my channels. I am sorry for occasional downtime. It took me a while to figure out what was was causing my Internet connection to go down regularly. June:  July: 39 routed transactions, 34 (!) of which were free of charge. 
|
|
|
20
|
Bitcoin / Development & Technical Discussion / Re: The Lightning Network node experience
|
on: August 26, 2022, 09:59:45 PM
|
I know my reply is slightly late, but you still might find it interesting. So, you prefer paying a third party monthly to watch the chain in case for cheating attempt, wherein there's trust involved and you don't gain the same level of privacy, and not paying for a power supplier, to be sure you'll be running 24/7?
I don't think that there are any paid watchtower services as none of the available implementations support reward watchtowers. The privacy is not an issue either. Watchtowers receive encrypted penalty transactions which can be decrypted only if an outdated commitment transaction is published. Here you can learn about LND's implemenation. I believe that lightningnetwork.plus is the most popular altruistic watchtower service. As for c-lightning, I know that a watchtower plugin exists, but I have never used it. Cheating happens publicly, not privately. You could open a case accusing me, with valid evidence. Anyone could, even people whom I've never talked to. Broadcasting a penalty transaction means one of the two is a scammer, de facto, and the honest user can prove the other guilty by showing their commitments.
You can't tell if someone tried to cheat or if it was an accident (due to a bug or an outdated backup).
|
|
|
|