Topic: Electrum 4.3.0 Relased (Read 322 times)

send works

but how do you receive in electrum given a LN URL withdrawl.
Where do I put a LNURL-withdraw URL on the electrum wallet?

OK, I get that part.
but where do I use it in the electrum desktop wallet?

You won't find the link in the Electrum UI, the link I was referring to is displayed on the playground site that I provided a link to: https://lnurl.fiatjaf.com/

That site produces a variety of LNURL links, one of them is labeled "LNURL-pay."  It's just a way to test if the links can be used with your wallet.

Sorry, but where is this link  "clicking on LNURL-pay"  I dont see it in the UI.

I'm still running 4.3.1, but it seems to be working fine for me.  Are you sure you're entering the correct url?  I haven't used LNURL-pay myself, but here's a link to a "playground": https://lnurl.fiatjaf.com/

Once Electrum is up and running, clicking on LNURL-pay link populates the data in the Send tab in Electrum.  Then I just need to click on "Get Invoice" button and it loads the transaction and prepares it for signing.

Hi I downloaded 4.3.2 but I do not see anywhere the support for LNURL.
What am I missing please?

* In addition, the following new features are worth noting:
    
    - support for LNURL-pay (LUD-06) (#7839)
    

Can anybody else confirm this?

Another comment in that thread has me confused, unless I'm missing something; a user mentioned that he no longer wants to use segwit addresses.  Why?  I know about the bech32 v0 flaw with the checksums, but I reckon the chances of that resulting in a loss of funds are rather remote.  I don't think segwit addresses are any more vulnerable to clipboard malware than any other address, and if you don't go around swapping your p's and q's I think you'll be fine.  Again, I may be missing something, and if so I hope someone will enlighten me.

Are you talking about the comment made by the user with the name of nbourbon?
If so, I think he/she doesn't want to use segwit addresses just because he/she thinks that it's better to use taproot addresses. I don't think that's due to a flaw in segwit addresses.
Maybe, that user doesn't know that with using taproot addresses instead of native segwit addresses, he/she will have to pay more fee for many of the transactions.

New electrum version is released. This release is focused on improvement of Lightning UI and finally the support of the Blockstream Jade hardware wallet^[1].

It looks bulky in the pictures since it's scaled with your monitor and it's hard to judge the size of a picture of an object without a reference.

but it's nice to see Electrum devs are constantly improving their wallet.

New electrum version is released. This release is focused on improvement of Lightning UI and finally the support of the Blockstream Jade hardware wallet^[1].

Although i just heard this new hardware wallet, it looks like neat but like a bulk remote to me. Lol
To those who keep collecting hardware wallets, making reviews, using the liquid network, i guess its must to try.

Another comment in that thread has me confused, unless I'm missing something; a user mentioned that he no longer wants to use segwit addresses.  Why?

It's currently in the "backlog Milestone" so there's no definite release date: github.com/spesmilo/electrum/milestone/12
Also, ecdsa seems to be annoyed by users asking for Taproot support :/ (reference post)

So no Taproot address support yet? Where is that in their release timetable? It shouldn't be too hard to implement since they can just adapt similar code from Bitcoin Core.

Although i just heard this new hardware wallet, it looks like neat but like a bulk remote to me. Lol

# Release 4.3.0 - (August 5, 2022)

 * This version introduces a set of UI modifications that simplify the
   use of Lightning. The idea is to abstract payments from the payment
   layer, and to suggest solutions when a lightning payment is hindered
   by liquidity issues.
    - Invoice unification: on-chain and lightning invoices have been
      merged into a unique type of invoice, and the GUI has a single
      'create request' button. Unified invoices contain both a
      lightning invoice and an onchain fallback address.
    - The receive tab of the GUI can display, for each payment
      request, a lightning invoice, a BIP21 URI, or an onchain
      address. If the request is paid off-chain, the associated
      on-chain address will be recycled in subsequent requests.
    - The receive tab displays whether a payment can be received using
      Lightning, given the current channel liquidity. If a payment
      cannot be received, but may be received after a channel
      rebalance or a submarine swap, the GUI will propose such an
      operation.
    - Similarly, if channels do not have enough liquidity to pay a
      lightning invoice, the GUI will suggest available alternatives:
      rebalance existing channels, open a new channel, perform a
      submarine swap, or pay to the provided onchain fallback address.
    - A single balance is shown in the GUI. A pie chart reflects how
      that balance is distributed (on-chain, lightning, unconfirmed,
      frozen, etc).
    - The semantics of the wallet balance has been modified: only
      incoming transactions are considered in the 'unconfirmed' part
      of the balance. Indeed, if an outgoing transaction does not get
      mined, that is not going to decrease the wallet balance. Thus,
      change outputs of outgoing transactions are not subtracted from
      the confirmed balance. (Before this change, the arithmetic
      values of both incoming and outgoing transactions were added to
      the unconfirmed balance, and could potentially cancel
      each other.)

 * In addition, the following new features are worth noting:
    - support for the Blockstream Jade hardware wallet (#7633)
    - support for LNURL-pay (LUD-06) (#7839)
    - updated trampoline feature bit in invoices (#7801)
    - the claim transactions of reverse swaps are not broadcast until
      the parent transaction is confirmed. This can be overridden by
      manually broadcasting the local transaction.
    - the fee of submarine swap transactions can be bumped (#7724)
    - better error handling for trampoline payments, which should
      improve payment success rate (#7844)
    - channel backups are removed automatically when the corresponding
      channel is redeemed (#7513)