0 sats \ 0 replies \ @Filiprogrammer 2 Nov \ on: A Fast, Scalable Protocol For Resolving Lightning Payments lightning
So as a Lightning node operator it could make sense to use a combination of the existing Poon-Dryja payment channels for larger payments and the Offchain Payment Resolution (OPR) protocol for small payments.
If you have a simple Electrum wallet file then it actually makes things pretty easy.
- In Sparrow Wallet go to "File" -> "Import Wallet..."
- Next to "Electrum" click "Import File..."
- Locate the Electrum wallet file (usually in ~/.electrum/wallets/)
- You are asked to name the wallet. Click "Create Wallet".
- Optionally set a password
- Now you have imported the wallet and your SegWit Coins should appear.
- Switch to the "Settings" tab
- Change "Script Type" to "Taproot (P2TR)"
- When asked whether to clear the keystores, select "No"
- Click "Apply"
- Now you should see your "lost" Taproot coins, ready to be spent.
Is your seed even a BIP39 seed?
If you generated it using Electrum it is most likely is an Electrum seed.
When you restore your wallet in Electrum you probably go through "Standard wallet" -> "I already have a seed". When entering the seed, do you change anything in the "Options" or do you leave it on the default "Electrum" seed type.
And on a different note: You do not actually have to patch Sparrow wallet. Under "File" -> "Preferences" -> "General" -> Turn off "Validate derivations"
I reproduced your situation on regtest and I managed to view the "lost" taproot coins in Sparrow wallet. I would also be able to recover the "lost" coins but that requires a patch to Sparrow wallet.
First to view the "lost" taproot coins:
- Download Sparrow wallet
- In Sparrow wallet create a new wallet
- Set "Script Type" to "Taproot (P2TR)"
- Under Keystore click "xPub / Watch Only Wallet"
- Next to "xpub:" paste the xpub you gave to Wasabi Wallet
- Next to "Master fingerprint:" enter "04b2430c"
- What you type next to "Derivation:" does not matter but just enter "m" since it requires this box to not be empty
- Click "Apply"
- Switch to the "Transaction" tab and your "lost" coins should be there.
Recovering the "lost" taproot coins (this method involves typing the seed into a computer, making the wallet hot):
-
Navigate to https://iancoleman.io/bip39/
-
Set the number of seed words you are using (12 or 24)
-
Type your seed words into the "BIP39 Mnemonic" text box (assuming that you have a BIP39 seed)
-
Scroll down to "Derivation Path" and select "BIP32"
-
Next to "BIP32 Derivation Path" enter "m/84'/0'/0'"
-
Copy the "BIP32 Extended Private Key"
-
Create a new wallet in Sparrow wallet
-
Set "Script Type" to "Taproot (P2TR)"
-
Under Keystore click "New or Imported Software Wallet"
-
Next to "Master Private Key (BIP32)" click "Enter Private Key"
-
Enter your xprv (the one you copied in step 6)
-
Click Import
-
Set the derivation path to "m/84'/0'/0'"
-
Click "Import Custom Derivation Key..."
-
And this is where you would click "Apply" but it is grayed out because of a restriction in Sparrow Wallet which would need to be patched out. (I can take a look at this later)
-
Then your "lost" taproot coins should theoretically appear and you should be able to send them.
There is probably a way to do this without making the wallet hot, but that depends on the type of cold wallet you are using.
In any case, your coins are NOT lost.
For anyone trying import a watch-only wallet without Taproot into Wasabi:
In the JSON file set
"TaprootExtPubKey" to null and "TaprootAccountKeyPath" also to null.It should be possible to recover your "lost" coins by manually specifying the
m/84'/0' derivation path when configuring the taproot wallet. I haven't tried that though.Does anything speak against decoding the invoice and checking whether the payee public key is the same as the public key of the own node and then just not doing a payment through LND, but instead just moving around some numbers in the internal database?
And to prevent anyone else from paying the invoice afterwards, you can use the CancelInvoice RPC call: https://api.lightning.community/api/lnd/invoices/cancel-invoice/index.html
When you want to receive payments to a private channel, invoices need to contain a routing hint telling the sender which node the last hop of the payment should go through. Without the routing hint the sender has no idea where to route the payment.
Next, we install mvp, a media player that allows for secure playback of media files.
Typo, should be mpv
An update to this is available at: #720736
110 sats \ 0 replies \ @Filiprogrammer 17 Sep \ parent \ on: Possibly stupid question about links security
As long as your web browser is up to date, the risk of malware entering your system just by clicking on a link is relatively low. But if you want to further minimize the risk, you can disable JavaScript in your browser. However, this will limit the functionality of many websites. And if you are really paranoid you can run your web browser in a virtual machine.
Also you should not store your bitcoin savings on a computer connected to the internet. Preferably store them on a hardware wallet.
Wallets do not send the xpub directly to the Electrum server. Instead, they derive the addresses (--> script hashes) from the xpub and then request the balance for each individual address.
Alternatively you could try Strike's fee estimator:
https://bitcoinchainfees.strike.me/v1/fee-estimates
LND does not allow multiple fee urls as of this point so the best alternative would still be to run your own Bitcoin node.
LND has actually had support for leader election for at least 3 years already. Some documentation on it can be found here: https://docs.lightning.engineering/lightning-network-tools/lnd/leader_election
But during my testing I did manage to get two nodes to become active at the same time, which is bad. I described it in this issue: https://github.com/lightningnetwork/lnd/issues/8913
This was an LND bug, where it would not resign from its leader role. etcd was working as it should.
Two weeks later the bug got fixed with this pull request: https://github.com/lightningnetwork/lnd/pull/8938
With the patch applied,
healthcheck.leader.interval set to 60 seconds and cluster.leader-session-ttl set to 100 seconds, I could no longer produce a situation where multiple nodes were active at the same time.With this configuration, each lnd node creates an etcd lease with a time-to-live of 100 seconds. This lease is kept alive at intervals of one third of the initial time-to-live. So in this case it is kept alive every 33 seconds. When a node loses its connection to the rest of the cluster, it takes 27-60 seconds to initiate a shutdown. And it takes 66-100 seconds for another node to take over. So in this configuration there is no room for overlap, so no chance of two nodes being active at the same time.
I did consider trying with bbolt on top of Ceph, but since etcd is already implemented in lnd it seemed like the more native approach to use etcd. But I am planning to compare this to a setup with Ceph and do some benchmarks.
I'm not sure I understand why polling would be a better option than LND being notified via ZMQ. Also there is only ever one instance of LND (the leader) connected to the Bitcoin node at the same time.
OP can you break this down a bit? at a glance this seems more perilous than simply running lnd on VM's over ZFS
ZFS is designed to only run on a single server. So if that server fails, the node will be down. If we are trying to achieve high availability, we need a distributed system where ideally every server has its own uninterrupted power supply.
I explain the setup in more detail in the linked guide.
I haven't compared this to postgres yet, but sending a 1000-part payment to a channel partner on etcd slowed the node to a crawl.
I plan to do some benchmarks under different configurations and also compare it to a postgres backend. I also plan to benchmark lnd with a bbolt database running on a 3-node Ceph RBD.