pull down to refresh
0 sats \ 3 replies \ @Filiprogrammer 19 Nov \ parent \ on: Wasabi Wallet v2.3.0.0 released! bitcoin
yes, not sure why
Mostly agree, but...
Buying non-KYC is nonsense.
Buying non-KYC Bitcoin can make sense when you don't want your government to know that you own Bitcoin.
The only issue I had was it took ages to pay the invoice and the status was stuck on 'attempting lightning payment' for over an hour. I thought the invoice I created would have expired for sure.
This is normal with Hodl invoices. Robosats will also tell you below the invoice when it is a hodl invoice, meaning it freezes in your wallet until the trade is over.
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.