Topic: ELECTRUM - BITCOIN WALLET - page 21. (Read 40171 times)

Tapi kalau berdasarkan pemahaman saya dari penjelasan om Husna maka saya pikir itu sudah jadi standar baku om. Maksudnya memang harus di verif dengan Electrum juga, tapi kalau kompatible atau bisa juga di verif dengan tool lain maka itu artinya fleksible. CMIIW.

There is no solution and you cannot sign a message with a segwit address. This has been the case since segwit was introduced. See https://github.com/bitcoin/bitcoin/issues/10542

akan saya coba juga nanti karena saya kira cara sign message-nya juga tidak ada bedanya berdasarkan tutorial yang saya baca.

>snip

Sedikit catatan, untuk sign message menggunakan Segwit address (contoh agan diatas menggunakan address awalan bc1...) setahu saya belum ada standar baku dalam memverifikasinya. Dengan kata lain ketika diverifikasi menggunakan tool lain bisa saja failed.

Jadi minimalnya untuk memverifikasi mesti menggunakan Electrum lagi. Saran saya untuk keperluan sign message, gunakan address Bitcoin P2PKH/Legacy address yang berawalan 1.

Kalau scan barcode transaksi, baik itu seluler mau pun PC belum ada.

Paradigma yang harus segera diubah jika bersentuhan dengan crypto. Nyimpen di wallet exchange itu memang gampang, cepat dan tak perlu ribet bikin sad seed key segala, namun resiko jauh lebih besar, seperti keterlambatan atau stuck karena beberapa kasus alamat pengirim yang diflag sebagai alamat yang dicurigai.

Kalau scan barcode transaksi, baik itu seluler mau pun PC belum ada. Di PC pun hanya sebatas alamat bitcoin.

Tapi sayangnya fitur scan barcode tampaknya belum ada untuk aplikasi selulernya, tapi untuk versi PC sepertinya sudah ada.

Sejauh ini saya lebih sering menggunakan wallet exchange daripada dompet lainnya

-snip-
Sejauh ini saya lebih sering menggunakan wallet exchange daripada dompet lainnya sehingga tidak sekalipun saya pernah mencoba membuat sign message, tetapi semenjak Electrum saya gunakan maka saya mulai belajar melakukan sign message. Jadi karena saya baru belajar, maka saya harap seseorang dari anda mau memverifikasinya.

Jadi karena saya baru belajar, maka saya harap seseorang dari anda mau memverifikasinya.

Kalau build manual dari source github mestinya fitur tersebut bakal ada mestinya, kalau download apk dari play store atau yang lain mungkin buildnya masih belum diupdate jadi belum ada. Soalnya ane lihat di release notesnya ga ada keterangan itu ekslusif di build pc aja.

Support for paying to "lnurl-pay" is added to the Qt and kivy GUIs.

LNURL dasarnya bukan dari ATM, tapi dari pengembangan Lighting Network yang dulunya pakai invoice ke sekarang (LNURL). Jadi tinggal scan, tidak perlu repot copa copy invoice lagi.

Kemudian mengenai fitur LNURL-pay apakah itu integrasi dengan walet electrum juga? Sudahkah semua ATM pakai LN ini.

Kebetulan saya pakai yang 4.3.0 versi android saja. Saya tidak instal di komputer. Memang beberapa minggu saya tidak transaksi. Tidak menemukan eror juga pada penggunaan sebelumnya. Apakah ini terjadi pada versi windows saja? Saya juga belum update ke versi 4.3.1, karena belum sempet juga.

Saya juga belum update ke versi 4.3.1, karena belum sempet juga.

Kemudian mengenai fitur LNURL-pay apakah itu integrasi dengan walet electrum juga?

Sudahkah semua ATM pakai LN ini. Jika sudah terintegrasi tentu biaya fee untuk transfer akan semakin murah,walau tergantung kepadatan jaringan juga.

Lightning-fast blockchain payments without worrying about block confirmation times.

Oh ya sejak versi 4.3.0, notifikasi error Electrum quit unexpectedly yang muncul ketika menutup Electrum yang digunakan bersamaan dengan hardware wallet sudah tidak muncul lagi sebagaimana di versi sebelumnya yang pernah saya alami: https://bitcointalksearch.org/topic/m.60248363

# Release 4.3.1 - (August 17, 2022)
 * build: we now also distribute a "source-only"
   Linux-packager-friendly tarball (d0de44a7, #7594), in addition
   to the current "normal" tarball. The "source-only" tarball excludes
   compiled locale files, generated protobuf files, and does not
   vendor our runtime python dependencies (the packages/ folder).
 * fix os.chmod when running in tmpfs on Linux (#7681)
 * (Qt GUI) some improvements for high-DPI monitors (38881129)
 * bring kivy request dialog more in-line with Qt (#7929)
 * rm support of "legacy" (without static_remotekey) LN channels.
   Opening these channels were never supported in a release version,
   only during development prior to the first lightning-capable
   release. Wallets with such channels will have to close them.
   (1f403d1c, 7b8e257e)
 * Qt: fix duplication of some OS notifications on onchain txs (#7943)
 * fix multiple recent regressions:
    - handle NotEnoughFunds when trying to pay LN invoice (#7920)
    - handle NotEnoughFunds when trying to open LN channel (#7921)
    - labels of payment requests were not propagated to
      history/addresses (#7919)
    - better default labels of outgoing txs (#7942)
    - kivy: dust-valued requests could not be created for LN (#7928)
    - when closing LN channels, future (timelocked) txs were not
      shown in history (#7930)
    - kivy: fix deleting "local" tx from history (#7933)
    - kivy: fix paying amountless LN invoice (#7935)
    - Qt: better handle unparseable URIs (#7941)

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)

Sudah bukan rahasia jika saat Wallet electrum terkoneksi dengan public server maka IP dari pengguna akan terekspos oleh server dan semua address yg dipakai juga akan te-record di server tersebut (yg berarti setiap transaksi didalam address-address tersebut juga tercatat di server).

Setahu saya wallet yang ber-extension .dat  adalah file wallet yang dibuat di Bitcoin Core, sementara itu untuk wallet yang dibuat di Electrum tidak memiliki extension apapun.

jadi tidak ada celah juga bagi hacker yang sudah memiliki file wallet untuk merobos masuk ke wallet dengan cara apapun jika tanpa mengetahui passwordnya. IMO

Baru tahu juga tentang itu Om, tapi sebenarnya ane nyadar bahwa itu biasanya ter-enkripsi otomatis jika tidak menghilangkan centang itu pada saat membuat wallet.

Baru tahu juga tentang itu Om, tapi sebenarnya ane nyadar bahwa itu biasanya ter-enkripsi otomatis jika tidak menghilangkan centang itu pada saat membuat wallet. Jika memang file wallet itu tidak berfungsi kalau peretas tidak tahu kata sandi, maka file wallet electrum bisa dikatakan lebih aman daripada file wallet bitcoin core.

Dan jika sebelumnya ketika membuat wallet di Electrum di-enkripsi dengan menggunakan password, maka jika file wallet tersebut dibuka di Electrum PC lain sekalipun mesti tahu passwordnya juga untuk men-decrypt-nya.

Setahu saya wallet yang ber-extension .dat  adalah file wallet yang dibuat di Bitcoin Core, sementara itu untuk wallet yang dibuat di Electrum tidak memiliki extension apapun.
Dan jika sebelumnya ketika membuat wallet di Electrum di-enkripsi dengan menggunakan password, maka jika file wallet tersebut dibuka di Electrum PC lain sekalipun mesti tahu passwordnya juga untuk men-decrypt-nya.

Resiko offline juga lebih kecil daripada resiko penyimpanan online. Karena resiko lebih besar, jadi dianjurkan untuk penyimpanan secara offline, karena wallet seperti electrum ini hanya sebagai tempat proses transaksi, yang sebenarnya bukanlah tempat penyimpanan bitcoin dan private key. jadi jika di %appdata% masih nyimpen wallet di sana, harus hati-hati, di luar hacker dengan mudah mengasesnya pakai remote, contohnya banyak yg jual wallet.dat