ELECTRUM - BITCOIN WALLET

[abhiseshakana]

Klo menurutku asumsiku waktu Ledger nano dijalankan di electrum versi 4.0.9 ada sebuah pengaturan yang secara otomatis tersimpan di file registry, sehingga supaya ledger nano tersebut bisa dijalankan pada versi electrum lama 3.0.8 maka file registry tersebut perlu dihapus/dimodifikasi terlebih dahulu.

Tetapi kenapa tidak pakai saja yang versi 4.0.9 yang notabene adalah versi terbaru dan tentunya memiliki fitur yang lebih complete ?

[joniboini]

Kalau dari ceritanya om Husna sebelumnya sih karena masih sering make PC yang OSnya masih out of date dan hanya support 3.3.8, tapi udah mulai move on sih. Eniwei yang pasti app di Ledger Live bukan jadi sebabnya. Bisa jadi file wallet atau file registry seperti yang dibilang om abhi di atas, dan berlaku baik di Mac ataupun Windows. Bisa jadi juga bukan bug tapi emang sengaja dibuat begitu biar ga konek ke versi lama yang punya bug untuk antisipasi kasus seperti 3.3.4 dst, who knows.

[Husna QA]

Klo menurutku asumsiku waktu Ledger nano dijalankan di electrum versi 4.0.9 ada sebuah pengaturan yang secara otomatis tersimpan di file registry, sehingga supaya ledger nano tersebut bisa dijalankan pada versi electrum lama 3.0.8 maka file registry tersebut perlu dihapus/dimodifikasi terlebih dahulu. -snip-

Kalau di Windows OS mungkin bisa jadi ada file registry yang temodifikasi ketika digunakan di Electrum 4.0.9. Namun untuk macOS setahu saya tidak ada registry, tidak ada regedit sebagaimana di Windows OS.

Sebenarnya sudah fix tinggal menggunakan Electrum versi terbaru saja sih ketika mau menggunakannya dengan Nano X, meskipun saya masih rada canggung ketika menggunakan macOS baru (full 64 bit) terutama harus adaptasi lagi dengan software-software lain untuk sehari-hari yang beberapa diantaranya bahkan ada yang tidak kompatibel karena paltformnya masih 32 bit.

-snip- Bisa jadi juga bukan bug tapi emang sengaja dibuat begitu biar ga konek ke versi lama yang punya bug untuk antisipasi kasus seperti 3.3.4 dst, who knows.

Sementara itu kasusnya terjadi di ledger Nano; Namun untuk di trezor meskipun sudah digunakan ke Electrum 4.0.9, masih tidak ada masalah ketika dikoneksikan kembali ke 3.3.8.

[Husna QA]

Beberapa hari yang lalu saya bertransaksi menggunakan Electrum, dengan fee sekitar 10 sat/byte (pada transaksi sebelumnya hanya perlu beberapa jam saja, namun untuk transaksi setelahnya ini ternyata masih belum terkirim juga meskipun sudah beberapa hari; Saya cek ternyata fee rate untuk transaksi melonjak drastis. Fitur RBF diaktifkan dan bisa saja di increase fee-nya, namun saya lihat fee rate saat ini untuk yang low saja sudah sekitar 135 sat/byte

Kemudian pada History, transaksi tersebut berubah yang tadinya tertera tulisan Unconfirmed menjadi Local, dan ada opsi untuk Remove atau mem-broadcast kembali transaksi ketika meng-klik Details.



Tadi sempat baca-baca ini juga:
https://www.reddit.com/r/Electrum/comments/9wkfve/dust_cant_confirm_status_local_any_suggestions_i/

[abhiseshakana]

Kemudian pada History, transaksi tersebut berubah yang tadinya tertera tulisan Unconfirmed menjadi Local, dan ada opsi untuk Remove atau mem-broadcast kembali transaksi ketika meng-klik Details.

Setau saya transaksi pada wallet Electrum yang dari Unconfirmed tiba-tiba menjadi Local, karena transaksi tersebut sudah tidak dikenali lagi oleh Server Electrum yang terhubung dengan wallet milik agan atau dengan kata lain Transaksi tersebut sudah di Drop dari MemPool Server yg terkoneksi tersebut.

Jika dicek di Blockchain explorer transaksi tersebut masih ada, berarti masih ada node yang memiliki MemPool berisi transaksi tersebut, tetapi jika dicek di Blockchain explorer transaksi tersebut tidak ada, berarti Transaksi tersebut sudah didrop dari MemPool milik node-node lainnya.

[Husna QA]

Jika dicek di Blockchain explorer transaksi tersebut masih ada, berarti masih ada node yang memiliki MemPool berisi transaksi tersebut, tetapi jika dicek di Blockchain explorer transaksi tersebut tidak ada, berarti Transaksi tersebut sudah didrop dari MemPool milik node-node lainnya.

Tadi sempat di cek juga melalui blockstream.info statusnya Transaction not found, tapi ketika di cek di blockchain.com statusnya masih di Mempool, jadinya tadi sempat ragu untuk memilih Remove transaksi;
Dan barusan saya buka lagi history di Electrum, status Local nya berubah lagi menjadi Unconfirmed, saya coba pilih Increase fee untuk menambah fee-nya.

[joniboini]

Mungkin transaksinya ke broadcast lagi karena client om Husna connect ke server yang berbeda. Apakah udah terkonfirmasi saat ini om transaksinya? Atau setelah rebroadcast/increase fee ke drop lagi?

[Husna QA]

Bisa jadi demikian setelah beberapa menit transaksinya connect lagi, karena di settingan Network, saya memilih Select server automatically. Sebenarnya tidak terlalu buru-buru juga sih, hanya karena tadi sempat berubah jadi Local, maka tadi saya coba increase fee ; status di ETA: 0.96 vMB from tip. Jika nanti masih stuck juga kemungkinan fee nya ditambah lagi secara bertahap.

[BITCOIN4X]

Karena ini masih berhubungan dengan Electrum wallet maka ane mau bertanya tentang fitur pada wallet Electrum yang ane gunakan saat ini.

Code:

Spend Uncomfirmed: YES
Use Uncomfirmed Coins In Transaction

Ane sudah pernah lihat sebelumnya peserta Signature Campaign memindahkan bitcoin dari bayaran Signature saat txid nya belum mendapatkan konfirmasi blok. Nah ane mau tanya apakah agan pernah melakukan hal yang sama dengan mengirimkan sejumlah bitcoin yang agan terima (belum dikonfirmasi) ke wallet lainnya tetapi mendapatkan konfirmasi blok meskipun txid sebelumnya belum dikonfirmasi ?

Mungkin agan-agan pernah melakukannya, jadi ane ingin tahu apakah transaksi itu mendapatkan konfirmasi atau tidak, soalnya kemaren lupa ane periksa txid tersebut.

Kondisi yang ane tahu:
1. Wallet X menerima sejumlah bitcoin namun belum mendapatkan konfirmasi.
2. Saldo bitcoin telah muncul di wallet.
3. Mengirimkan bitcoin yang belum mendapatkan konfirmasi ke wallet lain.

[Husna QA]

-snip-

Dari yang saya pahami dan saya ketahui:
1. Wallet x menerima sejumlah Bitcoin dan memunculkannya di wallet, itu statusnya belum final selama belum mendapat konfirmasi sama sekali, dan status ini berlaku juga bagi si pengirim, contoh status "Not Final" ini bisa dilihat juga ketika menggunakan Trezor suite.
https://blog.trezor.io/fixing-bitcoin-transaction-problems-using-rbf-23dca3d26746

2. Saldo Bitcoin yang muncul di wallet penerima (namun belum terkonfirmasi) tersebut, jumlah dan TX ID nya bisa saja berubah ketika si pengirim menggantinya dengan menggunakan RBF, atau bahkan jumlah yang terlihat tersebut hilang ketika pengirim menggunakan fitur Cancel (double-spend) untuk mengirim balik sejumlah aset tersebut ke wallet nya.

3. Untuk poin yang ke-3 ini, barusan saya coba menggunakan Electrum versi testnet.
Bisa melakukan transaksi dengan mengirim sejumlah aset yang masuk dan belum terkonfirmasi. Tentunya transaksi yang "ke-2" ini urutan transaksinya terjadi jika pada transaksi penerimaan aset yang masuk sebelumnya tersebut sudah dikonfirmasi (dan tidak ada perubahan semisal pengirim pertama melakukan Cancel (double-spend)).

- Pertama saya mengirim sejumlah aset menggunakan Bitcoin Core Testet
https://blockstream.info/testnet/tx/37817d9ff7e71be2bf031e3c58da1458854478849fba3c5d231c7676c539d079

- Di Electrum, aset sudah dimunculkan dengan status Unconfirmed.



- Saya coba kirim balik ke address lainnya yang ada di wallet Bitcoin Core
https://blockstream.info/testnet/tx/21964d98a599ff4e7fee13243d18167af3e8d7f12a57f6d777afac0f27d7f289
Dan untuk transaksi yang ke-2 ini statusnya : Unconfirmed parent



- Ketika Transaksi pertama mendapatkan konfirmasi (minimal 1 konfirmasi), maka Transaksi ke-2 juga otomatis dijalankan, sebagaimana nampak pada screenshot berikut:

[joniboini]

Mungkin agan-agan pernah melakukannya, jadi ane ingin tahu apakah transaksi itu mendapatkan konfirmasi atau tidak, soalnya kemaren lupa ane periksa txid tersebut.

Ane sudah sering melakukan hal ini ketika masih ikut Chipmixer, dan ga ada masalah (dengan konteks yang sama). Cepat atau tidaknya konfirmasinya datang tergantung fee yang agan set sendiri. Seringkali antara tx 1 dan tx 2 (yang bergantung dari input tx 2) terkonfirmasi di waktu yang sama, karena feenya emang ane set mirip/sesuai kondisi mempool.

[BITCOIN4X]

~snip

Berarti selama TX nya tidak berubah sampai terkonfirmasi maka TX kedua ini akan berhasil juga. Kalau TX pertama berubah atau dibatalkan oleh fitur double spend maka secara otomatis TX kedua akan gagal. Baik Om, ane ngerti sekarang dan terimakasih juga karena sudah mau mengujinya Om.

~snip

Baik Om, sekali lagi hal ini juga akan dipengaruhi oleh TX pertama. Seperti yang dijelaskan oleh @Husna QA, selama TX pertama tidak berubah atau diganti dengan TX baru menggunakan fitur Cancel Double Spend maka TX kedua akan dikonfirmasi yang kecepatannya tergantung pada fee yang digunakan pengirim.

[Husna QA]

-snip- selama TX pertama tidak berubah atau diganti dengan TX baru menggunakan fitur Cancel Double Spend maka TX kedua akan dikonfirmasi yang kecepatannya tergantung pada fee yang digunakan pengirim.

Bahkan jika menggunakan fee transaksi yang sama/hampir setara, bisa saja ketika TX pertama mendapat 1 konfirmasi, maka TX kedua mendapatkan konfirmasi yang sama, dan bisa saja kedua TX tersebut disertakan pada block yang sama; Sebagaimana contoh transaksi yang saya buat sebelumnya di atas, jika di periksa keduanya disertakan pada block yang sama.

Code:

00000000000000038ea6fb57d9834a6ee345fa4745c854ae517d7b316f2cfed0

Code:

https://blockstream.info/testnet/tx/37817d9ff7e71be2bf031e3c58da1458854478849fba3c5d231c7676c539d079

Code:

https://blockstream.info/testnet/tx/21964d98a599ff4e7fee13243d18167af3e8d7f12a57f6d777afac0f27d7f289

[joniboini]

Berarti selama TX nya tidak berubah sampai terkonfirmasi maka TX kedua ini akan berhasil juga. Kalau TX pertama berubah atau dibatalkan oleh fitur double spend maka secara otomatis TX kedua akan gagal. Baik Om, ane ngerti sekarang dan terimakasih juga karena sudah mau mengujinya Om.

Selama fee tx kedua ga terlalu kecil aja, karena bisa jadi didrop dari mempool meskipun dipublish di waktu yang hampir bersamaan.

Bahkan jika menggunakan fee transaksi yang sama/hampir setara, bisa saja ketika TX pertama mendapat 1 konfirmasi, maka TX kedua mendapatkan konfirmasi yang sama, dan bisa saja kedua TX tersebut disertakan pada block yang sama

Kecuali misalnya ada banyak sekali transaksi yang punya fee yang sama, misalnya dalam kasus 5 block berikutnya punya median 1 sats/vbyte, maka waktu publikasi tx juga berpengaruh. Jadi kalaupun ga langsung ke confirm meski feenya mirip ga perlu terlalu panik nantinya.

[BITCOIN4X]

Bahkan jika menggunakan fee transaksi yang sama/hampir setara, bisa saja ketika TX pertama mendapat 1 konfirmasi, maka TX kedua mendapatkan konfirmasi yang sama, dan bisa saja kedua TX tersebut disertakan pada block yang sama; Sebagaimana contoh transaksi yang saya buat sebelumnya di atas, jika di periksa keduanya disertakan pada block yang sama.

Mungkin cuma work di testnet saja Om dan tidak work di transaksi realnya. Tapi tidak apa-apa Om, besok rencananya mau coba langsung saja di real transaksi saat TX belum di konfirmasi dan juga menggunakan fee yang sama dengan TX pertama. Semoga saja tidak ada masalah.

~snip

Baik Om, besok rencananya kalau sempat mau test langsung saja dengan fee yang sama.

[Chikito]

Mungkin cuma work di testnet saja Om dan tidak work di transaksi realnya. Tapi tidak apa-apa Om, besok rencananya mau coba langsung saja di real transaksi saat TX belum di konfirmasi dan juga menggunakan fee yang sama dengan TX pertama. Semoga saja tidak ada masalah.

Testnet dibuat sama dengan aslinya memang untuk uji coba, jadi kalaupun ada beda, tipis. akan tapi karena jaringan testnet sedikit, jadi walaupun pakai fee sama dengan real tentu akan cepat terkonfirmasi di jaringan testnet.

besok rencananya mau coba langsung saja di real transaksi saat TX belum di konfirmasi dan juga menggunakan fee yang sama dengan TX pertama. Semoga saja tidak ada masalah.

mungkin baiknya kau coba juga Child Pays For Parent (CPFP), jika TX belum terkonfimasi, input (dalam hal ini kamu sendiri) yang increase fee sehingga cepat terkonfirmasi. Ini pernah saya coba beberapa waktu lalu, karena manager pakai fee kecil dan belum terkonfirmasi, jadi saya sebagai penerima yang nambah fee supaya cepat terkonfirmasi.

[abhiseshakana]

Baik Om, besok rencananya kalau sempat mau test langsung saja dengan fee yang sama.

Lebih baik nilai fee-nya disesuaikan dengan rekomendasi fee saat akan melakukan transaksi (tinggal dipilih mau yang wait 1 block, 2 block, 6 block atau waktu yg lebih lama lagi)
https://bitcoinfees.earn.com/

Tapi klo memang ingin mencobanya ya gpp, asal jangan lupa untuk mengaktifkan fitur RBF.

Testnet dibuat sama dengan aslinya memang untuk uji coba, jadi kalaupun ada beda, tipis. akan tapi karena jaringan testnet sedikit, jadi walaupun pakai fee sama dengan real tentu akan cepat terkonfirmasi di jaringan testnet.

Selain karena jumlah transaksi yang ada di jaringan Testnet lebih sedikit, difficulty mining testnet juga tidak sama dengan diff mainet (jauh lebih kecil) sehingga average block time testnet jauh lebih cepat daripada mainnet, sehingga meskipun cuma menggunakan fee 1 satoshi/byte transaksi pada jaringan testnet masih akan cepat terkonfirmasi.

[Husna QA]

Mungkin cuma work di testnet saja Om dan tidak work di transaksi realnya. Tapi tidak apa-apa Om, besok rencananya mau coba langsung saja di real transaksi saat TX belum di konfirmasi dan juga menggunakan fee yang sama dengan TX pertama. Semoga saja tidak ada masalah.

Baik di testnet maupun di mainnet bisa saja terjadi om, itu tergantung juga dari kepadatan transaksi dijaringan blockchain-nya; Karena transaksi di jaringan testnet Bitcoin saat ini tidak seramai transaksi yang terjadi di mainnet, maka TX 1 dan TX 2 dikonfirmasi dalam waktu yang sama dan bahkan berada di block yang sama lebih berpeluang terjadi.

[Husna QA]

Akhir Maret 2021 lalu Electrum merilis kembali update terbaru Versi 4.1.0 (Kangaroo). Rilis kali ini merupakan major release kedua yang cukup penting sejak Electrum mensupport Lightning Network.
Berikut ini catatan rilisnya:

# Release 4.1.0 - Kangaroo (March 30, 2021)

This version is our second major release with support for the
Lightning Network. While our initial Lightning release was mostly
about implementing the protocol, this release brings features that are
specifically aimed at keeping Electrum lightweight and trustless,
while avoiding single points of failure. Most of the features listed
below are user-visible.
 * The wallet creation wizard no longer asks for a seed type, and
   creates segwit wallets with bech32 addresses. Older seed types can
   still be created with the command line.
 * Paid invoices (both incoming and outgoing) are automatically
   removed from the send/receive lists of the GUI (one confirmation is
   needed for onchain invoices). Once removed from the list, invoice
   details can still be accessed from the transaction history. In Qt,
   invoice lists have been renamed to 'Sending queue' and 'Receiving
   queue'.
 * Lightning:
    - recoverable channels (see below)
    - trampoline payments (see below)
    - support multi-part-payment
    - support upfront-shutdown-script
 * Recoverable channels (option):
   - Recovery data is added to the channel funding transaction using
     an OP_RETURN. This makes it possible to recover a static backup
     of the channel from the wallet seed. Please note that static
     backups only allow users to request a force-close of the channel
     with the remote node, so that funds not locked in HTLCs can be
     recovered. This assumes that the remote node is still online, did
     not lose its data, and accepts to force close the channel.
   - This option is only available for standard wallets with an
     Electrum seed. It is not available for hardware wallets, because
     it requires a deterministic derivation of the nodeID. It is also
     not available in watching-only wallets, for the same reason. If a
     wallet can have recoverable channels but has an old nodeID, users
     who want to use that feature need to close all their existing
     channels, and to restore their wallet from seed.
   - Channel recovery data uses 20 bytes (16 bytes of the remote
     NodeID plus 4 magic bytes) and is encrypted so that only the
     wallet that owns it can decrypt it. However, blockchain analysis
     will be able to tell that the transaction was probably created by
     Electrum.
   - If the 'use recoverable channels' option is enabled, other nodes
     cannot open a channel to Electrum.
   - If a channel is force-closed, the information in the on-chain
     backup is not sufficient to retrieve the funds in the to_local
     output, in case the wallet is lost in a boating accident before
     expiration of the CSV delay. For that reason, an additional
     backup is presented to the user if they force-close a channel.
 * Trampoline routing (option): Trampoline is a solution that allows
   light clients to delegate path-finding on the Lightning Network, so
   that they do not have to download the entire network
   graph. Trampoline routing was originally proposed by Bastien
   Teinturier and is used in the Phoenix wallet. Here is how
   Trampoline works in Electrum:
   - Trampoline is enabled by default, in order to prevent unwanted
     download of the network gossip. If trampoline is disabled, the
     gossip will be downloaded, regardless of the existence of
     channels.
   - Because there is no discovery mechanism for trampoline nodes, the
     list of available trampolines is hardcoded in the client (it will
     remain so until support for trampoline routing is announced in
     gossip). 3 trampoline nodes are currently available on mainnet:
     ACINQ, Electrum and Hodlister.
   - If Trampoline is enabled:
      - payments use trampoline routing.
      - gossip is disabled.
      - the wallet can only open channels with trampoline nodes.
      - pre-existing channels with non-trampoline nodes are frozen for
        sending.
   - There are two types of trampoline payments: legacy and trampoline
     end-to-end. Legacy payments are possible with any receiver, but
     they offer less privacy than end-to-end trampoline
     payments. Electrum decides whether to perform legacy or
     end-to-end based on the features in the invoice:
       - OPTION_TRAMPOLINE_ROUTING_OPT (bit 25) for Electrum
       - OPTION_TRAMPOLINE_ROUTING_OPT_ECLAIR (bit 51) for Eclair/Phoenix
   - When performing a legacy payment, Electrum will add a second
     trampoline node to the route in order to protect the privacy of
     the payer and payee. It will fall back to a single trampoline if
     the two-trampoline strategy has failed for all trampolines.
     (Note: two-trampoline payments are currently not possible if the
     first trampoline is the ACINQ node, and is disabled for that
     node.)
   - Similar to Phoenix, the fee and CLTV delay are found by
     trial-and-error. If there is a second trampoline in the route, we
     use the same fee/CLTV for both. This trial-and-error is
     temporary; the final specification should add fee information in
     the failure messages, so that we will be able to better fine-tune
     trampoline fees.
 * Qt: The increase fee dialog now has advanced options, and offers
   the choice between different RBF strategies.
 * Watchtowers: The 'use_local_watchtower' feature is deprecated, and
   it has been removed from the Qt GUI. The 'use_remote_watchtower'
   setting has been renamed to 'use_watchtower'.
 * Password unification (Android only): When the Android app is
   started, the entered password is checked against all wallets in
   the directory. If the test passes:
    - all wallets are encrypted
    - new wallets will use the unified password
    - password updates are performed on all wallets
   Whether the password is unified can be seen in the GUI: In the
   'Settings' dialog, the description for the password setting is
   'Change password for this wallet' if the password is not unified,
   and becomes 'Change password' if password is unified.
 * Submarine swaps are now available on kivy/android.
 * Android PIN reset: If the password is unified, the PIN can be reset
   by providing the password.
 * Android: on-chain fees have been removed from the settings
   dialog. Instead, the fee slider is shown to the user everytime an
   on-chain transaction will be performed (sending a payment, opening
   a channel, initiating a submarine swap)
 * BIP-0350: use bech32m for witness version 1+ addresses (4315fa43).
   We have supported sending to any witness version since Electrum
   3.0, using BIP-0173 (bech32) addresses. BIP-0350 makes a breaking
   change in address encoding, and recommends using a new encoding
   (bech32m) for sending to witness version 1 and later.
 * Block explorer: allow setting a custom URL in Qt GUI (#6965)

Note:
Pastikan downloadnya dari official website:
https://electrum.org/#download  ;  https://download.electrum.org/4.1.0/

Pastikan juga verifikasi GPG Signature sesuai dengan public key ataupun fingerprint ThomasV:
https://raw.githubusercontent.com/spesmilo/electrum/master/pubkeys/ThomasV.asc

[joniboini]

Bagian restorasi wallet lama yang perlu pake command line ane rasa bisa jadi sedikit masalah buat user lama yang ga begitu hobi ngutak-ngatik program. Tapi mestinya ga terlalu sulit, walau bakal lebih enak lagi kalau ada UInya langsung. Tapi dari diskusi di thread luar nampaknya seed yang dibuat di versi terbaru ini masih belum BIP39 compatible. Semoga pada tahu hal ini sebelum bikin seed baru.